software requirements document
TRANSCRIPT
-
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
-
8/10/2019 Software Requirements Document
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
-
8/10/2019 Software Requirements Document
3/17
User stories (discussed in chap. 3) 3
-
8/10/2019 Software Requirements Document
4/17
(sers of a requirements document 4
-
8/10/2019 Software Requirements Document
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.
-
8/10/2019 Software Requirements Document
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
-
8/10/2019 Software Requirements Document
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/10/2019 Software Requirements Document
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
-
8/10/2019 Software Requirements Document
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.
-
8/10/2019 Software Requirements Document
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.)
-
8/10/2019 Software Requirements Document
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.
-
8/10/2019 Software Requirements Document
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
-
8/10/2019 Software Requirements Document
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
-
8/10/2019 Software Requirements Document
14/17
A structured specification of a
requirement for an insulin pump14
-
8/10/2019 Software Requirements Document
15/17
A structured specification of a
requirement for an insulin pump15
-
8/10/2019 Software Requirements Document
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
-
8/10/2019 Software Requirements Document
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