Lezione 4. Requirements
•
•






[S2001, Cap. 5]
[AC96, Cap. 1]
Functional, non-functional, domain requirements
User requirements
System and software requirements
Requirements languages
The requirements document
Requirements analysis [AC96]
Slide 1
What is a requirement?

It may range from a high-level abstract statement
of a service or of a system constraint to a detailed
mathematical functional specification…

…since requirements may serve a dual function
•
•
May be the basis for a bid for a contract - therefore must be
open to interpretation (client ==> potential developers)
May be the basis for the contract itself - therefore must be
defined in detail (developer ==> potential client)
Slide 2
Requirements definition/specification

Requirements definition (user requirements)
•

Requirements specification (system requirements)
•

A statement in natural language plus diagrams of the services the
system provides and its operational constraints. Based on information
from Client, and written for him (or even by him)
A structured document setting out detailed descriptions of the system
services. Written as a contract between Client and Developer
Software specification (software requirements)
•
A detailed software description which can serve as a basis for a design
or implementation. Written for technical developers (design team,
programmers…). May be omitted……...
Slide 3
Requirements definition/spec. - example
Requirements definition
1. The software must provide a means of repr esenting and
1. accessing external files created by other tools.
Requirements specification
1.1 The user should be provided with facilities to define the type of
1.2 external files.
1.2 Each external file type may have an associated tool which may be
1.2 applied to the file.
1.3 Each external file type may be represented as a specific icon on
1.2 the user’s display.
1.4 Facilities should be provided for the icon repr esenting an
1.2 external file type to be defined by the user.
1.5 When a user selects an icon repr esenting an external file, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.
Slide 4
Requirements readers
Requirements
definition
Client managers
System end-users
Client engineers
Contractor managers
System architects
Requirements
specification
System end-users
Client engineers
System architects
Software developers
Software
specification
Client engineers (perhaps)
System architects
Software developers
Slide 5
Functional, non-functional, domain
requirements



Requirements engineering is the process of establishing the
services that the Client requires from a system and the constraints
under which it operates and is developed
Requirements may be functional or non-functional
•
Functional requirements describe system services or functions,
often expressed in terms system reactions to inputs from the
environment
•
Non-functional requirements are constraints on the services
offered by the system, and on the development process
Domain requirements (funct./non funct.)come from the application
domain of the system and reflect characteristics of that domain
Slide 6
Functional requirements - examples

‘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 document
store’.
•
•

(*) User intention - special purpose viewer for each document type
(*) Developer interpretation - Provide a text viewer that shows the
contents of the document
‘Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy to
the account’s permanent storage area’.
Slide 7
Non-functional requirements



On: Reliability, response time, storage capacity, I/O
device capability, data representation.
On: 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
Slide 8
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
Space
requir ements
External
requirements
Interoperability
requirements
Implementation
requir ements
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
Slide 9
Non-functional requirements examples

Product requirement
•

Organisational requirement
•

4.C.8 It shall be possible for all necessary
communication between the APSE and the user to be
expressed in the standard Ada character set
9.3.2 The system development process and
deliverable documents shall conform to the process
and deliverables defined in XYZCo-SP-STAN-95
External requirement
•
7.6.5 The system shall not disclose any personal
information about customers apart from their name
and reference number to the operators of the
system
Slide 10
Verifiable non-functional reqs. Vs. goals

A system ‘goal’
•

A verifiable non-functional requirement
•

The system should be easy to use by experienced controllers and
should be organised in such a way that user errors are minimised.
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.
… nevertheless, goals are helpful to developers as
they convey the intentions of the Client
Slide 11
Requirements measures
Property
Speed
Size
Ease of use
Reliability
Robustnes s
Portability
Meas ure
Process ed trans actions/s econd
User/Event respons e time
Screen refres h time
K Bytes
Number of RAM chips
Training time
Number of help frames
Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Percentage of target dependent statements
Number of target systems
Slide 12
Non functional requirements conflicts

... are common in complex systems

Example: Spacecraft system
•
•
•
Req.1 - System should fit into 4Mbytes of
memory
Req.2 - System should be written in ADA
However, it may be impossible to compile an ADA program
with the required functionality into 4Mbytes: drop one of the
requirements...
Slide 13
Domain requirements



Derived from the application domain; describe system features
that reflect the domain
May be new functional requirements, constraints on existing
requirements or define specific computations
Problems:
•
•
Understandability. Requirements are expressed in the language of
the application domain. This is often not understood by software
engineers developing the system
Implicitness. Domain specialists understand the area so well that
they do not think of making the domain requirements explicit
Slide 14
Example: Library system domain requirements

‘There
shall
be
a
standard
user
interface to all databases which shall
be based on the Z39.50 standard’ (a
standard for this Library).

‘Because of copyright restrictions, some
documents must be deleted immediately on
arrival.
Depending
on
the
user’s
requirements,
these
documents
will
either be printed locally on the system
server for manually forwarding to the
user or routed to a network printer’.
Slide 15
Example: train system domain requirement

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.
Slide 16
User requirements


