Chapter Three

Requirements Engineering

1
 30/10/2014

Requirements engineering

• A software requirement
• Is condition or capability needed by a user to solve a
problem or achieve an objective
• must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or
other formally imposed document.

2
 30/10/2014

Requirements engineering

• Requirements Engineering
• is a systematic way of developing requirements through
• iterative process of analyzing a problem
• documenting the resulting observations, and
• checking the accuracy of the understanding gained.

3
 Requirements engineering

• Requirements Engineering provides the techniques for

• understanding what a customer wants,
• analyzing it, assessing feasibility,
• negotiating a reasonable solution,
• specifying the solution unambiguously,
• validating the specification, and
• managing the requirements as they are transformed into an
operational system
 Types of requirement

• 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.
 30/10/2014

User and system requirements

6
Readers of different types of requirements 30/10/2014

specification

7
 System stakeholders

• Any person or organization who is affected by the system

in some way and so who has a legitimate interest
• Stakeholder types
• End users
• System managers
• System owners
• External stakeholders
8
 30/10/2014

Stakeholders in the Mentcare system

• 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.
9
 30/10/2014

Stakeholders in the Mentcare 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.

10
Functional and non-functional requirements

11
 30/10/2014

Functional and non-functional requirements

• Functional requirements
• Statements of services the system should provide, how the
system should react to particular inputs and how the
system should behave in particular situations.
• May state what the system should not do.

12
 30/10/2014

Functional and non-functional requirements

• Non-functional requirements
• Constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.
• Often apply to the system as a whole rather than
individual features or services.

13
 30/10/2014

Functional requirements

• Describe functionality or system services.

• Depend on the type of software, expected users and the type of
system where the software is used.
• Functional user requirements may be high-level statements of
what the system should do.
• Functional system requirements should describe the system
services in detail.

14
 30/10/2014

Mentcare system: functional requirements

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

clinics.

• The system shall generate each day, for each clinic, a list of
patients who are expected to attend appointments that day.

• Each staff member using the system shall be uniquely identified

by his or her 8-digit employee number.

15
 30/10/2014

Non-functional requirements

• These define system properties and constraints e.g. reliability,

response time and storage requirements. Constraints are I/O device
capability, system representations, etc.
• Process requirements may also be specified mandating a particular
IDE, programming language or development method.
• Non-functional requirements may be more critical than functional
requirements. If these are not met, the system may be useless.

16
 30/10/2014

Types of nonfunctional requirement

17
 30/10/2014

Non-functional requirements implementation

• 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.

18
 30/10/2014

Non-functional classifications

• 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.

19
Examples of nonfunctional requirements in the 30/10/2014

Mentcare system
Product requirement
The Mentcare system 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 Mentcare system shall authenticate themselves using
their health authority identity card.

External requirement
The system shall implement patient privacy provisions as set out in
HStan-03-2006-priv.

20
 30/10/2014

Goals and requirements

• Non-functional requirements may be very difficult to state precisely and

imprecise requirements may be difficult to verify.

• Goal
• A general intention of the user such as ease of use.

• Verifiable non-functional requirement

• A statement using some measure that can be objectively tested.

• Goals are helpful to developers as they convey the intentions of the system
users.

21
 30/10/2014

Usability requirements

• 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)

22
Metrics for specifying nonfunctional 30/10/2014

requirements
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
23