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 and 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
 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
 Requirement Engineering process
 …
 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
 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
 RE process variability
 RE processes vary radically from one organization to another
 Factors contributing to this variability include
 Technical maturity – technologies and methods used vary
 Disciplinary involvement – engineering & managerial disciples
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:
 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
 Various methods such as fault-tree analysis and Petri net analysis have
been developed for safety validation.
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
 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
and their approximate sequencing
 Used as starting point for process description with separate sections
covering each box in the model
 Process Models…
 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.)
 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.
 Modeling tools are developed based on structured methods such as
SADT, or specialized requirement languages such as RSL.
 If a mathimematical model of requirements are developed using
VDM & Z then more extensive checkers may be used
 Management tools
 Help to manage a database of requirements and support the
management of changes to these requirements.
 Process support...
 Management tools (cont’d)
 These tools are developed to alleviate the problem of large
amount of data collected in RE process & variability of
requirements
 Examples: RequisitPro, DOORS, RML,
 Requirement Management tools provide a range of facilities to
access the information about the requirements.
 Requirements browser
 Requirements query system
 Traceability support system
 Report generator
 Requirements converter and word processor linker
 Change control system
 Process support...

A requirements management system

 Process Improvement
 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 recourses 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?
 Process Improvement...
 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 SEI’s 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
 Level 5 – Optimizing
 has a continuous process improvement strategy
 RE process Maturity Model
 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.
 RE process Maturity Model…
 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 the skills and
experience of individual engineers for requirements elicitation,
analysis & validation.
 RE process Maturity Model…
 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.
 Levels: 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)
 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)