Transcript Software Engineering, 7th edition. Chapter 6

Cerinţele software
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 1
Obiective



Conceptele de cerinţe utilizator şi cerinţe sistem
Cerinţe funcţionale şi cerinţe non-funcţionale
Organizarea cerinţelor software într-un document
al cerinţelor
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 2
Subiecte tratate





Cerinţe funcţionale şi non-funcţionale
Cerinţele utilizator
Cerinţele sistem
Specificaţiile de interfaţă
Documentul cerinţelor software
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 3
Ingineria cerinţelor
Def. Ingineria cerinţelor = procesul de stabilire a
serviciilor pe care le solicită utilizatorul din partea
sistemului şi constrângerile impuse operării şi
dezvoltării sistemului.
Def. Cerinţele = descrierile serviciilor şi
constrângerilor sistemului, care sunt generate în
timpul procesului de inginerie a cerinţelor.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 4
Ce este o cerinţă?


Poate varia de la o descriere abstractă de nivel înalt a
unui serviciu sau a unei constrângeri a sistemului până la
o specificaţie funcţională precizată în detaliu în termeni
matematici.
Acest lucru este inevitabil deoarece cerinţele pot servi
unei funcţii duale
•
•
•
Pot fi baza unei licitaţii pentru un contract – trebuie să fie
deschise către interpretare;
Pot fi baza contractului însuşi – trebuie definite în detaliu;
Ambele declaraţii (abstractă şi detaliată) pot fi numite cerinţe.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 5
Nivelul de abstractizare al cerinţelor
(Davis)
“Dacă o companie doreşte lansarea unui contract pentru dezvoltarea unui proiect software de dimensiuni
mari, aceasta trebuie să-şi definească necesităţile într-un mod suficient de abstract astfel încât să nu existe
o soluţie predefinită. Cerinţele trebuie scrise astfel încât mai mulţi contractori să poată licita pentru
obţinerea contractului, oferind, probabil, moduri diferite de a îndeplini necesităţile organizaţiei clientului.
Odată ce contractul a fost atribuit, contratorul trebuie să scrie o definiţie a sistemului cu un nivel mai
mare de detaliere astfel încât clientul înţelege şi poate valida ceea ce software-ul urmează să facă.
Ambele documente descrise mai sus pot fi numite documentul cerinţelor pentru sistem.”
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 6
Tipurile de cerinţe

Cerinţe utilizator
•

Expuneri în limbaj natural plus diagrame ale
serviciilor pe care le furnizează sistemul şi
constrângerile sale operaţionale. Scrise pentru
clienţi.
Cerinţe sistem
•
A structured document setting out detailed
descriptions of the system’s functions, services and
operational constraints. Defines what should be
implemented so may be part of a contract between
client and contractor.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 7
Definiţii şi specificaţii
Definiţie cerinţă utilizator:
1. Software-ul trebuie să oferă un mijloc de a reprezenta şi accesa fişiere externe create de
alte instrumente.
Specificaţie cerinţe sistem:
1.1 Utilizatorulului trebuie să i se ofere facilităţi de a defini tipuri de fişiere externe.
1.2 Fiecare tip de fişier extern poate avea asociat un instrument care poate fi aplicat fişierului.
1.3 Fiecare tip de fişier extern poate fi reprezentat sub forma unei pictograme specifice pe
display-ul utilizatorului.
1.4 Trebuie oferită facilităţi pentru definirea de către utilizator a pictogramei pentru reprezentarea
unui tip de fişier extern.
1.5 Când un utilizator selectează o pictogramă reprezentând un fişier extern, efectul selectării
este acela de a aplica instrumentul asociat tipului de fişier extern fişierului reprezentat de
pictograma selectată.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 8
Cititorii cerinţelor
Cerinţe utilizator
Cerinţe sistem
©Ian Sommerville 2004
Manageri la client
Utilizatori finali ai sistemului
Ingineri la client
Manageri la contractori
Arhitecţii sistemului
Utilizatori finali ai sistemului
Ingineri la client
Arhitecţii sistemului
Dezvoltatorii de software
Software Engineering, 7th edition. Chapter 6
Slide 9
Cerinţe funcţionale şi non-funcţionale

