Week 5 Study Notes

Requirements Engineering
Based on Pressman & Maxim — Software Engineering, Chapter 4

KEY DEFINITIONS

Requirements Engineering (RE): The process of establishing the services a customer requires
from a system, and the constraints under which it operates and is developed. It covers elicitation,
analysis, specification, validation, and management of requirements.

Requirement: A description of a service or constraint that a system must satisfy. Requirements

range from high-level abstract statements to precise mathematical specifications, and may serve
as both a basis for a contract bid and the contract itself.

User Requirements: High-level statements, written in natural language (often with diagrams),
describing what services the system should provide and its operational constraints. Written for
customers and non-technical stakeholders.

System Requirements: Detailed, structured descriptions of the system's functions, services, and
constraints. Technical enough to form part of a contract between client and developer. Defines
what must be implemented.

Functional Requirements: Statements of specific things a system must do — the services it

provides, how it reacts to inputs, and how it behaves in particular situations. May also state what
the system must NOT do.

Non-Functional Requirements (NFRs): Constraints on the system as a whole, rather than on

individual features. Include performance, reliability, security, usability, portability, and process
requirements. If NFRs are not met, the system may be useless even if all functional requirements
are satisfied.

Domain Requirements: Requirements derived from the application domain of the system —
constraints or behaviours that reflect rules, standards, or practices specific to the field (e.g.
healthcare regulations, aviation standards).

Stakeholder: Any person or organisation affected by the system who has a legitimate interest in
it. Includes end users, managers, system owners, external regulators, and anyone else whose
needs must be considered.

Requirements Elicitation: The process of gathering requirements by working with stakeholders

to discover what the system needs to do. Also called requirements discovery. Involves interviews,
observation, scenarios, and other techniques.

Requirements Specification: The process of writing requirements down formally in a

requirements document. Includes both user requirements (readable by non-technical
stakeholders) and system requirements (detailed and technical).

Requirements Validation: Checking that the written requirements actually define the system the
customer wants. Crucial because fixing a requirements error after delivery can cost up to 100
times more than fixing it during development.

Requirements Management: The process of tracking, controlling, and managing changes to

requirements throughout the development lifecycle. Includes maintaining traceability links
between requirements and system components.

Stakeholder: Any person or organisation affected by the system in some way. Types include:
end users, system managers, system owners, and external stakeholders (e.g. regulators).

Use Case: A UML technique for describing system interactions. A use case identifies the actors
(users or external systems) involved in an interaction and describes the sequence of steps in that
interaction. A complete set of use cases should cover all possible system interactions.

Scenario: A structured, real-world example of how a system is used for a particular task.
Includes: starting situation, normal flow of events, what can go wrong, concurrent activities, and
final state. More detailed than a user story.

Prototyping: Building an early executable model of the system to explore requirements, check
feasibility, and validate that requirements reflect what users actually need.

Ethnography: A requirements elicitation technique where an observer studies how people

actually work in their environment, without asking them to explain. Uncovers implicit, unstated
requirements that emerge from real work practices.

Traceability: The ability to link each requirement back to its origin (why it was needed) and
forward to the design/code that implements it. Essential for impact analysis when requirements
change.

Requirements Document (SRS): The official statement of what is required of the system
developers. Contains both user requirements and system requirements. NOT a design document
— it says WHAT the system must do, not HOW.

Verifiable Non-Functional Requirement: An NFR expressed using an objective, measurable

criterion that can be tested. For example: 'Medical staff shall be able to use all system functions
after four hours of training' — as opposed to vague goals like 'the system should be easy to use'.

Requirements Change Management: A formal process for evaluating and implementing

changes to requirements. Three steps: (1) Problem analysis and change specification, (2)
Change analysis and costing, (3) Change implementation.

Completeness (of requirements): All services and constraints required by the system are
described in the requirements document. In practice, achieving complete requirements is
extremely difficult due to system complexity.
 Consistency (of requirements): There are no conflicts or contradictions between requirements.
In practice, achieving full consistency is also very difficult, especially for large systems with many
stakeholders.

1. WHAT IS REQUIREMENTS ENGINEERING?

Requirements Engineering (RE) is the process of establishing what services a customer requires
from a system, and the constraints under which it must operate and be built. The output is a set of
system requirements.

What is a requirement?
A requirement can range from a vague high-level statement (e.g. 'the system must be fast') to a
precise mathematical specification. Requirements serve a dual function: they may be the basis for a
bid for a contract (so they must be open to interpretation) AND the basis for the contract itself (so
they must be defined in detail). Both of these can be called requirements.

