Software Requirements

Engineering
Software Requirements Elicitation and Specification

1
 Quotes from disgruntled customers

• They are not listening to what I want for my system. They are
giving me the system that they want to build, not the one that I
want.

• We often don’t know how to say what we want – we know it but

don’t know that we do – so it’s their job to listen to us, organize
it and say it back to us, better than how we ourselves could say it.

2
 Software Requirements Elicitation and
Specification
• Fundamentals
– Motivation and Goals
– Requirement Engineering
– Functional vs. Non-Functional
– Defining Software System Scope
– Specifying a Use Case
– Use case relationships
– Pitfalls
• Requirements Elicitation Process

• Documentation

3
 What is a Requirement ?

• A requirement is a statement about what the proposed system

will do that all stakeholders agree must be made true in order for
the customer’s problem to be adequately solved.
– Statement: brief, concise, fact-based.
• Collection of requirements = requirements document
– Do: What tasks the system will perform.
• Does not describe implementation (the “how”).
– All stakeholders: Fundamental purpose is communication vis-
à-vis agreements/contracts
– Problem: System must be focused on customer’s problem.

• A requirement is a feature that the system must have or a

constraint that it must satisfy to be accepted by the customer.

4
 What is a Requirement ?

• It may range from a high-level abstract statement of a service

or of a system constraint to a detailed mathematical functional
specification.
• This is inevitable as requirements may serve a multiple functions
function
– May be the basis for a bid for a contract - therefore must be open
to interpretation;
– May be the basis for the contract itself - therefore must be defined
in detail;

5
 What is a Requirement ?

Types of Requirements

• User requirements
– Statements in natural language plus diagrams of the services the
system provides and its operational constraints.
– Written for customers.
• System requirements
– A structured document setting out detailed descriptions of the
system’s
• functions,
• services
• operational constraints.
– Defines what should be implemented so may be part of a contract
between client and contractor.

6
 Example
User Requirement Definition
• The software must provide a means of representing and
accessing external files created by other tools

System Requirements Specification

• The user should be provided with facilities to define the type of

external files
• Each external file type may have an associated tool which may
be applied to the file
• Each external file type may be represented as a specific icon on
the user’s display
• Facilities should be provided for the icon representing an external
file type to be defined by the user
• When a user selects an icon representing an external file, the
effect of that selection is to apply the tool associated with the type
of the external file to the file represented by the selected icons

7
 Stating requirements

Typical statements…
• ATM: the ATM shall allow a customer to access (i.e., view the
balance of) his/her accounts.
• Cruise control: the cruise control shall be automatically and
immediately disengaged when the driver uses the break pedal.
• Air traffic control: the air traffic control software shall run 24h a
day, 7 days a week.
• Windows application: the software shall be configurable to any
language supported by the operating system.
• Anti-collision software: the software shall detect potential colliding
aircraft trajectories with at least 5mn before that can actually
happen.

8
 Motivations and Goals (I)

• Requirements describes the expected behavior of a system

– Functional requirements
– Non-functional requirements
• Every nontrivial engineering system must be specified, based on
user requirements
• Requirements need to be explicitly stated and documented
for system implementation
– e.g., used for design decisions, verification and validation and a
reference point during maintenance
• SE is about developing software solutions to problems
– Good solutions can only be developed if software engineers
understand the problems.

9
 Motivations and Goals (II)

• Defects are cheaper when detected earlier

• For safety-critical systems, requirements problems are more
likely to be safety-related
• Failure to understand and manage requirements is the biggest
single cause of cost and schedule slippage
• Requirements documentation treats the software system as a
black-box
• Separation of concerns: “What” vs. “How”

10
 Software Requirements Elicitation and
Specification
• Fundamentals
– Motivation and Goals
– Requirement Engineering
– Functional vs. Non-Functional
– Defining Software System Scope
– Specifying a Use Case
– Use case relationships
– Pitfalls
• Requirements Elicitation Process

• Documentation

11
 Requirements Engineering

• Requirements Engineering is the process of defining the

requirements for the system under construction
• Requirements engineering has two main activities:
1. Elicitation : results in requirements specification that the customer
understands
2. Analysis: results in analysis model that developer can unambiguously
understand
Both represent the same information
– Specification: communication with customer (informal notation)
– Analysis: communication among developers (formal notation)
• Traditional terminology:
– Requirements specification = = Requirements Definition
– Analysis model = = Requirements Specification

12
 Key Tasks in Requirements Engineering

