Chapter Two

Requirements Engineering Process

Contents
What is process?
Designing processes
Requirement Engineering process
RE process variability
RE Process for safety-related systems
Process Models
Actors in Requirements engineering process
Process support
Process Improvement
Process Maturity
A requirement engineering process maturity model
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
 Software engineering development process (SDLC)
 Requirements engineering process
 Design process
 Quality assurance process
 Change management process

 Process may be defined in

 a very fine level of detail (steps followed exactly they appear)

 An abstract way (process user may enact the process)

Designing Processes
 Designing processes involve creativity, interactions between a wide range of different

people, engineering judgment and background knowledge and experience.

 Examples of designing processes

Writing a book ,Organizing a conference

Designing a processor chip

Requirements engineering

 Unlike other processes in designing software processes

inputs are not precisely defined and

are many possible outputs which may result to satisfy this inputs.

It is hard to automate such processes

RE Process - 1
It is a continuous process in which the related activities are repeated until

requirements are of acceptable quality.

It is one of the most critical processes of system development

Based on the need of individual software projects and organizational needs,

requirements engineering processes are tailored

An important point to remember is that

“There is no ideal requirements engineering process!” it varies from project to

project
5
RE Process - 2
• A requirement Engineering process has a formal starting and ending point

in the overall software development lifecycle.

 Begins

There is recognition that a problem exists and requires a solution

A new software idea arises

 Ends

With a complete description of the external behavior of the software to

be built.
6
Two Main Tasks of RE
 There are two main tasks which needs to be performed in the

requirement engineering life cycle.

 Problem analysis

 Analysis of a software problem

 Product description

 Complete specification of the desired external behavior of the software

system to be built.
 Also known as functional description, functional requirements, or

7 specifications
Problem Analysis
Problem analysis is the first and foremost task of requirements
engineering process. It includes:
Brainstorming, interviewing, eliciting requirements

Identifying all possible constraints

Expansion of information

Trading-off constraints and organizing information

Complete understanding should be achieved

8
Product Description
Product description is another task of requirements engineering
process. In this task we:

Make decisions to define the external behavior of the

software product.
Organize ideas, resolve conflicting views, and eliminate

inconsistencies and ambiguities.

9
What Really Happens

It should be kept in mind that :

“Both problem analysis and product description run in

parallel and iteratively throughout the requirements
engineering process”

10
Requirements Engineering Processes
Processes are used to discover, analyse and validate system requirements
The process of establishing what services are required and the constraints on the
system’s operation and development.

Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document
Feasibility studies
For each new system RE starts with this study
Feasibility study leads to a decision:
go ahead
do not go ahead
think again

A feasibility study decides whether or not the proposed system is worthwhile

A short focused study that checks

If the system contributes to organisational objectives

If the system can be engineered using current technology and within budget

If the system can be integrated with other systems that are used
Requirements Elicitation

Requirements elicitation activity is performed by

Determining the system requirements through consultation

with stakeholders, from system documents, domain knowledge,

and market studies
Requirements acquisition or requirements discovery

13
Requirement Analysis

Refining and modifying the gathered requirements

Encompasses those tasks that go into determining the needs or

conditions to meet for a new or altered product taking the

possibility of conflicting requirements of the various stakeholders.
 Determining whether the stated requirements are clear,

complete, consistent and unambiguous

Requirements Specification

Building a tangible model of requirements using natural language and

diagrams.

Building a representation of requirements that can be assessed for

correctness, completeness, and consistency.

Formalizes the informational, functional, and behavioural requirements of

the proposed system in both graphical and textual formats.

15
Requirements Document

Detailed descriptions of the required software system in the form

of requirements is captured in the requirements document.

Software designers, developers and testers are the primary users

of the document.

16
Requirements Validation
It involves reviewing the requirements model for consistency and

completeness
This process is intended to detect problems in the requirements document,

before they are used as a basis for the system development.

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.

17
Requirements Management

Although, it is not shown as a separate activity in RE Process, it

is performed through out the requirements engineering

activities.

Requirements management asks to identify, control and track

requirements and the changes that will be made to them.

18
RE Process - Inputs and Outputs
…
RE Process - Inputs and Outputs
…
For Library information System(LIS) the following examples are
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.
Contd….
Organizational standards
The system shall run on a Sun server running the Solaris 2.0
operating system
Regulations

The system shall include a facility to print all of the

personnel information which is maintained for a library user.

Domain information

Books are uniquely identified by an international Standard

RE process variability

RE processes vary radically from one organization to

another and even within an organization in different projects.

