Requirements engineering involves discovering, documenting, and maintaining requirements for computer systems. It is important because getting requirements wrong can lead to projects being late, over budget, or delivering systems users do not like. Requirements engineering is difficult due to changing needs, differing stakeholder views, and politics influencing priorities.

1. Requirements Engineering
Professor Ian Sommerville
Requirements Engineering, 2013 Slide 1

2. Requirements and systems
User Software-based
world system
Requirements
Requirements Engineering, 2013 Photo © Liam Quinn Slide 2

3. What are system requirements?
• Requirements are defined during the early stages of
a system development as a specification of what
should be implemented or as a constraint of some
kind on the system.
• They may be:
– a user-level facility description,
– a detailed specification of expected system behaviour,
– a general system property,
– a specific constraint on the system,
– information on how to carry out some computation,
– a constraint on the development of the system.
Requirements Engineering, 2013 Slide 3

4. Examples of requirements
• Functional requirements
“If a patient is known to be allergic to a particular
medication, then prescription of that medication shall result in
a warning message being issued to to the prescriber”
• Non-functional requirements
“The system shall be available to all clinics during normal
working hours (Mon-Fri, 0830-1730). Downtime during
normal working hours shall not exceed 5 seconds in any one
day”
• Domain requirements
“The system shall implement patient privacy provisions as set
out in the 1998 Data Protection Act”
Requirements Engineering, 2013 Slide 4

5. What is requirements
engineering?
• Requirements engineering covers
all of the activities involved in
discovering, documenting, and
maintaining a set of requirements
for a computer-based system.
• The use of the term „engineering‟
implies that systematic and
repeatable techniques should be
used to ensure that system
requirements are complete,
consistent, relevant, etc.
Requirements Engineering, 2013 Slide 5

6. Are requirements important?
• European Software Process Improvement Training
Initiative (1996)
“The principal problem areas in software
development and production are the requirements
specification and the management of customer
requirements”
• In a study of errors in embedded systems, it was
found that:
“... difficulties with requirements are the key root-
cause of the safety-related software errors that have
persisted until integration and system testing”
Requirements Engineering, 2013 Slide 6

7. What happens if the requirements are
wrong?
• The system may be delivered late
and cost more than originally
expected.
• The customer and end-users are not
satisfied with the system. They may
not use its facilities or may even
decide to scrap it altogether.
• The system may be unreliable in use
with regular system errors and
crashes disrupting normal operation.
• If the system continues in use, the
costs of maintaining and evolving the
system are very high.
Requirements Engineering, 2013 Slide 7

8. Why is RE difficult?
• Changing environments
– Businesses operate in a rapidly changing environment so
their requirements for system support are constantly
changing.
• Differing views
– Multiple stakeholders with different goals and priorities are
involved in the requirements engineering process.
• Unclear opinions
– System stakeholders do not have clear ideas about the
system support that they need.
• Politics and people
– Requirements are often influenced by political and
organisational factors that stakeholders will not admit to Slide 8
Requirements Engineering, 2013

9. Requirements engineering
terminology
Terms that you should understand
Stakeholders, viewpoints and
concerns
Requirements Engineering, 2013 Slide 9

10. Stakeholders
• People or roles who are affected, in some way, by a
system and so who can contribute requirements or
knowledge to help you understand the requirements
• Example – medical system stakeholders
– Doctors
– Nurses
– Patients
– Hospital managers
– Administrators
– Owners of other connected systems
Requirements Engineering, 2013 Slide 10

11. Viewpoints
• Viewpoints are a way of organising and grouping
requirements that have been elicited from
stakeholders
• The requirements generally represent the views and
needs of a class or type of stakeholder
• Examples of viewpoints
– End-user viewpoint
– Managerial viewpoint
– System administration viewpoint
– Engineering viewpoint
Requirements Engineering, 2013 Slide 11

12. Stakeholders and viewpoints
Stakeholde
rs
Provide information about
VP2
VP1 VP4
VP3
Requirements
Requirements Engineering, 2013 Slide 12