Should describe functional and non-functional
requirements so that they are understandable by nontechnical system-users. Externally visible behaviour
User requirements are defined using natural language,
tables and diagrams. Problems:
•
Lack of clarity, ambiguity (‘Dogs must be carried’)
» Precision is difficult without making 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
Slide 17
Example: 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’.
Slide 18
Problems in the Editor grid requirement

Grid requirement mixes three different kinds of
requirement
•
•
•
Conceptual functional requirement (the need for a grid)
Non-functional requirement (grid units)
Non-functional UI requirement (grid switching)
Slide 19
Editor example: structured presentation
2.6 Grid f acilities
2.6.1
The editor shall provide a grid facility wh ere a
matrix of horizontal and ver tical lines provide a
background to the editor windo w. T his grid shall be
a p assive grid where the alignme nt 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: ECL IPSE/WS/Tools/DE/FS Section 5.6
Slide 20
Editor example: detailed user requirement
3.5.1 Adding nodes to a design
3.5.1.1
The editor shall provide a f acility for users to add nodes of a specified type to their
design.
3.5.1.2
The sequence of actions to add a node should be as follows:
1. The user should select the type of node to be added.
2. The user should mo ve the cursor to the approximate node position in the diagram and
indicate that the node symb ol should be added at that point.
3. The user should then drag the node symb ol to its final position.
Rationale: The user is the best person to decide where to position a node on the diagram.
This approach gives the user direct control over node type selection and positioning.
Specification: ECL IPSE/WS/Tools/DE/FS. Section 3.5.1
Slide 21
System and software requirements


More detailed specifications of user requirements
Serve as a basis for the Design
•
•


in principle Reqs. and Design are separated (WHAT vs. HOW)
in practice they are interdependent
May be used as part of the system contract
May be complemented with, or expressed by system
models (Entity-Relation, Data-Flow, Petri nets,
Communicating Finite State Machines, Statecharts,
Basic LOTOS…)
Slide 22
Alternatives to NL specification
Notation
Structured
natural
language
Design
description
language s
Graphical
notations
Mathematical
specification s
Description
This approach depends on defining standard forms or
templates to expr ess the requir ements specific ation .
This approach uses a la nguage li ke a programmi ng langu age
but with more abstract features to specify the requir ements
by defining an op erationa l m odel of the system.
A graph ic al languag e, supp lemented by text anno tations is
used to define the func tiona l requi rements for the system.
An early exa mple of such a graphical langu age was SADT
(Ross, 1977 ; Scho man and Ross, 1977 ). More recently, use case desc riptions (Jacobsen, Christerson et al., 1993) have
been used. I d iscuss these in the following chap ter.
These are no tations based on mathematical concep ts such
as finite-state ma chines or sets. Th ese una mbiguous
specification s reduc e the argum ents between cus tomer and
contractor about system func tiona lit y. Howeve r, most
customers don’t unde rstand forma l specifications and are
reluctant to accept it as a system contract. I discuss fo rmal
specification in Chap ter 9.
Slide 23
Structured natural language specifications



A limited form of natural language may be used
to express requirements
This removes some of the problems resulting
from ambiguity and over-flexibility and imposes
a degree of uniformity on a specification
Often supported by a forms-based approach
Slide 24
Form-based req. spec. - Editor example
ECLIPSE/Workstation/Tools /DE/FS/3.5.1
Function
Add node
Des cription
Addsa node to an exis ting des ign. The us er selects the type of node, and its position.
When added to the des ign, the node becomesthe current selection. The us er chooses the node position by
moving the cursor to the area where the node is added.
Inputs
Node type, Node position, Des ign identifier.
Source
Node type and Node position are input by the us er, Design identifier from the databas e.
Outputs
Des ign identifier.
Des tination
operation.
The design databas e. The des ign is committed to the database on completion of the
Requires
Des ign graph rooted at input des ign identifier.
Pre-condition
The design is open and dis played on the us er's s creen.
Pos t-condition
at the given position.
The design is unchanged apart from the addition of a node of the s pecified type
Side-effects
None
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1
Slide 25
PDL (Program Descr. Language)-based
requirements definition

Requirements may be defined operationally using a
programming language (e.g. Java)
•

Most appropriate in two situations
•
•