Cerinţe funcţionale
•

Cerinţe non-funcţionale
•

Precizarea serviciilor pe care trebuie să le ofere sistemul, cum
trebuie să reacţioneze sistemul la intrări particulare şi cum
trebuie să se comporte sistemul în situaţii particulare.
Constrângeri asupra serviciilor sau funcţiilor oferite de sistem,
cum ar fi constrângeri de timp, constrîngeri asupra procesului
de dezvoltare, standarde, etc.
Cerinţe de domeniu
•
Cerinţe care vin din partea domeniului de aplicaţie a sistemului
şi care reflectă caracteristicile acelui domeniu.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 10
Cerinţe funcţionale




Descriu funcţionalitatea sau serviciile sistem.
Depind de tipul de software, de utilizatorii
preconizaţi şi de tipul sistemului în care este
utilizat software-ul.
Cerinţele utilizator funcţionale pot fi expuneri de
nivel înalt despre ceea ce trebuie să facă
sistemul.
Cerinţele sistem funcţionale trebuie să descrie
serviciile sistemului în detaliu.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 11
Sistemul LIBSYS


Un sistem de bibliotecă ce oferă o interfaţă unică
către mai multe baze de date cu articole din
diferite biblioteci.
Utilizatorii pot căuta, descărca şi imprima aceste
articole pentru studiu individual.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 12
Exemple de cerinţe funcţionale



Utilizatorul trebuie să poată căuta fie în întregul
set iniţial al bazelor de date fie să poată selecta
un subset al acestuia.
Sistemul va oferă instrumente de vizualizare
corespunzătoare pentru ca utilizatorul să
citească documentele.
Fiecărui ordin i se va aloca un identificator unic
(ORDER_ID) pe care utilizatorul îl va putea copia
în zona de memorie permanentă a contului.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 13
Imprecizia cerinţelor



Dacă cerinţele nu sunt exprimate precis pot să apară
probleme.
Cerinţe ambigue pot fi interpretate în moduri diferite de
către dezvoltatori şi utilizatori.
Considerăm termenul ‘instrumente de vizualizare
corespunzătoare’
•
•
Intenţia utilizatorului – instrumente de vizualizare specifice
pentru fiecare tip de document;
Interpretarea dezvoltatorului – Oferirea unui instrument simplu
de vizualizare text care să arate conţinutul documentului.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 14
Completitudinea şi consistenţa cerinţelor




În principiu, cerinţele trebuie să fie atât complete cât şi
consistente.
Complete
• Trebuie să includă descrieri ale tuturor facilităţilor
necesare.
Consistente
• Nu trebuie să existe conflicte sau contradicţii în
descrierile facilităţilor sistemului.
În practică, este imposibil să se producă un document al
cerinţelor şi complet şi consistent.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 15
Cerinţe non-funcţionale



Definesc proprietăţile (ex. fiabilitate, timp de răspuns,
necesar de memorie) şi constrângerile (ex. capabilităţile
dispozitivelor de I/E, reprezentările sistemului, etc.)
Cerinţele procesului pot fi, de asemenea,
specificate impunând un anume sistem CASE,
un limbaj de programare sau o metodă de
dezvoltare.
Pot fi mai critice decât cerinţele funcţionale: dacă
nu sunt îndeplinite atunci sistemul este
nefolositor.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 16
Clasificarea cerinţelor
non-funcţionale

Cerinţe produs
•

Cerinţe de organizaţie
•

Cerinţe care specifică modul particular în care trebuie să se
comporte produsul furnizat (ex. viteză de execuţie, fiabilitate, etc.)
Cerinţe ce sunt consecinţă a politicilor şi procedurilor
organizaţionale (ex. standarde de proces utilizate, cerinţe de
implementare, etc.)
Cerinţe externe
•
Cerinţe care provin de la factorii externi sistemului şi procesului
dezvoltării sale (ex. cerinţe de interoperabilitate, cerinţe legislative
etc.)
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 17
Tipurile cerinţelor non-funcţionale
Non-funcţionale
Organizaţionale
Produs
Eficienţă
Fiabilitate
Performanţă
©Ian Sommerville 2004
Spaţiu
Interoperabilitate
Portabilitate
Furnizare
Utilizabilitate
Externe
Implementare
Etică
Standarde
Confidenţialitate
Software Engineering, 7th edition. Chapter 6
Legislative
Siguranţă
Slide 18
Cerinţe non-funcţionale: exemple