Inception:
• In some cases, a casual conversation is all that is needed
• most projects begin when
• a business need is identified or
• a potential new market or service is discovered
• stakeholders define a business case for the idea, try to identify the
breadth and depth of the market, do a rough feasibility analysis,
and identify a working description of the project’s scope.
• All of this information is subject to change
At project inception, you establish
– a basic understanding of the problem,
– the people who want a solution,
– the nature of the solution that is desired

13
 Key Tasks in Requirements Engineering

Elicitation :
Engaging with stakeholders to gather system objectives and needs
despite challenges
• Scope problems: ill-defined system boundaries, unnecessary technical
details that is confusing.
• Problems of Understanding : user not completely sure of what is
needed, poor domain knowledge, communication barriers, have a
poor understanding of the capabilities and limitations of their
computing environment , ambiguous or conflicting requirements.
• Volatility: Changing requirements over time.
Elaboration:
• The information obtained from the customer during inception and
elicitation is expanded and refined during elaboration.
• Refining customer information into a detailed requirements model
with user scenarios, analysis classes, and supplementary diagrams.
14
 Key Tasks in Requirements Engineering

Negotiation :
– Reconciling conflicting requirements through stakeholder discussion
and prioritization.
– Using an iterative approach that prioritizes requirements, assesses
their cost and risk, and addresses internal conflicts, requirements are
eliminated, combined, and/or modified so that each party achieves
some measure of satisfaction.

Specification :
• May include written documents, graphical models, formal models,
usage scenarios, prototypes, or combinations of those.
• Flexibility in approach may be required
– For large systems, a written document, combining natural language
descriptions and graphical models may be the best approach.
– However, usage scenarios may be all that are required for smaller
systems

15
 Key Tasks in Requirements Engineering

Validation :
• Assessing the requirements specification for quality, looking for
unambiguous statements, inconsistencies, omissions, and errors.
• Main mechanism: Technical review including stakeholders such as
software engineers, customers, and users.

Management :
• Identify, control, and track requirements and changes to requirements
at any time as the project proceeds
• Mirroring software configuration management activities to
accommodate the evolution of system requirements throughout the
project.

16
 Sources of Requirements

Stakeholders wants and needs

Current organization and systems

• Best practices
• Existing documents
• Requirement templates
• Domain models
• …
Requirements
Current standards, certification
• Standards
• Legal issues
• Certification bodies
• …

17
 Users of the Requirements

Specify the requirements and read them to

System Customers check that they meet their needs. They specify
changes to the requirements.

Use the requirements document to plan a bid

Managers for the system and to plan the system
development process.

Use the requirements to understand what

System Engineers
system is to be developed.

Use the requirements to develop validation tests

System Test Engineers
for the system.

Use the requirements to help understand the

System Maintenance Engineers
system and the relationships between its parts.

18
 Views of Specifications

• Developer’s
– Specification must be detailed enough to implement
– Unambiguous
– Self-consistent

• Client’s/user’s
– Specifications must be comprehensible
– Usually means: not too technical

• Legal
– Specification can be a contract
– Should include acceptance criteria
• If the software passes tests X, Y, and Z, it will be accepted

19
 Informal Specifications

• Written in natural language

– E.g., English

• Example
“If sales for current month are below target sales, then report is to be
printed, unless difference between target sales and actual sales is
less than half of difference between target sales and actual sales in
previous month, or if difference between target sales and actual
sales for the current month is under 5%”

20
 Problems with Informal Specifications

• Informal specs of any size inevitably suffer from serious problems

– Omissions
• Something missing
– Ambiguities
• Something open to multiple interpretations
– Contradictions
• Spec says “do A” and “do not do A”

These problems will be faithfully implemented in the software

unless found in the spec

21
 Informal Specifications Revisited

“If sales for current month are below target sales, then report is to be
printed, unless difference between target sales and actual sales is
less than half of difference between target sales and actual sales in
previous month, or if difference between target sales and actual
sales for the current month is under 5%”

22
 Informal Specifications Revisited

“If sales for current month are below target sales, then report is to be
printed, unless difference between target sales and actual sales is
less than half of difference between target sales and actual sales in
previous month, or if difference between target sales and actual
sales for the current month is under 5%”

What are sales? Orders received but not

yet paid for? Only orders paid for?
23
 Informal Specifications Revisited

“If sales for current month are below target sales, then report is to be
printed, unless difference between target sales and actual sales is
less than half of difference between target sales and actual sales in
previous month, or if difference between target sales and actual
sales for the current month is under 5%”

