Software Requirements Engineering

Requirements engineering
n The process of establishing the services that a
customer requires from a system and the constraints
under which it operates and is developed.
n The system requirements are the descriptions of the
system services and constraints that are generated
during the requirements engineering process.

May 19, 2024 2

 What is a requirement?
n It may range from a high-level abstract statement of a service or
of a system constraint to a detailed mathematical functional
specification.
n This is inevitable as requirements may serve a dual function
5 May be the basis for a bid for a contract - therefore must be
open to interpretation;
5 May be the basis for the contract itself - therefore must be
defined in detail;
5 Both these statements may be called requirements.

May 19, 2024 3

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
contractor must write a system definition for the client in more
detail so that the client understands and can validate what the
software will do. Both of these documents may be called the
requirements document for the system.”
May 19, 2024 4
Types of requirement
n User requirements
5 Statements in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers.
n System requirements
5 System requirements are more detailed descriptions
of the software system’s functions, services, and
operational constraints.
5 The system requirements document (sometimes
called a functional specification) should define exactly
what is to be implemented. It may be part of the
contract between the system buyer and the software
developers..
May 19, 2024 5
System stakeholders
n Any person or organization who is affected by the
system in some way and who has a legitimate
interest
n Stakeholder types
5 End users
5 System managers
5 System owners
5 External stakeholders

May 19, 2024 6

Agile methods and requirements
n Many agile methods argue that producing detailed
system requirements is a waste of time as
requirements change so quickly.
n The requirements document is therefore always out
of date.
n Agile methods usually use incremental requirements
engineering and may express requirements as ‘user
stories’
n This is practical for business systems but
problematic for systems that require pre-delivery
analysis (e.g. critical systems) or systems developed
by several teams.
May 19, 2024 7
Functional and non-functional
requirements

May 19, 2024 8

Functional and non-functional requirements
n Functional requirements
5 Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave
in particular situations.
5 May state what the system should not do.
n Non-functional requirements
5 Constraints on the services or functions offered by the system such
as timing constraints, constraints on the development process,
standards, etc. Non-functional requirements often apply to the system
as a whole, rather than individual system features or services.
5 Often apply to the system as a whole rather than individual features
or services.
n Domain requirements
5 Constraints on the system from the domain of operation

May 19, 2024 9

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

May 19, 2024 10

 Requirements imprecision
n Problems arise when functional requirements are not
precisely stated.
n Ambiguous requirements may be interpreted in
different ways by developers and users.
n Consider the term ‘search’ in requirement 1
5 User intention – search for a patient name across all
appointments in all clinics;
5 Developer interpretation – search for a patient name in
an individual clinic. User chooses clinic then search.
May 19, 2024 11
Requirements completeness and consistency

In principle, requirements should be both complete and

consistent.
n Complete
5 They should include descriptions of all facilities required.

n Consistent
5 There should be no conflicts or contradictions in the descriptions
of the system facilities.
n In practice, because of system and environmental complexity, it
is impossible to produce a complete and consistent
requirements document.
May 19, 2024 12
Non-functional requirements
n Non-functional requirements, as the name suggests,
are requirements that are not directly concerned with
the specific services delivered by the system to its
users
n These define system properties and constraints e.g.
reliability, response time and storage requirements.
n Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system may be useless.
5 For example, if an aircraft system does not meet its
reliability requirements, it will not be certified as safe
for operation

May 19, 2024 13

Types of nonfunctional requirement

May 19, 2024 14

Non-functional requirements implementation
n Non-functional requirements may affect the overall
architecture of a system rather than the individual
components.
5 For example, to ensure that performance
requirements are met, you may have to organize the
system to minimize communications between
components.
n 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.
5 It may also generate requirements that restrict
existing requirements.
May 19, 2024 15
 Non-functional classifications
n Product requirements
5 Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.

n Organisational requirements
5 Requirements which are a consequence of organisational policies and
procedures e.g. process standards used, implementation requirements,
etc.

