Ch 2-RE-process.pptx
- 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
- 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
- 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
- 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...
- 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
- 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)