Cerinţă produs
8.1 Interfaţa utilizator pentru LIBSYS va fi implementată în format HTML
simplu fără cadre (frames) şi applet-uri Java.

Cerinţă organizaţională
9.3.2 Procesul de dezvoltare a sistemului şi documentele livrabilelor se
vor conforma procesului şi livrabilelor definite în XYZCo-SP-STAN95.

Cerinţă externă
7.6.5 Sistemul nu va descoperi operatorilor sistem nici o informaţie
personală despre clienţi în afară de numele şi numărul referinţei lor.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 19
Ţeluri şi cerinţe


Poate fi foarte dificil de precizat unele cerinţe nonfuncţionale, iar cerinţe imprecise pot fi verificate cu
dificultate.
Ţel
•

Cerinţă non-funcţională verificabilă
•

O intenţie generală a utilizatorului (ex. uşurinţa în utilizare).
O exprimare care utilizează o măsură ce poate fi testată
obiectiv.
Ţelurile sunt utile dezvoltatorilor deoarece transmit
intenţiile utilizatorilor sistemului.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 20
Exemple

Un ţel al sistemului
•

Sistemul trebuie să fie uşor de folosit de către controlorii
experimentaţi şi trebuie organizat astfel încât să se minimizeze
erorile utilizatorilor.
O cerinţă non-funcţională verificabilă
•
Controlorii experimentaţi trebuie să fie capabili să utilizeze toate
funcţiile sistemului după un total de două ore de antrenament.
După acest antrenament, numărul mediu de erori efectuate de
utilizatorii experimentaţi nu va depăşi două pe zi.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 21
Măsuri ale cerinţelor
Proprietate
Măsură
Viteză
Numărul de tranzacţii procesate pe secundă.
Timpul de răspuns la utilizator/eveniment.
Timpul de refresh al ecranului.
Mărime
M Bytes
Numărul de chip-uri ROM.
Uşurinţă în utilizare
Timpul de instruire (antrenament).
Numărul de cadre (frames) al help-ului.
Fiabilitate
Timpul mediu între defectări.
Probabilitatea indisponibilităţii.
Rata de apariţie a defectelor.
Disponibilitate.
Robusteţe
Timpul de relansare după defect.
Procentul evenimentelor care produc defecte.
Probabilitatea coruperii datelor la apariţia unui defect.
Portabilitate
Procentul de instrucţiuni dependente de ţintă.
Numărul de sisteme ţintă.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 22
Interacţiunea cerinţelor


În sisteme complexe apar în mod obişnuit
conflicte între diferite cerinţe non-funcţionale.
Sistem pentru navă spaţială
•
•
•
Pentru a minimiza greutatea, trebuie minimizat
numărul de chip-uri separate în sistem.
Pentru a minimiza consumul de energie, trebuie
utilizate chip-uri la puteri joase.
Totuşi, utilizând chip-uri la puteri joase poate
însemna că trebuie utilizate mai multe chip-uri. Care
este cerinţa cea mai critică?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 23
Cerinţe de domeniu



Sunt derivate din domeniul aplicaţiei şi descriu
caracteristicile şi trasăturile sistemului care
reflectă domeniul.
Pot fi cerinţe funcţionale noi, constrângeri asupra
cerinţelor existente sau definiţii ale unor operaţii
de calcul specifice.
Dacă nu sunt satisfăcute, sistemul poate fi
nefuncţional.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 24
Cerinţele de domeniu ale sistemului
bibliotecii


Va exista o interfaţă utilizator standard la toate
bazele de date, care se va baza pe standardul
Z39.50.
Datorită restricţiilor de copyright, unele
documente trebuie şterse imediat după sosire.
Funcţie de opţiunea utilizatorului, aceste
documente vor fi fie imprimate local pe server-ul
sistemului pentru a fi înmânate utilizatorului, fie
trimise la o imprimantă de reţea.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 25
Sistem pentru protecţie tren

