Software Engineering

MOHAMMAD SALIM HAMDARD

01/06/2024 Chapter 4 Requirements Engineering 1

 Requirements Engineering

01/06/2024 Chapter 4 Requirements Engineering 2

Topics covered

Functional and non-functional requirements

Requirements engineering processes
Requirements elicitation
Requirements specification
Requirements validation
Requirements change

01/06/2024 Chapter 4 Requirements Engineering 3

Requirements engineering

The requirements for a system are the descriptions of the

services that a system should provide and the constraints
on its operation.
These requirements reflect the needs of customers for a
system that serves a certain purpose such as controlling a
device, placing an order, or finding information.
The process of finding out, analyzing, documenting and
checking these services and constraints is called
requirements engineering (RE).

01/06/2024 Chapter 4 Requirements Engineering 4

Types of requirement

User requirements are

 Statements in natural language plus diagrams of the services the
system provides to system user. Written for customers.
 User requirements are precise descriptions of the system
functionality.
System requirements are
 A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints.
 The system requirements document should define exactly what is to
be implemented. It may be part of the contract between the system
buyer and the software developers.

01/06/2024 Chapter 4 Requirements Engineering 5

User and system requirements

Figure, shows how a user requirement may be expanded into

several system requirements.

01/06/2024 Chapter 4 Requirements Engineering 6

Readers of different types of requirements
specification

You need to write requirements at different levels of detail

because different types of readers use them in different
ways.
 The readers of the user requirements are not usually concerned with
how the system will be implemented and may be managers who are
not interested in the detailed facilities of the system.
 The readers of the system requirements need to know more
precisely what the system will do because they are involved in the
system implementation.
 The different types of document readers are examples of system
stakeholders.

01/06/2024 Chapter 4 Requirements Engineering 7

Cont..

01/06/2024 Chapter 4 Requirements Engineering 8

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

01/06/2024 Chapter 4 Requirements Engineering 9

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.

01/06/2024 Chapter 4 Requirements Engineering 10

Cont..

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

01/06/2024 Chapter 4 Requirements Engineering 11

 Functional and non-functional requirements

01/06/2024 Chapter 4 Requirements Engineering 12

Functional and non-functional requirements

Functional requirements
 These are statements of services the system should provide, how the
system should react to particular inputs and how the system should
behave in particular situations.
Non-functional requirements
 These are constraints on the services or functions offered by the system
such as timing constraints, constraints on the development process(ex.
MySQL and PHP should be used), etc.
 Often apply to the system as a whole rather than individual features or
services.

01/06/2024 Chapter 4 Requirements Engineering 13

To be clear

A functional requirement is a function or feature that must be

included in a system in order to satisfy the business need and be
acceptable to the users.
Example:
 Software should be able to help students view marks, attendance
 Software should be have online fee payment facility etc.
 Software should be able to help teachers view students’
attendance, to upload marks, and perform other daily activities etc.

01/06/2024 Chapter 4 Requirements Engineering 14

Non-functional requirements, as the name suggests, are
requirements that are not directly concerned with the
specific functions delivered by the system.
These define system properties and constraints e.g.
performance, security, efficiency, usability, maintainability,
availability.

01/06/2024 Chapter 4 Requirements Engineering 15

Requirements completeness and Consistency

Problems arise when requirements are not precisely

stated.
Ambiguous requirements may be interpreted in different
ways by developers and users.
In principle, requirements should be both complete and
consistent.
Complete
 They should include descriptions of all facilities required.
Consistent
 There should be no conflicts or contradictions in the
descriptions of the system facilities.

01/06/2024 Chapter 4 Requirements Engineering 16

Non-functional classifications

01/06/2024 Chapter 4 Requirements Engineering 17

Cont..

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, regulatry requirements, etc.

01/06/2024 Chapter 4 Requirements Engineering 18

 Requirements engineering processes

01/06/2024 Chapter 4 Requirements Engineering 19

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 a number of generic activities common
to all processes
 Requirements elicitation and analysis;
 Requirements validation;
 Requirements management.
In practice, RE is an iterative activity in which these
processes are interleaved.

01/06/2024 Chapter 4 Requirements Engineering 20

Requirements elicitation and analysis

Sometimes called requirements elicitation or requirements

discovery.
Involves technical staff working with customers to find out
about the application domain, the services that the system
should provide and the system’s operational constraints.
May involve end-users, managers, engineers involved in
maintenance, domain experts, etc. These are called
stakeholders.