enriched by constructs for further flexibility
Where an operation is specified as a sequence of actions and the
order is important
When hardware and software interfaces have to be specified
Disadvantages are
•
•
The PDL may not be sufficiently expressive to define domain
concepts
The specification will be taken as a design rather than a specification
Slide 26
PDL Example: 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 PIN");
thisBalance = thisCard.getBalance () ;
do { Screen.prompt (" Please select a service ") ;
service = Screen.touchKey () ;
switch (service) {
case Services.withdrawalWithReceipt:
receiptRequired = true ;
Slide 27
System requirements: interface specification


Most systems must operate with other systems
and the operating interfaces must be specified as
part of the requirements
Three types of interface may have to be defined
•
•
•

Procedural interfaces
Data structures that are exchanged
Data representations
Formal notations are an effective technique for
interface specification
Slide 28
PDL interface description
interface PrintServer {
// defines an abstract printer server
// requires:
interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter
void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
Il costrutto ‘Interface’ di Java è molto adatto alla specifica…
di interfacce
Slide 29
Requirements document structure

Introduction
•

Glossary
•

Describe the services to be provided
Non-functional requirements definition (user reqs.)
•

Define technical terms used
Functional requirements definition (user reqs.)
•

Describe need for the system and how it fits with business objectives
Define constraints on the system and the development process
System Architecture
•
helps structuring requirements around subsystems
Slide 30

System and software requirements specification
•

System models
•

Define fundamental assumptions on which the system is based and
anticipated changes
Appendices
•
•
•

Define models showing system components and relationships
System evolution
•

Detailed specification of functional requirements
System hardware platform description
Database requirements (as an ER model perhaps)
May include USER MANUAL and TEST PLAN
Index
Slide 31
Analisi dei requisiti
[AC96, fig 1.1]
Slide 32
La fase di Analisi
•
•

Sottofase I (linguaggio naturale +...)
•
•
•
•

Studia e definisce il problema da risolvere
Stretta interazione con il committente
1. studio di fattibilità
2. comprensione del dominio (==> glossario)
3. stesura (raccolta e definizione) dei requisiti
4. ispezione dei requisiti
…’analisi’
Sottofase II (linguaggio formale)
•
5. specifica formale dei requisiti ==> modello astratto del
sistema
Slide 33
1. Studio di fattibilità

Valutazione di costi, benefici e rischi
•
•
•

Output
•

Disponibilità di librerie SW? HW adatto alle prestazioni attese?
Uso di tecnologie non consolidate?
Valore di mercato al tempo di consegna?
n scenari di sviluppo, con relativi tempi e costi
Società specializzate nel puro studio di fattibilità
Slide 34
2. Comprensione del dominio
•
Comprensione dei concetti e termini usati dal Committente per
parlare del sistema e del suo contesto.
»
•
Input: documenti dal Committente e altri reperiti autonomam.
»
•
Lo Sviluppatore acquisisce la competenza del Committente, non
viceversa ==> migliore interazione
Es. strutture organizzative/commerciali, caratteristiche di impianti,
leggi fisiche
Output: Glossario
»
»
Insieme chiuso e sintetico di definizioni che rifletta la complessità
del dominio.
Può includere descrizioni di algoritmi, procedure d’ufficio, ...
Slide 35
Stesura del Glossario
Slide 36
3. Stesura dei requisiti
•
Ha valore contrattuale…
(stesura e ispezione)
Slide 37
Il documento dei requisiti
•
•
•
•
•
•
Ha valore contrattuale…
.. ma è soggetto a cambiamenti ‘tardivi’.
E’ scritto in linguaggio naturale
Ogni requisito cattura un aspetto o vincolo, completo e
indipendente, del sistema
Requisiti obbligatori, desiderabili, opzionali (==> contratto)
Non dovrebbe contenere:
»
»
»
»
»
inconsistenze (req. ==><== req.)
ambiguità (req. ?!)
imprecisioni terminologiche (req. ==><== glossario)
ridondanze (req ==> req.)
dettagli tecnici e rif. alla soluzione-implementazione
Slide 38
•
Dovrebbe essere completo
» Elenca tutte e sole le esigenze del Committente
» Usa tutti e soli i termini del Glossario
•
Dovrebbe essere ben strutturato
» bilanciando la granularità dei requisiti
» minimizzando riferimenti in avanti.
•
Lemmario: elenco dei termini usati nei requisiti, ciascuno con
lista di puntatori ai requisiti che lo usano.
» Facilita la ricerca di inconsistenze o ridondanze in requisiti
semanticamente vicini
Slide 39
4. Ispezione dei requisiti

Boehm:
•

“Trovare e riparare un difetto nel software consegnato costa
100 volte meno che farlo durante l’analisi dei requisiti”.
Fagan:
•
“la maggior parte degli errori si manifesta dopo la consegna
del sistema, ma ha origine durante l’analisi dei requisiti”.
Slide 40
Lettura strutturata


È economica e rivela il 60% degli errori [Boehm]
ESEMPIO
•
•
•
Analisi dei requisiti di CTC (Centralised Traffic Controller)
delle ferrovie nordamericane - 1990
10 gruppi di analisti in parallelo
Dei 92 difetti del documento dei requisiti
» 77 vengono trovati durante l’ispezione dei requisiti
» 15 nelle fasi successive
•

Ogni gruppo trova mediamente ‘solo’ 25 difetti.
L’ispezione parallela e ridondante paga.
Slide 41
5. Specifica formale

Descrizione tecnica del comportamento di un
sistema che risponde ai requisiti
•

(dei requisiti…) [AC96]
enfasi sull’osservatore esterno: sistema come black box
==> Modello astratto del sistema
•
primo passo dalla caratterizzazione verso la soluzione del
problema
Slide 42
Specifica simultanea dei requisiti (problema)
e di un modello astratto del sistema (soluzione)
User Requirements
Formal specification
P1
R1 ...
P2
Modello formale
astratto del sistema,
dal comportamento
osservabile
desiderato
R2 ...
R3 ...
In linguaggio naturale
P3
???
In linguaggio formale
eseguibile, analizzabile
Slide 43