13. Concerns
• Are issues that an organisation must pay attention to
and that are systemic i.e. they apply to the system as
a whole
• They are cross-cutting issues that may affect all
system stakeholders and the requirements from
these stakeholders
• Concerns help bridge the gap between organisational
goals (what the organisation has to achieve) and
system requirements (how a system contributes to
these goals)
Requirements Engineering, 2013 Slide 13

14. Concerns
Software and
hardware
Operators and
managers
The organisation
Society
Security Availability Safety
Requirements Engineering, 2013 Slide 14

15. Requirements engineering
processes
Different views of the processes involved
in requirements engineering
Requirements Engineering, 2013 Slide 15

16. The systems engineering
process
System System
requirements validation
engineering
Architectural System
design integration
Requirements Sub-system
partitioning development
Software
requirements
engineering
Requirements Engineering, 2013 Slide 16

17. RE process context
System acquisition
Requirements engineering
System design
Requirements Engineering, 2013 Slide 17

18. RE process inputs and outputs
Existing
systems
information
Stakeholder Agreed
needs requirements
Requirements System
Organisational engineering process
standards specification
System
Regulations models
Domain
information
Requirements Engineering, 2013 Slide 18

19. RE process activities
Requirements Requirements Requirements
analysis and Requirements
elicitation documentation validation
negotiation
User needs
domain Requirements
information, document
Agreed
existing system System requirements
information, specification
regulations,
standards, etc.
Requirements Engineering, 2013 Slide 19

20. RE process iteration
Informal statement of
Decision point: requirements
Accept document
or re-enter spiral
Requirements elicitation Requirements analysis and
negotiation
Requirements START
document and Agreed
validation requirements
report
Requirements validation Requirements documentation
Draft requirements
document
Requirements Engineering, 2013 Slide 20

21. Requirements engineering
problems
Fundamental issues that mean that establishing
requirements for complex systems will always be a
difficult technical and organisational problem
Requirements Engineering, 2013 Slide 21

22. Requirements change
• System requirements reflect the world outside of the
system. As this is constantly changing then the
requirements will inevitably also change
– Technology changes
– Organisational changes
– Market changes
– Economic changes
– Political and legal changes
• It is often difficult to understand the implications of
changes for the requirements as a whole
Requirements Engineering, 2013 Slide 22

23. Stakeholder perspectives
Technical perspective
Social perspective Objects
Functions
Roles ...
Certification The problem and Customer
perspective the required system perspective
User perspective
Interactions
Usability
Management perspective
Requirements Engineering, 2013 Slide 23

24. Stakeholder uncertainty
• Key stakeholders have other jobs to do!
– Developing detailed requirements for future systems often
cannot be given a high priority by the senior people who will
be affected by these requirements.
– They therefore are unable to express their requirements
except as vague, high-level descriptions
Requirements Engineering, 2013 Slide 24

25. How good are the
requirements?
• There are no objective ways to
compare alternative sets of
requirements
– The impact of a system on a
business is very hard to
understand so therefore we
cannot tell which might be the
„best‟ system for any particular
business
Requirements Engineering, 2013 Slide 25

26. Process variability
• The level of detail required in a requirements
specification differs greatly depending on the type of
product that is being developed
– A railway signalling system is a very detailed specification
that can be validated by authorities outside of the
organisation procuring the software
– A computer game specification is a storyboard with pictures
and examples
• They use completely different processes involving
different types of people to derive these specifications
• Scope for process standardisation and support is
therefore limited
Requirements Engineering, 2013 Slide 26

27. Politics and people
• Many system requirements are influenced by the
politics in an organisation. Decisions on requirements
are not made on a rational basis but are made
because of the personal goals of stakeholders
• Requirements engineers may not understand the
politics and, even when they do, they may not be able
to challenge the „political‟ requirements
• People providing requirements for a system may not
be convinced that the system is necessary or may
feel that other systems should have a higher priority.
They may actively or passively refuse to cooperate in
the requirements engineering process
Requirements Engineering, 2013 Slide 27

28. Summary
• Requirements engineering is a key component of
system development processes.
• If we pay attention to requirements, we reduce later
problems in system development and operation
• Requirements engineering will always be difficult
because the requirements are reflections of a rapidly
changing business environment
Requirements Engineering, 2013 Slide 28