Specification implies, but does not say, that

there are monthly sales targets. Are there
separate monthly targets, or is the monthly
target e.g., 1/3 of the quarterly target?
24
 Informal Specifications Revisited

“If sales for current month are below target sales, then report is to be
printed, unless difference between target sales and actual sales is
less than half of difference between target sales and actual sales in
previous month, or if difference between target sales and actual
sales for the current month is under 5%”

5% of the target sales, or of the actual sales?

25
 Why Do People Use Informal Specs?

• Informal specification is widely practiced for smaller projects

• The common language is natural language

– Customers can’t read formal specs
– Or most managers
– A least-common denominator effect takes hold

• Truly formal specs are very time-consuming

– And hard to understand
– And overkill for small projects

26
Products of Requirements Process

Problem
Statement
Requirements
Elicitation
Requirements Specfication

Functional
Model

Nonfunctional
Requirements Model
Analysis

Analysis Model

27
 Requirements Elicitation - Objectives

• Understand the processes, people, and resources involved

• Determine the coverage and boundary of the future system
(scope)
– VERY important decision, huge consequences if wrong
• Separate requirements according to level of priority
• No implementation decisions (i.e., No How), unless mandated by
customer

28
 Why is Requirements Elicitation hard?

• Customers / Users are not always good at describing what they

want or need
• Software Engineers are not always good at understanding
someone else’s concerns
• In certain application domains, software engineers and
customers have completely different backgrounds and use a
different terminology
• Volatility: requirements change over time.

29
 Techniques for Requirement Elicitation

• Observation
– Observe users at work
– Obtain subtle information not told by customer (forgotten, didn’t think
it was important, didn’t understand implication)
• Interviewing
– Requires skill, preparation, listening
– Ask specific details: boundaries, exceptions, anticipated changes
– Ask vision of future
– Ask alternatives
– Ask minimally acceptable solution
– Ask other sources of information
• Brainstorming : Moderated meeting with trigger questions
• Prototyping : To stimulate reaction by user.

30
 Qualities of Specifications I

• Clear, unambiguous, understandable

=> Need for rigor (and perhaps formality)
=> But rigor and understandability may be contradictory goals
• Realistic (late changes to requirements are expensive)
• Correspond to real needs (Valid)
• Verifiable (to ease testing), e.g., use metrics

31
 Qualities of Specifications II

• Consistency: lends itself to verifiable, testable, modifiable

specifications
– the specification is inconsistent if it is self-contradictory
=> More likely to be inconsistent as complexity grows, and
modifications are performed over time
• Completeness:
– Respond to all classes of inputs
– Internally complete, self-contained
– Complete set of requirements (captures all needs)
– Includes things the system must not do …

32
 Quality Example
Restaurant Advisor System:
“This system will allow people to choose a restaurant in a city.
Users enter one or more of the following criteria, and then the
system searches its database for suitable restaurants: food
type, price range, neighborhood, size, service type (fast food,
cafeteria, buffet, full service), smoking arrangements (none
allowed, separately ventilated section, non-separately-ventilated
section). The user can also specify a desired day and time
period, and the number of people in their party. The system will
tap into the reservation database (of participating restaurants)
and only display restaurants that have available space. After
entering the criteria, the user clicks on “search” and the system
displays a list of matching restaurants. For restaurants that
participate in the automated reservation system, the user can
click on “reserve” next to a selection in order to make a
reservation. Point out problems that you find in this
“short statement of functional requirements”

33
Restaurant Advisor System: quality deficiencies
• Duplication (ie. saying twice in two different ways) :
– System searches for suitable / System displays matching.
• Food type, price range, neighbourhood, size are inadequately defined.
– Are these taken from a fixed set of values, does a database contain free-form
information? Will it be standardized (to make searches easier)?
• Ambiguity in “reservation database” and “automated reservation
system”
– Same thing or not ?
• Unclear: It appears that some listed restaurants are not in the
reservation system/database.
– What does the system do with restaurants that are not participating ? Are they
omitted from the list?
• Unspecified: Can user select just one option or more than one option for
“type of food”, or smoking arrangement.
• Incomplete: If user selects “reserve”, there must be some way for the
system to record identifying information about the user so restaurant
knows who made it. This is omitted.
34
 The importance of organization and priority
