TheSoftware Requirements, .. & ..

Requirements Engineering [Part 1]

What are Requirements ? .. Why are they important ?
Defining Requirements Engineering
Criteria of a Good Requirement
Requirements Completeness, & Consistency
Project Failure / Success Factors

Selected topics in Requirements Engineering

Applied Software Engineering
What is a Requirement?

“ .. A requirement is a necessary attribute in a system, a

statement that identifies a capability, characteristic, or
quality factor of a system for it to have value and utility
to a customer or user.”

“ .. A statement that identifies a product or process

operational, functional, or design characteristic or
constraint, which is unambiguous, testable or
measurable, and necessary for product or process
acceptability (by consumers or internal quality
assurance guidelines).” ~IEEE-STD-1220-1998 (IEEE 1998)

2
What is a Requirement?

It may range from a high-level abstract statement of a

service or of a system constraint to a detailed mathematical
functional specification.

This is inevitable as requirements may serve a dual function:

✓ May be the basis for a bid for a contract - therefore must be
open to interpretation.

✓ May be the basis for the contract itself - therefore must be

defined in detail.
✓ Both these statements may be called requirements.

3
Requirements ..
Why are they important ?

“ .. Requirements are important because they provide the

basis for all the development work that follows. Once the
requirements are set, developers initiate the other technical
work: system design, development, testing, implementation,
and operation.”

“Without requirements or design, programming is the art of

adding bugs to an empty text file.”
- Louis Srygley

4
Requirements ..
Why are they important ?
Requirements therefore form the basis for:
oProject Planning; o

Risk Management; o

Trade Off;

o Change Control;

o Acceptance Testing.

5
Requirements ..
Why are they important ?

6
Defining Requirements Engineering

“.. The subset of systems engineering concerned with

discovering, developing, tracing, analyzing, qualifying,

communicating and managing requirements that define

the system at successive levels of abstraction.”

7
Defining Requirements Engineering

• The process of establishing the services that the

customer requires from a system and the constraints
under which it operates and is developed.

• The requirements themselves are the descriptions of

the system services and constraints that are generated
during the requirements engineering process.

8
Requirements Completeness, .. & ..
Consistency
o Theoretically, requirements should be both complete &
consistent.
o Complete; They should include descriptions of all facilities
required.
o Consistent; There should be no conflicts or contradictions in
the descriptions of the system facilities.
o Actually, because of system and environmental complexity,
it is impossible to produce a complete and consistent
requirements document.
9
Other Criteria of Good Requirements

10
 Requirements ..
Why are they important ?
The most common reasons for project failure are not technical.

11
Jeremy Dick, Elizabeth Hull, & Ken Jackson (2017). Requirements Engineering 4th Edition. Springer.
 Requirements ..
Why are they important ?
The most common reasons for project failure are not technical.

12
Jeremy Dick, Elizabeth Hull, & Ken Jackson (2017). Requirements Engineering 4th Edition. Springer.
 Requirements ..
Why are they important ?
The most common reasons for project failure are not technical.

13
Jeremy Dick, Elizabeth Hull, & Ken Jackson (2017). Requirements Engineering 4th Edition. Springer.
 Requirements Classifications, .. & ..
the Requirements Engineering Process
RequirementsAbstraction
Views of Requirements Classifications (Types)
The Importance of Requirements Engineering
Stated Requirements versus Real Requirements
Requirements Engineering Process (Generic)
ASpiral View of the Requirements Engineering Process
Requirements-Related Activities (Detailed)
Top Reasons for Difficulties in Software Projects

Selected topics in Requirements Engineering

Applied Software Engineering
Requirements Abstraction