Unstructured process rely heavily on the experience of the

people, while systematic processes are based on application

of some analysis methodology , but they still require human
judgment.
RE process Variability Factors
Factors contributing to this variability include

Technical maturity – technologies and methods used vary.

Disciplinary involvement – engineering & managerial disciplines involved vary.

Organizational culture – culture of an organization has effect on all business

processes.
Application domain – different applications need different RE process

There is therefore no ‘ideal’ requirements engineering process.

Rather organizations should start with generic RE process and instantiate this into

more detailed process which is appropriate to their own needs.

RE Process for safety-related systems
The requirements engineering process for safety-related systems

should incorporate a specific safety-analysis activity

The widely accepted model of the system critical, systems life cycle

[British Computer Society (BCS) and Institution of Electrical

Engineers (IEE) 1989] identifies two stages in the safety analysis
process:
1. Safety requirements discovery
2. Safety validation
Cont.…

Safety requirements discovery – establishment of safety

requirements or constraints which the system must satisfy
Involves hazard identification and analysis, risk assessment

and formulation
Safety validation – analysis of system requirements against

global safety constraints to ensure these requirements do not

conflict.
Integrating safety analysis with RE
Integrating safety analysis with RE…
As shown in the diagram in preceding slide the requirements process has been

extended to incorporate an explicit safety analysis activity

The safety analysis process is based on requirements information drawn from

the requirements elicitation and documentation process

The starting point for specifying the system is a set of abstract organisational

needs and constraints.

The abstract safety requirements serves as a reference model for identifying

initial safety considerations or concerns

Cont.…
The safety analysis process includes:

The identification of safety considerations

Hazard identification

Hazard analysis

Risk analysis and derivation of safety requirements

Process Models
 A process model is a simplified description of a process presented from a particular

perspective.
 No single model gives you a complete understanding of the process

 To describe a process in detail it is usual to produce several different types of model giving

different process information.

 Types of process model include:

Coarse-grain activity models

 shows the major activities involved in particular process and shows their approximate

sequencing.
Used as starting point for process description with separate sections covering each box in

the model
Fine-grain activity models

detailed model of a specific process.

Used for understanding & for improving existing process

Role-action models

show the role of different people involved in the process & the actions which they

take.
Helpful for process understanding & automation

Entity-relation models

Show the process inputs, outputs & intermediate results & the relationships b/n

them
Used in a quality management system & supplement models of process activities
Process Models…

Coarse-grain activity model of

RE
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.)
Actors in RE process...
Role-action diagrams: are process models which show the actors associated with
different process activities.
They document the information needs of different people involved in the process

Role Action Diagram (RAD) for software

Actors in RE process...

Human and social factors in RE processes

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
 One way to minimize errors in the requirements engineering is to use process models and

to use CASE tools.

 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 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 requirements.
Process support...
Management tools (cont’d)
Examples: RequisitPro, DOORS, RML, …..
RML tools 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

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 resources 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?

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.
Process maturity…

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 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
Level 5 – Optimizing
has a continuous process improvement strategy
Process maturity…

The Key Process Challenges

Process Maturity ….
 Requirement engineering process maturity is an extent to which an organization has

defined requirement engineering process based on good requirement engineering

practices.
 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
RE process maturity 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 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 engineering's process model based on good practice

and techniques.
They have an active process improvement program 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)

ISO 9001 Standards
 ISO 9001 identify requirements for systems of quality management for an organization who:

 a) wants to exhibit its capability to consistently give product that meets up customer requirements

 b) plans to improve customer satisfaction via valuable system application, together with processes for

continuous system improvement and the guarantee of compliance to customer requirements.

 ISO 9001 requirements are generic and are planned to be appropriate to all organizations, in

spite of :
 organization type,

 organization size and,

 organization product provided for enhancing the customer satisfaction by meeting customer

requirements.
IEEE Std 1362™-1998
 This standard deals with the concept of operations (ConOps) document.

 It is a user-oriented document that explains proposed system characteristics from the users’

perspective.
 The concept of operation (ConOps) document is used to communicate the system characteristics to

the stakeholders and other organizational elements like staffing, training etc.
 It is also notified that the standard is used to describe not only the user organization(s) but also the

user mission(s) besides with that of the objectives of an organization from an integrated systems
perspective.
 It acts as a guide for all software-intensive systems.

 The standard is applicable to all software products irrespective of its size, scope, complexity, or

criticality.
Reading Assignments

1. Generic practices in RE process

2. Requirement’s development process area

3. Requirements management process area

Thank you !!
.
.
???