Decelerarea trenului va fi calculată astfel:
Dtren = Dcontrol + Dgradient
unde:
• Dgradient este 9.81ms2 * gradientul compensat/alpha
• valorile pentru 9.81ms2/alpha sunt cunoscute
pentru diferite tipuri de tren.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 26
Cerinţe de domeniu: problematică

Înţelegere
•
•

Cerinţele sunt exprimate în limbajul domeniului
aplicaţiei;
Acesta este deseori greu de înţeles pentru inginerii
care dezvoltă sistemul.
Subînţelegere
•
Specialiştii domeniului înţeleg domeniul atât de bine
încât nu consideră că este necesar să expliciteze
cerinţele de domeniu. Acestea li se par subînţelese
şi implicite.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 27
Cerinţe utilizator


Cerinţele funcţionale şi non-funcţionale trebuie
descrise astfel încât să poată fi înţelese de către
utilizatorii sistemului care nu au conoştinţe
tehnice de detaliu.
Sunt definite utilizând limbajul natural, tabele şi
diagrame deoarece acestea pot fi înţelese de toţi
utilizatorii.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 28
Probleme cu limbajul natural

Lipsă de claritate
•

Confuzii ale cerinţelor
•

Odată cu creşterea preciziei exprimării documentul
devine dificil de citit.
Se tinde către amestecarea cerinţelor funcţionale şi
non-funcţionale.
Amalgamarea cerinţelor
•
Mai multe cerinţe diferite ar putea fi exprimate
împreună.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 29
Cerinţă LIBSYS
4.5 LIBSYS va oferi un sistem de contabilitate
financiară care păstrează înregistrări ale tuturor plăţilor
efectuate de utilizatorii sistemului. Managerii sistemului
îl pot configura astfel încât utilizatorii fideli să poată
obţine rate de discount.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 30
Cerinţă pentru editor grilă
2.6 Facilităţile grilei. Pentru a asista poziţionarea entităţilor pe o diagramă,
utilizatorul poate solicita afişarea unei grile în centimetri sau în inch-i,
prin intermediul unei opţiuni de pe panoul de control. Iniţial, grila nu este
vizibilă. Grila poate fi făcută vizibilă sau invizibilă oricând în timpul
unei sesiuni de editare şi poate fi comutată oricînd între inch-i şi
centimetri. Va fi oferită o opţiune a grilei pentru obţinerea unei afişări
de tip “reduce-to-fit” dar numărul de linii ale grilei afişate va fi redus pentru
a evita umplerea diagramelor mici cu linii ale grilei.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 31
Probleme ale cerinţelor

Cerinţa pentru LIBSYS include atât informaţii
conceptuale cât şi detaliate
•
•

Descrie conceptul unui sistem de contabilitate financiară care
va fi inclus în;
include detliul că managerii pot configura acest sistem – nu
este necesar la acest nivel.
Cerinţa pentru grilă amestecă trei tipuri de cerinţe
•
•
•
Cerinţă funcţională conceptuală (necesitatea unei grile);
Cerinţă non-funcţională (unităţile de măsură pe grilă);
Cerinţă non-funcţională UI (comutarea afişării grilei).
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 32
Prezentare structurată
2.6.1 Facilităţile grilei
Editorul va avea o facilitate grilă, unde o matrice de linii orizontale
şi verticale oferă un fundal pentru fereastra editorului. Această grilă
va fi o grilă pasivă în care alinierea entităţilor este responsabilitatea
utilizatorului.
Motivare (raţiune fundamentală): O grilă ajută utilizatorul în crearea unei
diagrame curate şi cu entităţi bine spaţiate. Deşi o grilă activă, unde
entităţile se autoaliniază la liniile grilei, poate fi utilă, poziţionarea este
imprecisă. Utilizatorul este persoana cea mai potrivită să decidă
unde trebuie poziţionate entităţile.
Specificaţie: ECLIPSE/WS/Tools/DE/FS Section 5.6
Soursă: Ray Wilson, Glasgow Office
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 33
Directive pentru scrierea cerinţelor




