Transcript Software Requirements - Electrical and Computer

Chapter 5
Software Requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 1
Software Requirements

Descriptions and specifications of
a system
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 2
Objectives




To introduce the concepts of user and system
requirements
To describe functional and non-functional
requirements
To explain two techniques for describing system
requirements
To explain how software requirements may be
organized in a requirements document
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 3
What is a requirement?


Range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification
Requirements may serve a dual function
•
•
•
©Ian Sommerville 2000
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
Software Engineering, 6th edition. Chapter 5
Slide 4
Requirements engineering


The requirements are the descriptions of the system
services and constraints
The requirements engineering is the process of
establishing the customer services and addressing
system constraints
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 5
Types of requirement

User requirements
•

System requirements
•

Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for customers
A structured document setting out detailed descriptions of the system
services. Written as a contract between client and contractor
Software specification
•
©Ian Sommerville 2000
A detailed software description which can serve as a basis for a design
or implementation. Written for developers
Software Engineering, 6th edition. Chapter 5
Slide 6
Requirements readers
User requirements
Client managers
System end-users
Client engineers
Contractor managers
System architects
System requirements
System end-users
Client engineers
System architects
Software developers
Software design
specification
©Ian Sommerville 2000
Client engineers (perhaps)
System architects
Software developers
Software Engineering, 6th edition. Chapter 5
Slide 7
Topics covered

Functional and non-functional requirements

User requirements

System requirements

The software requirements document
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 8
Functional and non-functional requirements

Functional requirements
•

Non-functional requirements
•

Statements of services the system should provide, how the system
should react and behave in a certain condition.
Emergent properties such as reliability, response time, availability,
not concerned with any specific functions delivered by the system.
Domain requirements
•
Requirements that come from the application domain of the system
and that reflect characteristics of that domain
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 9
Functional requirements



Describe functionality or system services
Functional user requirements are high-level
statements
Functional system requirements describe system
services in detail
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 10
Examples of functional requirements



The user shall be able to search either all databases or
specify a subset.
The system shall provide appropriate viewers for the
user to read documents.
Every order shall be allocated a unique identifier
(ORDER_ID).
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 11
Requirements imprecision



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’
•
•
©Ian Sommerville 2000
User intention - special purpose viewer for each different document
type
Developer interpretation - Provide a text viewer that shows the
contents of the document
Software Engineering, 6th edition. Chapter 5
Slide 12
Requirements completeness and consistency


Typically, requirements should be both complete and
consistent but may have difficulty in practice
Complete
•

The requirements should include descriptions of all facilities
required
Consistent
•
©Ian Sommerville 2000
There should be no conflicts or contradictions in the
descriptions of the system facilities
Software Engineering, 6th edition. Chapter 5
Slide 13
Non-functional requirements



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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 14
Non-functional classifications

Product requirements
•

Organizational requirements
•

Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
Requirements which are a consequence of organizational
policies and procedures e.g. process standards used,
implementation requirements, etc.
External requirements
•
©Ian Sommerville 2000
Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Software Engineering, 6th edition. Chapter 5
Slide 15
Non-functional requirement types
Non-functional
requir ements
Product
requir ements
Ef ficiency
requir ements
Reliability
requir ements
Usability
requirements
Performance
requirements
Or ganizational
requir ements
Portability
requirements
Delivery
requirements
Interoperability
requirements
Implementation
requir ements
Space
requir ements
©Ian Sommerville 2000
External
requirements
Software Engineering, 6th edition. Chapter 5
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
Slide 16
Non-functional requirements examples

Product requirement
•

Organizational requirement
•

Performance requirements on how fast the system must execute
Process standards which must be used in the organization
External requirement
•
Legislative requirements which must be followed
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 17
Goals and requirements


Non-functional requirements may be very difficult to
state precisely and imprecise requirements may be
difficult to verify.
Goal
•

Verifiable non-functional requirement
•

A general intention of the user such as ease of use
A statement using some measure that can be objectively tested
Goals are helpful to developers as they convey the
intentions of the system users
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 18
Examples

A system goal
•