“ .. 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 for the client in more
contractor must write a system definition
detail so that the client understands and can validate what the
software will do. Both documents may be called the requirements
document for the system.”
15
Views of Requirements Classifications
[ i.e., Types of Requirements ]
Numerous ways to organize requirements types exit.
Common Requirements Classifications include:
o Business REQs: The essential activities of an enterprise (the
reason for developing the software in the first place).
o User REQs: Describes for the customers/users the services the
system provides and its operational constraints.
o Functional REQs: Describes what the software should do.
o Non-Functional REQs: Describes software properties.
o Domain REQs: Describes constraints on the system from the
domain of operation.
o .. Etc.

16
 Recap ..

Defining Requirements Engineering

• The process of establishing the services that the

customer requires from a system and the constraints
under which it operates and is developed.

• The requirements themselves are the descriptions of

the system services and constraints that are generated
during the requirements engineering process.

17
Requirements Engineering .. Why?

“ .. It’s not just a simple matter of writing down what the customer
says (s)he wants.”
o A fundamental problem in business is that requirements are
inherently dynamic; they will change over time as our
understanding of the problem we are trying to solve changes.
o The importance of good requirements and the underlying dynamic
nature of the process mean that we must be (1) as accurate as
possible, and yet be (2) flexible (i.e., we have a process for
developing requirements & accommodating changed requirements
as we clarify the real requirements of customers).

18
Requirements Engineering .. Why?

“ .. Too often, there is a tendency to want to start what is often

referred to as “the real work” (developing, or programming, the
software) too quickly.”
o Many customers and project managers (PMs) seem to believe that
actual programming work (“coding”) indicates that progress is
being made.
o According to industry experience, insufficient time and effort are
spent on the requirements-related activities associated with
system development.
o Industry experience confirms that a better approach is to invest
more time in requirements gathering, analysis, and management
activities.
19
Requirements Engineering .. Why?
Stated vs. Real Requirements
o Stated Requirements are provided by a user/customer
at the beginning of a software development effort.
o Real Requirements reveal the verified needs for a
particular system or capability (i.e., some real
requirements may be identified that the customer and
users omitted in the stated requirements). Actually,
identifying omitted requirements is a key task of the
Requirements Analysts (RA).

20
Requirements Engineering Process
Generic Activities
The processes used for Requirements Engineering (RE) vary
widely depending on the application domain, the people involved
and the organisation developing the requirements. But, there are
a number of generic activities common to all processes:
• Requirements elicitation;
• Requirements analysis;
• Requirements validation;
• Requirements management.
In practice, RE is an iterative activity in which these processes are
interleaved. 21
Requirements Engineering Process
A Spiral View

22
Requirements Engineering Processes
More detailed Requirements-Related Activities
Start by Identifying the Stakeholders (i.e., anyone who has an interest in
the system, or in the system’s possession of particular
capabilities/qualities). Then Requirements Elicitation is about gaining
an understanding of the customers’ & users’ needs and discovering their
expectations. Followed by stating the REQs in simple sentences and
providing them as a set (Identifying Requirements), ensuring that they
describe the customer’s real needs and are in a form that can be
understood/used by developers of the system (Clarifying & Restating
the Requirements), ensuring that they are well defined (in a way that
means the same thing to all the stakeholders) and that they conform to

the criteria of a good REQ (Analyzing the Requirements). 23

Requirements Engineering Processes
More detailed Requirements-Related Activities
The remaining activities include Specifying the Requirements by
including all the precise detail of each REQ (in a specification document),
Prioritizing the Requirements (in to – for instance – critical, high
priority, normal/average priority, and lower priority) to provide the
opportunity to address the highest priority first and ensure that an
appropriate amount of investment is made in meeting various customer
needs. Partitioning Requirements as those that can be met by – for
example – hardware, software, ..etc., and Allocating Requirements to
different subsystems/components of the system. Sometimes Deriving
Requirements that come about because of the design of a system (but

do not provide a direct benefit to the end user) is required. 24

Requirements Engineering Processes
More detailed Requirements-Related Activities
Final activities include:
Tracking Requirements by tracing where in the system each REQ is
satisfied (so that we can verify that each REQ is being addressed).
Testing & Verifying Requirements; checking the REQs, designs, code,
test-plans, & system products to ensure that all REQs are met. Validating
Requirements (confirming that the real REQs are
implemented in the delivered system).
Managing Requirements (adding, deleting, and modifying REQs during
all the phases of system design, development, integration, testing,
deployment, and operation).

