software reuirements

8/9/2019 SOftware Reuirements

1/49

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 1

Software Requirements


2/49


Objectives

To introduce the concepts of user and system

requirements

To describe functional and non-functional

requirements To explain how software requirements may be

organised in a requirements document


3/49


Topics covered

Functional and non-functional requirements

ser requirements

System requirements

!nterface specification The software requirements document


4/49


5/49Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 5

#hat is a requirement$

!t may range from a high-level abstract statementof a service or of a system constraint to adetailed mathematical functional specification"

This is inevitable as requirements may serve a

dual function% &ay be the basis for a bid for a contract - therefore

must be open to interpretation'

% &ay be the basis for the contract itself - therefore

must be defined in detail'% (oth these statements may be called requirements"


6/49



Types of requirement

ser requirements

% Statements in natural language plus diagrams of the

services the system provides and its operational

constraints" #ritten for customers"

System requirements

% , structured document setting out detailed

descriptions of the systems functions. services and

operational constraints" *efines what should be

implemented so may be part of a contract betweenclient and contractor"



*efinitions and specifications

1. The software must provide a means ofrepresenting and

1.accessing external les created by other tools.

1.1 The user should be provided with facilities to dene the type of

1.2external les.

1.2 Each external le type may have an associated tool which may be

1.2applied to the le.

1.3 Each external le type may be represented as a specic icon on

1.2the users display.

1. !acilities should be provided for the icon representing an

1.2external le type to be dened by the user.1." #hen a user selects an icon representing an external le$ the

1.2e%ect of that selection is to apply the tool associated with the t

1.2the external le to the le represented by the selected icon.

&ser re'uirement denition

(ystem re'uirements specication



Requirements readers

)lient managers

(ystem end*users

)lient engineers

)ontractor managers

