1. Requirements E n g i n e e r i n g
Software Engineering
C h a p t e r 4
Requirements E n g i n e e r i n g
Dr.Doaa Sami
Modified from Sommerville’s originals

2. Objectives 2
 Understand the concepts of user and system requirements.
 Show differences between functional and nonfunctional requirements.
 Understand how requirements may be organized in a software requirements document.
 Understand the principal requirements engineering activities of elicitation, analysis and validation.
 Understand why requirements management is necessary.

3. Requirements Engineering3
 Requirements: The descriptions of the system
services and constraints that are generated during
the requirements engineering process.
 Requirements Engineering (RE): The process of finding out, analyzing, documenting and checking these services and constraints.
 Developed during the first phase in the software
development life cycle.

4. What is a Requirement? 4
 It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.
“If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization's needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.”
Some of the problems that arise during the requirements engineering process are a result of failing to make a clear separation between these different levels of description. I distinguish between them by using the term ‘user requirements’ to mean the high-level abstract requirements and ‘system requirements’ to mean the detailed description of what the system should do.

5. Requirements Types  User Requirements
 Statements in a natural language plus diagrams of the
services that system provides and its operational constraints.
 Written for customers.
 System Requirements
 A structured document setting out more detailed to define exactly what should be implemented, descriptions of the system’s functions, services and operational constraints.
 Written for those who are involved in system implementation.
 A user requirement may expanded into several system requirements. 5

6. User & System Requirements Example6

7. Readers of different types of requirements specification
Chapter 4 Requirements engineering

8. User Requirements Vs. System Requirements7
User Requirements System Requirements
 Written for customers  Statements that set out detailed
 Statements in natural language descriptions of the system’s
 Describe the services that system constraints. provides and its operational
implemented so may be part of a
 May include diagrams or tables contract between client and
 Should describe functional and non contractor.
functional requirements  Intended to be a basis for
 Should be understandable by designing the system.
system users who don’t have  Can be illustrated using system detailed technical knowledge models.
We provide a definition for a user We provide a specification for a
requirement system requirement.
constraints.
functions, services and operational
 Defines what should be

9. Functional & Non-Functional Requirements8
 Functional Requirements
 Statements of services the system should provide, specify how the system should react to particular inputs or situation.
They say what the system is supposed to do, not do.
 Non-Functional Requirements
 Defines system properties and constraints such as timing constraints, constraints on the development process, etc.
Applied to the system as a whole, rather than individual system features or services.
 Domain Requirements
 Derived from the domain of operation. They may be new functional requirements that constrain existing functional requirements.

10. Functional Requirements9
 Describe functionality or system services.
 Depend on:
 The type of software being developed.
 Expected users.
 The general approach taken by the organization.
 Functional user requirements may be high- level statements of what the system should do.
 Functional system requirements should
describe the system services in detail, that includes
input and outputs.

11. The LIBSYS Case Study 10
 A library system that provides a single interface to a number of databases of articles in different libraries.
 Users can search for, download and print these articles for personal study.

12. Functional Requirements for LIBSYS11
1. The user shall be able to search databases for a
specific materials.
2. The system shall provide appropriate viewers for
the user to read documents in the document store.
3. Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy
to the account’s permanent storage area.

13. Ambiguous Requirements12
 Problems arise when requirements are not precisely stated (Ambiguous).
 Ambiguous requirements may be interpreted in different ways by developers and users.
 Consider the term ‘appropriate viewers ’ in requirement(2) of LIBSYS:
 User intention – special purpose viewer for each different
document type.
 Developer interpretation –provide text viewer that shows the
contents of the documents.

14. Requirements Completeness and Consistency13
 In principle, requirements should be both complete and consistent.
 Completeness:
 All services required by the user should be defined.
 Consistency:
 Requirements should not have contradictory descriptions or definitions.
 In practice, for large and complex systems, it is impossible to produce a complete and consistent requirements document.

15. Non-Functional Requirements14
 Define system properties rather than specific services.
 Example of non-functional requirements:
System properties: reliability, response time, maintainability, storage requirements.
Constraints: I/O device capability, data representations, etc.
Process requirements: Mandating particular CASE system, Programming language.

16. Non-Functional Requirements Classifications
 Product Requirement
 Specify that the delivered product must behave in a particular
way e.g. Performance: how fast systems is, and Reliability: acceptable failure rate.
 Organizational Requirement (process requirement)
 Requirements which are a consequence of organisational
policies and procedures e.g. process requirements that define how the system will be used.
 External Requirement
 Requirements which arise from factors which are external to