Encounter game example
1. Every character in the Encounter video game shall have a name;
2. Every game character has the same set of qualities, each with a
floating point value;
3. Encounter shall take less than a second to compute the results of an
engagement;
4. Each area has a specified set of “qualities needed”;
5. When two Encounter game characters are in the same area at the
same time, they may either choose or be obliged by the game to
engage each other;
6. Every game character shall have an amount of life points;
7. The sum of the value of qualities of a game character relevant to the
area in question shall be referred to as the character’s area value. In
an engagement the system compares the area values of the
characters and computes the result of the engagement.
8. The name of any character shall have no more than 15 letters.

35
 Deficiencies

• The organization and order will affect the readers’ understanding

• The Encounter game examples are a mix of:

– functional (behavioural) requirements (5 and 7)
– non-functional performance (3)
• Some naturally belong with related ones :
– some are about areas(4)
– some are about characters (1,2,6,8)
– some about engagement (3,5,7).

• Lack of organization:
– makes finding specific requirements hard (especially with big
systems)
– makes prioritizing hard.
36
 The importance of precision
Before: Every area shall have a name of up to 15 characters.
After: Every area will have a unique name consisting of 1 to 15
characters. Acceptable characters shall consist of blanks, 0
through 9, a through z, and A through Z only.

Before: Every game character has the same set of qualities, each
have a floating point value. These are initialized to 100/n where
n is the number of qualities. The qualities are attention span,
endurance, intelligence, patience and strength.
After: Every game character has the same set of qualities. Each
quality shall be a nonnegative floating point number with at least
one decimal of precision. These are all initialized equally so that
the sum of their values is 100. The value of a quality cannot be
both greater than 0 and less than 0.5. For the first release, the
default qualities will be concentration, intelligence, patience,
stamina and strength. Qualities may be added or removed
during configuration, before any characters are created.

37
 Software Requirements Elicitation and
Specification
• Fundamentals
– Motivation and Goals
– Requirement Engineering
– Functional vs. Non-Functional
– Defining Software System Scope
– Specifying a Use Case
– Use case relationships
– Pitfalls
• Requirements Elicitation Process

• Documentation

38
 Functional vs. Non-Functional

• Functional requirement:
– interaction between a system and its environment (e.g., UML actors)
– (independent from its implementation)
• Non-Functional requirement:
– restriction on the system that limits our choices for constructing a
solution
– e.g., memory, platform, real-time constraints.

• Non-Functional requirements have as much impact on the

system cost and development as functional requirements.

39
 Functional Requirements

• Functional requirements describe the

– specific functions,
– features, and
– capabilities that a software system must possess to
meet the needs of its users and stakeholders.
• These requirements define what the software should do and how
it should behave when certain conditions are met.
• Functional requirements can be thought of as a set of actions or
behaviors that the software system must perform.
• Functional requirements should be clear, unambiguous, and
verifiable.
• They serve as the foundation for design, development, and
testing activities during the software development life cycle.

40
 Structuring Functional Requirements

Here's how you can structure your functional requirements within

each of these sections: Introduction, Inputs, Processing, Outputs,
Error Handling

• Introduction Provide a brief overview of the functionality or

feature you're describing in this section.

• Inputs List and describe the inputs required for the functionality.
Be clear about what data or information is needed for the system
to perform this function.
For example:
Input: User's username and password
Description: The user needs to provide their username and
password to access the system.

41
Structuring Functional Requirements (cont)

• Processing Explain how the system processes the inputs and

what actions it takes. Describe the logic or steps involved in
handling the inputs.
For example:
Processing: The system shall validate the user's credentials against the
stored user database.
Description: The system checks whether the provided username and
password match any valid user records in the database
• Outputs List and describe the expected outputs or results of the
functionality. Explain what the system will provide to the user or
other components of the system.
For example:
Output: User's access to the application
Description: If the provided username and password match a valid user
record, the system grants access to the application.

42
Structuring Functional Requirements (cont)

• Error Handling Explain how the system handles errors or

exceptions that may occur during the execution of this
functionality.
• Describe how the system responds to incorrect inputs or
unexpected situations.

For example:

Error Handling: If the provided username and password do not match

any valid user record, the system shall deny access and display an
error message.

Description: When the user enters incorrect credentials, the system

informs the user of the error and prevents access to the application.

43
 Types of NF Requirements