25
Top Reasons for Difficulties in Software
Projects as stated by a group of Project
Managers based on their experience
• The REQs for the project are not explicit.
• Requirements changes are made/accepted without addressing the
associated cost, schedule, and quality impacts.
• A requirements process is not used.
• No mechanism to reach agreement on the definition of the REQs and
to manage the requirements through the project life cycle.
• The “real” customer needs are not defined.
• Known, familiar, proven methods, techniques, & tools are not utilized.
• The customer is not involved as a partner throughout the project life
cycle. 26
 Types of Requirements:
User and System Requirements, .. & ..
the System Stakeholders
System Stakeholders, .. & .. How to Identify Them
User Requirements
System Requirements
Readers of Different Types of Requirements Specification

Selected topics in Requirements Engineering

Applied Software Engineering
System Stakeholders

A stakeholder is anyone (person or organization) who has a

legitimate interest in the project and anyone who will be affected
or influenced by the proposed system in some way.
• Think of customers / system-owners / investors (those who are paying
for the work), end-users / system-users (people who will use the
system), government & public opinion, advisors / regulatory-
authorities (such as legal experts or regulators who have relevant
information about the requirements), system managers, maintenance
& service staff, project groups that are involved in developing the
system (e.g., systems engineers, software engineers, training
personnel, testers, etc.). 28
 System Stakeholders
How to identify them ..?

