Software Engineering

Requirements Engineering
 𝐴
Requirements engineering = 𝜋𝑟 2

The process to gather the software

requirements from client, analyze and
document them is known as requirement
engineering.
The process of establishing the services
that the customer requires from a system
and the constraints under which it operates
and is developed.
 Why so difficult? 𝐴
Software designer
= 𝜋𝑟 2
Users/stakeholders

Interaction….match

– Different “worlds”
– using vs designing something
– knowing what should be done vs knowing to let a
computer do that
– Users/stakeholders are not an uniform group
– conflict between cost and usability / performance /
features
– conflicting demands from different departments
– Getting the good (ideal) system vs possibility building it
3
good
 𝐴
Requirements Example = 𝜋𝑟 2

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 / her 8-digit
employee number.
 𝐴
Requirements imprecision = 𝜋𝑟 2

Ambiguous requirements may be

interpreted in different ways by developers
and users.
Consider the term ‘search’ in requirement
▪ User intention – search for a patient name
across all appointments in all clinics;
▪ Developer interpretation – search for a patient
name in an individual clinic. User chooses
clinic then search.
 𝐴
Requirements completeness and consistency = 𝜋𝑟 2

Complete
▪ They should include descriptions of all facilities
required.
Consistent
▪ There should be no conflicts or contradictions
in the descriptions of the system facilities.
In practice, it is impossible to produce a
complete and consistent requirements
document.
RE Process and Related Activities

Why? Identify Business Needs and Goals

What? Derive User & Functional Requirements

Time
Design Solutions
How?
TIME

Project Management Process

Who?
When? Risk Management Process

If-Then Quality Management Process

Does It? Component & Configuration Management Process

Where? 7
 𝐴
Users of a requirements document = 𝜋𝑟 2
 𝐴
Requirement Elicitation Techniques = 𝜋𝑟 2

 Interviews
▪ Structured (closed) interviews
▪ Non-structured (open) interviews
▪ One-to-one interviews
▪ Group interviews
 Surveys
 Questionnaires
 𝐴
Requirements categorized logically = 𝜋𝑟 2

Must Have : Software cannot be said

operational without them.
Should have : Enhancing the functionality of
software.
Could have : Software can still properly function
with these requirements.
Wish list : These requirements do not map to
any objectives of software.
 𝐴
Requirement Engineering Process = 𝜋𝑟 2

Feasibility Study
Requirement Gathering
Requirement Specification
Requirement Validation
 𝐴
Feasibility study = 𝜋𝑟 2

When the client approaches the

organization for getting the desired
product developed, it comes up with
rough idea about what all functions
the software must perform and which
all features are expected from the
software.
 𝐴
Types of requirement = 𝜋𝑟 2

Business Requirements:
▪ the scope of the project and identify stakeholders

User requirements
▪ concern the user goals of the
system
▪ Statements in natural language plus
diagrams of the services the system
provides and its operational
constraints. Written for customers.
 𝐴
Types of requirement = 𝜋𝑟 2

System requirements
▪ define functional and non-functional (or
quality) 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.
 𝐴
Example = 𝜋𝑟 2

you are designing a website for

teachers to post homework
assignments online
▪ Allow teachers to upload documents.
▪ Provide a login for teachers.
▪ Be accessible from schools and
teachers' homes.
𝐴
= 𝜋𝑟 2
 𝐴
System requirements Types
= 𝜋𝑟 2

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.
Non-functional requirements
▪ Constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.
Domain requirements
▪ Constraints on the system from the domain of operation
 𝐴
Functional requirements = 𝜋𝑟 2

Describe functionality or system

services.
Depend on the type of software,
expected users and the type of system
where the software is used.
Functional system requirements should
describe the system services in detail.
 𝐴
Functional requirements Example = 𝜋𝑟 2

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 / her 8-digit
employee number.
 𝐴
Non-functional requirements = 𝜋𝑟 2

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 in programming
language or development method.
 𝐴
Non-functional requirements implementation = 𝜋𝑟 2

Non-functional requirements may affect the

overall architecture of a system rather than
the individual 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.
 𝐴
Types of nonfunctional requirement = 𝜋𝑟 2
 𝐴
Non-functional classifications = 𝜋𝑟 2

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.
 𝐴
