Chapter Three

Requirements Engineering Process

 Contents
What is process?
Requirement Engineering process
Feasibility study
Requirements elicitation
Requirements analysis
Requirements specification
System modeling
Requirements validation &Verification
Requirements management
Actors in Requirements engineering process
Process support
 What is process?
A process is an organized set of activities which
transforms inputs to outputs
Once someone has worked out how to solve a problem,
they can document the way in which that solution was
derived as a process.
Process descriptions (should be as complete,
consistent & clear) encapsulate knowledge and allow
it to be reused
Examples of process descriptions
Instruction manual for a dishwasher
Cookery book
Procedures manual for a bank
Quality manual for software development
Requirements Engineering Processes
Processes used to discover, analyse and validate
system requirements
 Five distinct steps of R.E process
Feasibility study
Requirements elicitation
Requirements analysis
Requirements specification
System modeling
Requirements validation &Verification
Requirements management
 Feasibility Study….
 Feasibility study leads to a decision:
go ahead
do not go ahead
think again
 In research, feasibility study is often in the form of a proposal.
 A feasibility study decides whether not the proposed system is
worthwhile.
 It is a short focused study that checks
If the system contributes to organizational objectives or not;
If the system can be engineered using current technology and within
budget or not ;
If the system can be integrated with other systems that are used or not;
Feasibility Report….
Based on information assessment (what is required),information
collection, Feasibility report writing will be carried over…..
 Requirements Elicitation
 Is the process through which the customer and developer discover,
review, articulate, and understand the users needs and constraints on
the software and development activities.
 RE is about discovering what requirements a system should be based
upon.
 This doesn’t involve just stakeholders what they want.
 It Requires a careful analysis of:
 The organization
 The application domain
 Organization process where the system will be used to determine what the
stakeholders need.
 It certainly seems simple enough to ask the customer, the users,
and others
What the objectives of the system are….?
What is to be accomplished…?
How the system or product fits into the needs of the business and
Finally, how the system or product is to be used on a day-to-day
 Where do Requirements come from?
 Stakeholders
 Business Processes
 Organizational Policies and Procedures
Organization Standards
Protocols
Technical Standards
 Existing Automated Systems
User Manuals
 Data Samples
 Interface Descriptions
 Sample Reports
 Sample Screens
 Where do Requirements come from?
 Stakeholders
 Business Processes
 Organizational Policies and Procedures
Organization Standards
Protocols
Technical Standards
 Existing Automated Systems
User Manuals
 Data Samples
 Interface Descriptions
 Sample Reports
 Sample Screens
Where do Requirements come from….?
Identify stakeholders by asking questions
Who will use the product?
Who will provide the inputs?
Who will get the outputs?
Who has an oversight role?
Who has a related role?
Who will be rewarded?
Who will be penalized?
Techniques to elicit Requirements to bridge the gap between
end user and the Developer
1.INTERVIEWS
2.QUESTIONAAIRES
3.LITERATURE REVIEW
4.ON-SITE OBSERVATIONS
5.BRAIN STORMING etc…
 Requirements Analysis

Focus on: “what” instead of “how”

Who does Analysis.? System Analyst
Analysis & Negotiation
 Requirements Specification
Def: The development of a document or set of documents
that clearly and precisely records each of the requirements
of the software system.
A specification can be
a written document,
a graphical model,
a formal mathematical model,
a collection of usage scenarios, a prototype, or any
combination of these.
 Requirements Specification…..
The customer requirements identified during the
requirements gathering and analysis activity are organized
into a SRS document.
Customer and developer can check the quality of the
software and provide the feedback.
Important components of SRS document are
Functional requirements
Non-functional requirements and
Goals of implementation.
 Requirements Validation
The process of ensuring that the requirement
specification is in compliance with the user needs,
system requirements , confirms to document standards,
and is a adequate basis for the architectural design.
Work products produced as a consequence of
requirements engineering are assessed for quality
during a validation step.
Checking whether the requirements are
consistent with the overall objectives of the
system.
Concerned with demonstrating that the
requirements define the system that the
customer really wants.
 Requirements Management
Def: The planning and controlling of the
requirements elicitation, specification, analysis, and
verification process.
Requirements management is a set of activities that
help the project team to Identify, Control &Track
requirements and Changes to requirements at any
time as the project proceeds.
[Configuration Management]
 Requirement Engineering process
…
 Requirement Engineering process...
…
For Library information System(LIS) the following are
example requirements for inputs
Existing System information
The LIS shall poll the bar code reader system and
process all of the transaction requests every two
seconds
Stakeholder needs
The system should provide a help facility which will
explain the facilities of the system to new user. This
help facility should be accessible from all user
interface screens
Organizational standards
The system shall run on a Sun server running the
Solaris 2.0 operating system
Contd….
Regulations
The system shall include a facility to a print all of the
personnel information which is maintained for a library
user
Domain information
Books are uniquely identified by an international
Standard Book Number which is a 10 digit identifier
Actors in 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 are process models which show
the actors associated with different process activities
 Actors in RE process...

Role Action Diagram (RAD) for software prototyping

 Actors in RE process...

Human and social factors

RE processes are dominated by human, social and organizational factors
because they always involve a range of stakeholders from different
backgrounds and with different individual and organizational goals.
System stakeholders may come from a range of technical and non-
technical background and from different disciplines
 Process support