(ystem architects

(ystem end*users

)lient engineers

(ystem architects

(oftware developers

)lient engineers +perhaps,

(ystem architects

(oftware developers

&ser

re'uirements

(ystem

re'uirements

(oftware design

specication


10/49


Functional and non-functional requirements

Functional requirements% Statements of services the system should provide. how the

system should react to particular inputs and how the systemshould behave in particular situations"

/on-functional requirements

% constraints on the services or functions offered by the systemsuch as timing constraints. constraints on the developmentprocess. standards. etc"

*omain requirements% Requirements that come from the application domain of the

system and that reflect characteristics of that domain"


11/49


Functional requirements

*escribe functionality or system services"

*epend 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"


12/49


The 0!(S1S system

, library system that provides a single interface

to a number of databases of articles in different

libraries"

sers can search for. download and print thesearticles for personal study"


13/49


2xamples of functional requirements

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 documentstore"

2very order shall be allocated a unique identifier

)OR*2R3!*+ which the user shall be able to

copy to the accounts permanent storage area"


14/49


Requirements imprecision

4roblems arise when requirements are not

precisely stated"

,mbiguous requirements may be interpreted in

different ways by developers and users"

5onsider the term 6appropriate viewers

% ser intention - special purpose viewer for each

different document type'

% *eveloper interpretation - 4rovide a text viewer thatshows the contents of the document"


15/49


Requirements completeness and consistency

!n principle. requirements should be both complete and

consistent"

5omplete

% They should include descriptions of all facilities

required" 5onsistent

% There should be no conflicts or contradictions in the

descriptions of the system facilities"

!n practice. it is impossible to produce a complete andconsistent requirements document"


16/49


/on-functional requirements

These define system properties and constraintse"g" reliability. response time and storagerequirements" 5onstraints are !7O devicecapability. system representations. etc"

4rocess requirements may also be specifiedmandating a particular 5,S2 system.programming language or development method"

/on-functional requirements may be more critical

than functional requirements" !f these are notmet. the system is useless"


17/49


/on-functional classifications

4roduct 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 organisationalpolicies and procedures e"g" process standards used.

implementation requirements. etc"

2xternal requirements

% Requirements which arise from factors which are external to

the system and its development process e"g" interoperabilityrequirements. legislative requirements. etc"


18/49


/on-functional requirement types

-erformance

re'uirements

(pace

re'uirements

&sability

re'uirements

Efciency

re'uirements

eliability

re'uirements

-ortability

re'uirements

/nteroperability

re'uirements

Ethical

re'uirements

0egis lative

re'uirements

/mplementation

re'uirements

(tandards

re'uirements

elivery

re'uirements

(afety

re'uirements

-ri vacy

re'uirements

-roduct

re'uirements

rganisational

re'uirements

External

re'uirements

on*functionalre'uirements


19/49


/on-functional requirements examples

4roduct requirement8"9 The user interface for 0!(S1S shall be implemented as simple :T&0

without frames or ;ava applets"

Organisational requirement

The system development process and deliverable documents shall

conform to the process and deliverables defined in ?1@5o-S4-

ST,/-


20/49


Doals and requirements

/on-functional requirements may be very difficult to stateprecisely and imprecise requirements may be difficult to

verify"

Doal

% , general intention of the user such as ease of use" Eerifiable non-functional requirement

% , statement using some measure that can be objectively

tested"

Doals are helpful to developers as they convey the

intentions of the system users"


21/49


2xamples

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

% 2xperienced controllers shall be able to use all the system

functions after a total of two hours training" ,fter this training.

the average number of errors made by experienced users shall

not exceed two per day"


22/49


Requirements measures

Property Measure

#peed $rocessed transactions%second

&ser%'vent response time

#creen refresh time

#i(e ) !ytes

*umber of +) chips

'ase of use Training time*umber of help frames

+eliability )ean time to failure

$robability of unavailability

+ate of failure occurrence

vailability

+obustness Time to restart after failure

$ercentage of events causing failure$robability of data corruption on failure

$ortability $ercentage of target dependent statements

*umber of target systems


23/49


*omain requirements

*erived from the application domain anddescribe system characteristics and features that

reflect the domain"

*omain requirements be new functional

requirements. constraints on existing

requirements or define specific computations"

!f domain requirements are not satisfied. the

system may be unworable"


24/49


0ibrary system domain requirements

There shall be a standard user interface to alldatabases which shall be based on the @=


25/49


*omain requirements problems

nderstandability% Requirements are expressed in the language of the

application domain'

% This is often not understood by software engineers

developing the system" !mplicitness

% *omain specialists understand the area so well that

they do not thin of maing the domain requirements

explicit"


26/49


ser requirements

Should describe functional and non-functionalrequirements in such a way that they are

understandable by system users who dont have

detailed technical nowledge"

ser requirements are defined using natural

language. tables and diagrams as these can be

understood by all users"


27/49


4roblems with natural language

0ac of clarity% 4recision is difficult without maing 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"


28/49


0!(S1S requirement

4..5 LIBSYS shall provide a financial accounting system

that maintains records of all payments made by users of

the system. System managers may configure this systemso that regular users may receive discounted rates.


29/49


Duidelines for writing requirements

!nvent a standard format and use it for allrequirements"

se language in a consistent way" se shall for

mandatory requirements. should for desirable

requirements"

se text highlighting to identify ey parts of the

requirement"

,void the use of computer jargon"


30/49


31/49


Requirements and design

!n principle. requirements should state what thesystem should do and the design should describehow it does this"

!n practice. requirements and design are

inseparable% , system architecture may be designed to structure therequirements'

% The system may inter-operate with other systems thatgenerate design requirements'

% The use of a specific design may be a domainrequirement"


32/49


4roblems with /0 specification

,mbiguity% The readers and writers of the requirement must

interpret the same words in the same way" /0 isnaturally ambiguous so this is very difficult"

Over-flexibility% The same thing may be said in a number of different

ways in the specification"

0ac of modularisation% /0 structures are inadequate to structure system

requirements"


33/49


,lternatives to /0 specification

Notation Description

#tructured natural

language

This approach depends on defining standard forms or templates to epress the

requirements specification.

esign

description

languages

This approach uses a language li/e a programming language but with more abstract

features to specify the requirements by defining an operational model of the system.

This approach is not now widely used although it can be useful for interface

specifications.

0raphical

notations

graphical language, supplemented by tet annotations is used to define the

functional requirements for the system. n early eample of such a graphical

language was #T. *ow, use-case descriptions and sequence diagrams arecommonly used .

)athematical

specifications

These are notations based on mathematical concepts such as finite-state machines or

sets. These unambiguous specifications reduce the arguments between customer andcontractor about system functionality. 1owever, most customers dont understandformal specifications and are reluctant to accept it as a system contract.


34/49


35/49


Form-based specifications

*efinition of the function or entity" *escription of inputs and where they come from"

*escription of outputs and where they go to"

!ndication of other entities required" 4re and post conditions )if appropriate+"

The side effects )if any+ of the function"


36/49


Form-based node specification

Insulin Pump/Control Software/SRS/3.3.2

Function 2ompute insulin dose3 #afe sugar level

Description 2omputes the dose of insulin to be delivered when the current measured sugar level is inthe safe (one between 4 and 5 units.

Inputs 2urrent sugar reading 6r78, the previous two readings 6r9 and r:8

Source 2urrent sugar reading from sensor. ther readings from memory.

Outputs 2ompose ;the dose in insulin to be delivered

Destination )ain control loop

Action: 2ompose is (ero if the sugar level is stable or falling or if the level is increasing but the rate of

increase is decreasing. If the level is increasing and the rate of increase is increasing, then 2ompose is

computed by dividing the difference between the current sugar level and the previous level by < and

rounding the result. If the result, is rounded to (ero then 2ompose is set to the minimum dose that can

be delivered.

Requires Two previous readings so that the rate of change of sugar level can be computed.

Pre-condition The insulin reservoir contains at least the maimum allowed single dose of insulin..

Post-condition r9 is replaced by r: then r: is replaced by r7

Side-effects *one


37/49


Tabular specification

sed to supplement natural language" 4articularly useful when you have to define a

number of possible alternative courses of action"


38/49


Tabular specification

Condition Action

#ugar level falling 6r7 = r:8 2ompose > 9

#ugar level stable 6r7 > r:8 2ompose > 9

#ugar level increasing and rate ofincrease decreasing 66r7-r:8=6r:-r988

2ompose > 9

#ugar level increasing and rate of

increase stable or increasing. 66r7-r:8

6r:-r988

2ompose > round 66r7-r:8% 9 then

2ompose > )inimumose


39/49


Draphical models

Draphical models are most useful when youneed to show how state changes or where you

need to describe a sequence of actions"

*ifferent graphical models are explained in

5hapter 8"


40/49


Sequence diagrams

These show the sequence of events that taeplace during some user interaction with asystem"

1ou read them from top to bottom to see the

order of the actions that tae place" 5ash withdrawal from an ,T&

% Ealidate card'

% :andle request'

% 5omplete transaction"


41/49


42/49


!nterface specification

&ost systems must operate with other systemsand the operating interfaces must be specified aspart of the requirements"

Three types of interface may have to be defined

% 4rocedural interfaces'% *ata structures that are exchanged'

% *ata representations"

Formal notations are an effective technique for

interface specification"

f


43/49


4*0 interface description

interface 4rintServer H

77 defines an abstract printer server

77 requiresI interface 4rinter. interface 4rint*oc

77 providesI initialiJe. print. display4rintKueue. cancel4rint;ob. switch4rinter

void initialiJe ) 4rinter p + 'void print ) 4rinter p. 4rint*oc d + '

void display4rintKueue ) 4rinter p + '

void cancel4rint;ob )4rinter p. 4rint*oc d+ '

void switch4rinter )4rinter p9. 4rinter p>. 4rint*oc d+ '

L 774rintServer

Th i t d t


44/49


The requirements document

The requirements document is the officialstatement of what is required of the system

developers"

Should include both a definition of user

requirements and a specification of the systemrequirements"

!t is /OT a design document" ,s far as possible.

it should set of #:,T the system should do

rather than :O# it should do it

f i t d t


45/49


sers of a requirements document

&se the re'uirements to

develop validation tests for

the system

&se the re'uirements

document to plan a bid for

the system and to plan the

system development proces

&se the re'uirements to

understand what system is t

be developed

(ystem test

engineers

4anagers

(ystem

engineers

(pecify the re'uirements anread them to chec5 that the

meet their needs. They

specify changes to the

re'uirements

(ystem

customers

&se the re'uirements to hel

understand the system and

the relationships between it

parts

(ystem

maintenance

engineers


46/49

R i t d t t t


47/49


Requirements document structure

4reface !ntroduction Dlossary ser requirements definition

System architecture System requirements specification System models System evolution ,ppendices !ndex

M i t


48/49


Mey points

Requirements set out what the system should do anddefine constraints on its operation and implementation"

Functional requirements set out services the system

should provide"

/on-functional requirements constrain the system beingdeveloped or the development process"

ser requirements are high-level statements of what the

system should do" ser requirements should be written

using natural language. tables and diagrams"

Mey points


49/49


Mey points

System requirements are intended tocommunicate the functions that the systemshould provide"

, software requirements document is an agreedstatement of the system requirements"

The !222 standard is a useful starting point fordefining more detailed specific requirements

standards"

software reuirements

Documents