Two levels of requirements:

Type Description

User Requirements Written in natural language, often with diagrams. Describe services and operational constraints fro

System Requirements Structured, detailed technical descriptions of functions, services, and constraints. May form part of

System stakeholders
A stakeholder is any person or organisation affected by the system who has a legitimate interest.
Requirements must account for all stakeholder perspectives, which often conflict.

• End users — people who interact with the system directly

• System managers — people who manage the use of the system
• System owners — people who paid for and own the system
• External stakeholders — regulators, legal bodies, auditors

Note: Example from the Mentcare system: stakeholders include patients, doctors, nurses, receptionists, IT
staff, medical ethics managers, healthcare managers, and medical records staff — all with different and
sometimes conflicting needs.

2. FUNCTIONAL vs. NON-FUNCTIONAL REQUIREMENTS

Type Description Mentcare Example

Functional Describe specific things the system must do — services,

Search appointments
behaviours, and
list; responses
generate daily
to inputs.
patientMay
attendance
also sta

Non-Functional Constraints on the system as a whole — reliability,

System
performance,
available security,
Mon–Fri usability,
0830–[Link]
Notmax
tied 5toseconds
individuad
Domain Requirements from the application domain — rules,
System
standards,
must implement
or practices
patient
specific
privacy
to the
asfield
set out
thatinthe
HStan-
syst

Non-Functional Requirements in Detail

NFRs are often MORE critical than functional requirements. A system that is fast but insecure, or
functional but unusable, fails its purpose. NFRs are also harder to specify and verify.

Three categories of NFRs:

Category Description Examples

Product requirements Specify how the delivered product must [Link], reliability, memory usage, usability.

Organisational requirementsArise from policies and procedures of the developing

Use oforspecific
client organisation.
programming language, development

External requirements Arise from factors outside the system and its development
Legal compliance,
[Link] with other systems,

Goals vs. Verifiable NFRs

Non-functional requirements are often stated vaguely as goals. Goals are useful for conveying
intent, but they must be made verifiable (measurable) to be useful for development and testing.

Type Example

Goal (vague) The system should be easy to use by medical staff and should minimise user errors.

Verifiable NFR Medical staff shall be able to use all system functions after four hours of training. After training, experienc

Common metrics for NFRs:

Property Measure

Speed Transactions per second; user/event response time; screen refresh time

Reliability Mean time to failure; probability of unavailability; rate of failure occurrence

Usability Training time required; number of help frames accessed

Robustness Time to restart after failure; probability of data corruption on failure

Portability Percentage of target-dependent code statements; number of supported target systems

3. THE REQUIREMENTS ENGINEERING PROCESS

RE is not a linear sequence — it is an iterative, spiral activity. The same core activities repeat at
increasing levels of detail:

Activity Description

1. Requirements Elicitation Gathering requirements from stakeholders and the application domain.
2. Requirements Analysis Analysing and refining requirements; resolving conflicts and ambiguities.

3. Requirements Validation Checking that requirements define what the customer actually wants.

4. Requirements Management Managing changes to requirements throughout the project lifecycle.

Note: These activities are interleaved in practice, not done sequentially. New discoveries during analysis
may trigger more elicitation. This is why RE is visualised as a spiral, not a straight line.

Agile methods and requirements:

Many agile methods argue that detailed requirements documentation is wasteful because
requirements change so quickly that any document becomes outdated immediately. Agile teams
use incremental requirements engineering, expressing requirements as user stories. This works well
for business systems but is problematic for safety-critical systems or multi-team projects that need
pre-delivery analysis.

4. REQUIREMENTS ELICITATION

Requirements elicitation (also called requirements discovery) involves technical staff working with
stakeholders to find out about: the application domain, the services the system must provide,
required performance, hardware constraints, and interactions with other systems.

Four stages of elicitation:

• Requirements discovery — gathering information from stakeholders and domain sources
• Requirements classification and organisation — grouping related requirements into coherent
clusters
• Requirements prioritisation and negotiation — resolving conflicts and ranking requirements by
importance
• Requirements specification — documenting requirements as input to the next iteration

Problems with requirements elicitation:

• Stakeholders often don't know exactly what they want
• Stakeholders express requirements in domain-specific terms the engineer may not understand
• Different stakeholders have conflicting requirements
• Organisational and political factors influence what requirements are stated
• Requirements change during analysis; new stakeholders emerge

Elicitation Technique 1: Interviewing

Formal or informal conversations with stakeholders. Most RE processes include some form of
interviewing.

