Requirements processes

1. Requirements Engineering Process
Chapter Two

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

3.  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
What is process?

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

5. 5
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!”

6. 6
RE Process - 2
 A requirement Engineering process has
a formal has a 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

7. 7
Two Main Tasks of RE
 There are two main tasks which needs to
be performed in the requirement
engineering life cycle.o be performed in
the requirements engineering process.
 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 specifications
T

8. 8
Problem Analysis - 1
 Brainstorming, interviewing, eliciting requirements
 Identifying all possible constraints
 Expansion of information
 Trading off constraints and organizing information
 Complete understanding should be achieved
Problem analysis is the first and foremost
task of re
Q
Problem analysis is the first and foremost
task of requirements engineering process.
It includes:

9. 9
Product Description
 Make decisions to define the external
behavior of the software product
 Organize ideas, resolve conflicting
views, and eliminate inconsistencies and
ambiguities
Product description is another task of
requirements engineering process. In this
task we:

10. 10
What Really Happens
“Both problem analysis and product description run in
parallel and iteratively throughout the requirements
engineering process”
It should be kept in mind that :

11. Requirements Engineering Processes
 Processes 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
study
Requirements
elicitation and
analysis
Requirements
specification
Requirements
validation
Feasibility
report
System
models
User andsystem
requirements
Requirements
document

12. Feasibility studies
 For each new system RE starts with this study
 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

13. 13
Requirements Elicitation
 Determining the system requirements
through consultation with stakeholders,
from system documents, domain
knowledge, and market studies
 Requirements acquisition or
requirements discovery
Requirements elicitation activity is
performed by

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

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

16. 16
Requirements Document
 Detailed descriptions of the required software
system in form of requirements is captured in the
requirements document
 Software designers, developers and testers are the
primary users of the document

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

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

19.  …
RE Process - Inputs and Outputs

20.  …
RE Process - Inputs and Outputs

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

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

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

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

25.  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:
RE Process for safety-related systems

26. Contd…
 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

27. Integrating safety analysis with RE

28.  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
Integrating safety analysis with RE…

29. Contd…
 The safety analysis process includes:
 The identification of safety considerations
 Hazard identification
 Hazard analysis
 Risk analysis and derivation of safety
requirements

30.  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
Process Models

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

32. Process Models…
Coarse-grain activity model of RE

33. 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.)

34. Actors in RE process...
Role Action Diagram (RAD) for software
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

35.  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
Actors in RE process...

36.  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
Process support

37. Stakeholder Types
 Software engineers
 System end-users
 Managers of system end-users
 External regulators
 Domain experts
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

38.  One way to minimize errors in the requirements
engineering is to use process models and to use CASE
tools
 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
Process support...

39.  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
Process support...

40. Process support...
A requirements management system

41.  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?
 How should process improvements be controlled and
Process Improvement

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

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

44.  ….
Process maturity…
Process Capability Maturity
Model

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

46.  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 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
RE process Maturity Model

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

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

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

51.  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)
Good practice for RE process improvement

52. 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)