An introduction to requirements engineering for students with no previous background in this area. Part of critical systems engineering course, CS 5032.

1. Requirements Engineering
Professor Ian Sommerville
L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 1

2. Requirements and systems
User Software-based
world system
Requirements
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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.
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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”
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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.
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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”
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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.
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 stakeholders will not admit to Slide 8
organisational factors that

9. Requirements engineering
terminology
Terms that you should understand
Stakeholders, viewpoints and
concerns
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 11

12. Stakeholders and viewpoints
Stakeholde
rs
Provide information about
VP2
VP1 VP4
VP3
Requirements
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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)
L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 13

14. Concerns
Software and
hardware
Operators and
managers
The organisation
Society
Security Availability Safety
L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 14

15. Requirements engineering
processes
Different views of the processes involved
in requirements engineering
L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 15

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

17. RE process context
System acquisition
Requirements engineering
System design
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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.
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 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
L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 28