Type Description
Closed interviews Based on a pre-determined list of questions. Efficient for gathering specific information.

Open interviews Exploratory — various issues are discussed freely with the stakeholder. Better for discovering unexpe

Effective interviewing requires:

• Being open-minded — avoid pre-conceived ideas about what the system should do
• Actively listening, not just collecting answers
• Using a prompt (springboard question, prototype, or requirements proposal) to get discussion
going

Problems with interviews:

• Domain specialists use jargon the requirements engineer doesn't understand
• Some domain knowledge is so familiar that experts forget to mention it
• Interviews are not good for understanding deep domain-specific requirements

Elicitation Technique 2: Ethnography

A researcher observes people working in their real environment for an extended period — without
asking them to explain or justify what they do. The goal is to discover how work actually happens,
not how it is supposed to happen.

What ethnography reveals:

• Requirements that emerge from actual work practice, not formal process definitions
• Requirements based on how people cooperate and coordinate with each other
• Implicit assumptions and tacit knowledge that people never think to mention

Limitations of ethnography:
• Cannot identify new features that should be added — only reveals how existing work happens
• May uncover historical practices that are no longer relevant
• Time-consuming and resource-intensive

Focused ethnography:
Combines ethnography with prototyping. Building a prototype raises unanswered questions, which
then focus the ethnographic observation. More efficient than pure ethnography.

Elicitation Technique 3: Stories and Scenarios

Scenarios are structured real-life examples of how a system will be used for a specific task.
Because they are grounded in practical situations, stakeholders find it easier to understand and
comment on them than on abstract requirement statements.

A complete scenario includes:

• Starting situation — what is the state before the interaction begins
• Normal flow of events — the expected step-by-step interaction
• What can go wrong — alternative or error flows
 • Other concurrent activities — what else might be happening in parallel
• Final state — what the system state is when the scenario ends

Note: User stories (used in XP/Scrum) are informal, brief versions of scenarios. Scenarios are more
structured and detailed — they include error handling and system state.

5. REQUIREMENTS SPECIFICATION

Requirements specification is the process of formally writing down both user and system
requirements in a requirements document (also called the Software Requirements Specification —
SRS).

• User requirements must be understandable by non-technical customers

• System requirements are more detailed and may include technical information
• Requirements may form part of a contract — so completeness is critical
• The SRS states WHAT the system must do, NOT HOW it will do it (that is design)

Ways of Writing Requirements

Notation Description Limitation

Natural language Numbered sentences in plain English. Expressive

Risk
andofuniversal
ambiguity,
—mixed
readable
functional/non-functional
by all stakeholders. Most
requc

Structured natural languageNatural language written in a standard template/form.

Can beEach
too rigid
field for
covers
complex
a specific
business
aspect
requirements.
of the require

Design description languages

Specification using abstract programming-like language.
Rarely used
Precise
now;and
hardunambiguous.
for non-technical stakeholders t

Graphical notations UML use case and sequence diagrams supplemented

Requires
by UML
text. Good
knowledge;
for showing
may miss
interactions.
detail.

Mathematical specificationsFormal notations based on mathematics (e.g. finite-state

Most customers
machines).
cannot
Completely
read or verify
unambiguous.
them.

Guidelines for Writing Natural Language Requirements

• Use a standard format consistently across all requirements
• Use 'shall' for mandatory requirements, 'should' for desirable ones
• Use text highlighting to identify key parts
• Avoid computer jargon when writing for non-technical readers
• Include an explanation (rationale) of why each requirement is necessary

Problems with natural language:

• Lack of clarity — precision is hard to achieve without making the document unreadable
• Requirements confusion — functional and non-functional requirements get mixed together
• Requirements amalgamation — several different requirements combined into one sentence

Use Cases
Use cases are a UML technique for specifying system interactions. Each use case identifies the
actors involved (users or external systems) and describes the interaction itself. A complete set of
use cases should cover all possible system interactions.

• High-level graphical model shows which actors interact with which use cases
• Supplemented by detailed tabular descriptions of each interaction
• UML sequence diagrams can add further detail by showing the order of event processing

Structure of a Requirements Document

Section Contents

Preface Expected readership, version history, rationale for new versions, summary of changes.

Introduction Need for the system, overview of functions, how it fits into business strategy.

Glossary Definitions of all technical terms used in the document.

User requirements definition Services provided to users; non-functional requirements; written for non-technical readers.

System architecture High-level architecture overview; distribution of functions across modules.

System requirements specificationDetailed functional and non-functional requirements; interface definitions.