the system and its development process e.g. Interoperability: how system work with other system on other organization, Legislative requirements  law requirements. 15

17. Examples of nonfunctional requirements in the MHC-PMS
Product requirement
The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day.
Organizational requirement Users of the MHC-PMS system shall authenticate themselves using their health authority identity card.
External requirement The system shall implement patient privacy provisions as set out in HStan priv.
Chapter 4 Requirements engineering

18. Non-Functional Requirements Classifications16

19. Non-Functional Requirements Implementation17
 Non-functional requirements may affect the overall
architecture of a system rather than the individual
components.
 For example, to ensure that performance requirements are
met, you may have to organize the system to minimize
communications between components.
 A single non-functional requirement, such as a
security requirement, may generate a number of
related functional requirements that define system
services that are required.
 It may also generate requirements that restrict existing
requirements.

20. Goals and Requirements
 Common problem with non-functional requirement is that user express them as a general goal.
 Goals:
 General intention of the user such as ease of use.
 Verifiable Non-Functional Requirement:
 Statements using some measures that can be objectively tested.
 Goals are helpful to developers as they convey the intentions of the system users. 18

21. Example  Goal: The system shall be easy to use.19
 Goal: The system shall be easy to use.
 Better expressed as: Experienced users shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.

22. Non-Functional Requirements Specifying Metrics20
Property Measure
Speed User/event response time
Size Number of ROM chips
Ease of use Training time
Reliability Rate of failure occurrence
Time to restart after failure
Robustness Percentage of events causing failure
Probability of data corruption on failure
Portability Number of target systems
Screen refresh time
Availability

23. Domain Requirements requirements on the system.21
 The operational domain of the system imposes
requirements on the system.
 For example, a train control system has to take into account
the braking characteristics in different weather conditions.
 Domain requirements may be new functional
requirements, constraints on existing requirements
or define specific computations.
 If domain requirements are not satisfied, the system
may be unworkable.

24. LIBSYS Domain Requirement22
 Because of copyright restrictions, some documents
must be deleted immediately on arrival.
 Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer.

25. Domain Requirements Problems23
 Understandability
 Requirements are expressed in the language of the application
domain;
 This is often not understood by software engineers developing
the system.
 Implicitness
 Domain specialists understand the area so well that they do
not think of making the domain requirements explicit.

26. Software Requirements Specification (SRS)24
 Representing requirements using SRS document: The software requirements specifications document is the official statement of what is required of the
system developers.
 Should include both
 a definition of user requirements and
 a specification of the system requirements.
 It is NOT a design document.
 As far as possible, it should set WHAT the system should do rather than HOW it should do it.

27. Ways of Writing a SRS 1. Natural language25
1. Natural language
 The requirements are written using numbered sentences in
natural language. Each sentence should express one
requirement.
 Invent a standard format and use it for all requirements.
 Use language in a consistent way.
Use shall for mandatory requirements, should for desirable
requirements.
 Use text highlighting to identify key parts of the requirement.

28. Problems with Natural Language26
 Lack of clarity
 Precision is difficult without making document difficult to read.
 Requirements confusion
 Functional and non-functional requirements tend to be mixed-up.
 Requirements Mixture
 Several different requirements may be expressed together.

29. Example requirements for the insulin pump software system
3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.)
3.6 The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.)
Chapter 4 Requirements engineering

30. Ways of Writing a SRS 2. Structured natural language
 The freedom of the requirements writer is limited.
 Requirements are written in a standard form or template. Each field provides information about an aspect of the requirement.
3. Mathematical specifications
 These notations are based on mathematical concepts such as
finite-state machines or sets.
 Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. 27

31. Ways of Writing a SRS 4. Graphical models28
4. Graphical models
 Supplemented by text annotations, are used to define the
functional requirements for the system; UML use case and
sequence diagrams are commonly used.

32. Use cases for the MHC-PMS
Chapter 4 Requirements engineering

33. Users of the SRS Document
 Customers  check that requirements meet needs.
 Managers  plan developments process.
 System engineers  understand what system to be developed.
 System test engineers  develop validation tests for the system.
 System maintenance engineers understand the system and the relationships between its parts. 29