Inventaţi un format standard şi utilizaţi-l pentru
toate cerinţele.
Utilizaţi limbajul într-un mod consistent. Utilizaţi
“trebuie” pentru cerinţe obligatorii şi “ar trebui”
pentru cerinţe dezirabile.
Utilizaţi evidenţierea textului pentru a identifica
părţile cheie ale cerinţei.
Evitaţi utilizarea jargonului de specialitate (calculator).
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 34
Cerinţe sistem
Def. Specificaţii, mai detaliate decât cerinţele
utilizator, ale funcţiilor, serviciilor şi
constrângerilor sistemului.



Sunt destinate să constituie baza pentru
proiectarea sistemului.
Pot fi incorporate în contractul sistemului.
Pot fi definite sau ilustrate utilizând modele de
sistem (curs ulterior).
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 35
Cerinţele şi proiectarea


În principiu, cerinţele trebuie să exprime ceea ce sistemul
trebuie să facă şi proiectarea trebuie să descrie cum se
realizează aceasta.
În practică, cerinţele şi proiectarea sunt inseparabile
•
•
•
Pentru a structura cerinţele se poate proiecta o arhitectură a
sistemului;
Sistemul poate să inter-opereze cu alte sisteme care
generează cerinţe de proiectare;
Utilizarea unei anumite proiectări poate fi o cerinţă de domeniu.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 36
Probleme cu specificarea în limbaj
natural

Ambiguitate
•

Supra-flexibilitate
•

Cititorii şi scriitorii cerinţei trebuie să înterpreteze
aceleaşi cuvinte în acelaşi fel. Limbajul natural este
inerent ambiguu astfel încât acest lucru este dificil.
Acelaşi lucru poate fi spus în mai multe moduri în
specificaţie.
Lipsa modularizării
•
Structurile limbajului natural nu sunt adecvate
structurării cerinţelor sistem.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 37
Alternative la specificarea în limbaj
natural
Notaţie
Descriere
Limbaj natural
structurat
Abordare ce depinde de definirea de forme sau tipare (templates) standard
pentru a exprima specificaţiile cerinţelor.
Limbaje de descriere Abordare care utilizează un limbaj de tipul limbajelor de programare, dar
a design-ului
cu caracteristici mai abstracte, pentru a specifica cerinţele prin definirea
(rezultatul proiectării) unui model operaţional al sistemului. Abordare puţin răspândităş poate fi
utilă pentru specificaţiile de interfaţă.
Notaţii grafice
Limbaj grafic, suplimentat cu adnotări textuale utilizat pentru a defini
cerinţele funcţionale pentru sistem. Un exemplu timpuriu al unui astfel de
limbaj a fost SADT (Structured Analysis and Design Technique). În
prezent se folosesc descrieri use-case şi diagrame de secvenţe.
Specificaţii
matematice
Notaţii bazate pe concepte matematice ca cele de maşini cu stări finite sau
mulţimi (set). Aceste specificaţii neambigue reduc disputele între client şi
contractor referitoare la funcţionalitatea sistemului. Totuşi, majoritatea
clienţilor nu înţeleg specificaţiile formale şi sunt refractari în acceptarea
lor ca şi contract pentru sistem.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 38
Specificaţii în limbaje structurate




Libertatea scriitorului de cerinţe este limitată de
un tipar (template) predefinit pentru cerinţe.
Toate cerinţele sunt scrise într-o manieră
standard.
Terminologia utilizată în descriere poate fi
limitată.
Avantajul constă în faptul că se păstrează
expresivitatea limbajului natural dar se impune
un grad de uniformitate asupra specificaţiilor.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 39
Specificaţii bazate pe formă






Definiţia funcţiei sau a entităţii.
Descrierea intrărilor şi surselor acestora.
Descrierea ieşirilor şi a destinaţiilor acestora.
Indicarea altor entităţi necesare.
Pre şi post condiţii (dacă e cazul).
Efectele colaterale (dacă există) ale funcţiei.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 40
Specificaţii bazate pe formă: exemplu
Insulin Pump/Control Software/SRS/3.3.2
Function
Compute insulin dose: Safe sugar level
Description
Computes the dose of insulin to be delivered w hen the current measured sugar level is in
the safe zone between 3 and 7 units.
Inputs Current sugar reading (r2), the previous two readings (r0 and r1)
Source Current sugar reading from sensor. Other readings from memory.
Outputs CompDose Š the dose in insulin to be delivered
Destination
Main control loop
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 diff erence 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-condition
r0 is replaced by r1 then r1 is replaced by r2
Side-effects
None
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 41
Specificare tabelară


