software requirements document

8/10/2019 Software Requirements Document

1/17

Software Requirements Document

The software requirements document is the

official statement of what is required of the

system developers. Should include both a definition of user

requirements and a specification of the

system requirements.

1


2/17

Agile methods and requirements

Many agile methods argue that producing a

requirements document is a waste of time as

requirements change so quickly.

The document is therefore always out of date. Methods such as ! use incremental requirements

engineering and e"press requirements as #user stories$.

This is practical for business systems but problematic for

systems that require a lot of pre%delivery analysis &e.g.critical systems' or systems developed by several

teams.

2


3/17

User stories (discussed in chap. 3) 3


4/17

(sers of a requirements document 4


5/17

The structure of a requirements document 5

Chapter Description

!reface This should define the e"pected readership of the document and describeits version history) including a rationale for the creation of a new versionand a summary of the changes made in each version.

*ntroduction This should describe the need for the system. *t should briefly describe the

system$s functions and e"plain how it will work with other systems. *tshould also describe how the system fits into the overall business orstrategic ob+ectives of the organi,ation commissioning the software.

-lossary This should define the technical terms used in the document. ou shouldnot make assumptions about the e"perience or e"pertise of the reader.

(ser requirementsdefinition

/ere) you describe the services provided for the user. The nonfunctionalsystem requirements should also be described in this section. Thisdescription may use natural language) diagrams) or other notations thatare understandable to customers. !roduct and process standards thatmust be followed should be specified.

System architecture This chapter should present a high%level overview of the anticipatedsystem architecture) showing the distribution of functions across systemmodules. Architectural components that are reused should be highlighted.


6/17

The structure of a requirements document

Chapter Description

Systemrequirementsspecification

This should describe the functional and nonfunctional requirements in moredetail. *f necessary) further detail may also be added to the nonfunctionalrequirements. *nterfaces to other systems may be defined.

System models This might include graphical system models showing the relationships betweenthe system components and the system and its environment. 0"amples of

possible models are ob+ect models) data%flow models) or semantic data models.

System evolution This should describe the fundamental assumptions on which the system isbased) and any anticipated changes due to hardware evolution) changing userneeds) and so on. This section is useful for system designers as it may help themavoid design decisions that would constrain likely future changes to the system.

Appendices These should provide detailed) specific information that is related to theapplication being developed1 for e"ample) hardware and database descriptions./ardware requirements define the minimal and optimal configurations for thesystem. Database requirements define the logical organi,ation of the data usedby the system and the relationships between data.

*nde" Several inde"es to the document may be included. As well as a normalalphabetic inde") there may be an inde" of diagrams) an inde" of functions) andso on.

6


7/17

Requirements specification

The process of writing down the user and systemrequirements in a requirements document.

(ser requirements have to be understandable by end%

users and customers who do not have a technical

background. System requirements are more detailed requirements

and may include more technical information.

The requirements may be part of a contract for the

system development *t is therefore important that these are as complete as

possible.

7


8/17

2ays of writing a system

requirements specification 8

Notation Description

3atural language The requirements are written using numbered sentences in naturallanguage. 0ach sentence should e"press one requirement.

Structured naturallanguage

The requirements are written in natural language on a standard form ortemplate. 0ach field provides information about an aspect of therequirement.

Design descriptionlanguages

This approach uses a language like a programming language) but with moreabstract features to specify the requirements by defining an operationalmodel of the system. This approach is now rarely used although it can beuseful for interface specifications.

-raphical notations -raphical models) supplemented by te"t annotations) are used to define thefunctional requirements for the system1 (M4 use case and sequence

diagrams are commonly used.

Mathematicalspecifications

These notations are based on mathematical concepts such as finite%statemachines or sets. Although these unambiguous specifications can reducethe ambiguity in a requirements document) most customers don$tunderstand a formal specification. They cannot check that it represents whatthey want and are reluctant to accept it as a system contract


9/17

-uidelines for writing requirements

in natural language *nvent a standard format and use it for all

requirements.

(se language in a consistent way. (se shall for

mandatory requirements) should for desirable

requirements.

(se te"t highlighting to identify key parts of the

requirement.

Avoid the use of computer +argon.

*nclude an e"planation of why a requirement is

necessary.


10/17

0"ample requirements for the insulin

pump software system10

3.2 The system shall measure the lood su!arand deli"er insulin# i$ re%uired# e"ery 10 minutes.(Changes in blood sugar are relatively slow so

more frequent measurement is unnecessary; lessfrequent measurement could lead tounnecessarily high sugar levels.)

3.6 The system shall run a sel$&test routine e"eryminute 'ith the conditions to e tested and theassociated actions dened in Tale 1.(A self-testroutine can discover hardware and software

problems and alert the user to the fact thenormal operation may be impossible.)


11/17

!roblems with natural language

4ack of clarity

!recision is difficult without making the document

difficult to read.

Requirements confusion 5unctional and non%functional requirements tend to

be mi"ed%up.

Requirements amalgamation Several different requirements may be e"pressed

together.


12/17

Structured specifications

An approach to writing requirements where

the freedom of the requirements writer is

limited and requirements are written in astandard way.

This works well for some types of

requirements e.g. requirements for embedded

control system but is sometimes too rigid for

writing business system requirements.

12


13/17

5orm%based specifications

Definition of the function or entity.

Description of inputs and where they come from.

Description of outputs and where they go to.

*nformation about the information needed for the

computation and other entities used.

Description of the action to be taken.

!re and post conditions &if appropriate'.

The side effects &if any' of the function.

14


14/17

A structured specification of a

requirement for an insulin pump14


15/17

A structured specification of a

requirement for an insulin pump15


16/17

Tabular specification

(sed to supplement natural language.

!articularly useful when you have to define a

number of possible alternative courses ofaction.

5or e"ample) the insulin pump systems

bases its computations on the rate of change

of blood sugar level and the tabularspecification e"plains how to calculate the

insulin requirement for different scenarios.

17


17/17

Tabular specification of

computation for an insulin pump17

Condition Action

Sugar level falling &r6 7 r8' 9ompDose : ;

Sugar level stable &r6 : r8' 9ompDose : ;

Sugar level increasing and rate of increasedecreasing&&r6 < r8' 7 &r8 < r;''

9ompDose : ;

Sugar level increasing and rate of increasestable or increasing&&r6 < r8' = &r8 < r;''

9ompDose :round &&r6 < r8'>?'

*f rounded result : ; then9ompDose : MinimumDose

software requirements document

Documents