Requirements Engineering Processes

COMSATS Institute of Information Technology
Requirements Engineering
Requirements Engineering Processes

Atique Zafar
Processes
A process is an organised 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

Cookery book
Procedures manual for a bank
Quality manual for software development
Design processes
Processes which involve creativity,

interactions between a wide range of different
people, engineering judgement and
background knowledge and experience
Examples of design processes
Writing a book
Organising a conference
Designing a processor chip
Requirements engineering
RE process - inputs and outputs

Existing
systems
information
Agreed
requirements
Stakeholder
needs
Organisational
standards
Regulations
Domain
information
Requirements
engineeringprocess
System
specification
System
models
Input/output description
Input or o utput
Existingsystem
information
Stakeholderneeds
Ty pe
Input
Organisational
standards
Regulations
Input
Input
Input
Domaininformation Input
Agreedrequirements Output
System
specification
Systemmodels
Output
Output
Des cri pti on

Informationaboutthefunctionalityofsystemstobereplacedor
othersystemswhichinteractwiththesystembeingspecified
Descriptionsofwhatsystemstakeholdersneedfromthesystemto
supporttheirwork
Standardsusedinanorganisationregardingsystemdevelopment
practice,qualitymanagement,etc.
Externalregulationssuchashealthandsafetyregulationswhich
applytothesystem.
Generalinformationabouttheapplicationdomainofthesystem
Adescriptionofthesystemrequirementswhichisunderstandable
bystakeholdersandwhichhasbeenagreedbythem
Thisisamoredetailedspecificationofthesystemfunctionality
whichmaybeproducedinsomecases
Asetofmodelssuchasadataflowmodel.anobjectmodel,a
processmodel,etc.whichdescribesthesystemfromdifferent
perspectives
Explanation with examples
1. Existing system information

Assume that the system has to interface with a bar code reader system which has already been
installed and which generates a queue of bar codes for processing and associated transaction
requests.
Example: The LIS shall poll the bar code reader system and process all of the transaction requests every
two seconds.
2. Stakeholder needs
Assume that the stakeholder is a visitor to the library who has no previous experience of using
the system.
Example: The system should provide a help facility which will explain the facilities of the system to new
users. This help facility should be accessible from all user interface screens.
3. Organizational standards
Assume that the library uses a hardware platform for all of its systems.
Example: The system shall run on a Sun server running the Solaris 2.0 operating system.
4. Regulations
Regulations such as health and safety regulations are unlikely to have much impact on this type
of system. However, data protection laws do apply to it.
Example: The system shall include a facility to print all of the personal information which is maintained for
a library user.
5. Domain information
This is general information which is applicable to all or most library systems.
Example: Books are uniquely identified by an International Standard Book Number which is a 10 digit
identifier .
Software Engineering-II
RE process variability
RE processes vary radically from one

organisation to another
Factors contributing to this variability include
Technical maturity
Disciplinary involvement
Organisational culture
Application domain
There is therefore no ideal requirements

engineering process
Requirements Engineering
Processes
Like a life cycle development process there

are some limited numbers of requirements
engineering processes available.
These are the set of activities involved in
development of
requirements.
Linear Requirements Engineering Process

Model
Mostly used for small
projects with some less
amount of complexity
Problems
Not good for some large
and huge projects to get
their requirements
because,
No user feedback, no
validation of requirements,
No iterations of RE,
The most important that
there is no strategy defined
for risk management.
Linear Iterative Requirements

Engineering Process Model
Requirements
elicitation
Userneeds
domain
information,
existingsystem
information,
regulations,
standards,etc.
Requirements
analysisand
negotiation
Requirements
documentation
Requirements
validation
Requirements
document
System
specification
Agreed
requirements
Cont
This model is useful for the system where the
specifications should be pin point accurate and
should be validated multiple numbers of times
through the potential stakeholders.
Solves some of the problems of linear RE
process model
such as freezing of requirements and
requirements invalidation.
Problems
No reverse engineering is possible and
No risk management is suggested by this model.
11
Iterative RE Process Model
Used to perform the requirements engineering in

multiple iterations
Better for those software development which are
launched versions by versions in the market.
12
Cont
Suggests the user and domain information
feedback in case of new iteration in the
product.
Problem
Still there is no methodology set to manage
the risks in the project.
13
Spiral Model of RE Process
One spiral represents the complete version of

the requirements on the bases of which the
system has to be developed.
Each spiral is divided into four quadrants
called specification elicitation, requirements
analysis
and
negotiation,
requirements
documentations and requirements validations.
The main characteristic of this model is to
handle the unwanted consequences called
risks such as speciation delay, requirements
change.
14
Spiral model of the RE process

Decisionpoint:
Acceptdocument
orreenterspiral
Informalstatementof
requirements
Requirementselicitation
Requirements
documentand
validation
report
Requirementsanalysisand
negotiation
START
Requirementsvalidation
Draftrequirements
document
Agreed
requirements
Requirementsdocumentation
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
Understand
problem
Establish
outline
requirements
Select
prototyping
system
Develop
prototype
Req.engineer
Domainexpert
Enduser
Req.engineer
Enduser
Software
engineer
Projectmanager
Req.engineer
Software
engineer
RO LES
Evaluate
prototype
Enduser
Domainexpert
Req.engineer
Softwareengineer
Role descriptions
Ro l e
Domainexpert
Systemenduser
Requirementsengineer
Softwareengineer
Projectmanager
Des cri pti o n

Responsibleforprovidinginformationaboutthe
applicationdomainandthespecificprobleminthat
domainwhichistobesolved.
Responsibleforusingthesystemafterdelivery
Responsibleforelicitingandspecifyingthesystem
requirements
Responsiblefordevelopingtheprototypesoftware
system
Responsibleforplanningandestimatingthe
prototypingproject
Human and social factors
Requirements engineering processes are

dominated by human, social and
organisational factors because they always
involve a range of stakeholders from different
backgrounds and with different individual and
organisational goals.
System stakeholders may come from a range
of technical and non-technical background
and from different disciplines
Types of stakeholder
Software engineers responsible for system

development
System end-users who will use the system after it
has been delivered
Managers of system end-users who are
responsible for their work
External regulators who check that the system
meets its legal requirements
Domain experts who give essential background
information about the system application domain
Factors influencing requirements
Personality and status of stakeholders

The personal goals of individuals within an
organisation
The degree of political influence of
stakeholders within an organisation

Requirements Engineering Processes

Uploaded by

Copyright:

Available Formats

Requirements Engineering Processes

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirements Engineering Processes

Uploaded by

Copyright:

Available Formats

What are some examples of design processes mentioned?

What are some examples of design processes mentioned?

What are the inputs and outputs of the requirements engineering process?

What are the inputs and outputs of the requirements engineering process?

COMSATS Institute of Information Technology

Requirements Engineering Processes

A process is an organised set of activities

Instruction manual for a dishwasher

Processes which involve creativity,

RE process - inputs and outputs

Des cri pti on

Explanation with examples

1. Existing system information

RE processes vary radically from one

There is therefore no ideal requirements

Like a life cycle development process there

Linear Requirements Engineering Process

Linear Iterative Requirements

Iterative RE Process Model

Used to perform the requirements engineering in

Spiral Model of RE Process

One spiral represents the complete version of

Spiral model of the RE process

Actors in the RE process

Actors in a process are the people involved in

RAD for software prototyping

Des cri pti o n

Human and social factors

Requirements engineering processes are

Software engineers responsible for system

Factors influencing requirements

Personality and status of stakeholders

You might also like