First Area [25 Marks]

Introductory part of the requirements engineering:

Elaborate all the components in the development and management part.
Activities within the subcomponents at least three and their explanation plus examples:
Requirements Development:
Identifying the products expected user classes
Eliciting needs from user class
Understanding user tasks, goals and business objectives
Analyzing user information, distinguishing task goals, functional and non-
functional requirements
Transforming user needs to requirements specification
Requirements Management:
Is the establishing and maintaining an agreement with the customer on the
requirements for the software project
The agreement is embodies in the written requirement specification
Req. Mgt. Activities :-
Define requirements baseline
Review proposed changes
Incorporate approved requirements
Keeping project plans
Tracing individual requirements, from design to source code
Tracking requirements status

Full definition of RE:
Requirements Engineering (RE) is a set of activities concerned with identifying and
communicating the purpose of a software intensive system, and the contexts in
which it will be used. Hence, RE acts as the bridge between the real-world needs
of users, customers, and other constituencies affected by a software system, and
the capabilities and opportunities afforded.
Benefits of RE and why do we RE?
Advantages of good requirements:
Fewer requirements defects
Reduced development reworks
Fewer unnecessary features
Lower enhancement costs
Faster development
Fewer miscommunications
Reduced scope creep










Second Area [25 Marks]
(a) Various types of requirements in a computer system, Explanation with examples:
User requirements:
The description of the functions that the system has to fulfil for its environment in
terms of the users interacting with the system, e.g. in the form of use cases
Domain requirements:
Requirements that come from the application domain of the system and that
reflect characteristics of that domain. Requirements other than specific needs of
the user
standard user interfaces to all databases
Because of copyright requirements all documents to be deleted
upon arrival

Functional requirements:
Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.
Non-functional requirements:
constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, Availability,
Security, Reliability, Timeliness, etc.




(b) Natural language has its weaknesses.
Lack of clarity
Precision is difficult without making the document difficult to read
Requirements confusion
Functional and non-functional requirements tend to be mixed-up
Requirements amalgamation
Several different requirements may be expressed together
Therefore, alternatives to natural language:
Structured natural language
Design description languages
Graphical notations
Mathematical specifications
Structured language:
A limited form of natural language may be used to express requirements
This removes some of the problems resulting from ambiguity and flexibility
and imposes a degree of uniformity on a specification







(c) Instances where non-functional requirements are more critical than functional
requirements, state reasons:
If these are not met, the system is useless, for example Safety critical systems

Third Area [25 Marks]
View Points: Multiple perspective or views of a system.
Definition of view point:
Viewpoints are a way of structuring the requirements to represent the
perspectives of different stakeholders. Stakeholders may be classified
under different viewpoints.
This multi-perspective analysis is important as there is no single correct
way to analyse system requirements
Different types of viewpoints implemented on a system, hospital:
Interactor viewpoints
People or other systems that interact directly with the system. In an ATM, the
customers and the account database are interactor VPs.
Indirect viewpoints
Stakeholders who do not use the system themselves but who influence the
requirements. In an ATM, management and security staff are indirect viewpoints.
Domain viewpoints
Domain characteristics and constraints that influence the requirements. In an
ATM, an example would be standards for inter-bank communications.




System requirement.. What the system should do.
Security issues associated with banking system.
Encryption, higher level management,
From the manager.....security.
Constraints imposed by major domains such as banking systems,
telecommunication industry and etc.

Fourth Area [25 Marks]
Requirements Management:
1. Controlling changes to the requirements baseline
2. Keeping project plans current with the requirements
3. Controlling versions or both individual requirements and requirements
documents
4. Tracking the status of the requirements in the baseline
5. Managing the logical links between individual requirements and other
project work products.

Change controls:
Change control in requirements management is the process by which any changes
needed to the requirements baseline are managed. Whether the change is big
and complex or small and simple they still need to travel the same initial route
into the change control process.


Version control:
Each circulated version of the requirements documents should include a revision
history that identifies the changes made, the date of each change the individual
who made the change.

Requirements Status tracking:
Proposed - requested by an authorized source
Approved has been analyzed, it impact on the project, been estimated and
allocated to the baseline
Implemented code that implements the requirement has been designed,
written and unit tested., and can be traced to the design and code elements.
Verified the correct functioning of the requirement has been confirmed, the
requirement has been traced to test cases
Deleted removal of an approved requirement from the baseline with supporting
explanation
Rejected a proposed requirement but is not planned for implementation with
supporting explanations
Requirements Tractability:
Detect implied legitimate requirements, unexpected functionalities with no
corresponding requirements or orphan code which indicates gold plating.
Unimplemented requirements via test cases derived from and traced back
to requirements.



Discuss five reasons why it is important:
Certification of safety critical products, all requirements are implemented
Change impact analysis avoid overlooking systems elements that would
be affected
Maintenance facilities making changes correctly and completely.
Project tracking - accurate record of implementation status
Reengineering transferring from legacy systems to new systems
Reuse facilitate reusing product components of related requirements
Testing knowing which test relates to which requirements.














Fifth Area [25 Marks]
All the faces of pieces framework:
Performance
o Throughput
o Response Time
Information (and Data)
o Outputs
Lack of any information
Lack of necessary information
Lack of relevant information
Too much information information overload
Information that is not in a useful format
Information that is not accurate
Information that is difficult to produce
Information that is not timely to its subsequent use
o Inputs
Data is not captured
Data is not captured in time to be useful
Data is not accurately captured contains errors
Data is difficult to capture
Data us captured redundantly same data is captured more
than once
Too much data is captured
Illegal data is captured
o Stored Data
Data is stored redundantly in multiple files and/or databases
Stored data is not accurate
Data is not secure from accident or vandalism
Data is not well organized
Data is not flexible not easy to meet new information needs
from stored data
Data is not accessible

Economics
o Costs
Costs are unknown
Costs are untraceable
Costs are too high
o Profits
New markets can be explored
Current marketing can be improved
Control (and Security)
o Too little security or control
Input data is not adequately edited
Crimes (e.g. fraud, embezzlement) are (or can be) committed
against the data
Ethics are breached on data or information refers to data or
information getting to unauthorized people
Redundantly stored data is inconsistent in different files or
databases
Data privacy regulations or guidelines are being (or can be)
violated
Processing errors are occurring (either by people, machines, or
software)
Decision- making errors are occurring
o Too much control or security
Bureaucratic red tape slows the system
Controls inconvenience customers or employees
Excessive controls cause processing delays
Efficiency
o People, machines, or computers waste time
Data is redundantly input or copied
Data is redundantly processed
Information is redundantly generated
o People, machines, or computers waste materials and suppliers
Effort required for tasks is excessive
Materials required for tasks is excessive


Service
o The system produces inaccurate results
o The system produces inconsistent results
o The system produces unreliable results
o The system is not easy to learn
o The system is not easy to use
o The system is awkward to use
o The system is inflexible to new or exceptional situations
o The system is inflexible to change
o The system is incompatible with other systems
o The system is not coordinated with other systems

Feasibility study:
A feasibility study is an analysis of the viability of an idea. The feasibility study
focuses on helping answer the essential question of should we proceed with the
proposed project idea? All activities of the study are directed toward helping
answer this question.
Why does management want to do it?
To determine the viability of their idea before proceeding with the development
of a business. Determining early that a business idea will not work saves time,
money and heartache later.
What type of questions can be asked during this phase?
is there a demand for the produce?
Who else is producing similar products?
What is needed to make the product?
What is the cost of producing aproduct?
What is the likely profit?


Talk about economic, technical feasibility. Comes at the beginning during the
inception stage: