Requirements Engineering

Processes
Objectives
 To introduce the notion of processes
and process models for requirements
engineering
 To explain the critical role of people in
requirements engineering processes
 To explain why process improvement
is important and to suggest a process
improvement model for requirements
engineering
Processes
 A process is an organized set of
activities which transforms inputs to
outputs
 Process descriptions encapsulate
knowledge and allow it to be reused
 Examples of process descriptions
 Instruction manual for a dishwasher
 Cookbook
 Procedures manual for a bank
 Quality manual for software development
Design processes
 Design processes are processes which
involve:
 Creativity,
 Interaction with a wide range of
different people,
 Engineering judgment,
 Background knowledge, and
 Experience
Design processes
 Inputs not precisely defined
 Many possible outputs satisfying
inputs
 Cannot be automated or specified in
detail
 Different people tackle intellectual
tasks in different ways and adapt the
process to suit their own way of
thinking.
Design processes
 Examples of design processes
 Writing a book
 Organizing a conference
 Designing a processor chip
 Requirements engineering
RE process - inputs and outputs
Existing
systems
information

Stakeholder Agreed
needs requirements

Requirements System
Organisational engineering process
standards specification

System
Regulations models

Domain
information
Input/output description
Input or 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
RE process variability
 RE processes vary radically from one
organization to another
 Factors contributing to this variability
include
 Technical maturity
 Disciplinary involvement
 Organizational culture
 Application domain
 There is therefore no ‘ideal’
requirements engineering process
Process models
 A process model is a simplified
description of a process presented
from a particular perspective
 Processes may be defined at different
levels of detail.
 In some cases, processes are defined at a
very fine level of detail
 The steps in the process must be carried
out exactly as described.
Process models
 Different people usually enact a process in
different ways depending on the
background of the people involved and the
particular circumstance in which the
process is enacted.
 The same person will enact the same
process in different ways at different times
 Types of process models include:
 Coarse-grain activity models
 Fine-grain activity models
 Role-action models
 Entity-relation models
 Requirements Engineering Process
Model #1

Requirements Requirements Requirements

analysis and Requirements
elicitation documentation validation
negotiation

User needs
domain Requirements
information, document
Agreed
existing system System requirements
information, specification
regulations,
standards, etc.
RE process activities

 Requirements elicitation
 Requirements discovered through consultation with
stakeholders
 Requirements analysis and negotiation
 Requirements are analyzed and conflicts resolved
through negotiation
 Requirements documentation
 A requirements document is produced
 Requirements validation
 The requirements document is checked for
consistency and completeness
Requirement Engineering Process
 Alan Davis defines requirements
engineering as:
 “all activities up to but not including the
decomposition of the software into its actual
architectural components”
 2nd definition: (focus is on what RE is
rather than what it is not)
 “Investigating and describing the problem
domain and requirements and designing and
documenting the characteristics for a solution
system that will meet those requirements.”
Alternative Requirement
Engineering Process Model
 The following sub-tasks may be
identified:
 Elicitation
 Analysis
 Specification
 Human machine interface (HMI) design
 Validation
Alternative
RE Process
Model
Clarification of the Alternative RE
Model
 Initially, information comes from questions to the
users
 This “raw” information feeds through the elicitation
process and primarily consists of problem domain
information and functional requirements.
 Analysis uncovers more problem domain
understanding which feeds back into and guides the
elicitation process.
 The specification can be done when the analysis is
complete.
 The detailed external design of the HCI (“look and
feel”) is factored out of the specification because if it
is part of the spec., it can mask the essential, logical
behavior of the system.
Outputs of the Alternative RE Model
 Four documents are produced:
 Elicitation notes: not in a structured format, not
passed on from the RE phase, useful for
traceability purposes
 Requirements document (the analysis document):
consists of a precise description of the problem
domain together with the requirements
 Specification: contains a definition of the required
behavior of the solution system; also known as
RS, SRS,RD; forms the basis of the contract
between client and developer
 HMI Design Document: elaborates the details of