Roles of stakeholders.
29
(Source: John Boardman Associates (JBA).
 for a Mental Health Care Patient Management System (MHC-PMS);
A system used to maintain records of people receiving care for mental health problems.

System Stakeholders
How to identify them ..? An Example
• Patients whose information is recorded in the system.
• Doctors who are responsible for assessing and treating patients.
• Nurses who coordinate the consultations with doctors and administer
some treatments.
• Medical Receptionists who manage patients’ appointments.
• IT Staff who are responsible for installing and maintaining the system.
• A Medical Ethics Manager who must ensure that the system meets
current ethical guidelines for patient care.
• Health Care Managers who obtain management information from the
system.
• Medical Records Staff who are responsible for ensuring that system
information can be maintained and preserved, and that record keeping
procedures have been properly implemented.

30
 Recap ..

Requirements Abstraction

“ .. 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 for the client in more
contractor must write a system definition
detail so that the client understands and can validate what the
software will do. Both documents may be called the requirements
document for the system.”
31
User REQs versus System REQs

User Requirements:
Statements in natural language plus diagrams of the services
the system provides and its operational constraints. Written for
customers.
System Requirements:
A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract
between client and contractor.

32
 for a Mental Health Care Patient Management System (MHC-PMS);
A system used to maintain records of people receiving care for mental health problems.

User REQs versus System REQs

33
Readers of the Different Types of
Requirements Specification

34
 Types of Requirements:
Functional Requirements
Functional Requirements
Functional Requirements Imprecision

Selected topics in Requirements Engineering

Applied Software Engineering
Functional REQs
the Definition

Statements of services the system should provide, how the

system should react to specific inputs and how the system
should behave in specific situations.

36
Functional REQs
a.k.a. Behavioural REQs or Operational REQs

o Functional requirements is an important category of the real

requirements.
o They describe what the system/software must do; functionality or
services (a function is a useful capability provided by one or more
components of a system). Therefore, they specify an action that a
system must be able to perform.
o They are sometimes called behavioral / operational requirements
because they specify the inputs (stimuli) to the system, the outputs
(responses) from the system, & behavioral relationships between
them.
o Functional User Requirements may be high-level statements of what
the system should do. Functional System Requirements should
describe the system services in detail.
o May state what the system/software should not do.
37
 for a Mental Health Care Patient Management System (MHC-PMS);
A system used to maintain records of people receiving care for mental health problems.

Functional REQs
an Example

o A user shall be able to search the appointments lists for all

clinics.
o The system shall generate each day, for each clinic, a list of
patients who are expected to attend appointments that day.
o Each staff member using the system shall be uniquely
identified by his or her 8-digit employee number.

38
 for a Mental Health Care Patient Management System (MHC-PMS);
A system used to maintain records of people receiving care for mental health problems.

Functional REQs
Requirements Imprecision

o Problems arise when requirements are not precisely stated.

o Ambiguous requirements may be interpreted in different ways
by developers and users.
o Consider the term ‘search’ in requirement 1
o User intention – search for a patient name across all
appointments in all clinics;
o Developer interpretation – search for a patient name in
an individual clinic. User chooses clinic then search.

40
 Types of Requirements:
Non-Functional Requirements
Non-Functional Requirements
Non-Functional Requirements Classifications
Constraints
Implementing Non-Functional Requirements
Verifiable Non-Functional Requirements
Metrics / Fit-Criteria for Specifying Non-Functional REQs
Non-Functional versus Functional REQs

Selected topics in Requirements Engineering

Applied Software Engineering
Non-Functional REQs
the Definition
Non-Functional requirements specify system/software properties (such
as reliability and safety), and constraints on the services or functions
offered by the system (such as timing constraints; response-time), or
constraints on the development process, I/O device capability,
standards, etc. (e.g., process requirements may also be specified
mandating a particular IDE, programming language or development
method).
o Often apply to the entire system/software (rather than individual
features or services).
o Non-functional REQs may be more critical than functional REQs. If
these are not met, the system/software may be useless. 42
Non-Functional REQs Classifications
Types of Non-Functional Requirements
Numerous ways to classify non-functional requirements exist.
According to Ian Sommerville, they can be grouped into 3 classes:
Product Requirements
Requirements which specify that the delivered product must
behave in a particular way (e.g., execution speed, reliability, etc.)
Organisational Requirements
Requirements which are a consequence of organisational policies
and procedures (e.g., process standards used, implementation
requirements, etc.)
External Requirements
Requirements which arise from factors which are external to the
system and its development process (e.g., interoperability
requirements, legislative requirements, etc.)

43
Non-Functional REQs Classifications
Types of Non-Functional Requirements

44
Non-Functional REQs Classifications
Types of Non-Functional Requirements
According to Robertson & Robertson (2012), they can be grouped into 8
classes:
1) Look-and-Feel REQs. The spirit of the product’s appearance.
2) Usability & Humanity REQs. The product’s ease of use, and any
special usability considerations.
3) Performance requirements. How fast, how safe, how accurate, how
reliable, and how available the functionality must be.
4) Operational & Environmental REQs. The environment on which the
product will have to work (e.g., under water), & what considerations
must be made for this environment.
5) Maintainability & Support REQs. Expected changes, and the time
allowed to make them.
6) Cultural REQs. Special requirements that come about because of
the people involved in the product’s development and operation.
7) Legal REQs. The laws and standards that apply to the product.
8) Security REQs. The security and confidentiality of the product.
44
Non-Functional REQs Implementation
Verifiable Non-Functional Requirements

o Non-functional requirements may be very difficult to state

precisely, and imprecise requirements may be difficult to
verify [i.e., normally, their evaluation tends to be subjective &
they are hard to test].
o Given a Goal, which is a general intention of the user (such as
ease-of-use, a.k.a. usability), a Verifiable / Testable Non-
Functional Requirement is a statement using some measure
that can be objectively tested.

45
 for a Mental Health Care Patient Management System (MHC-PMS);
A system used to maintain records of people receiving care for mental health problems.

Non-Functional REQs Implementation

Verifiable Non-Functional Requirements
An Example

The system should be easy to use by medical staff and should

be organized in such a way that user errors are minimized.
[Goal]

Medical staff shall be able to use all the system functions

