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 !!
.
.
???