System models Graphical models — object models, data-flow models, semantic data models.

System evolution Fundamental assumptions; anticipated future changes (useful for designers).

Appendices Hardware and database descriptions; specific technical details.

Index Alphabetical index, function index, diagram index.

6. REQUIREMENTS VALIDATION

Requirements validation checks that the requirements actually define the system the customer
wants. This is distinct from requirements verification (checking the requirements are correct) —
validation asks 'is this the right system?'

Why validation is critical:

Fixing a requirements error after delivery can cost up to 100 times more than fixing it during
development. Getting requirements right early is one of the highest-value activities in software
engineering.

Five checks performed during validation:

Check Question Asked

Validity Does the system provide the functions that best support what customers actually need?
Consistency Are there conflicts or contradictions between requirements?

Completeness Are all functions required by the customer included?

Realism Can the requirements be implemented within available budget and technology?

Verifiability Can the requirements be objectively tested and checked?

Validation Techniques

Technique Description

Requirements reviews Systematic manual analysis of the requirements document. Both client and contractor staff particip

Prototyping Building an executable model of the system to let stakeholders interact with a working version and

Test-case generation Writing test cases for requirements before implementation. If a test case cannot be written for a req

Review Checks (What Reviewers Look For)

• Verifiability — is the requirement realistically testable?
• Comprehensibility — is the requirement clearly and fully understood?
• Traceability — is the origin/rationale of the requirement clearly stated?
• Adaptability — can the requirement be changed without a large ripple effect on other
requirements?

7. REQUIREMENTS CHANGE AND MANAGEMENT

Why requirements always change:

• Business and technical environments change after a system is installed
• New hardware, new legislation, or new business priorities emerge
• The people who pay for the system and the people who use it are rarely the same — their
needs differ
• Large systems have diverse user communities with conflicting priorities; compromises made
during development may later prove wrong

Requirements management
Requirements management is the process of tracking and controlling changes to requirements
during development and after deployment. Key activities:

• Assign a unique ID to every requirement for cross-referencing

• Maintain traceability links between requirements and between requirements and design/code
• Establish a formal change management process
• Use tools: from specialist requirements management systems to spreadsheets
Requirements Change Management Process
Before accepting any change to requirements, it must go through three formal steps:

Step Description

1. Problem analysis and change specification

Analyse the problem or change proposal to check it is valid. Feed analysis back to the

2. Change analysis and costing Assess the impact of the proposed change using traceability information. Estimate the

3. Change implementation Modify the requirements document, and if necessary the system design and implement

Note: Key principle: never modify the system or its design directly in response to a change request. Always
go through the formal process first. This prevents uncontrolled changes that may break other requirements.

8. EXAM TIPS — COMMON QUESTIONS

Difference between user requirements and system requirements?

User requirements are high-level, natural language, written for non-technical stakeholders. System
requirements are detailed, structured, technical — written for developers and may form part of a
contract.

Why can't requirements be complete and consistent?

Because systems are complex, stakeholders have conflicting needs, and the environment changes.
In practice, it is impossible to fully specify a large system upfront — requirements will always be
incomplete or contain subtle contradictions.

Why are non-functional requirements often more critical than functional ones?
If a functional requirement is missing, the system just lacks a feature. If a critical NFR is unmet (e.g.
the system is too slow, insecure, or unreliable), the entire system may be unusable, regardless of
whether all features work correctly.

What is the difference between a goal and a verifiable NFR?

A goal is vague and cannot be objectively tested (e.g. 'the system should be easy to use'). A
verifiable NFR includes a measurable criterion (e.g. 'users shall complete task X in under 2 minutes
after 4 hours of training').

Why is validation so expensive if left late?

Fixing a requirements error after delivery costs up to 100x more than fixing it during the RE process.
The error propagates through design and implementation, meaning multiple artefacts must be
changed, retested, and redeployed.

What is the difference between a scenario and a use case?

A scenario is a specific, narrative example of a system interaction — including normal flow, what
can go wrong, and final state. A use case is a UML notation that identifies actors and describes
interactions at a slightly more abstract level. Use cases are supplemented by detailed descriptions
that look like scenarios.

Why does agile treat requirements differently?

Agile argues that detailed requirements documents become outdated immediately because
requirements change so fast. Instead, agile uses incremental requirements engineering with user
stories. This works for business systems but is problematic for safety-critical or multi-team projects
that need stable requirements upfront.

Week 5 Study Notes | Requirements Engineering | Pressman & Maxim, Chapter 4