after four hours of training. After this training, the average
number of errors made by experienced users shall not exceed
two per hour of system use. [Testable Non-Functional
Requirement] 58
Metrics [ Fit-Criteria ] for specifying
Non-Functional REQs
Property Measure

Speed • Processed transactions/second

• User/event response time
• Screen refresh time
Size • Mbytes
• Number of ROM chips
Ease of use • Training time
• Number of help frames
Reliability • Mean time to failure
• Probability of unavailability
• Rate of failure occurrence
• Availability
Robustness • Time to restart after failure
• Percentage of events causing failure
• Probability of data corruption on failure
Portability • Percentage of target dependent statements
• Number of target systems 59
Non-Functional REQs [ Constraints ]

o Solution Constraints; Any mandated technology.

• E.g., The product shall operate using Windows XP.
o Deadlines; Any known deadlines.
• E.g., The product must be available at the beginning of the
new tax year.
o Financial Budget;
o Current System Constraints;
• E.g., The product is a photocopier to be used by an
environmentally conscious organization; it must work with
recycled paper. 60
 Requirements Engineering Processes:
Requirements Specification, .. & ..
the Software Requirements Document
What is Requirements Specification?
Writing a System Requirements Specification
• Natural Language Specification: Guidelines & Problems
• Structured Specifications: Form-based Specifications
• Tabular Specification
• Graphical Models: Use-Cases
The Structure of a Requirements Document [ SRS ]

Selected topics in Requirements Engineering

Applied Software Engineering
Requirements Specification

The process of writing down the user and system requirements

in a requirements document.

✓ User requirements must be understandable by end-users and

customers who do not have a technical background.
✓ System requirements are more detailed requirements and may
include more technical information.
✓ The requirements may be part of a contract for the system
development (It is therefore important that these are as
complete as possible).

50
Requirements Specification
Definition of a Requirement Expression
A Requirement Expression includes a requirement statement
with a set of associated attributes.

[SH234] The ambulance control system shall be able to handle up

to 100 simultaneous emergency calls.
Source: R. Thomas
Priority: Mandatory
Release: 1
Review Status: Accepted
Verifiable: Yes
Verification: By simulation, then by a system test.

51
 Requirements Specification
Ways of Writing
Notation Description

Natural The requirements are written using numbered sentences in natural

Language language. Each sentence should express one requirement.
Structured The requirements are written in natural language on a standard form
Natural or template. Each field provides information about an aspect of
Language the requirement.
Design This approach uses a language like a programming language, but with more
Description abstract features to specify the requirements by defining an
Languages operational model of the system. This approach is now rarely used
although it can be useful for interface specifications.
Graphical Graphical models, supplemented by text annotations, are used to define the
Notations functional requirements for the system; UML use case and sequence
diagrams are commonly used.
Mathematical These notations are based on mathematical concepts such as finite-
Specifications state machines or sets. Although these unambiguous specifications can
reduce the ambiguity in a requirements document, most
customers don’t understand a formal specification. They cannot check that
it represents what they want and are reluctant to accept it as a system
contract
Requirements Specification
Ways of Writing [ Natural Language Spec. ]

Requirements are written as natural language sentences

supplemented by diagrams and tables.

• Used for writing requirements because it is expressive, intuitive

and universal. This means that the requirements can be

understood by users and customers.

53
Requirements Specification
Ways of Writing [ Natural Language Spec. ]
Problems with Natural Language:
1. Lack of Clarity; Precision is difficult without making the document
difficult to read.
2. Requirements Amalgamation; Several different requirements may
be expressed together.
3. Requirements Confusion; and Non-Functional
Functional requirements
tend to be mixed-up.
1. Invent afor
Guidelines standard
Writingformat and use it for all requirements.
Requirements:
2. Use language in a consistent way. Use shall for mandatory
requirements, should for desirable requirements.
3. Use text highlighting to identify key parts of the requirement.
4. Avoid the use of computer jargon.
5. Include an explanation (rationale) of why a requirement is
necessary.
54
Requirements Specification
Ways of Writing [ Natural Language Spec. ]