Utilizată pentru a suplimenta limbajul natural.
Utilă în special atunci când trebuie definite mai
multe cursuri alternative de acţiune.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 42
Specificare tabelară: exemplu
Condition
Action
Sugar level falling (r2 < r1)
CompDose = 0
Sugar level stable (r2 = r1)
CompDose = 0
Sugar level increasing and rate of
increase decreasing ((r2-r1)<(r1-r0))
CompDose = 0
Sugar level increasing and rate of
increase stable or increasing. ((r2-r1) •
(r1-r0))
CompDose = round ((r2-r1)/4)
If rounded result = 0 then
CompDose = MinimumD ose
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 43
Modele grafice


Sunt foarte utile atunci când este necesar să se
ilustreze cum se modifică stările sau când este
necesară descrierea unei secvenţe de acţiuni.
Diferite modele grafice vor fi explicate într-un curs ulterior.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 44
Diagrame de secvenţe


Ilustrează secvenţele de evenimente care au loc în cursul
unei interacţiuni a utilizatorului cu sistemul.
Ordinea acţiunilor este exprimată de sus în jos.
Exemplu: Sistem pentru extragere cash de la un ATM
•
•
•
Validare card;
Tratare cerere;
Finalizare tranzacţie.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 45
Diagramă de secvenţe: exemplu
ATM
Card
P IN req u es t
D at ab ase
Card nu mb er
Card O K
P IN
Valid ate card
O p tio n men u
<<excep t io n>>
in v al id card
Wit hd raw req u es t
A mou n t req u es t
Bal an ce req u es t
Bal an ce
H an d le req uest
A mou n t
D eb i t (amo un t)
<<excep t io n>>
in s uffi ci en t cash
D eb i t res po n se
Card
Card remo v ed
Cas h
Comp lete
tran s actio n
Cas h remov ed
Recei pt
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 46
Specificaţii de interfaţă


Majoritatea sistemelor trebuie să lucreze cu alte sisteme
iar interfeţele de operare trebuie specificate ca parte a
cerinţelor.
Trebuie definite trei tipuri de intefeţe:
•
•
•

Interfeţele procedurale;
Structurile datelor care sunt transferate;
Reprezentările datelor.
Notaţiile formale - tehnică eficientă pentru specificarea
intefeţei.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 47
Descriere interfaţă în PDL (Java
Procedural Definition Language)
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
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 48
Documentul cerinţelor



Documentul cerinţelor este declaraţia oficială a
ceea ce se cere de la dezvoltatorii sistemului.
Trebuie să includă atât o definiţie a cerinţelor
utilizator cât şi o specificaţie a cerinţelor sistem.
NU este un document de proiectare. În măsura
în care este posibil, trebuie precizat CE, mai
curând decât CUM, trebuie să facă sistemul.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 49
Utilizatorii documentului cerinţelor
- Specifică cerinţele
-Citesc cerinţele - pentru a verifica
Clienţi sistem
- Specifică modificări ale cerinţelor.
Manageri
Utilizează documentul cerinţelor
pentru:
- planificarea licitaţiei pentru sistem
- planificarea procesului de
dezvoltare a sistemului.
Inginerii de sistem
Utilizează documentul cerinţelor
pentru a înţelege ce sistem
trebuie dezvoltat.
Inginerii de la
testare sistem
Inginerii de la
întreţinere sistem
©Ian Sommerville 2004
-faptul că acestea satisfac necesităţile lor.
Utilizează cerinţele pentru a
dezvolta teste de validare a
sistemului.
Utilizează cerinţele pentru a
înţelege sistemul şi relaţiile dintre
părţile acestuia.
Software Engineering, 7th edition. Chapter 6
Slide 50
Standardul IEEE pentru cerinţe
Defineşte o structură generică pentru un document de cerinţe ce trebuie instanţiată pentru
fiecare sistem specific.
•
Introducere
•
•
•
•
•
•
Scopul documentului cerinţelor
Domeniul produsului
Definiţii, acronime şi abrevieri
Referinţe
Rezumat al restului documentului
Descriere generală
•
•
•
•
•
©Ian Sommerville 2004
Perspectiva produsului
Funcţiile produsului
Caracteristicile utilizator
Constrângeri generale
Premize şi dependenţe
Software Engineering, 7th edition. Chapter 6
Slide 51
Standardul IEEE pentru cerinţe
(Cont.)
•
Cerinţe specifice.
• Funcţionale
• Non-funcţionale
• De interfaţă
• Cea mai substanţială parte a documentului
• Variabilitate mare în practica organizaţională – nu are o
structură standard
•
•
Apendice.
Index.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 52
Structura documentului cerinţelor










