Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
COMP 201
Lecturer: Sebastian Coope
Ashton Building, Room G.18
E-mail: coopes@liverpool.ac.uk
COMP 201 web-page:
http://www.csc.liv.ac.uk/~coopes/comp201
COMP201SoftwareEngineering
Software Requirements
Descriptions and specifications of a system
Last time:
This lecture:
System Requirements
System Requirements are more detailed
specifications of user requirements:
They serve as a basis for designing the
system;
may be used as part of the system
contract;
may be expressed using system models
(will be discussed more later).
COMP201SoftwareEngineering
Over-flexibility
The same thing may be said in a number of different
Lack of modularisation
Natural language structures are inadequate to
An Example
Imagine the following example of an informal
[1]
this specification?
We will later see some other ways with
documenting this example by a Petri net (see
Lecture 9).
[1]C.Ghezzi,M.Jazayeri,D.Mandrioli,FundamentalsofSoftware
Engineering,PrenticeHall,SecondEdition,page196198
Alternatives to NL Specification
Notation
Structured
natural
language
Design
description
languages
Graphical
notations
Mathematical
specifications
Description
This approach depends on defining standard forms or
templates to express the requirements specification.
This approach uses a language like a programming
language but with more abstract features to specify the
requirements by defining an operational model of the
system.
A graphical language, supplemented by text annotations is
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.
These are notations based on mathematical concepts
such as finite-state machines or sets. These unambiguous
specifications reduce the arguments between customer
and contractor about system functionality. However, most
customers dont understand formal specifications and are
reluctant to accept it as a system contract. I discuss formal
specification in Chapter 9.
COMP201SoftwareEngineering
approach
COMP201SoftwareEngineering
Forms
Define the information required
Constrain its format
Keeps the information in a defined structure
Filter out extra information that might cause
confusion
Makes it possible to read specification quickly
Supports tasks like system testing
COMP201SoftwareEngineering
Form-Based Specifications
Definition of the function or entity
Description of inputs and where they come
from
Description of outputs and where they go to
Indication of other entities required
Pre and post conditions (if appropriate)
The side effects (if any)
COMP201SoftwareEngineering
10
Action: CompDose is zero 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 CompDose is
computed by dividing the difference between the current sugar level and the previous level by 4 and
rounding the result. If the result, is rounded to zero then CompDose is set to the mi nimum dose that can
be delivered.
Requires
Two previous readings so that the rate of change of sugar level can be comp uted.
Pre-condition
The insulin reservoir contains at least the maximum allowed single dose of insulin..
Post-condi tion
Side-effects
None
COMP201SoftwareEngineering
11
Tabular Specification
Tabular Specification is used to supplement
natural language.
It is particularly useful when you have to define
a number of possible alternative courses of
action
This can be thought of as a series of if
statements to determine the action to be
taken upon a certain criteria being met.
COMP201SoftwareEngineering
12
Action
Sugarlevelfalling(r2<r1)
CompDose=0
CompDose=0
Sugarlevelincreasingandrateof
increasedecreasing((r2r1)<(r1r0))
CompDose=0
Sugarlevelincreasingandrateof
increasestableorincreasing.((r2r1)
(r1r0))
CompDose=round((r2r1)/4)
Ifroundedresult=0then
CompDose=MinimumDose
COMP201SoftwareEngineering
13
COMP201SoftwareEngineering
15
Interface Specification
Most systems must operate with existing systems
16
COMP201SoftwareEngineering
17
18
Systemcustomers
Specifytherequirementsand
read themtocheckthatthey
meet theirneeds.They
specifychangesto the
requirements
Managers
Usetherequirements
document toplan abid for
thesystemand toplan the
systemdevelopmentprocess
Systemengineers
Usetherequirements to
understand whatsystemis to
be developed
Systemtest
engineers
Usetherequirements to
develop validationtestsfor
thesystem
System
maintenance
engineers
Usetherequirements tohelp
understand thesystemand
therelationshipsbetween its
parts
COMP201SoftwareEngineering
Users of a
Requireme
nts
Document
19
Requirements Document
Specify external system behaviour
Specify implementation constraints
Easy to change
Serve as reference tool for maintenance
Record forethought about the life cycle of the
COMP201SoftwareEngineering
20
Requirements Document
The level of detail used within the requirements
21
COMP201SoftwareEngineering
22
23
System architecture
High-level overview of the system architecture
functional requirements.
COMP201SoftwareEngineering
25
components, the system and its environment (object, dataflow models etc.)
System evolution
Describe anticipated changes to the system due to hardware
Appendices
Detailed specific information about the system being
Index
Indices of the document including diagrams and functions.
COMP201SoftwareEngineering
26
Key Points
Requirements set out what the system should
27
Key Points
User requirements should be written in natural
28
Next Lecture
We shall be looking in more detail at
COMP201SoftwareEngineering
29