CASE tools provide automated support for software
engineering processes
CASE tools increase productivity (not though the
scale predicted) and product quality
The most mature CASE tools support well understood
activities such as programming and testing and the use
of structured methods
Support for requirements engineering is still limited
because of the informality and the variability of the
process
Some companies have developed their own tools
which are directed towards their own RE process
 Process support...
There are two types of tools which are available to support
the requirement engineering process
Modeling and validation tools
support the development of system models which can
be used to specify the system and the checking of these
models for completeness and consistency.
Management tools
Help to manage a database of requirements and support
the management of changes to these requirements.
 are developed to alleviate the problem of large
amount of data collected in RE process & variability of
reqs.
 Process support...
Management tools (cont’d)
Examples: RequisitPro, DOORS, RML, …..
RMtools provide a range of facilities to access
the information about the requirements.
Requirements browser
Requirements query system
Traceability support system
Report generator
Reqs. converter and word processor linker
Change control system
Checkon:http://makingofsoftware.com/resources/list-of-
rm-tools
 Process support...

A requirements management system

 Reading assignment
Process Models
 Types of process model include:
Coarse-grain activity models
 Fine-grain activity models
 Role-action models
 Entity-relation models

Process Improvement
Process Maturity
Level 1 - Initial (Chaotic)
Level 2 – Repeatable
Level 3 – Defined
Level 4 – Managed
Level 5 – Optimizing
 Process Improvement
is concerned with modifying processes in order to meet some
improvement objectives
Improvement objectives
Quality improvement – fewer errors, more complete, better reflect
real needs, etc
Schedule reduction – output produced more quickly
Resource reduction- fewer resourses needed to enact the process
Planning process improvement
What are the problems with current processes?
What are the improvement goals?
How can process improvement be introduced to achieve these
goals?
How should process improvements be controlled and managed?
RE process problems
Lack of stakeholder involvement
Business needs not considered
Lack of requirements management
Lack of defined responsibilities
Stakeholder communication problems
Over-long schedules and poor quality requirements
documents
There is no standard set of process improvement which
should be introduced nor is there a standard requirement
engineering process which all organizations should be
aiming to.
Rather, the appropriate improvement depend on the type
of organization and the organizational culture
 Process maturity
Process maturity can be thought of as the extent that an
organization has defined its processes, actively controls these
processes and provides systematic human and computer-based
support for them.
An organization which has defined a set of standards for
processes and provide tool support for these standards is
more mature than an organization with only informal
process definition.
The Capability Maturity Model (CMM) is a framework for
assessing software process maturity in development
organizations
The basic idea underlying the CMM approach is that
organizations should asses their maturity then introduce
process changes which will enable them to progress up the
maturity ‘ladder’ in a five stage process.
 Process maturity…
….

Process Capability Maturity Model

 Process maturity…
Level 1 - Initial (Chaotic)
have undocumented and undisciplined process , the
environment for the processes is chaotic or unstable
Level 2 – Repeatable
Have basic cost and schedule management procedures
in the and processes are repeatable, possibly with
consistent results
Level 3 – Defined
processes at this level are sets of defined and
documented standard processes established and subject to
some degree of improvement over time.
Level 4 – Managed
Detailed measurements of both process and product
quality are collected and used to control the process
 RE process Maturity Model
Level 5 – Optimizing
has a continuous process improvement strategy
Requirement engineering process maturity is extent to
which an organization has defined requirement
engineering process based on good requirement
engineering practice.
An organization with a mature RE process
will have this process explicitly defined.
Will use appropriate methods and techniques
Will have defined standards for requirement
documents, requirement descriptions, etc
Will have used automated tools to support the process
 Will have management policies and procedures in
place to ensure that the process is followed
May use process measurements to collect
information about the process to help assess the
value of process changes.
The CMM is mostly concerned with the management
of software development process and doesn’t cover
RE process.
A comparable model of RE process maturity is
discussed by Sommerville & Swayer, 1997.
The requirement process maturity model is three-
level model
Level 1: Initial Level
Do not have a defined RE process & often suffer
from requirements problems such as excessive
requirements volatility, unsatisfied stakeholders &
large rework costs when requirements change.
They do not use advanced methods to support
their requirements engineering process.
They often fail to produce good quality
requirement documents on time & within budget.
The requirements are dependent on the skills and
the skills and experience of individual engineers
for requirements elicitation, analysis & validation.
Level 2: Repeatable level
Have defined standards for requirements documents
and requirements descriptions and have introduced
policies and procedures for requirements management.
They may use some advanced tools and techniques in
their RE process
Their requirements documents are likely to be of a
consistent high quality and to produced on schedule.
Level 3: Defined level
Have a defined requirements engineers process model
based on good practice and techniques.
They have an active process improvement programme
in place and can make objective assessments of the
value of new methods & techniques
 Good practice for RE process improvement
RE processes can be improved by the systematic
introduction of good requirements engineering
practice
Each improvement cycle identifies good practice
guidelines and works to introduce them in an
organization
Examples of good practice guidelines
Define a standard document structure (initial)
Uniquely identify each requirement (initial)
Define policies for requirements management
(initial)
Contd..

Use checklists for requirements analysis (initial)

Use scenarios to elicit requirements (Repeatable)
Specify requirements quantitatively (Repeatable)
Use prototyping to animate requirements
(Repeatable)
Reuse requirements (Defined)
Specify systems using formal specification
(Defined)