Lecture 10

Types of Requirement
1
1. Functional Requirements
Statements of services the system should provide, how the system should
react to inputs and how the system should behave in particular situations.

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

2
 Functional Requirements
1

1. Describe functionality or system services.

2. Depend on the type of software, expected users and the type of
system where the software is used.
3. When expressed as user requirements, functional requirements are
usually described in an abstract way that can be understood by
system users. high level abstract environment
4. More specific functional system requirements describe the system
functions, its inputs and outputs, exceptions, etc., in detail.

3
 Functional Requirements for the MHC- 1

PMS
1. A user shall be able to search the appointments lists for all clinics.
2. The system shall generate each day, for each clinic, a list of patients
who are expected to attend appointments that day.
3. Each staff member using the system shall be uniquely identified by his
or her 8-digit employee number.

4
 Non-Functional Requirements
1
1. These define system properties and constraints
1. System properties such as reliability, response time and storage
requirements.
2. Constraints on system implementation, such as I/O device capability,
processor speed, network bandwidth, data representation used in
interfaces with other systems
2. Process requirements may also be specified mandating a particular
programming language or development method.
3. Non-functional requirements may be more critical than functional
requirements. If these are not met, the system may be useless.

5
 Non-Functional Classifications
1
1. Product requirements
▪ Requirements which specify that the delivered product must
behave in a particular way e.g., execution speed, reliability, etc.
2. Organisational requirements
▪ Requirements which are a consequence of organisational policies
and procedures e.g., process standards used, development process
requirements (programming language) operational requirements
(how the system will be used), etc.
3. External requirements
▪ Requirements which arise from factors which are external to the
system and its development process e.g., regulatory requirements
(such as a central bank;), legislative requirements (ensure that the
system operates within the law), etc.

6
 Types of Non-Functional Requirements
1
Non-functional
requirements

buy hardware Organizational Product requirements External

out of the box law and
or licenses requirements requirements constraint.

Usability requirements
Delivery Legal
requirements Reliability requirements constraints
implementation Safety requirements Economic
requirements constraints
standards Efficiency requirements
Interoperability
requirements requirements
Performance requirements
Capacity requirements

7
Activity of Non-Functional Requirements
in the MHC-PMS 1
Non-Functional Requirements
Implementation 1

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

9
Usability Requirements 1

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

organized in such a way that user errors are minimized. (Goal)
2. 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)

10
 Metrics for Specifying Non-Functional platform: etheir

Requirements 1
software requirement
or hardware requirement

Property Measure
Performance Processed transactions/second
User/event response time
Screen refresh time
Capacity Mbytes etisalate net servies

Ease of use Training time

Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness restore google tab Time to restart after failure
ex: login --> valied valied input --> rebust Percentage of events causing failure
user + pass --> rebust
Portability Percentage of target dependent statements
- move from one system to another Number of target systems
- work on one system so it should be work on
other system

11
 Actors in RE
1
 Many people are involved besides the requirements specialist. The
stakeholders will vary across projects, but will always include
users/operators and customers.
user consider
stakeholder Stakeholder is an entity/person who is interested in project success.
 Actor is an entity/person/stakeholder who interacts directly with the
system.
 Examples:
 Users: This group comprises those who will operate the software.
It is often a heterogeneous group involving people with different
roles and requirements. (actor)
 Customers: This group comprises those who have commissioned the
software or who represent the software’s target market. (actor)

12
 Actors in RE
1

 Market analyst: A mass-market product will not have a

commissioning customer, so marketing people are often needed to
establish what the market needs and to act as proxy customers.
(stakeholder)
 Regulators: Many application domains, such as banking and
public transport, are regulated. Software in these domains must
comply with the requirements of the regulatory authorities.
(stakeholder)
 Software engineers: These individuals have a legitimate interest
in profiting from developing the software by, for example,
reusing components in or from other products. (actor)

13
 Actors in RE
1

mange  Requirements Manager. A Requirements Manager is a person

responsible for, tracing, prioritizing and agreeing on requirements
and then controlling change and communicating to relevant
stakeholders.
 A Requirements Manager is mainly working with the Requirements
Management process.
 Requirements Developer. A Requirements Developer is a person
acutal
actuvity mainly involved in the Elicitation, Analysis, Modelling, Specification
and Validation of requirements.
 A Requirements Developer is mainly working with the
Requirements Development process.

14
Key Points
1
1. Requirements for a software system set out what the
system should do and define constraints on its operation
and implementation.
2. Functional requirements are statements of the services
that the system must provide or are descriptions of how
some computations must be carried out.
3. Non-functional requirements often constrain the system
being developed and the development process being
used.
4. They often relate to the properties of the system and
therefore apply to the system as a whole.

15
Requirement Engineering Process
▪ The processes used for RE vary widely depending
1 on the application
domain, the people involved and the organization developing the
requirements.
▪ However, there are a number of generic activities common to all processes
1. Requirements elicitation;
2. Requirements analysis;
3. Requirements validation;
4. Requirements management.
▪ In practice, RE is an iterative activity in which these processes are
interleaved.

16
Requirements Elicitation
 Requirements elicitation is: 1

 concerned with the origins of software requirements and how the

software engineer can collect them
 the first stage in building an understanding of the problem the
software is required to solve
 fundamentally a human activity

 where the stakeholders are identified and relationships

established between the development team and the customer.

requirements requirements requirements

capture discovery acquisition