01/06/2024 Chapter 4 Requirements Engineering 21

Requirements elicitation

Software engineers work with a range of system

stakeholders to find out about the application domain, the
services that the system should provide, the required
system performance, hardware constraints, other systems,
etc.
Stages include:
 Requirements discovery,
 Requirements classification and organization,
 Requirements prioritization and negotiation,
 Requirements specification.

01/06/2024 Chapter 4 Requirements Engineering 22

Problems of requirements elicitation

Stakeholders don’t know what they really want.

Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
Organisational and political factors may influence the
system requirements.
The requirements change during the analysis process. New
stakeholders may emerge and the business environment
may change.

01/06/2024 Chapter 4 Requirements Engineering 23

The requirements elicitation and analysis
process

01/06/2024 Chapter 4 Requirements Engineering 24

Process activities

Requirements discovery
• Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
Requirements classification and organisation
• Groups related requirements and organises them into coherent
clusters.
Prioritisation and negotiation
• Prioritising requirements and resolving requirements conflicts.
Requirements specification
• Requirements are documented the next round of the spiral.

01/06/2024 Chapter 4 Requirements Engineering 25

 Requirements elicitation techniques

01/06/2024 Chapter 4 Requirements Engineering 26

Interviewing

Formal or informal interviews with stakeholders are part of

most RE processes.
Types of interview
 Closed interviews based on pre-determined list of questions
 Open interviews where various issues are explored with
stakeholders.
Effective interviewing
 Be open-minded, avoid pre-conceived ideas about the requirements
and are willing to listen to stakeholders.

01/06/2024 Chapter 4 Requirements Engineering 27

Ethnography

A social scientist spends a considerable time observing and

analysing how people actually work.
People do not have to explain or articulate their work.
Social and organisational factors of importance may be
observed.

01/06/2024 Chapter 4 Requirements Engineering 28

Stories and scenarios

Scenarios and user stories are real-life examples of how a

system can be used.
Stories and scenarios are a description of how a system
may be used for a particular task.
Because they are based on a practical situation,
stakeholders can relate to them and can comment on their
situation with respect to the story.

01/06/2024 Chapter 4 Requirements Engineering 29

Scenarios

A structured form of user story

Scenarios should include
 A description of the starting situation;
 A description of the normal flow of events;
 A description of what can go wrong;
 Information about other concurrent activities;
 A description of the state when the scenario finishes.

01/06/2024 Chapter 4 Requirements Engineering 30

Requirements validation

Concerned with demonstrating that the requirements

define the system that the customer really wants.
Requirements error costs are high so validation is very
important
 Fixing a requirements error after delivery may cost up to 100 times
the cost of fixing an implementation error.

01/06/2024 Chapter 4 Requirements Engineering 31

Requirements checking

During the requirements validation process, different types

of checks should be carried out on the requirements. These
checks include:
 Validity. Does the system provide the functions which best support
the customer’s needs?
 Consistency. Are there any requirements conflicts?
 Completeness. Are all functions required by the customer included?
 Realism. Can the requirements be implemented given available
budget and technology

01/06/2024 Chapter 4 Requirements Engineering 32

Requirements validation techniques

Requirements reviews
 Systematic manual analysis of the requirements.
Prototyping
 Using an executable model of the system to check requirements.
Test-case generation
 Developing tests for requirements to check testability.

01/06/2024 Chapter 4 Requirements Engineering 33

Requirements Change

01/06/2024 Chapter 4 Requirements Engineering 34

Requirements management

Requirements management is the process of managing

changing requirements during the requirements
engineering process and system development.
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.

01/06/2024 Chapter 4 Requirements Engineering 35

Requirements change management

Deciding if a requirements change should be accepted

Problem analysis and change specification
 During this stage, the problem or the change proposal is analyzed
to check that it is valid.
Change analysis and costing
 The effect of the proposed change is assessed. Once this analysis
is completed, a decision is made whether or not to proceed with
the requirements change.
Change implementation
 The requirements document and, where necessary, the system
design and implementation, are modified.

01/06/2024 Chapter 4 Requirements Engineering 36

Requirements change management

01/06/2024 Chapter 4 Requirements Engineering 37

 THANK YOU

01/06/2024 Chapter 4 Requirements Engineering 38