Beruflich Dokumente
Kultur Dokumente
Processes
Objectives
To introduce the notion of processes
and process models for requirements
engineering
To explain the critical role of people in
requirements engineering processes
To explain why process improvement
is important and to suggest a process
improvement model for requirements
engineering
Processes
A process is an organized set of
activities which transforms inputs to
outputs
Process descriptions encapsulate
knowledge and allow it to be reused
Examples of process descriptions
Instruction manual for a dishwasher
Cookbook
Procedures manual for a bank
Quality manual for software development
Design processes
Design processes are processes which
involve:
Creativity,
Interaction with a wide range of
different people,
Engineering judgment,
Background knowledge, and
Experience
Design processes
Inputs not precisely defined
Many possible outputs satisfying
inputs
Cannot be automated or specified in
detail
Different people tackle intellectual
tasks in different ways and adapt the
process to suit their own way of
thinking.
Design processes
Examples of design processes
Writing a book
Organizing a conference
Designing a processor chip
Requirements engineering
RE process - inputs and outputs
Existing
systems
information
Stakeholder Agreed
needs requirements
Requirements System
Organisational engineering process
standards specification
System
Regulations models
Domain
information
Input/output description
Input or output Type Des cri pti on
Existing system Input Information about the functionality of systems to be replaced or
information other systems which interact with the system being specified
Stakeholder needs Input Descriptions of what system stakeholders need from the system to
support their work
Organisational Input Standards used in an organisation regarding system development
standards practice, quality management, etc.
Regulations Input External regulations such as health and safety regulations which
apply to the system.
Domain information Input General information about the application domain of the system
Agreed requirements Output A description of the system requirements which is understandable
by stakeholders and which has been agreed by them
System Output This is a more detailed specification of the system functionality
specification which may be produced in some cases
System models Output A set of models such as a data-flow model. an object model, a
process model, etc. which describes the system from different
perspectives
RE process variability
RE processes vary radically from one
organization to another
Factors contributing to this variability
include
Technical maturity
Disciplinary involvement
Organizational culture
Application domain
There is therefore no ‘ideal’
requirements engineering process
Process models
A process model is a simplified
description of a process presented
from a particular perspective
Processes may be defined at different
levels of detail.
In some cases, processes are defined at a
very fine level of detail
The steps in the process must be carried
out exactly as described.
Process models
Different people usually enact a process in
different ways depending on the
background of the people involved and the
particular circumstance in which the
process is enacted.
The same person will enact the same
process in different ways at different times
Types of process models include:
Coarse-grain activity models
Fine-grain activity models
Role-action models
Entity-relation models
Requirements Engineering Process
Model #1
User needs
domain Requirements
information, document
Agreed
existing system System requirements
information, specification
regulations,
standards, etc.
RE process activities
Requirements elicitation
Requirements discovered through consultation with
stakeholders
Requirements analysis and negotiation
Requirements are analyzed and conflicts resolved
through negotiation
Requirements documentation
A requirements document is produced
Requirements validation
The requirements document is checked for
consistency and completeness
Requirement Engineering Process
Alan Davis defines requirements
engineering as:
“all activities up to but not including the
decomposition of the software into its actual
architectural components”
2nd definition: (focus is on what RE is
rather than what it is not)
“Investigating and describing the problem
domain and requirements and designing and
documenting the characteristics for a solution
system that will meet those requirements.”
Alternative Requirement
Engineering Process Model
The following sub-tasks may be
identified:
Elicitation
Analysis
Specification
Human machine interface (HMI) design
Validation
Alternative
RE Process
Model
Clarification of the Alternative RE
Model
Initially, information comes from questions to the
users
This “raw” information feeds through the elicitation
process and primarily consists of problem domain
information and functional requirements.
Analysis uncovers more problem domain
understanding which feeds back into and guides the
elicitation process.
The specification can be done when the analysis is
complete.
The detailed external design of the HCI (“look and
feel”) is factored out of the specification because if it
is part of the spec., it can mask the essential, logical
behavior of the system.
Outputs of the Alternative RE Model
Four documents are produced:
Elicitation notes: not in a structured format, not
passed on from the RE phase, useful for
traceability purposes
Requirements document (the analysis document):
consists of a precise description of the problem
domain together with the requirements
Specification: contains a definition of the required
behavior of the solution system; also known as
RS, SRS,RD; forms the basis of the contract
between client and developer
HMI Design Document: elaborates the details of
the external interfaces of the solution system
(may not always be an interface for humans); will
have some overlap with the specification
What comes next (and what about
Validation?
The requirements document, the
specification document, and the HCI
specification form the input to the design
phase
Why does this RE model leave off Validation?
Validation is an extremely important part of RE,
and is not shown as a separate process because it
permeates the entire process.
During an elicitation interview, repeat the client’s
statements back to them to check
understanding;
When the 1st draft of the requirements document
is complete, do a formal review of it; etc.
Software Validation
Validation attempts to ensure that the correct
functionality for the solution system has been defined.
Need to validate the entire RE process (and the entire
SWE process as well) to check:
Is the description of the problem domain an accurate
reflection of its properties?
Are the requirements (the effects to be produced in
the problem domain) accurately recorded?
Is the external design correct; will the invented
behavior of the new system produced the required
effects?
Is the specification an accurate reflection of the
intended external design?
Spiral model of the RE process (3rd
model)
Informal statement of
Decision point: requirements
Accept document
or re-enter spiral
Requirements START
document and Agreed
validation requirements
report
Draft requirements
document
Actors in the 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 document which
actors are involved in different activities
RAD for software prototyping
ACTIONS
RO LES
Role descriptions
NL
requirements Req. convertor Requirements Traceability
document database support system
Traceability
WP linker report
Report generator
Le vel 4
Managed
Level 3
Defined
Le vel 2
Repeatable
Level 1
Initial
Maturity levels
Initial level
Organizations have an undisciplined process
and it is left to individuals how to manage the
process and which development techniques
to use.
Repeatable level
Organizations have basic cost and schedule
management procedures in place. They are
likely to be able to make consistent budget
and schedule predictions for projects in the
same application area.
Maturity levels
Defined level
The software process for both management
and engineering activities is documented,
standardized and integrated into a standard
software process for the organization.
Managed level
Detailed measurements of both process and
product quality are collected and used to
control the process.
Optimizing level
The organization has a continuous process
improvement strategy, based on objective
measurements, in place.
RE process maturity model
Level 3 - Defined
Defined process based
on best practice; process
improvement in place
Level 2 - Repeatable
Standardised requirements
engineering; fewer
requirements problems
Level 1 - Initial
Ad-hoc requirements
engineering; requirements
problems are common
RE process maturity levels
Initial level
No defined RE process. Problems such as
requirements volatility, unsatisfied stakeholders and
high rework costs. Dependent on individual skills.
Repeatable level
Defined standards for requirements documents and
policies and procedures for requirements
management.
Defined level
Defined RE process based on good practices and
techniques. Active process improvement process in
place.
Good practice for RE process
improvement