Examples of nonfunctional requirements
= 𝜋𝑟 2

Product requirement
The 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 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.
 𝐴
Usability requirements Example = 𝜋𝑟 2

The system should be easy to use by

medical staff and should be organized in
such a way that user errors are minimized.
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)
 𝐴
Metrics for specifying nonfunctional requirements= 𝜋𝑟 2

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
 𝐴
Domain requirements = 𝜋𝑟 2

The system’s operational domain 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 be new functional
requirements, constraints on existing requirements
or define specific computations.
If domain requirements are not satisfied, the system
may be unworkable.
 𝐴
Train protection system Example = 𝜋𝑟 2

This is a domain requirement for a train protection

system:
The deceleration of the train shall be computed as:
▪ Dtrain = Dcontrol + Dgradient
▪ where Dgradient is 9.81ms2 * compensated
gradient/alpha and where the values of 9.81ms2 /alpha
are known for different types of train.
It is difficult for a non-specialist to understand the
implications of this and how it interacts with other
requirements.
 𝐴
Domain requirements problems = 𝜋𝑟 2

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.
 𝐴
The software requirements document= 𝜋𝑟 2

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.
 𝐴
Problem Identification & Requirements Specification
= 𝜋𝑟 2

 Answering question:
▪ What problem is being solved?
 10-25% of life cycle should be spent here
▪ E.g., Expected software or application life is 10 years
• 1 to 2.5 years in this phase
 Techniques
▪ Partitioning: Divide and conquer
• Parts & relationships
▪ Abstraction: Defining in general terms
• Leaving out details
▪ Projection: Viewing problem from different perspectives
• User perspective, programmer perspective, maintainer perspective
▪ Many other techniques
• E.g., data flow diagrams
 𝐴
Banking ATM system Example = 𝜋𝑟 2

 The example used here is an auto-teller system which

provides some automated banking services
 I use a very simplified system which offers some services to
customers of the bank who own the system and a narrower
range of services to other customers
 Services include cash withdrawal, message passing (send a
message to request a service), ordering a statement and
transferring funds
 𝐴
Requirements document variability = 𝜋𝑟 2

Information in requirements document

depends on type of system and the
approach to development used.
Requirements documents standards have
been designed e.g. IEEE standard. These
are mostly applicable to the requirements
for large systems engineering projects.
The structure of a requirements document 𝐴
= 𝜋𝑟 2
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 requirements Here, you describe the services provided for the user. The
definition nonfunctional system requirements should also be described in this
section. This description may use natural language, diagrams, or other
notations that are understandable to customers. Product and process
standards that must be followed should be specified.
System architecture This chapter should present a high-level overview of the anticipated
system architecture, showing the distribution of functions across
system modules. Architectural components that are reused should be
highlighted.
 𝐴
The structure of a requirements document = 𝜋𝑟 2
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 between
the system components and the system and its environment. Examples of
possible models are object models, data-flow models, or semantic data models.

System evolution This should describe the fundamental assumptions on which the system is
based, 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.
Ways of writing a system requirements 𝐴
specification = 𝜋𝑟 2

Notation Description
Natural language The requirements are written using numbered sentences in natural
language. Each sentence should express one requirement.
Structured natural The requirements are written in natural language on a standard form or
language template. Each field provides information about an aspect of the
requirement.
Design description This approach uses a language like a programming language, but with
languages more abstract features to specify the requirements by defining an
operational model of the system. This approach is now rarely used although
it can be useful for interface specifications.
Graphical notations 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.
Mathematical These notations are based on mathematical concepts such as finite-state
specifications 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
Example requirements for the insulin pump
software system 𝐴
= 𝜋𝑟 2
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.)
A structured specification of a requirement for 𝐴
an insulin pump = 𝜋𝑟 2
A structured specification of a requirement for 𝐴
an insulin pump = 𝜋𝑟 2
Tabular specification of computation for an 𝐴
insulin pump = 𝜋𝑟 2

Condition Action

Sugar level falling (r2 < r1) CompDose = 0

Sugar level stable (r2 = r1) CompDose = 0

Sugar level increasing and rate of increase CompDose = 0

decreasing
((r2 – r1) < (r1 – r0))