n External requirements
5 Requirements which arise from factors which are external to the system
and its development process e.g. interoperability requirements,
legislative requirements, etc.
May 19, 2024 16
Goals and requirements
n Non-functional requirements may be very difficult to state
precisely and imprecise requirements may be difficult to verify.
n Goal
5 A general intention of the user such as ease of use.
n Verifiable non-functional requirement
5 A statement using some measure that can be objectively tested.
n Goals are helpful to developers as they convey the intentions
of the system users.

May 19, 2024 17

Usability requirements
n The system should be easy to use by medical staff
and should be organized in such a way that user
errors are minimized. (Goal)
n 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)

May 19, 2024 18

Metrics for specifying nonfunctional requirements

Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes or any other units

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

May 19, 2024 19

Requirements engineering processes

May 19, 2024 20

Requirements engineering processes
n The processes used for RE vary widely depending
on the application domain, the people involved and
the organisation developing the requirements.
n However, there are a number of generic activities
common to all processes
5 Requirements elicitation;
5 Requirements analysis;
5 Requirements validation;
5 Requirements management.
n In practice, RE is an iterative activity in which these
processes are interleaved.

May 19, 2024 21

A spiral view of the requirements engineering process

May 19, 2024 22

Requirements elicitation

May 19, 2024

2323
Requirements elicitation and analysis
n Sometimes called requirements elicitation or requirements
discovery.
n 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.
n May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These are
called stakeholders.

May 19, 2024 24

Requirements elicitation
n 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.
n Stages include:
5 Requirements discovery,
5 Requirements classification and organization,
5 Requirements prioritization and negotiation,
5 Requirements specification.

May 19, 2024 25

Problems of requirements elicitation
n Stakeholders don’t know what they really want.
n Stakeholders express requirements in their own terms.
n Different stakeholders may have conflicting requirements.
n Organisational and political factors may influence the system
requirements.
n The requirements change during the analysis process. New
stakeholders may emerge and the business environment may
change.

May 19, 2024 26

The requirements elicitation and analysis process

May 19, 2024 27

Process activities
n Requirements discovery
5 Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.

n Requirements classification and organisation

5 Groups related requirements and organises them into coherent
clusters.

n Prioritization and negotiation

5 Prioritizing requirements and resolving requirements conflicts.

n Requirements specification
5 Requirements are documented and input into the next round of the
spiral.
May 19, 2024 28
Requirements discovery
n The process of gathering information about the
required and existing systems and distilling the user
and system requirements from this information.
n Interaction is with system stakeholders from
managers to external regulators.
n Systems normally have a range of stakeholders.

May 19, 2024 29

Interviewing
n Formal or informal interviews with stakeholders are part of
most RE processes.
n Types of interview
5 Closed interviews based on pre-determined list of
questions
5 Open interviews where various issues are explored with
stakeholders.
n Effective interviewing
5 Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
5 Prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by
working together on a prototype system.

May 19, 2024 30

Interviews in practice
n Normally a mix of closed and open-ended interviewing.
n Interviews are good for getting an overall understanding of
what stakeholders do and how they might interact with the
system.
n Interviewers need to be open-minded without pre-conceived
ideas of what the system should do
n You need to prompt the use to talk about the system by
suggesting requirements rather than simply asking them what
they want.

May 19, 2024 31

 Problems with interviews
n Application specialists may use language to describe
their work that isn’t easy for the requirements engineer
to understand.
5 Some domain knowledge is so familiar that people find
it hard to articulate or think that it isn’t worth articulating.
g For example, for a librarian, it goes without saying that all
acquisitions are catalogued before they are added to the
library. However, this may not be obvious to the
interviewer, and so it isn’t taken into account in the
requirements. May 19, 2024 32
Ethnography
n A social scientist spends a considerable time observing and
analysing how people actually work.
n People do not have to explain or articulate their work.
n Social and organisational factors of importance may be
observed.
n Ethnographic studies have shown that work is usually richer
and more complex than suggested by simple system models.

May 19, 2024 33

