CSE 2101 Software Engineering

Lecture 7:
Requirements Engineering

Alicia Layne
September 2019
 Requirements Engineering
• The process of establishing the services that
the customer needs/requires from a system
– and the constraints under which it operates and is
developed.
• The requirements themselves are the
descriptions of the system
– and constraints that are generated during the
requirements engineering process.

(Sommerville, 2016)
 What is a Requirement?
• Services that the customer needs/requires from a
system
• Functional and non-functional descriptions of the
system
• It may range from a high-level abstract statement
of a service or detailed functional specification.
• Requirements serve a dual function
– Outlining system requirements
– Establishing the contractual parameters of the system

(Sommerville, 2016)
 Types of Requirements
• User requirements
– Statements in natural language and maybe diagrams
of the services the system provides
– Written for customers.
• System requirements
– The system’s functions and services (and constraints)
– Defines what should be implemented
– Usually a structured document setting out detailed
descriptions

(Sommerville, 2016)
 User and System Requirements

(Sommerville, 2016)
 Readers of Different Requirements

(Sommerville, 2016)
 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.
• Non-functional Requirements:
– A non-functional requirement is a requirement that
specifies criteria that can be used to judge the
operation of a system, rather than specific behaviours
– Often implicit and relate to quality factors and metrics

(Sommerville, 2016)
 Examples of Functional Requirements
• Generate monthly reports based on total sales
and revenue
• Create (R/U/D) a user
• Calculate the tax payable based on cost and tax
scheme
• Automatically send reports to manager accounts
• Allow users to login with a username and
password

(Sommerville, 2016)
 Examples of Non-Functional Requirements

•Performance
•Scalability
•Capacity
•Dependability
•Maintainability
•Data Integrity
•Usability

(Sommerville, 2016)
 Non-Functional Requirements
• 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.

(Sommerville, 2016)
 Non-Functional Requirements

(Sommerville, 2016)
 Non-Functional Requirements
• 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.

(Sommerville, 2016)
 Non-Functional Requirements

(Sommerville, 2016)
 Requirements Imprecision
• Problems arise when requirements are not precisely
stated.
• Ambiguous requirements may be interpreted in
different ways by developers and users.
• Consider the requirement “search” in requirement 1
– 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.

(Sommerville, 2016)
 Requirements Imprecision
• 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.
• In practice, it is impossible to produce a complete and
consistent requirements document.

(Sommerville, 2016)
 Software Requirements Document
• 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
– It should set of WHAT the system should do rather
than HOW it should do it.

(Sommerville, 2016)
 Agile Methods and Requirements
• Many agile methods argue that producing a
requirements document is a waste of time as
requirements change so quickly.
• The document is therefore always out of date.
• Methods such as XP use incremental requirements
engineering and express requirements as ‘user stories’
• This is practical for business systems but problematic for
systems that require a lot of pre-delivery analysis (e.g.
critical systems) or systems developed by several teams.

(Sommerville, 2016)
 Users of Requirements Document

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

(Sommerville, 2016)
 Structure of a Requirements Document
Chapter Description
System requirements This should describe the functional and nonfunctional requirements in more detail. If
specification necessary, further detail may also be added to the nonfunctional 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.

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

(Sommerville, 2016)
 Requirements and Design
• Requirements are stored in a requirements document.
• User requirements have to be understandable by end-
users and customers who do not have a technical
background.
• System requirements are more detailed requirements
and may include more technical information.
• The requirements may be part of a contract for the
system development
– It is therefore important that these are as complete as
possible.

(Sommerville, 2016)
 Guidelines for Writing Requirements
• Invent a standard format and use it for all
requirements.
• Use language in a consistent way. Use shall for
mandatory requirements, should for desirable
requirements.
• Use text highlighting to identify key parts of the
requirement.
• Possibly include an explanation (rationale) of why
a requirement is necessary – if not apparent

(Sommerville, 2016)
 Problems with Natural Language
• Lack of clarity
– Precision is difficult without making the document
difficult to read
• Requirements confusion
– Functional and non-functional requirements tend
to be mixed-up
• Requirements amalgamation
– Several different requirements may be expressed
together

(Sommerville, 2016)
 Structured Specifications
• Definition of the function or entity.
• Description of inputs and where they come from.
• Description of outputs and where they go to.
• Information about the information needed for
the computation and other entities used.
• Description of the action to be taken. Pre and
post conditions (if appropriate).
• The side effects (if any) of the function.

(Sommerville, 2016)
 Structured Specification Example

(Sommerville, 2016)
 Structured Specification Example

(Sommerville, 2016)
 Requirements Engineering Process
• 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;
– Requirements analysis;
– Requirements validation;
– Requirements management.
• In practice, RE is an iterative activity in which these
processes are interleaved.

(Sommerville, 2016)
 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, trade
unions, etc. These are the stakeholders.

(Sommerville, 2016)
 Problems
• 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.

(Sommerville, 2016)
 Requirements Elicitation and Analysis

(Sommerville, 2016)
 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 in a SRS document (or as specified by the
development model used)

(Sommerville, 2016)
 Requirements Discovery
• The process of gathering information about
the required and existing systems and
distilling the user and system requirements
from this information.
• Interaction is with system stakeholders from
managers to external regulators.
• Systems normally have a range of
stakeholders.

(Sommerville, 2016)
 Interviewing
• Formal or informal interviews with stakeholders are part of
most RE processes
• Types of interviews
– 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.
– Prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by working
together on a prototype system.

(Sommerville, 2016)
 Interviewing
• Normally a mix of closed and open-ended interviewing.
• Interviews are good for getting an overall understanding
of what stakeholders do and how they might interact
with the system.
• Interviews are not good for understanding domain
requirements
• Requirements engineers cannot understand specific
domain terminology;
• Some domain knowledge is so familiar that people find it
hard to articulate or think that it isn’t worth articulating.

(Sommerville, 2016)
 Scenarios
• 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.

(Sommerville, 2016)
 Use Cases
• Use-cases are a scenario based technique in the UML
which identify the actors in an interaction and which
describe 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.

(Sommerville, 2016)
 Use Case Diagram

(Sommerville, 2016)
 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
significantly more than the cost of fixing an
implementation error.

(Sommerville, 2016)
 Requirements Checking
• 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?

(Sommerville, 2016)
 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.

(Sommerville, 2016)
 Requirements Change Management

• Deciding if a requirements change should be

(Sommerville, 2016)
 Requirements Change Management
• Change Analysis and Impact
– 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.

(Sommerville, 2016)