Requirements engineering covers all activities involved in discovering, documenting, and maintaining system requirements. Requirements specify what a system should do and its qualities. There are three main types - functional, non-functional, and domain. Requirements engineering uses systematic techniques to ensure requirements are complete and consistent. Difficulties in requirements engineering are a leading cause of project failures and system problems, as stakeholders often have unclear needs and requirements change over time with multiple priorities involved.

1. Requirements and Requirements
Engineering
Ian Sommerville
http://www.youtube.com/watch?v=Ec0s0z5uXQ8
An introduction to requirements engineering, 2013
Slide 1

2. Requirements and systems
Software-based
system
User
world
Requirements
An introduction to 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.
An introduction to requirements engineering, 2013
Slide 3

4. Types of requirement
• a user-level facility description,
• a detailed specification of expected
system behaviour,
An introduction to requirements engineering, 2013
Slide 4

5. • a general system property,
• a specific constraint on the system,
An introduction to requirements engineering, 2013
Slide 5

6. • information on how to carry out some
computation,
• a constraint on the development of the
system.
An introduction to requirements engineering, 2013
Slide 6

7. Functional requirements
• Requirements that define a function or
feature of the system
• Something that the system should DO
An introduction to requirements engineering, 2013
Slide 7

8. • “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”
An introduction to requirements engineering, 2013
Slide 8

9. Non-functional requirements
• Requirements that define some
observable characteristics or quality of
the system
• Availability, reliability, safety, security,
resilience, …
An introduction to requirements engineering, 2013
Slide 9

10. • “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”
An introduction to requirements engineering, 2013
Slide 10

11. Domain requirements
• Requirements that are derived from
characteristics of the application domain
or rules and regulations that apply in
that domain
An introduction to requirements engineering, 2013
Slide 11

12. • “The system shall implement patient
privacy provisions as set out in the 1998
Data Protection Act”
An introduction to requirements engineering, 2013
Slide 12

13. 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.
An introduction to requirements engineering, 2013
Slide 13

14. An introduction to requirements engineering, 2013
Slide 14

15. • „engineering‟ implies that systematic
and repeatable techniques should be
used to ensure that system
requirements are complete, consistent,
relevant, etc.
An introduction to requirements engineering, 2013
Slide 15

16. Are requirements important?
“The principal problem areas in software
development and production are the
requirements specification and the
management of customer requirements”
An introduction to requirements engineering, 2013
Slide 16

17. “... difficulties with requirements are the
key root-cause of the safety-related
software errors that have persisted until
integration and system testing”
An introduction to requirements engineering, 2013
Slide 17

18. If the requirements are wrong
• the system may be delivered late
and cost more than originally
expected.
An introduction to requirements engineering, 2013
Slide 18

19. If the requirements are wrong
• the customer and end-users may not
satisfied with the system,
• they may not use its facilities or may
even decide to scrap it altogether.
An introduction to requirements engineering, 2013
Slide 19

20. If the requirements are wrong
• the system may be unreliable in use
with regular system errors and crashes
disrupting normal operation.
An introduction to requirements engineering, 2013
Slide 20

21. • If the system continues in use, the costs
of maintaining and evolving the system
are very high.
An introduction to requirements engineering, 2013
Slide 21

22. Software-based
system
User
world
Requirements
An introduction to requirements engineering, 2013
Photo © Liam Quinn
Slide 22

23. Difficulties with requirements
• Stakeholders don‟t know what they want
from a new system
• It is very difficult to imagine how future
systems might work
An introduction to requirements engineering, 2013
Slide 23

24. • Businesses operate in a rapidly
changing environment so their
requirements for system support
are constantly changing.
An introduction to requirements engineering, 2013
Slide 24

25. • Multiple stakeholders with different
goals and priorities are involved in
the requirements engineering
process.
An introduction to requirements engineering, 2013
Slide 25

26. • System stakeholders do not have clear
ideas about what they need
• They can only describe their
requirements in a vague and ambiguous
way
An introduction to requirements engineering, 2013
Slide 26

27. • Requirements are often influenced
by political and organisational
factors that stakeholders will not
admit to publicly.
An introduction to requirements engineering, 2013
Slide 27

28. Summary
•
Requirements define what a system should do and
the desirable qualities of that system
•
Requirements engineering is a set of systematic
techniques for defining and validating system
requirements
•
Requirements engineering is difficulties and problems
with requirements are the major cause of system
problems and project failures
An introduction to requirements engineering, 2013
Slide 28