4. Requirements engineering
• RE is not a separate and distinct process that
is carried out at the beginning of the software
development life cycle
• Requirements may be developed as part of
the system acquisition or procurement
process
• Requirements are refined and new
requirements emerge during system design
RE processes, 2013
Slide 4
5. RE process context
System acquisition
Requirements engineering
System design
RE processes, 2013
Slide 5
6. RE process inputs and outputs
Existing
systems
information
Agreed
requirements
Stakeholder
needs
Organisational
standards
Regulations
Requirements
engineering process
System
specification
System
models
Domain
information
RE processes, 2013
Slide 6
7. RE process activities
Requirements
elicitation
User needs
domain
information,
existing system
information,
regulations,
standards, etc.
RE processes, 2013
Requirements
analysis and
negotiation
Requirements
documentation
Requirements
validation
Requirements
document
System
specification
Agreed
requirements
Slide 7
8. RE process iteration
Decision point:
Accept document
or re-enter spiral
Informal statement of
requirements
Requirements elicitation
Requirements
document and
validation
report
Requirements analysis and
negotiation
START
Agreed
requirements
Requirements validation
Requirements documentation
Draft requirements
document
RE processes, 2013
Slide 8
9. • Go round spiral until you run out of time
for requirements engineering
• RE is always time constrained
• Problems with requirements arise
because not enough time is allowed for
the process
RE processes, 2013
Slide 9
10. Summary
• There are a number of different ways to
look at requirements engineering
• These present different views of the
goals and activities in requirements
engineering
RE processes, 2013
Slide 10
11. RE perspectives
• Systems engineering
• Other procurements and design
processes
• Inputs and outputs
• Activities
• Iteration
RE processes, 2013
Slide 11