17
Requirements Elicitation
1

 One of the fundamental principles of a good requirements elicitation

process is that of effective communication between the various
stakeholders.
 A critical element of requirements elicitation is informing the project
scope. boundaries if requirement high --> scope high
if requirement less but critical and detailed --> scope high

 A description of the software being specified

 The purpose of the software

 The Deliverables

18
19
No registration
CEOs, if not paid
Executives,
etc. 1
Time/schedule
Experts limitations
Stakeholders Business rules
in the
vendor
domain user source of requirement

Domain The
knowledge operational
environment

Use IOs
platform

Requirements The
Goals organizational
sources environment

CIT, UAE University.

19
Requirements Elicitation
Goals
• “Goal” (“business concern” or “critical
success factor”) refers to the overall
objectives of the software. Goals provide
the motivation for the software but are
often vaguely formulated.
• Software engineers need to pay particular
attention to assessing the value and cost of
goals.
Domain1 knowledge
• Domain knowledge provides the
background against which all elicited
requirements knowledge must be set in
order to understand it.
• The software engineer needs to acquire or
have available knowledge about the
application domain.

Stakeholders
• Much software has proved unsatisfactory because it has stressed the
requirements of one group of stakeholders at the expense of
others. Hence, the delivered software is difficult to use, or subverts
the cultural or political structures of the customer organization.
• The software engineer needs to identify, represent, and manage the
“viewpoints” of many different types of stakeholders

20
Requirements Elicitation
Business rules
• These are statements that define or constrain
some aspect of the structure or the behavior of
the business itself.
• “A student cannot register in next semester’s
courses if there remain some unpaid tuition
fees” would be an example of a business rule
that would be a requirement source for a
university’s course-registration software.
The operational environment
1
• Requirements will be derived from the
environment in which the software will be
executed. These may be, for example, timing
constraints in real-time software.
• These must be sought out actively because
they can greatly affect software feasibility
and cost as well as restrict design choices.

The organizational environment

• Software is often required to support a business
process, the selection of which may be conditioned
by the structure, culture, and internal politics of the
organization.
• The software engineer needs to be sensitive to
these since, in general, new software should not
force unplanned change on the business process.

21
Requirements Elicitation
1

 Once the requirements sources have been identified, the software

engineer can start eliciting requirements from them. It can be very difficult,
in fact users:
 may have difficulty describing their tasks

 May leave important information unstated

 May be unwilling or unable to cooperate.

 The software engineer should identify the known, unknown and

unknowable using elicitation techniques.

22
Requirements Elicitation
Interacting with stakeholders 1 to
discover their requirements. Domain
requirements are also discovered at
this stage.
just gather requirements

create
detail description of requirement
Requirements are what system should do group and organize according to module(groups)
documented and input Groups related
into the next round of requirements and
iteration. organises them into
coherent clusters.

what should be developed first (user decide)

Prioritising requirements and

resolving requirements conflicts.

23
 Requirements Elicitation
Interviews formal --> recording
informal --> not recorded
1

Scenarios

Prototypes
Elicitation Facilitated meetings
Techniques
Observation ethnography

User stories

request for proposal (RFP): client mention use case and prototype
Other techniques

24
 Interviewing
1
• Formal or informal interviews with stakeholders are part of most RE
processes.
• Types of interview
options 1. Closed interviews based on pre-determined list of questions formal interview
ask-->explain 2. Open interviews where there is no predefined agenda. Various
issues are explored with stakeholders.
• Effective interviewing
1. Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
2. Prompt the interviewee to get discussions going using a
requirements proposal, or by working together on a prototype
system.

25
Scenarios
1

• Scenarios are real-life examples of how a system can be used.

• They should include
1. A description of the starting situation;
2. A description of the normal flow of events;
3. A description of what can go wrong;
4. Information about other concurrent activities;
5. A description of the state when the scenario finishes.

26
 Scenario for Collecting Medical History in
MHC-PMS 1

27
Use Cases 1function requaerment --> 1 use case
for every FR there is use case

1
• Use-cases are a scenario based technique in the UML which identify the
actors in an interaction and the interaction itself.
• A set of use cases should describe all possible interactions with the
system.
• High-level graphical model supplemented by more detailed tabular
description.
• Sequence diagrams may be used to add detail to use-cases by showing
the sequence of event processing in the system.

28
 Use Cases for the MHC-PMS
1

actor

29
 Ethnography
1

• People often find it very difficult to explain how they carry out their
routine tasks and how they work together in particular situation.
1. How to tie a shoelace?
2. Difficult to describe but easy to demonstrate process
• Observation is a better way of understanding this type of tasks to
understand what support people need from a computer-based system
• Ethnography is an observational technique that can be used to
after observing
client dose
not able
to explain the
understand operational processes and help derive requirements for
requirements
batter
these processes.
• A social scientist spends a considerable time observing and analysing
how people actually work.

30
 Ethnography
1
• People do not have to explain or articulate their work.
• Ethnographic studies have shown that work is usually richer and more
complex than suggested by simple system models.
• For example observing workers in a bank to understand their everyday
work and hence derive requirements for computer support.
• Ethnography studies cannot be carried out according to a formula
1. They are dependent on the personality of ethnographer
2. The type of process being studied
3. People involved in the process
4. To be effective, the ethnographer must be accepted by the
people being studied
5. The people must feel comfortable to carry on their daily tasks in
the presence of ethnographer.

31
 1

32