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
Client managers
System end-users
Client engineers
Contractor managers
System architects
System end-users
Client engineers
System architects
Software developers
Client engineers (perhaps)
System architects
Software developers
Slide 5
Functional, non-functional, domain
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
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
‘The system shall provide appropriate viewers (*)
for the user to read documents in the document
(*) 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
requir ements
requir ements
Ef ficiency
requir ements
requir ements
Or ganizational
requir ements
requir ements
requir ements
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
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
… nevertheless, goals are helpful to developers as
they convey the intentions of the Client
Slide 11
Requirements measures
Ease of use
Robustnes s
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
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
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
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
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
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
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
Slide 18
Problems in the Editor grid requirement
Grid requirement mixes three different kinds of
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
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
The editor shall provide a f acility for users to add nodes of a specified type to their
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
language s
specification s
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
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.
Node type, Node position, Des ign identifier.
Node type and Node position are input by the us er, Design identifier from the databas e.
Des ign identifier.
Des tination
The design databas e. The des ign is committed to the database on completion of the
Des ign graph rooted at input des ign identifier.
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
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
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
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
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)
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
Sottofase II (linguaggio formale)
5. specifica formale dei requisiti ==> modello astratto del
Slide 33
1. Studio di fattibilità
Valutazione di costi, benefici e rischi
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
“Trovare e riparare un difetto nel software consegnato costa
100 volte meno che farlo durante l’analisi dei requisiti”.
“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]
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
Slide 42
Specifica simultanea dei requisiti (problema)
e di un modello astratto del sistema (soluzione)
User Requirements
Formal specification
R1 ...
Modello formale
astratto del sistema,
dal comportamento
R2 ...
R3 ...
In linguaggio naturale
In linguaggio formale
eseguibile, analizzabile
Slide 43

Requirements Engineering