Scope of ethnography
n Requirements that are derived from the way in which people
actually work, rather than the way in which process definitions
say they ought to work.
n Requirements are derived from cooperation and awareness of
other people’s activities.
5 Awareness of what other people are doing leads to
changes in the ways in which we do things.
n Ethnography is effective for understanding existing processes
but may or may not identify new features that should be
added to a system.
May 19, 2024 34
Focused ethnography
n Combines ethnography with prototyping
n Prototype development results in unanswered questions
which focus the ethnographic analysis.
n Ethnographic studies can reveal critical process details that
are often missed by other requirements elicitation techniques.
n However, because of its focus on the end-user, this approach
is not always appropriate for discovering organizational or
domain requirements. They cannot always identify new
features that should be added to a system.
n Ethnography is not, therefore, a complete approach to
elicitation on its own and it should be used to complement
other approaches, such as use case analysis.

May 19, 2024 35

Ethnography and prototyping for requirements analysis

May 19, 2024 36

Stories and scenarios
n Scenarios and user stories are real-life examples of
how a system can be used.
n Stories and scenarios are a description of how a
system may be used for a particular task.
n Because they are based on a practical situation,
stakeholders can relate to them and can comment
on their situation with respect to the story.

May 19, 2024 37

Scenarios
n Scenarios can be particularly useful for adding detail
to an outline requirements description. They are
descriptions of example interaction sessions
n A structured form of user story
n Scenarios should include
5 A description of the starting situation;
5 A description of the normal flow of events;
5 A description of what can go wrong;
5 Information about other concurrent activities;
5 A description of the state when the scenario finishes.

May 19, 2024 38

Scenarios
n Scenario-based elicitation involves working with
stakeholders to identify scenarios and to capture
details to be included in these scenarios.
n Scenarios may be written as text, supplemented by
diagrams, screen shots, etc. Alternatively, a more
structured approach such as event scenarios or use
cases may be used.

May 19, 2024 39

Use Case
n A use case diagram can describe the different types of users
of a system and the various ways that they interact with the
system
n In its simplest form, a use case identifies the actors involved
in an interaction and names the type of interaction
n Use cases are documented using a high-level use case
diagram. The set of use cases represents all of the possible
interactions that will be described in the system requirements.
n Actors in the process, who may be human or other systems,
are represented as stick figures.
n Each class of interaction is represented as a named ellipse.
n Lines link the actors with the interaction. Optionally,
arrowheads may be added to lines to show how the
interaction is initiated.
May 19, 2024 40
Use Cases

May 19, 2024 41

Requirements specification

May 19, 2024 42

Requirements specification
n The process of writing down the user and system
requirements in a requirements document.
n User requirements have to be understandable by
end-users and customers who do not have a
technical background.
n System requirements are more detailed
requirements and may include more technical
information.
n The requirements may be part of a contract for the
system development
5 It is therefore important that these are as complete as
possible.

May 19, 2024 43

Ways of writing a system requirements specification
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 template.
language Each field provides information about an aspect of the requirement.

Design description This approach uses a language like a programming language, but with more
languages 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 machines
specifications 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

May 19, 2024 44

Requirements and design
n In principle, requirements should state what the
system should do and the design should describe
how it does this.
n In practice, requirements and design are inseparable
5 A system architecture may be designed to structure
the requirements;
5 The system may inter-operate with other systems
that generate design requirements;
5 The use of a specific architecture to satisfy non-
functional requirements may be a domain
requirement.
5 This may be the consequence of a regulatory
requirement.

May 19, 2024 45

Natural language specification
n Requirements are written as natural language
sentences supplemented by diagrams and tables.
n Used for writing requirements because it is
expressive, intuitive and universal. This means that
the requirements can be understood by users and
customers.

May 19, 2024 46

Guidelines for writing requirements
n Invent a standard format and use it for all requirements.
n Use language in a consistent way. Use shall for
mandatory requirements, should for desirable
requirements.
n Use text highlighting to identify key parts of the
requirement.
n Avoid the use of computer jargon.
n Include an explanation (rationale) of why a requirement
is necessary.

