Software Requirements

Objectives:
 To introduce the concepts of user and system requirements

 To describe functional / non-functional requirements

 To explain two techniques for describing system requirements

 To explain how software requirements may be organised in a

requirements document
Requirements engineering is the process of establishing
 the services that the customer requires from a system

 the constraints under which it operates and is developed

Requirements
The descriptions of the system
services and constraints
that are generated during the
requirements engineering
process
Requirements

Requirements define the function of the system from the client‘s viewpoint.

• The requirements establish the system‘s functionality, constraints, and goals

byconsultation with the client, customers, and users.

• The requirements may be developed in a self--‐contained study, or

May emerge incrementally.

• The requirements form the basis for acceptance testing. The development
team and the client need to work together closely during the requirements
phase of a so(ware project.

• The requirements must be developed in a manner that is understandable by

both the client and the development staff.
 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
dual 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
◦ Both these statements may be called requirements
Why are Requirements Important?

Causes of failed software projects (Standish Group study)

Incomplete requirements 13.1%

Lack of user involvement 12.4%
Lack of resources 10.6%
Unrealistic expectations 9.9%
Lack of executive support 9.3%
Changing requirements & specifications 8.8%
Lack of planning 8.1%
System no longer needed 7.5%
Failures to understand the requirements led the developers to build the
wrong system.
Requirement Goals

• Understand the requirements in appropriate detail.

• Define the requirements in a manner that is clear to the client. This may be a
wrieen specification, prototype system, or other form of communication.

• Define the requirements in a manner that is clear to the people who will
design, implement, and maintain the system.

• Ensure that the client and developers understand the requirements and
their implications.
Steps in the Requirements Phase

The requirements part of a project can be divided into several stages:

• Analysis to establish the system‘s services, constraints, and goals by

consultation with client, customers, and users.

• Modelling to organize the requirements in a systematic and

comprehensible manner.

• Define, record, and communicate the requirements.

With iterative methods, these stages will be repeated several times.

 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 services. Written as a contract between
client and contractor
 Software specification
◦ A detailed software description which can serve as a
basis for a design or implementation. Written for
developers
 Client managers
System end-users
User requirements Client engineers
Contractor managers
System architects

System end-users
Client engineers
System requirements
System architects
Software developers

Client engineers (perhaps)

Software design
System architects
specification
Software developers
 Functional requirements
◦ Statements of services the system should provide, how
the system should react to particular inputs and how the
system should behave in particular situations.
 Non-functional requirements
◦ constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.
 Domain requirements
◦ Requirements that come from the application domain of
the system and that reflect characteristics of that
domain
Functional requirements

They are identified by analyzing the use made of the system and include
topics such as:

• functionality
• Data
• User interfaces Modelling
 Describe functionality or system services

 Depend on the type of software, expected users

and the type of system where the software is used

 Functional user requirements may be high-level

statements of what the system should do BUT
functional system requirements should describe
the system services in detail
 The user shall be able to search either all of the
initial set of databases or select a subset from it.
 The system shall provide appropriate viewers for
the user to read documents in the document
store.
 Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy
to the account’s permanent storage area.
 Problems arise when requirements are not
precisely stated
 Ambiguous requirements may be interpreted in
different ways by developers and users
 Consider the term ‘appropriate viewers’
◦ User intention - special purpose viewer for each
different document type
◦ Developer interpretation - Provide a text viewer that
shows the contents of the document
 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 very difficult or impossible to
produce a complete and consistent requirements
document
 Define system properties and constraints e.g.
reliability, response time and storage
requirements. Constraints are I/O device
capability, system representations, etc.
 Process requirements may also be specified
mandating a particular CASE system,
programming language or development method
 Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system is useless
Non--‐functional Requirements

Requirements that are not directly related to the functions that the
system must perform

Product requirements performance, reliability, portability, etc...

Organizational requirements delivery, training, standards, etc...

External requirements legal, interoperability, etc...

Marketing and public relations

Example: In the NSDL, the client (the National Science Foundation)

wanted a live system that could be demonstrated to senior managers six
months after the grant was awarded.
 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.
 Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements
 Product requirement
◦ 4.C.8 It shall be possible for all necessary communication
between the APSE and the user to be expressed in the
standard Ada character set
 Organisational requirement
◦ 9.3.2 The system development process and deliverable
documents shall conform to the process and deliverables
defined in XYZCo-SP-STAN-95
 External requirement
◦ 7.6.5 The system shall not disclose any personal
information about customers apart from their name and
reference number to the operators of the system
Example of Non--‐functional Requirements

Example: Library of Congress Repository

Use technology that the client‘s staff are familiar with:

• Hardware and software systems (IBM/Unix)

• Database systems (Oracle)
• Programming languages (C and C++) Recognize that the client is a
federal library
• Regulations covering government systems, e.g., accessibility to
people with disabilities
• Importance of developing a system that would be respected by other
major libraries
 Non-functional requirements may be very difficult
to state precisely and imprecise requirements
may be difficult to verify.
 Goal
◦ A general intention of the user such as ease of use
 Verifiable non-functional requirement
◦ A statement using some measure that can be objectively
tested
 Goals are helpful to developers as they convey the
intentions of the system users
 A system goal
◦ The system should be easy to use by experienced
controllers and should be organised in such a way that
user errors are minimised.
 A verifiable non-functional requirement
◦ Experienced controllers shall be able to use all the
system functions after a total of two hours training.
After this training, the average number of errors made
by experienced users shall not exceed two per day.
Property Measure
Speed Processed transactions/second
Us er/Event respons e time
Screen refresh time
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robus tness Time to restart after failure
Percentage of events caus ing failure
Probability of data corruption on failu re
Portability Percentage of target dependent statements
Number of target systems
 Conflicts between different non-functional
requirements are common in complex systems
 Spacecraft system
◦ To minimise weight, the number of separate chips in
the system should be minimised
◦ To minimise power consumption,
lower power chips should be used
◦ However, using low power chips
may mean that more chips have
to be used.
Which is the most critical requirement?
 Derived from the application domain and describe
system characteristics and features that reflect
the domain

 May be new functional requirements, constraints

on existing requirements or define specific
computations
 If domain requirements are not satisfied, the
system may be unworkable
 Understandability
◦ Requirements are expressed in the language of the
application domain
◦ This is often not understood by software engineers
developing the system
 Implicitness
◦ Domain specialists understand the area so well that
they do not think of making the domain requirements
explicit
 Should describe functional and non-functional
requirements so that they are understandable by
system users who don’t have detailed technical
knowledge

 User requirements are defined using natural

language, tables and diagrams
 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
 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

Avoid the use of computer jargon !!!

– More detailed specifications of user requirements

 Serve as a basis for designing the system

 May be used as part of the system contract

 System requirements may be expressed using

system models (will be discussed in later)
 In principle, requirements should state what the
system should do and the design should describe
how it does this
 In practice, requirements and design are
inseparable
◦ A system architecture may be designed to structure the
requirements
◦ The system may inter-operate with other systems that
generate design requirements
◦ The use of a specific design may be a domain
requirement
 Ambiguity
◦ The readers and writers of the requirement must
interpret the same words in the same way. NL is
naturally ambiguous so this is very difficult
 Over-flexibility
◦ The same thing may be said in a number of different
ways in the specification
 Lack of modularisation
◦ NL structures are inadequate to structure system
requirements
Notation Description
Structured This approach depends on defining standard forms or
natural templates to express the requirements specification.
language
Design This approach uses a language like a programming
description language but with more abstract features to specify the
languages requirements by defining an operational model of the
system.
Graphical A graphical language, supplemented by text annotations is
notations used to define the functional requirements for the system.
An early example of such a graphical language was SADT
(Ross, 1977; Schoman and Ross, 1977). More recently,
use-case descriptions (Jacobsen, Christerson et al., 1993)
have been used. I discuss these in the following chapter.
Mathematical These are notations based on mathematical concepts
specifications such as finite-state machines or sets. These unambiguous
specifications reduce the arguments between customer
and contractor about system functionality. However, most
customers don’t understand formal specifications and are
reluctant to accept it as a system contract. I discuss formal
specification in Chapter 9.
 A limited form of natural language may be used to
express requirements
 This removes some of the problems resulting from
ambiguity and flexibility and imposes a degree of
uniformity on a specification

Special-purpose forms where designed

to describe the input, output and
functions of a software system

 Often best supported using a forms-based

approach
 The requirements document is the official
statement of what is required of the system
developers

 Should include both a definition and a

specification of requirements

 It is NOT a design document. As far as possible, it

should set of WHAT the system should do rather
than HOW it should do it
 Specify the requirements and
read them to check that they
System customers meet their needs. They
specify changes to the
requirements

Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process

Use the requirements to

System engineers understand what system is to
be developed

System test Use the requirements to

engineers develop validation tests for
the system

System Use the requirements to help

maintenance understand the system and
engineers the relationships between its
parts
 Specify external system behaviour
 Specify implementation constraints
 Easy to change
 Serve as reference tool for maintenance
 Record forethought about the life cycle of the
system i.e. predict changes
 Characterise responses to unexpected events
 Introduction
 General description
 Specific requirements
 Appendices
 Index
 This is a generic structure that must be
instantiated for specific systems
 Introduction
 Glossary
 User requirements definition
 System architecture
 System requirements specification
 System models
 System evolution
 Appendices
 Index
Requirements Analysis:

Interviews with Clients

Client interviews are the heart of the requirements analysis.

Clients may have only a vague concept of requirements.

• Allow plenty of time.

• Prepare before you meet with the client.
• Keep full notes.
• If you do not understand, delve further, again and again
. • Repeat what you hear.
Requirements Analysis: Understand the Requirements

Understand the requirements in depth

• Domain understanding Example: Manufacturing light bulbs

• Understanding of the real requirements of all stakeholders

Stakeholders may not have clear ideas about what they require, or they
may not express requirements clearly. They are often too close to the old
way of doing things.

• Understanding the terminology Clients often use specialized

terminology. If you do not understand it, ask for an explanation. Keep
asking questions, “Why do you do things this way?”
“Is this essential?”
“What are the alterna2ves?”
Requirements Analysis: New and Old Systems

A new system is when there is no existing system.

This is rare.

A replacement system is when a system is built to replace an existing

system.

A legacy system is an existing system that is not being replaced, but must
interface to the new system.

Clients often confuse the current system with the underlying requirement.
In requirements analysis it is important to distinguish:

• features of the current system that are needed in the new system

• features of the current system that are not needed in the new system

• proposed new features

Requirements Analysis: Unspoken Requirements

Discovering the unspoken requirements is often the most difficult part of

developing the requirements.

Examples:

• Resistance to change

• Departmental friction (e.g., transfer of staff)

• Management strengths and weaknesses

Requirements Analysis: Stakeholders

Identify the stakeholders:

Who is affected by this system?

Client Senior management Production staff Computing staff Customers

Users (many categories) etc., etc., etc.,

Example: Web shopping site (shoppers, administration, finance, warehouse)

projects that build web applications often find that the administrative
system that is not seen by the users is bigger than the part of the site that is
visible to the users.
Requirements Analysis: Viewpoint Analysis

Viewpoint Analysis

Analyze the requirements as seen by each group of stakeholders.

Example: University Admissions System

• Applicants
• University administration Admissions office Financial aid office Special
offices (e.g., athletics, development)
• Academic departments
• Computing staff Operations and maintenance
Requirements Analysis: Special Studies

Understanding the requirements may need studies:

Market research focus groups, surveys, competitive analysis, etc.

Example: Windows XP T--‐shirt that highlighted Apple’s strengths

Technical evaluation experiments, prototypes, etc.

Example: Windows XP boot faster

Defining and Communicating Requirements

Objectives

• Record agreement between clients and developers

• Provide a basis for acceptance testing

• Provide visibility

• Be a foundation for program and system design

• Communicate with other teams who may work on or rely on this system

• Inform future maintainers

Defining and Communicating Requirements: Realism and Verifiability

Requirements must be realistic, i.e., it must be possible to meet them.

Wrong: The system must be capable of x (if no known computer system

can do x at a reasonable cost).

Requirements must be verifiable, i.e., since the requirements are the basis
for acceptance testing, it must be possible to test whether a requirement
has been met.

Wrong: The system must be easy to use.

Right: Ager one day‘s training an operator should be able to input 50

orders per hour.
Defining and Communicating Requirements:

Option 1 – Heavyweight Processes

Heavyweight software processes expect detailed specification

• Written documentation that specifies each requirement in detail.
• Carefully checked by client and developers.
• May be a contractual document.

Difficulties
• Time consuming and difficult to create.
• Time consuming and difficult to maintain.
• Checking a detailed specification is difficult and tedious.
• Details may obscure the overview of the requirements.
• Clients rarely understand the implications.
The difficulty of creating and maintaining a detailed requirements
specification is one of the reasons that many organizations
are atracted to lighter weight development processes.
Defining and Communicating Requirements:

Option 2 – Lightweight Processes

Lightweight processes use a outline specification and other tools

• Documentation describing key requirements in appropriate detail.

• Reviewed by client and developers. Details provided by supplementary
tools, e.g.,
• User inter face mock-up or demonstration.
• Models, e.g., data base schema, state machine, etc. Clients understand
prototypes beter than specification
• Iterative or incremental development processes allows the client to
appreciate what the final system will do.
Lightweight Processes (continued)

With lightweight processes, experience and judgment are needed to

distinguish between details that can be left for later in the development
process and key requirements that must be agreed with the client early in the
rocess.

Examples where detailed specifications are usually needed

Business rules (e.g., reference to an accounting standard)

Legal restraint (e.g., laws on retention of data, privacy)
Data flow (e.g., sources of data, data validation)

A common fault is to miss crucial details. This results in misunderstandings

between the client and the developers. Yet the whole intent of lightweight
processes is to have minimal intermediate documentation.
Requirements: Negotiation with the Client

Some requests from the client may conflict with others:

Recognize and resolve conflicts (e.g., functionality v. Cost v. timeliness)

Example: Windows XP boot faster: shorter time--‐out v. Recognize all

equipment on bus
Requirements: Negotiation with the Client

Sometimes the client will request functionality that is very expensive or

impossible.

What do you do?

• Talk through the requirement with the client.

Why is it wanted?
Is there an alternative that is equivalent?

• Explain the reasoning behind your concern.

Explain the technical, organizational, and cost implications.

• Be open to suggestions.
Is there a gap in your understanding?
Perhaps a second opinion might suggest other
approaches.
Before the requirements phase is completed the client and development team
must resolve these questions.

Example : National Science Foundation grant system, client asked for

every format that had ever been used in proposals (e.g., scientific samples).
After negotiation, agreed that the first phase would support only PDF
Requirements Analysis v. System Design

Dilemma about technical decisions

• Requirements analysis should make minimal assumptions about the system

design.

• But the requirements definition must be consistent with computing

technology and the resources available.

In practice, analysis and design are interwoven. However:

1. Do not allow assumptions about the design to influence the requirements

analysis.
2. 2. Do not to allow the requirements analysis to prejudge the system
design.
 Requirements set out what the system should do
and define constraints on its operation and
implementation
 Functional requirements set out services the
system should provide
 Non-functional requirements constrain the
system being developed or the development
process
 User requirements are high-level statements of
what the system should do
 User requirements should be written in natural
language, tables and diagrams
 System requirements are intended to
communicate the functions that the system
should provide
 System requirements may be written in structured
natural language, a PDL or in a formal language
 A software requirements document is an agreed
statement of the system requirements