Requirements Engineering

Process
 Requirements engineering process
• The structured set of activities involved in developing system
requirements
• Process activities include requirements elicitation, requirements
analysis and negotiation, requirements specification,
requirements validation and requirements management
• A complete process description should include
– what activities are carried out,
– the structuring or scheduling of these activities,
– who is responsible for each activity,
– the inputs and outputs to/ from the activity and
– the tools used to support requirements engineering
Requirements Engineering Process
 RE process activities
• Requirements elicitation
– Requirements discovered through consultation with stakeholders
• Requirements analysis and negotiation
– Requirements are analysed and conflicts resolved through
negotiation
• Requirements documentation
– A requirements document is produced
• Requirements validation
– The requirements document is checked for consistency and
completeness
• Requirement management
– Concerned with managing changes to the requirements
 Requirements Elicitation
• Elicitation encompasses all of the activities involved with
discovering requirements, such as interviews, workshops,
document analysis, prototyping, and others.
• The principle activities are:
1. Identifying the product’s expected user classes and other
stakeholders.
2. Understanding user tasks and goals and the business
objectives with which those tasks align.
3. Learning about the environment in which the new
product will be used.
4. Working with individuals who represent each user class to
understand their functionality needs and their quality
expectations.
 Requirements Analysis
Analyzing requirements involves reaching a richer and more
precise understanding of each requirement.
Requirements are analysed and conflicts resolved through
negotiation
 Requirements Analysis
Principle Activities
1. Analyzing the information received from users to distinguish their
task goals from functional requirements, quality expectations,
business rules, suggested solutions, and other information
2. Decomposing high-level requirements into an appropriate level of
detail
3. Deriving functional requirements from other requirements
information
4. Understanding the relative importance of quality attributes
5. Classifying requirements into clusters
6. Negotiating implementation priorities
7. Identifying gaps in requirements or unnecessary requirements as
they relate to the defined scope
 Requirement Specification
• Requirements specification involves representing and
storing the collected requirements knowledge in a
persistent and well-organized fashion.
• The principal activity is:
1. Translating the collected user needs into written
requirements and diagrams suitable for
comprehension, review, and use by their intended
audiences.
 Requirements Validation
• Requirements validation confirms that you have the
correct set of requirements information that will
enable developers to build a solution that satisfies the
business objectives.
• The central activities are:
1. Reviewing the documented requirements to correct
any problems before the development group accepts
them.
2. Developing acceptance tests and criteria to confirm
that a product based on the requirements would
meet customer needs and achieve the business
objectives
Requirements development is an
iterative process
 Requirements management
• Requirements management activities include the following:
1. Defining the requirements baseline,
▪ a snapshot in time that represents an agreed-upon,
reviewed, and approved set of functional and
nonfunctional requirements, often for a specific
product release or development iteration
2. Evaluating the impact of proposed requirements changes
and incorporating approved changes into the project in a
controlled way
3. Keeping project plans up-to-date with the requirements
as they evolve
 Requirements management
4. Negotiating new commitments based on the
estimated impact of requirements changes
5. Defining the relationships and dependencies
that exist between requirements
6. Tracing individual requirements to their
corresponding designs, source code, and
tests
7. Tracking requirements status and change
activity throughout the project
 Unforeseen ripple effect (side effect)
Module C
Module B
Module A This module is
dependent on
You make a the parts of the
change only in code from Module D
this module module A which
and suddenly you have just
Hardware you cannot use taken away.

User manual
Requirement Design Instructions to the
Specification users are no
Specification longer
Due to your change Due to your change
the requirements valid
the design no
no longer are valid longer is valid

A change to one part of a program may affect other sections in an

unpredictable fashion, thereby leading to a distortion in the logic of the
system.
13
 Traceability
User
Manual

…………….
Requirements …………… Regression Test
Specification Case
……………. SpecificationTest
…………… Case
……………… Specification

…………….
Change ……………
Request Regression Test
Design …
…………… Case
Specification
Specification Test
……………. Case
…………… Specification
………………
…………….
……………
SoftwareCode Regression Test
Case
…………….
SoftwareCode Specification Test
Case
……………
Documentation
Specification
………………
……………. …………….
……………
……………

Traceability Traceablilityof change

The boundary between requirements development and
requirements management
Inputs and outputs for RE Process
Existing
systems
information

Stakeholder Agreed
needs requirements

Requirements System
Organisational engineering process
standards specification

System
Regulations models

Domain
information
 input/output description
Input o r output Type Des cri pti on
Existing system Input Information about the functionality of systems to be replaced or
information other systems which interact with the system being specified
Stakeholder needs Input Descriptions of what system stakeholders need from the system to
support their work
Organisational Input Standards used in an organisation regarding system development
standards practice, quality management, etc.
Regulations Input External regulations such as health and safety regulations which
apply to the system.
Domain information Input General information about the application domain of the system
Agreed requirements Output A description of the system requirements which is understandable
by stakeholders and which has been agreed by them
System Output This is a more detailed specification of the system functionality
specification which may be produced in some cases
System models Output A set of models such as a data-flow model. an object model, a
process model, etc. which describes the system from different
perspectives

The LIS shall communicate with the bar code reader system and process transaction requests

The system should provide a help facility which will explain the facilities of the system to new users.

The system shall run on a Sun server running the Solaris 2.0 operating system

The system shall include a facility to print all of the personal information which is maintained for a library user.
Books are uniquely identified by an international standard book number which is a 10 digit identifier
 RE process variability
• RE processes vary radically from one organisation to another
– Factors contributing to this variability include
– Technical maturity
• The technology and methods used for requirements engineering vary
from one organization to another
– Disciplinary involvement
• The types of engineering and managerial disciplines involved in
requirements engineering vary from one organization to another
– Organisational culture
• The culture has an important effect on all processes , as the culture varies,
so does the requirements engineering process
– Application domain
• Different types of application domains have different types of
requirements engineering process

There is therefore no ‘ideal’ requirements engineering process

 Actors in the RE process
• Actors in a process are the people involved in the
execution of that process
• Actors are normally identified by their roles rather
than individually
• Requirements engineering involves actors who are
primarily interested in the problem to be solved
(end-users, etc) as well actors interested in the
solution (system designers, etc.)
• Role-action diagrams document which actors are
involved in different activities
 RAD for software prototyping

ACTIONS

Establish Select Develop Evaluate

Understand prototyping
problem outline prototype prototype
requirements system

Req. engineer Software Req. engineer End-user

Req. engineer engineer Domain expert
Domain expert End-user Software
End-user Project manager engineer Req. engineer
Software engineer

RO LES
 Role descriptions

Ro l e Des cri pti on

Domain expert Responsible for providing information about the
application domain and the specific problem in that
domain which is to be solved.
System end-user Responsible for using the system after delivery
Requirements engineer Responsible for eliciting and specifying the system
requirements
Software engineer Responsible for developing the prototype software
system
Project manager Responsible for planning and estimating the
prototyping project
 Benefits from a High-Quality
Requirements Process
• Fewer requirements defects
• Reduced development rework
• Fewer unnecessary features
• Lower enhancement costs
• Faster development
• Reduced scope creep
• Reduced project chaos
• More accurate system-testing
• Higher customer and team member satisfaction