Example: Requirements for the Insulin Pump Software System

55
Requirements Specification
Ways of Writing [ Natural Language Spec. ]

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.)
56
Requirements Specification
Ways of Writing [ Structured Specifications ]

An approach to writing requirements where the freedom of the

requirements writer is limited, and requirements are written in
a standard way.
o This works well for some types of requirements(e.g.,
requirements for an embedded control system), but is
sometimes too rigid for writing business system requirements.

57
Requirements Specification
Ways of Writing [ Structured Specifications ]

For Example: Form-based specifications

o Definition of the function or entity.
o Description of inputs and where they come from.
o Description of outputs and where they go to.
o Information about the information needed for the
computation and other entities used.
o Description of the action to be taken.
o Pre- conditions and post-conditions (if appropriate).
o The side effects (if any) of the function. 70
Requirements Specification
Ways of Writing [ Structured Specifications ]

Example: Requirements for the Insulin Pump Software System

Insulin Pump/Control Software/SRS/3.3.2
Function Compute insulin dose: safe sugar level.
Description
Computes the dose of insulin to be delivered when the
current measured sugar level is in the safe zone between 3 and 7
units.
Inputs Current sugar reading (r2); the previous two readings (r0
and r1).
Source Current sugar reading from sensor. Other readings
from memory.
Outputs CompDose—the dose in insulin to be delivered.
Destination Main control loop.
71
Requirements Specification
Ways of Writing [ Structured Specifications ]
Action
CompDose is zero if the sugar level is stable or falling or if the
level is increasing but the rate of increase is decreasing. If the
level is increasing and the rate of increase is increasing, then
CompDose is computed by dividing the difference between the
current sugar level and the previous level by 4 and rounding the
result. If the result, is rounded to zero then CompDose is set to
the minimum dose that can be delivered.
Requirements
Two previous readings so that the rate of change of sugar level
can be computed.
Pre-condition
The insulin reservoir contains at least the maximum allowed
single dose of insulin.
Post-condition r0 is replaced by r1 then r1 is replaced by r2.
72
Side effects None.
Requirements Specification
Ways of Writing [ Structured Specifications ]

E.g., Volere Requirements Shell

73
Requirements Specification
Ways of Writing [ Tabular Specification ]

Used to supplement natural language.

Particularly useful when you must define several possible

alternative courses of action.

For example, the insulin pump systems bases its computations on

the rate of change of blood sugar level and the tabular
specification explains how to calculate the insulin requirement for
different scenarios. 74
 Requirements Specification
Ways of Writing [ Tabular Specification ]

Example: Requirements for the Insulin Pump Software System

Computation for the Insulin Pump:

Condition Action
Sugar level falling ( r2 < r1 ) CompDose = 0
Sugar level stable ( r2 = r1 ) CompDose = 0
Sugar level increasing & rate of increase decreasing CompDose = 0
( ( r2 – r1 ) < ( r1 – r0 ) )
Sugar level increasing & rate of increase stable or increasing CompDose =
( ( r2 – r1 ) ≥ ( r1 – r0 ) ) round ( ( r2 – r1 ) / 4 )

If rounded result = 0 then

CompDose = MinimumDose

63
Requirements Specification
Ways of Writing [ Graphical Models ]

Example: an ATM System

– A Use Case Diagram
(top level use cases)

64
The Software Requirements Document

The software requirements 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 of
WHAT the system should do rather than HOW it should do it. Note:
Information in Requirements Document depends on the
type of system and the approach to development used (for
instance, systems developed incrementally will, typically, have less

detail in the requirements document). 77

The Software Requirements Document
Typical Users of
a Requirements
Document:

78
 The Software Requirements Document
Typical Structure of a Requirements Document:
Chapter Description