Sugar level increasing and rate of increase stable or CompDose =

increasing round ((r2 – r1)/4)
((r2 – r1) ≥ (r1 – r0)) If rounded result = 0 then
CompDose = MinimumDose
 𝐴
Stakeholders in the MHC-PMS = 𝜋𝑟 2

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.
 𝐴
Scenarios = 𝜋𝑟 2

Scenarios are real-life examples of how a

system can be used.
They 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.
 𝐴
Example = 𝜋𝑟 2

 Scenario 1: User logs in using a valid username and

password
 Scenario 2: User performs search using item description

 Requirement 1: only authorized user can use the system

 Requirement 2: search result page should only return the
first 50 records
 𝐴
Scenario: customer withdrawing money from ATM = 𝜋𝑟 2

 It’s Friday afternoon and Hassan is flying to Aswan.

 He doesn’t have enough money for a taxi to the airport,
and he’s running late.
 He goes to the local ATM and identifies himself.
 He specifies that he wants 100 from his savings account.
 He’d like the money in 20 notes so that he can give the
taxi driver the correct change.
 He doesn’t want a printed receipt, as he doesn’t bother
keeping track of transactions in this account.
 𝐴
In details = 𝜋𝑟 2

 Mohamed Hassan presses the "Withdraw Funds" button in ATM

 The ATM displays the preset withdrawal amounts (20, 100, and so on)
 Mohamed chooses the option to specify the amount of the withdrawal
 The ATM displays an input field for the withdrawal amount
 Mohamed indicates that he wishes to withdraw 500
 The ATM displays a list of Mohamed's accounts, a checking and two
savings accounts
 Mohamed chooses his checking account
 The ATM verifies that the amount may be withdrawn from his account
 The ATM verifies that there is at least 500 available to be disbursed from
the machine
 𝐴
= 𝜋𝑟 2

 The ATM debits Mohamed's account by 500

 The ATM disburses 500 in cash
 The ATM displays the "Do you wish to print a receipt"
options
 Mohamed indicates "Yes"
 The ATM prints the receipt
 𝐴
Event scenario - start transaction = 𝜋𝑟 2
Scenario for collecting medical history in MHC- 𝐴
PMS = 𝜋𝑟 2
Scenario for collecting medical history in MHC- 𝐴
PMS = 𝜋𝑟 2
 𝐴
Requirements validation = 𝜋𝑟 2

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.
 𝐴
Requirements checking = 𝜋𝑟 2

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
Verifiability. Can the requirements be checked?
 𝐴
Requirements validation techniques
= 𝜋𝑟 2

Requirements reviews
▪ Systematic manual analysis of the
requirements.
Prototyping
▪ Using an executable model of the system to
check requirements. Covered in Chapter 2.
Test-case generation
▪ Developing tests for requirements to check
testability.
 𝐴
Requirements management = 𝜋𝑟 2

 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.
You need to establish a formal process for making
change proposals and linking these to system
requirements.
 𝐴
Changing requirements = 𝜋𝑟 2

Requirements will change!

▪ inadequately captured or expressed in the first place
▪ user and business needs may change during the project
Validation is needed throughout the software
lifecycle, not only when the “final system” is
delivered!
▪ build constant feedback into your project plan
▪ plan for change
▪ early prototyping [e.g., UI] can help clarify requirements
 𝐴
Changing requirements = 𝜋𝑟 2

 The business and technical environment of the system

always changes after installation.
▪ New hardware may be introduced, it may be necessary to interface
the system with other systems, business priorities may change (with
consequent changes in the system support required), and new
legislation and regulations may be introduced that the system must
necessarily abide by.
 The people who pay for a system and the users of that
system are rarely the same people.
▪ System customers impose requirements because of organizational
and budgetary constraints. These may conflict with end-user
requirements and, after delivery, new features may have to be added
for user support if the system is to meet its goals.
 𝐴
Requirements evolution = 𝜋𝑟 2
 𝐴
Requirements change management = 𝜋𝑟 2

 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. This analysis is fed back to the change
requestor who may respond with a more specific requirements
change proposal, or decide to withdraw the request.
▪ Change analysis and costing
• The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements.
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. Ideally, the document
should be organized so that changes can be easily implemented.