The system should be easy to use by experienced
controllers and should be organized in such a way that user
errors are minimised.
A verifiable non-functional requirement
•
©Ian Sommerville 2000
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.
Software Engineering, 6th edition. Chapter 5
Slide 19
Requirements measures
Pro perty
Speed
Size
Eas e of u se
Rel iabi li ty
Rob u st ness
P ortabi li ty
©Ian Sommerville 2000
Meas ure
P ro cess ed t rans acti o ns /s econ d
User/ Event res po n se ti me
Screen refresh t ime
K By tes
Nu mb er o f RAM ch ip s
Train in g time
Nu mb er o f h elp frames
Mean ti me t o failu re
P ro b ab il ity o f u n av ailab ili ty
Rat e of failu re o ccu rren ce
Av ai lab i lit y
Time to rest art aft er failu re
P ercent ag e o f event s caus in g fail ure
P ro b ab il ity o f d ata co rru pt io n on fail ure
P ercent ag e o f targ et d ep end ent st at ement s
Nu mb er o f t arget sy st ems
Software Engineering, 6th edition. Chapter 5
Slide 20
Requirements interaction


Conflicts between different non-functional
requirements are common in complex systems
Spacecraft system – an example
•
•
•

To minimise weight with few chips
To minimise power consumption with low power chips
However, using low power chips need more chips
Which is the most critical requirement?
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 21
Domain requirements



Requirements and features are for a specific domain.
Domain requirements have specific functions,
constraints or computations
The system may not work if domain requirements are
not satisfied
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 22
Train protection system

A specific computation function for train
domain:
The deceleration of the train shall be computed as:
Dtrain = Dcontrol + Dgradient
where Dgradient is 9.81ms2 * compensated
gradient/alpha and where the values of 9.81ms2 /alpha
are known for different types of train.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 23
Domain requirements problems

Understandability
•

Requirements are expressed in the language of the
application domain, resulting in understanding problems
for software engineers
Implicitness
•
©Ian Sommerville 2000
Domain specialists understand the area so well that they
do not think of making the domain requirements explicit
Software Engineering, 6th edition. Chapter 5
Slide 24
Topics covered

Functional and non-functional requirements

User requirements

System requirements

The software requirements document
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 25
User requirements


Describe functional and non-functional
requirements for users who don’t have
technical knowledge
Use natural language, tables and diagrams
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 26
Problems with natural language

Ambiguity
•

Requirements confusion
•

Several different requirements may be expressed together
Over-flexibility
•

Functional and non-functional requirements tend to be mixed-up
Requirements amalgamation
•

Readers and writers may interpret the same words differently.
The same thing may be described in different ways in the specification
Lack of modularization
•
NL structures are inadequate to structure system requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 27
Editor grid requirement
2.6 Grid facilities To assist in the positioning of entities on a
diagram, the user may turn on a grid in either centimetres or
inches, via an option on the control panel. Initially, the grid is off.
The grid may be turned on and off at any time during an editing
session and can be toggled between inches and centimetres at any
time. A grid option will be provided on the reduce-to-fit view but
the number of grid lines shown will be reduced to avoid filling the
smaller diagram with grid lines.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 28
Guidelines for user requirements




Invent a standard format and use it for all
requirements
Use language in a consistent way.
Use text highlighting to identify key parts of the
requirement
Avoid the use of computer jargon
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 29
Structured presentation
2.6 Grid facilities
2.6.1 The editor shall provide a grid facility where a matrix of
horizontal and vertical lines provide a background to the
editor window. This grid shall be a passive grid where the
alignment of entities is the user's responsibility.
Rationale: A grid helps the user to create a tidy diagram with
well-spaced entities. Although an active grid, where entities
'snap-to' grid lines can be useful, the positioning is imprecise.
The user is the best person to decide where entities should be
positioned.
Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 30
Topics covered

Functional and non-functional requirements

User requirements

System requirements

The software requirements document
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 31
System requirements

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 (data-flow model, object model,
etc.)
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 32
Requirements and design