the external interfaces of the solution system
(may not always be an interface for humans); will
have some overlap with the specification
What comes next (and what about
Validation?
 The requirements document, the
specification document, and the HCI
specification form the input to the design
phase
 Why does this RE model leave off Validation?
 Validation is an extremely important part of RE,
and is not shown as a separate process because it
permeates the entire process.
 During an elicitation interview, repeat the client’s
statements back to them to check
understanding;
 When the 1st draft of the requirements document
is complete, do a formal review of it; etc.
Software Validation
 Validation attempts to ensure that the correct
functionality for the solution system has been defined.
 Need to validate the entire RE process (and the entire
SWE process as well) to check:
 Is the description of the problem domain an accurate
reflection of its properties?
 Are the requirements (the effects to be produced in
the problem domain) accurately recorded?
 Is the external design correct; will the invented
behavior of the new system produced the required
effects?
 Is the specification an accurate reflection of the
intended external design?
Spiral model of the RE process (3rd
model)
Informal statement of
Decision point: requirements
Accept document
or re-enter spiral

Requirements elicitation Requirements analysis and

negotiation

Requirements START
document and Agreed
validation requirements
report

Requirements validation Requirements documentation

Draft requirements
document
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

Rol 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
Human and social factors
 Requirements engineering 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
Types of stakeholder
 Software engineers responsible for
system development
 System end-users who will use the
system after it has been delivered
 Managers of system end-users who are
responsible for their work
 External regulators who check that the
system meets its legal requirements
 Domain experts who give essential
background information about the
system application domain
Factors influencing
requirements
 Personality and status of stakeholders
 The personal goals of individuals
within an organization
 The degree of political influence of
stakeholders within an organization
Process support
 CASE tools provide automated support
for software engineering processes
 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
CASE tools for RE
 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 manage a
database of requirements and support
the management of changes to these
requirements.
A requirements management
system
Req. query
Req. browser system

NL
requirements Req. convertor Requirements Traceability
document database support system

Traceability
WP linker report
Report generator

Change control Requirements

system report
Requirements management
tools
 Requirements browser
 Requirements query system
 Traceability support system
 Report generator
 Requirements converter and word
processor linker
 Change control system
Requirements Management
Activities
 Defining the requirements baseline (a snapshot in time
representing the current agreed-on body of requirements)
 Reviewing proposed requirements changes and evaluating
the likely impact of each proposed change before deciding
weather to approve it
 Incorporating approved requirements changes into the
project in a controlled way
 Keeping project plans current with the requirements
 Negotiating new commitments based on the estimated
impact of changed requirements
 Tracing individual requirements to their corresponding
designs, source code, and test cases
 Tracking requirements status and change activity
throughout the project
Process improvement
 Process improvement is concerned
with modifying processes in order to
meet some improvement objectives
 Improvement objectives
 Quality improvement
 Schedule reduction
 Resource reduction
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
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.
 The SEI’s Capability Maturity Model is
a framework for assessing software
process maturity in development
organizations
Capability maturity model
Level 5
Optimizing

Le vel 4
Managed

Level 3
Defined

Le vel 2
Repeatable

Level 1
Initial
Maturity levels
 Initial level
 Organizations have an undisciplined process
and it is left to individuals how to manage the
process and which development techniques
to use.
 Repeatable level
 Organizations have basic cost and schedule
management procedures in place. They are
likely to be able to make consistent budget
and schedule predictions for projects in the
same application area.
Maturity levels
 Defined level
 The software process for both management
and engineering activities is documented,
standardized and integrated into a standard
software process for the organization.
 Managed level
 Detailed measurements of both process and
product quality are collected and used to
control the process.
 Optimizing level
 The organization has a continuous process
improvement strategy, based on objective
measurements, in place.
 RE process maturity model

Level 3 - Defined
Defined process based
on best practice; process
improvement in place

Level 2 - Repeatable
Standardised requirements
engineering; fewer
requirements problems

Level 1 - Initial
Ad-hoc requirements
engineering; requirements
problems are common
RE process maturity levels
 Initial level
 No defined RE process. Problems such as
requirements volatility, unsatisfied stakeholders and
high rework costs. Dependent on individual skills.
 Repeatable level
 Defined standards for requirements documents and
policies and procedures for requirements
management.
 Defined level
 Defined RE process based on good practices and
techniques. Active process improvement process in
place.
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

 Uniquely identify each requirement
 Define policies for requirements
management
 Use checklists for requirements analysis
 Use scenarios to elicit requirements
 Specify requirements quantitatively
 Use prototyping to animate requirements
 Reuse requirements
Key points
 The requirements engineering process is a
structured set of activities which lead to the
production of a requirements document.
 Inputs to the requirements engineering process
are information about existing systems,
stakeholder needs, organizational standards,
regulations and domain information.
 Requirements engineering processes vary
radically from one organization to another.
Most processes include requirements
elicitation, requirements analysis and
negotiation and requirements validation.
Key points
 Requirements engineering process models are
simplified process description which are
presented from a particular perspective.
 Human, social and organizational factors are
important influences on requirements
engineering processes.
 Requirements engineering process improvement
is difficult and is best tackled in an incremental
way.
 Requirements engineering processes can be
classified according to their degree of maturity.