Prefaţă
Introducere
Glosar
Definiţiile cerinţelor utilizator
Arhitectura sistemulu
Specificaţiile cerinţelor sistem
Modelele sistemului
Evoluţia sistemului
Apendice
Index
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 53
Structura documentului cerinţelor

Prefaţă
•
•
•

Cititorii vizaţi
Istoria verisunilor, incluzând motivarea creării unei versiuni noi
Rezumatul modificărilor făcute la fiecare versiune
Introducere
•
•
•
•
Necesitatea sistemului
Funcţiile descrise pe scurt
Cum lucrează sistemul cu alte sisteme
Cum se încadrează sistemul în obiectivele economice şi
strategice de ansamblu ale organizaţiei pentru care acesta este
dezvoltat
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 54
Structura documentului cerinţelor

Glosar
•

Definiţiile cerinţelor utilizator (notaţii inteligibile de către clienţi)
•
•
•

Definiţii ale termenilor tehnici utilizaţi în document
Serviciile furnizate utilizatorului
Cerinţe sistem non-funcţionale
Standarde de produs şi de proces ce vor fi utilizate
Arhitectura sistemului
•
•
Descriere generală de nivel înalt a arhitecturii anticipată pentru
sistem: distribuirea funcţiilor pe modulele sistemului
Cumponentele arhitecturale reutilizate: evidenţiate (highlighted).
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 55
Structura documentului cerinţelor

Specificaţiile cerinţelor sistem
•
•
•

Cerinţe funcţionale în detaliu
Cerinţe non-funcţionale în detaliu
Detalii suplimentare la cerinţele non-funcţionale: ex. Definiţii ale
interfeţelor cu alte sisteme.
Modele ale sistemului
•
Unul sau mai multe modele ale sistemului
Modele ale obiectelor
Modele ale fluxurilor de date
Modele semantice ale datelor
•
•
Relaţii între componentele sistemului
Relatii între sistem şi contextul său
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 56
Structura documentului cerinţelor

Evoluţia sistemului
•
•
Premizele fundamentale be care se bazează sistemul
Modificări anticipate datorate:
• Evoluţiei hardware-lui
• Necesităţilor în schimbare ale utilizatorului, etc.

Apendice
•
•
Informaţie specifică, detaliată referitoare la aplicaţia ce trebuie
dezvoltată
Exemple: descrieri cerinţe pentru:
• Hardware: configuraţii minimale şi optime
• Bază de date: organizarea logică a datelor, relaţii între date

Index (pot fi mai multe)
•
•
•
Alfabetic
Diagrame
Funcţii, etc.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 57
Puncte cheie




Cerinţele indică ce trebuie să facă sistemul şi definesc
constrângeri asupra operarii şi implementării lui.
Cerinţele funcţionale indică serviciile pe care trebuie să le
ofere sistemul.
Cerinţele non-funcţionale constrâng sistemul ce trebuie
dezvoltat sau procesul de dezvoltare a acestuia.
Cerinţele utilizator sunt expuneri de nivel înalt despre ce
trebuie să facă sistemul. Cerinţele utilizator trebuie scrise
utilizând limbajul natural, tabele şi diagrame.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 58
Puncte cheie



Cerinţele sistem sunt destinate să comunice
funcţiile pe care sistemul trebuie să le furnizeze.
Undocument al cerinţelor software este o
expunere agreată a cerinţelor sistemului.
Standardul IEEE este un punct de plecare util
pentru definirea de standarde specifice de
cerinţe mai detaliate.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 59