Requirements care about “what the system
should do”
Design cares about “how to fulfill the
requirements”
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 33
Two Alternatives to NL specification

Structured natural language specifications

PDL-based definitions
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 34
Structured NL specifications


A limited form of natural language may be used to
express requirements
This removes the problems of ambiguity and
flexibility and supports uniformity
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 35
Structured NL -- Form-based
ECLIP SE/W orks tati on/Tool s/ DE/FS/ 3.5.1
Function
Add node
Des cripti on
Addsa node to an exi st ing des ign. The user s el ects t he type of node, and it s posi ti on.
When added to the des ign, the node becomes
the current select ion. The user choos es the node posi ti on by
movi ng t he cursor t o the area where t he node is added.
I nputs Node type, Node pos it ion, Des ign ident ifi er.
Source
Node type and Node pos it ion are i nput by the us er, Desi gn i denti fier from the databas e.
Outputs
Des ign ident ifi er.
Des ti nati on
operati on.
The des ign databas e. The des ign is committ ed t o the database on compl et ion of the
Requires
Des ign graph rooted at input des ign ident ifi er.
Pre-conditi on
The des ign is open and dis pl ayed on the user's s creen.
Pos t-condi tion
at t he given posi tion.
The des ign is unchanged apart from t he
addit ion of a node of the specified t ype
Side-ef fects
None
Def init ion: ECLIPSE/W or ks tati on/ Tools /DE/RD/3.5.1
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 36
PDL-based requirements definition


A programming language like description but with more
flexibility of expression
Appropriate in two situations
•
•
Where an operation is specified as a sequence of actions and
the order is important
When interfaces have to be specified
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 37
Part of an ATM specification
class ATM {
// declarations here
public static void main (String args[]) th rows InvalidCard {
try {
thisCard.read () ; // may throw InvalidCard exception
pin = KeyPad.readPin () ; attempts = 1 ;
while ( !thisCard.pin.equals (pin) & attempts < 4 )
{
pin = KeyPad.readPin () ; attempts = attempts + 1 ;
}
if (!thisCard.pin.equals (pin))
throw new InvalidCard ("Bad P IN");
thisBalance = thisCard.getBalance () ;
do { Screen.prompt (" Please select a servi ce ") ;
service = Screen.touchKey () ;
switch (service) {
case Services.withdrawalWithReceipt:
receiptRequired = true ;
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 38
PDL disadvantages



PDL may not be sufficiently expressive to express the
system functionality in an understandable way
Notation is only understandable to people with
programming language knowledge
The requirement may be taken as a design
specification rather than a model to help understand
the system
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 39
Topics covered

Functional and non-functional requirements

User requirements

System requirements

The software requirements document
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 40
IEEE requirements standard






Introduction
General description
Specific requirements
Appendices
Index
This is a generic structure that must be instantiated for
specific systems
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 41
Requirements document structure









Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 42
Requirements Specification – Volere
Template
Table of Contents

Project Drivers
1.
2.
3.

Project Constraints
1.
2.
3.

The Purpose of the Product
Client, Customer and Stakeholders
Users of the Product
Mandated Constraints
Naming Conventions and Definitions
Relevant Facts and Assumptions
Functional Requirements
1.
2.
3.
©Ian Sommerville 2000
The Scope of the Work
The Scope of the Product
Functional and Data Requirements
Software Engineering, 6th edition. Chapter 5
Slide 43
Requirements Specification – Volere
Template

Non-Functional Requirements
1.
2.
3.
4.
5.
Look and Feel Requirements
Usability Requirements
Performance Requirements
Operational Requirements
Maintainability and Portability
Requirements
6. Security Requirements
7. Cultural and Political Requirements
8. Legal Requirements
©Ian Sommerville 2000

Project Constraints
1. Open Issues
2. Off-the-Shelf Solutions
3. New Problems
4. Tasks
5. Cutover
6. Risks
7. Costs
8. User Documentation and Training
9. Waiting Room
10. Ideas for Solutions
Software Engineering, 6th edition. Chapter 5
Slide 44
Key points




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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 45
Key points




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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 5
Slide 46