34. Structure of a Requirements Document30
Chapter Description
Preface This should define the expected readership of the document and
This should describe the need for the system. It should briefly describe
Introduction the system’s functions and explain how it will work with other systems.
strategic objectives of the organization commissioning the software.
Glossary This should define the technical terms used in the document.
Here, describe the services provided for the user. The non-functional
User Requirements system requirements should also be described in this section. This
are understandable to customers. Product and process standards that must be followed should be specified.
This chapter should present a high-level overview of the anticipated
System architecture system architecture, showing the distribution of functions across system
highlighted.
describe its version history,
It should also describe how the system fits into the overall business or
definition
description may use natural language, diagrams, or other notations that
modules. Architectural components that are reused should be

35. Structure of a Requirements Document Cont.31
Chapter Description
System This should describe the functional and nonfunctional requirements in more Requirements detail. If necessary, further detail may also be added to the nonfunctional specification requirements. Interfaces to other systems may be defined.
System Models This might include graphical system models showing the relationships
This should describe the fundamental assumptions on which the system is
System Evolution based, and any anticipated changes due to hardware evolution, changing user needs, and so on.
These should provide detailed, specific information that is related to the
Appendices application being developed; for example, hardware and database
descriptions and Hardware requirements.
Index Several indexes to the document may be included.
between the system components and the system and its environment.

36. Requirements Engineering Processes
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.
 However, there are four generic activities which
common to all requirements engineering processes:
Feasibility study.
Requirements elicitation and analysis.
Requirements specification.
Requirements validation. 32

37. Requirements Engineering Processes33

38. 1. Feasibility Study 34
 Feasibility study decides whether or not the proposed system is worthwhile.
 A short focused study that checks
 If the system contributes to organisational objectives;
 If the system can be engineered using current technology and within budget;
 If the system can be integrated with other systems that are used.

39. A spiral view of the requirements engineering process
Chapter 4 Requirements engineering

40. 2. Requirements Election and Analysis35
 software engineers work with customers and system end-users to find out about the application domain, the services that the system should provide and the system’s operational constraints.
 May involve a variety of different kinds of people in an organization: end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.
Can you identify possible stakeholders for the
LIBSYS?

41. 2. Requirements Election and Analysis Cont.
 Requirements Discovery
 Sources of information
 Documentation ex: Existing documents and files (business mission, sample forms, flowcharts...etc.
 System stakeholders by:
 Interviews.
 Observation (ethnography).
 Questioners.
 Specifications of similar systems (reports). 36

42. System Models  Requirements Analysis (System Models)37
 Requirements Analysis (System Models)
 The model aids the analyst in understanding the system, thereby makes the requirements analysis easier and more systematic.
 The model becomes the focal point of review.
 The model becomes foundation for design.
 Produced during requirements analysis.

43. 3. Requirements Specifications38
 Requirements specifications
o It is the final work product produced by the requirements engineer.
o The SRS document
o It serves as a foundation for the software design and
implementation.

44. 4. Requirements Validation39
 The process of ensuring that the requirements actually define the system that the customer wants.
 Why is it important?
 The cost of fixing a requirements problem by making a system change is much greater than repairing design or coding errors.

45. 4. Requirements Validation Cont.40
 Validity checks
 Is this what the user wants?
 Consistency checks
 Requirements should not conflict
 Completeness checks
 Requirements should define all functions and constraints
 Realism checks
 Ensure they could be implemented
 Verifiability
 Requirements should be written so that they are verifiable, you should be able to write tests for each requirement.

46. Requirements Validation Techniques
 Requirements reviews
 A team of reviewers manually check the requirements.
 Prototyping
 An executable model of the system is demonstrated to customers.
 Test-case generation
 Requirements should be testable. If tests are difficult or impossible to design, this means that the requirements will be difficult to implement. 41

47. Requirements Management42
 Requirements Management is the process of
controlling changes to system requirements.
 New requirements emerge as a system is being
developed and after it has gone into use.
You need to keep track of individual requirements and maintain links between dependent requirements, so that you can assess the impact of requirements changes.
 You need to establish a formal process for making change proposals and linking these to system requirements.

48. Requirements change management
Chapter 4 Requirements engineering

49. Summery system should do and define constraints on its43
 Requirements for a software system set out what the
system should do and define constraints on its
operation and implementation.
 Functional requirements are statements of the
services that the system must provide or are
descriptions of how some computations must be
carried out.
 Non-functional requirements often constrain the
system being developed and the development
process being used.

50. Summery elicitation including interviews, scenarios and use- cases .44
 You can use a range of techniques for requirements
elicitation including interviews, scenarios and use-
cases .
 Requirements validation is the process of checking the requirements for validity, consistency, completeness, realism and verifiability.
 Business, organizational and technical changes
inevitably lead to changes to the requirements for a
software system. Requirements management is the
process of managing and controlling these changes.