May 19, 2024 47

Problems with natural language
n Lack of clarity
5 Precision is difficult without making the document
difficult to read.
n Requirements confusion
5 Functional and non-functional requirements tend to
be mixed-up.
n Requirements amalgamation
5 Several different requirements may be expressed
together.

May 19, 2024 48

Structured specifications
n An approach to writing requirements where the
freedom of the requirements writer is limited and
requirements are written in a standard way.
n This works well for some types of requirements e.g.
requirements for embedded control system but is
sometimes too rigid for writing business system
requirements.

May 19, 2024 49

Form-based specifications
n Definition of the function or entity.
n Description of inputs and where they come from.
n Description of outputs and where they go to.
n Information about the information needed for the
computation and other entities used.
n Description of the action to be taken.
n Pre and post conditions (if appropriate).
n The side effects (if any) of the function.

May 19, 2024 50

The software requirements document
n The software requirements document is the official
statement of what is required of the system
developers.
n Should include both a definition of user requirements
and a specification of the system requirements.
n 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.

May 19, 2024 51

Users of a requirements document

May 19, 2024 52

Requirements document variability
n Information in requirements document depends on
type of system and the approach to development
used.
n Systems developed incrementally will, typically, have
less detail in the requirements document.
n Requirements document standards have been
designed e.g. IEEE standard. These are mostly
applicable to the requirements for large systems
engineering projects.

May 19, 2024 53

The 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 requirements Here, you describe the services provided for the user. The nonfunctional
definition 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.

May 19, 2024 54

Requirements validation

May 19, 2024 55

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

May 19, 2024 56

Requirements checking
n Validity. Does the system provide the functions which best
support the customer’s needs?
n Consistency. Are there any requirements conflicts?
n Completeness. Are all functions required by the customer
included?
n Realism. Can the requirements be implemented given
available budget and technology
n Verifiability. Can the requirements be checked?

May 19, 2024 57

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

May 19, 2024 58

 Requirements reviews
n Regular reviews should be held while the requirements
definition is being formulated.
n Both client and contractor staff should be involved in
reviews.
n Reviews may be formal (with completed documents) or
informal. Good communications between developers,
customers and users can resolve problems at an early
stage.

May 19, 2024 59

Review checks
n Verifiability
5 Is the requirement realistically testable?
n Comprehensibility
5 Is the requirement properly understood?
n Traceability
5 Is the origin of the requirement clearly stated?
n Adaptability
5 Can the requirement be changed without a large
impact on other requirements?

May 19, 2024 60

Requirements change

May 19, 2024 61

Changing requirements
n The business and technical environment of the system always
changes after installation.
5 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.
n The people who pay for a system and the users of that
system are rarely the same people.
5 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.
May 19, 2024 62
 Changing requirements
n Large systems usually have a diverse user community,
with many users having different requirements and
priorities that may be conflicting or contradictory.
5 The final system requirements are inevitably a
compromise between them and, with experience, it is
often discovered that the balance of support given to
different users has to be changed.

May 19, 2024 63

Requirements evolution

May 19, 2024 64

Requirements management
n Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development.
n New requirements emerge as a system is being
developed and after it has gone into use.
n 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.

May 19, 2024 65

Requirements management planning
n Establishes the level of requirements management detail that is
required.
n Requirements management decisions:
5 Requirements identification Each requirement must be
uniquely identified so that it can be cross-referenced with other
requirements.
5 A change management process This is the set of activities that
assess the impact and cost of changes.
5 Traceability policies These policies define the relationships
between each requirement and between the requirements and
the system design that should be recorded.
5 Tool support Tools that may be used range from specialist
requirements management systems to spreadsheets and
simple database systems.

May 19, 2024 66

Requirements change management
n Deciding if a requirements change should be accepted
5 Problem analysis and change specification
g 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 Change analysis and costing
g to withdraw the request.
g 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.
5 Change implementation
g 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.

May 19, 2024 67

Requirements change management

May 19, 2024 68