• Usability: the ease with which a user can learn to operate, prepare
inputs for, and interpret outputs of a system.
– Relates to the user interface—number of nested levels in menus, color
schemes …, online help, level of documentation …
• Dependability: the property of a system such that reliance can
justifiably be placed on the service it delivers. Includes reliability,
robustness, and safety.
• Reliability: the ability of a system to perform its required functions
under stated conditions for a specified period of time.
– Includes acceptable mean time to failure, the ability to detect specified faults
or withstand specified security attacks
• Robustness: the degree to which a system can function correctly in
the presence of invalid inputs or stressful environment conditions.
• Safety: A measure of the absence of catastrophic consequences to the
environment.

44
 Types of NF Requirements (cont.)

• Performance: Quantifiable attributes of the system such as response

time, throughput, availability, accuracy.
• Response time: how quickly the system reacts to a user input.
• Throughput: how much work the system can accomplish within a
specified amount of time.
• Availability: the degree to which a system is operational and
accessible when required for use.
– E.g., an availability of 0.998 means that in every 1000 time units, the
system is likely to be available for 998 units.
• Accuracy: a quantitative measure of the magnitude of error.

45
 Types of NF Requirements (cont.)

• Supportability: Requirements concerned with the ease of changes to

the system after deployment. Includes adaptability, maintainability.
• Adaptability: the ability to change the system to deal with additional
application domain concepts.
• Maintainability: the ability to change the system to deal with new
technology or to fix defects.

• In practice, NF requirements have to be prioritized by importance.

Some of them need to be met for the system to operate correctly.

46
 Sommerville’s Classification

Non-functional
requirements

Product Organizational External

requirements requirements requirements

Usability Efficiency Reliability Portability Interoperability Ethical Legislative

requirements requirements requirements requirements requirements requirements requirements

Performance Space Delivery Implementation Standards Privacy Safety

requirements requirements requirements requirements requirements requirements requirements

47
 Examples

• The product should identify an aircraft within 0.25 seconds

• The product should be used with poor lighting conditions and the
users will wear gloves
• The product should be easy to use with only one hand
• The system shall not disclose any personal information about
customers
• The product should be readily portable to the Linux operating
system.

48
 What is usually not in the Requirements?

• System structure, implementation technology

• Development methodology
• Development environment
• Implementation language
• Reusability

It is desirable that none of these are constrained by the client

• But in certain application domains, like airborne systems, military

systems, there are (international) standards to follow.

49
 Realistically

• Many requirements can only be clearly identified after some

experience with the system => incrementality
• Some amount of imprecision (“common knowledge”) is accepted
– e.g., what is a saving bank account in a given banking environment,
• Responsibility of users and software engineers to determine what
is acceptable.

50
 NF Requirements Metrics examples

Property Metric
• Speed • Process transactions per second
• User/event response time
• Screen refresh time
Notice how each metric is a
• Size • K Bytes
quantifiable amount – a number
• Number of RAM chips to be verified! Even portability
• Ease of use • Training time
• Number of help frames
• Reliability • Mean time between failure (MTBF)
• 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

51
 Software Requirements Elicitation and
Specifications
• Fundamentals
– Motivation and Goals
– Requirement Engineering
– Functional vs. Non-Functional
– Defining Software System Scope
– Specifying a Use Case
– Use case relationships
– Pitfalls
• Requirements Elicitation Process

• Documentation

52
 Defining the Software System Scope

• VERY important decision, huge consequences if wrong

• System Boundary: define activities and data IN the system
• Fundamental questions:
– What/who triggers the behaviour expected from the software?
– Should we implement the requirements or is the requested
functionality a responsibility of another system or a human?
• We need to know the context in which a system operates
• External entities:
– other systems, organizations, people, machines, device (sensor,
actuator), etc. that expect services/data from us or provide services
to us
• Input/Output data flows from/to external entities

53
 Scope Example

• Web-based store: The system allows the purchase of items over the
web. When a purchase it made, inventory is checked and updated and
the total cost is computed. Because it is web-based, foreign purchases
may be made, requiring the cost to be computed in the foreign currency
using that day’s currency exchange rate.

• Two databases can be envisioned:

– Inventory/price database: For each item, number available and price
– Google’s currency exchange database

• Question: Define the scope of the system. In particular, are the

databases inside or outside the system ? Answer:
– Google’s currency exchange database is outside the system (i.e., an actor)
– Inventory/price database is internal
• however, the DBMS used to implement it is not part of the system,
• only the schema definition and DB queries are part of the system.

54
 Defining Software System Scope

• Defines what is IN the software system

– Defines what is OUT of the software system
• Defines what is the responsibility of the software
• Defines what the engineers have to build
• Can be a binding (legal) description of the software system

55