Preface This should define the expected readership of the document and describe its
version history, including a rationale for the creation of a new version and a
summary of the changes made in each version.
Introduction This should describe the need for the system. It should briefly describe
the system’s functions and explain how it will work with other systems. It should
also describe how the system fits into the overall business or strategic objectives
of the organization commissioning the software.
Glossary This should define the technical terms used in the document. You should not make
assumptions about the experience or expertise of the reader.
User Here, you describe the services provided for the user. The nonfunctional system
Requirements requirements should also be described in this section. This description may use
Definition natural language, diagrams, or other notations that are understandable
to customers. Product and process standards that must be followed should
be specified.
System This chapter should present a high-level overview of the anticipated system
Architecture architecture, showing the distribution of functions across system
modules. Architectural components that are reused should be highlighted. 79
 The Software Requirements Document
Typical Structure of a Requirements Document:
Chapter Description
System This should describe the functional and nonfunctional requirements in more detail.
Requirements If necessary, further detail may also be added to the nonfunctional requirements.
Specification Interfaces to other systems may be defined.
System This might include graphical system models showing the relationships between the
Models system components and the system and its environment. Examples of possible
models are object models, data-flow models, or semantic data models.
System This should describe the fundamental assumptions on which the system is based,
Evolution and any anticipated changes due to hardware evolution, changing user needs, and
so on. This section is useful for system designers as it may help them avoid design
decisions that would constrain likely future changes to the system.
Appendices These should provide detailed, specific information that is related to the application
being developed; for example, hardware and database descriptions. Hardware
requirements define the minimal and optimal configurations for the
system. Database requirements define the logical organization of the data
used by the system and the relationships between data.
Index Several indexes to the document may be included. As well as a normal alphabetic
index, there may be an index of diagrams, an index of functions, and so on.
80
The Software Requirements Document
Examples of a Requirements Document:

► Requirements for the MentCare System (a system to support the

clinical management of patients suffering from mental illness):
https://iansommerville.com/software-engineering-book/case-studies/mentcare/

► Software Requirements Specification for a Web Publishing System:

https://www.cse.msu.edu/~cse435/Handouts/SRSExample-webapp.doc

► A Personal Insulin Pump:

• Case Study details: https://iansommerville.com/software-engineering-
book/case-studies/insulin-pump/
• Insulin Pump – an Overview:
https://www.dropbox.com/s/tzc8shdjmrqo4cz/InsulinPumpOverview.pdf?dl=0
• Requirements for the Insulin Pump:
https://www.dropbox.com/s/grgaaxtdas4oj1i/InsulinPumpRequirements.pdf?
dl=0
69
The Software Requirements Document
Examples of a Requirements Document:

► Flight Control System (Airbus 340); System Specification that

describes the architecture of the Airbus 340 flight control system, a
safety critical system that implements the fly-by-wire flight system on
the Airbus.
• Flight Control System (Airbus 340) - Overview:
https://www.slideshare.net/software-engineering-book/airbus-fcs-42647819
• Flight Control System (Airbus 340) - System Specification [ Part 1 ]:
https://www.dropbox.com/s/o6d7056eh3bvv9u/FCS1.pdf?dl=0
• Flight Control System (Airbus 340) - System Specification [ Part 2 ]:
https://www.dropbox.com/s/jbe0ajlhxotvqn2/FCS2.pdf?dl=0

.. + More Examples/Samples in the description below the video.

70
 Le c t u r e i s b a s e d o n i t s c o u n t e r p a r t s i n t h e f o l l o w i n g
courses (and the following resources) :

• Sommerville, I. (2016). Software Engineering 10th Edition. International

Computer Science.
• Jeremy Dick, Elizabeth Hull, & Ken Jackson (2017). Requirements
Engineering 4th Edition. Springer.
• Young, R. R. (2004). The Requirements Engineering Handbook. Artech
House.
• Sommerville, I. (2020). Engineering Software Products. Pearson.

• Lecture source: Dr.AmrS.Ghoneim

Presented by Dr. Sarah Naiem Thank You!