Sunteți pe pagina 1din 52

Cerintele proceselor de inginerie

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 1


Obiective
⚫ Pentru a descrie cerinţele principale activităţi
de inginerie şi relaţiile lor
⚫ Pentru a introduce tehnici pentru
descoperirea cerinţelor şi analiză
⚫ Pentru a descrie cerintele de validare şi rolul
comentariilor din cerinţe
⚫ Pentru a discuta rolul cerinţelor de
management în sprijinul altor cerinţe din
procesele de inginerie

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 2


Subiecte abordate
⚫ Studii de fezabilitate
⚫ Descoperirea cerinţelor si analiza
⚫ Cerinţele de validare
⚫ Gestionarea cerinţelor

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 3


Cerinţele proceselor de inginerie

⚫ Procedeele utilizate pentru RE variază


considerabil în funcţie de domeniul de
aplicare, oamenii implicaţi si organizarea
dezvoltării cerinţelor.
⚫ Cu toate acestea, există un numar de
activităţi generice comune pentru toate
procesele :
• Descoperirea cerinţelor;
• Analiza cerinţelor;
• Validarea cerinţelor;
• Gestionarea cerinţelor.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 4


Cerinţele procesului de proiectare

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 5


Cerinţele de inginerie

Requirements
specification
System requirements
specification and
modeling

User requirements
specification

Business requirements
specification

System
requirements Feasibility
User study
elicitation requirements
elicitation
Prototyping

Requirements
elicitation Requirements
Reviews
validation

System requirements
document

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 6


Studii de fezabilitate
⚫ Un studiu de fezabilitate decide dacă merită
sau nu sistemul propus.
⚫ Un scurt studiu concentrat care verifică
• Dacă sistemul contribuie la obiectivele
organizaţionale;
• Dacă sistemul poate fi proiectat cu ajutorul
tehnologiei actuale şi în buget;
• Dacă sistemul poate fi integrat cu alte sisteme
care sunt utilizate.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 7


Implementarea studiului de
fezabilitate

⚫ Pe baza evaluării informaţiilor (ceea ce este


necesar), colectarea informaţiilor şi raport scris.
⚫ Întrebări pentru oamenii din organizatie:
• Ce dacă sistemul nu a fost implementat?
• Care sunt problemele procesului curent?
• Cum vă ajută sistemul propus?
• Care vor fi problemele de integrare?
• Este nevoie de noi tehnologii? Ce aptitudini?
• Ce facilităţi trebuie să fie acceptate de sistemul
propus?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 8


Căutare si analiză
⚫ Cateodată denumite căutare de cerinţe sau
descoperire de cerinţă.
⚫ Implică personalul tehnic care lucreaza cu clienţii
pentru a afla despre domeniul de aplicare, serviciile
pe care sistemul trebuie să le furnizeze şi a
sistemului constrângerilor operaţionale.
⚫ Poate implica utilizatorii finali, manageri, inginerii
implicaţi în întreţinere, experţi în domeniu,
sindicatele etc. Acestea sunt numite actorilor
implicaţi sau “stakeholders”.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 9


Probleme de analiză a cerinţelor
⚫ Părţile interesate nu ştiu ce vor.
⚫ Părţile interesate exprimă cerinţe in termeni proprii.
⚫ Diferitele părţi interesate pot avea cerinţe
contradictorii.
⚫ Organizarea şi factorii politici pot influenţa cerinţele
de sistem.
⚫ Cerinţele se schimbă în timpul procesului de analiza.
Apar noi “stakeholders” şi mediul de afaceri se poate
schimba.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 10


Cerinţele spirală

Requirements Requirements
classificatio n and prioritization and
organisation negotiation

Requirements Requirements
discovery documentation

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 11


Activitățile de proces
⚫ Cerinţele descoperite
⚫ Interacţionarea cu parțile interesate de a descoperi cerințele lor.
⚫ Cerinţele de domeniu sunt de asemenea descoperite în
această etapă.
⚫ Cerinţele de clasificare şi organizare
⚫ Cerinţele legate de grupuri şi organizarea în clustere coerente.
⚫ Prioritizarea şi negociere
⚫ Acestea canalizează cerințele si rezolvă conflictele cerinţelor.
⚫ Documentarea cerinţelor
⚫ Sunt documentate şi la intrare în runda urmatoare a spiralei.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 12


Descoperirea cerințelor
⚫ Procesul de culegerea de informaţii despre
sistemele existente propuse şi de distilare a
utilizatorului şi cerinţele de sistem de la
aceste informaţii.
⚫ Surse de informaţii includ sistemul de
documentaţie, părţilor interesate şi de
specificaţiile sisteme similare.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 13


ATM stakeholders
⚫ Clienţii băncii
⚫ Reprezentanţii altor bănci
⚫ Managerii băncii
⚫ Personalul de control
⚫ Administratorii de baze de date
⚫ Managerii de securitate
⚫ Departamentul de marketing
⚫ Inginerii de întreţinere hardware şi software
⚫ Regulatoare bancare

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 14


Puncte de vedere
⚫ Viziunile sunt un mod de structurare a
cerinţelor de a reprezenta perspective de
diferite părţi interesate. Părţile interesate pot
fi clasificate in puncte diferite.
⚫ Această perspectivă multi-analiza este
importantă deoarece nu există un singur
mod corect de a analiza cerinţele de sistem.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 15


Tipuri de viziuni
⚫ Puncte de vedere a celui care interacţionează
• Oameni sau alte sisteme care interacţionează direct cu
sistemul. Într-un un ATM, contul clientului în baza de date
este interactor VPs.
• Puncte de vedere indirecte
• Părţi interesate care nu utilizeaza sistemul ei înşişi dar
care influenţează cerinţele. Într-un un ATM, personalul de
administrare si securitate au puncte de vedere indirecte.
⚫ Domenii ale punctelor de vedere
• Caracteristicile de domeniu şi constrângerile care
influenţează cerinţele. Într-un un ATM, un exemplu ar fi
standardele pentru comunicaţiile intre banci .

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 16


Viewpoint identification
⚫ Identify viewpoints using
• Providers and receivers of system services;
• Systems that interact directly with the system
being specified;
• Regulations and standards;
• Sources of business and non-functional
requirements.
• Engineers who have to develop and maintain
the system;
• Marketing and other business viewpoints.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 17


LIBSYS viewpoint hierarchy

All VPs

Indirect Interactor Domain

Library Article Library UI Classification


Finance Users standards system
manager providers staff

System
Students Staff External Cataloguers
managers

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 18


Intervievarea
⚫ În intervievarea formală sau informală,
echipa RE pune întrebări pentru părţile
interesate despre sistem ce folosesc şi
sistemului de dezvoltare.
⚫ Există două tipuri de interviu
⚫ Interviuri inchise unde intrebările au un set predefinit
de răspunsuri.
⚫ Deschideţi interviuri unde nu există predefinită
ordinea de zi şi o serie de probleme sunt explorate
cu partile interesate(stakeholders).

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 19


Interviuri în practică
⚫ În mod normal un mix de interviuri închise şi
deschise .
⚫ Interviurile sunt bune pentru a obţine o înţelegere
generală stakeholderilor, ce şi cum ar putea
interacţiona cu sistemul.
⚫ Interviurile nu sunt bune pentru înţelegerea
cerinţelor de domeniu
⚫ Cerinţele inginerilor nu inţeleg terminologia specifică a
domeniului ;
⚫ Unele cunosţinte dintr-un anumit domeniu sunt atat de familiare
incat unora li se pare greu sa pună accent pe ele sau nu
consideră necesar să facă asta.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 20


Intervievatori eficienţi
⚫ Intervievatorii trebuie să fie deschişi, dispuşi
să asculte părțile interesante și nu ar trebui
să aibă idei preconcepute cu privire la
cerințe.
⚫ Ei ar trebui să determine intervievatul cu o
întrebare sau o propunere și nu trebuie să se
aștepte pur și simplu să le răspundă la o
întrebare, cum ar fi "ce vrei".

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 21


Scenarii
⚫ Scenarii sunt exemple reale de cum poate fi
utilizat un sistem .
⚫ Ele trebuie sa includa
• O descriere a situaţiei de pornire;
• O descriere a fluxului normal de evenimente;
• O descriere a ceea ce poate greşi;
• Informaţii despre alte activitati concurente;
• O descriere a situaţiei atunci cand scenariul se
termină.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 22


LIBSYS scenario (1)

Initial assumption: The user has logged on to the LIBSYS system and has located the journal containing
the copy of the article.
Normal: The user selects the article to be copied. He or she is then prompted by the system to ei ther
provide subscriber information for the journal or to indicate how they will pay for the article. Alte rnative
payment methods are by credit card or by quoting an organisational account number.
The user is then asked to fill in a copyright form that maintains details of the transaction and they then
submit this to the LIBSYS system.
The copyright form is c hecked and, if OK, the PDF version of the artic le is downloaded to the LIBSYS
working area on the userÕscomputer and the user is informed that it is available. The user is asked to selec t
a printer and a copy of the article is printed. If the article has been flagged as Ôprint-onlyÕit i s deleted from
the userÕs system once the user has confirmed that printing is complete.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 23


LIBSYS scenario (2)

What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the form should
be re-presented to the user for correction. If the resubmitted form is s till incorrect then the userÕsrequest
for the article is rejec ted.
The payment may be rejected by the system. The userÕs er quest for the article is rejected.
The article download may fail. Retry until successful or the user terminates the session.
It may not be possible to print the article. If the article is not flagged as Ôprint-onlyÕthen it is held in the
LIBSYS workspace. Otherwise, the artic le is deleted and the userÕs account credited with the cost of the
article.
Other activities: Simultaneous downloads of other articles.
System state on completion: User is logged on. The downloaded article has been dele ted from LIBSYS
workspace if it has been flagged as print-only.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 24


Cazuri de utilizare
⚫ Cazurile de utilizare sunt un scenariu de
tehnică de bază in UML care identifică actori
dintr-o interacţiune şi care descriu
interacţiunea însăşi.
⚫ Un set de cazuri de utilizare ar trebui să
descrie toate posibilele interacţiuni cu
sistemul.
⚫ Schemele de secvenţă poate fi utilizate
pentru a adăuga detalii pentru cazurile
utilizate prin care arată secvenţa de caz
prelucrată în sistem.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 25
Article printing use-case

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 26


LIBSYS use cases

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 27


Article printing

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 28


Print article sequence

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 29


Factori sociali si organizaţionali
⚫ Sistemele de software sunt utilizate în
contexte organizaţionale şi sociale . Acest
lucru poate influenţa sau chiar domina
cerinţele de sistem.
⚫ Factorii sociali și organizaționali nu sunt un
singur punct de vedere, dar au influențe din
toate punctele de vedere.
⚫ Bunii analiști trebuie sa fie sensibili la aceşti
factori dar momentan nu au un mod
sistematic de a aborda analiza acestora.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 30
Etnografia
⚫ O ştiintă socială işi petrece un timp considerabil
pentru a observa si analiza cum lucrează oamenii
efectiv.
⚫ Oamenii nu trebuie să explice sau articuleze munca
lor.
⚫ Pot fi observaţi factori sociali și organizaţionali
importanţi.
⚫ Etnografic studii au arătat că munca este de obicei
mai bogată şi mai complexă decat sugestiile
modelelor de sistem simple.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 31


Etnografia concentrată
⚫ Dezvoltată în cadrul unui proiect studierea
procesului de control a traficului aerian
⚫ Combină etnografie cu prototipuri
⚫ Prototipul dezvoltării rezultatelor în întrebări
fără răspuns care se axeaza pe analiza
etnografică.
⚫ Problema cu etnografia este că studiile
practicillor existente care pot avea o bază
istorică care nu mai este relevantă.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 32


Ethnography and prototyping

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 33


Scopul etnografiei
⚫ Cerinţele sunt derivate din modul în care
oamenii lucrează efectiv mai degrabă decât
din modul în care definiţiile sugerează cum
ar trebui să lucreze.
⚫ Cerinţe care sunt derivate din cooperarea şi
de conştientizare activităţilor altor persoane.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 34


Validarea cerinţelor
⚫ Preocupat cum să demonstreze că cerințele
definesc sistemul pe care clientul îl dorește
cu adevărat.
⚫ Costurile erorilor de cerințe sunt mari, astfel
validarea este foarte importantă
• Stabilirea erorilor de cerinţe e după livrare poate
costa până la 100 de ori costul de fixare a unei
erori de implementare.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 35


Ceriţele de control
⚫ Valabilitate. Oferă sistemul funcţiile pentru o buna
asistenţă a nevoilor clientului?
⚫ Consistență. Sunt acolo orice cerinţe conflicte?
⚫ Completitudine. Sunt toate funcţiile necesare incluse
de către client ?
⚫ Realism. Pot fi aplicate cerinţele indicate, bugetul
disponibil şi tehnologia.
⚫ Verificabilitate. Pot fi verificate cerințele?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 36


Cerinţele tehnicilor de validare
⚫ Cerințe de comentarii
⚫ Analiza manual sistematică a cerințelor.
⚫ Prototyping
• Cu ajutorul unui model executabil a sistemului
pentru a verifica cerințele. Incluse în capitolul
17.
• Generație de testare caz
• Dezvoltarea testelor pentru a verifica cerințele
de testabilitate.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 37


Comentarii si cerinţe
⚫ Evaluările periodice trebuie să aibă loc în
timp ce definiția cerințelor este formulată.
⚫ Atât clientul cat și contractantul ar trebui să
se implice în comentarii.
⚫ Comentariile pot fi formale (cu documentele
de completat) sau informale. O bună
comunicare între dezvoltatori, clienţii şi
utilizatorii poate rezolva probleme de la un
stadiu incipient.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 38


Verificări de revizuire
⚫ Verificare. Este cerința realist testabilă?
⚫ Ințelegere. Este cerinţa corect înţeleasă?
⚫ Trasabilitate. Este originea cerinţei precizată
clar?
⚫ Adaptabilitate . Poate fi modificat la o cerinţa
fără un impact mare la alte cerinţe?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 39


Gestionarea cerinţelor
⚫ Cerinţele de management schimbă procesul de
gestionare a cerinţelor în timpul procesului de
inginerie şi sistemului de cerinţe de dezvoltare.
⚫ Cerinţele sunt inevitabil incomplete şi incoerente
⚫ Noile cerinţe apar în timpul procesului ca dezvoltarea afacerii şi
o mai bună înţelegere a sistemului dezvoltat;
⚫ Punctele de vedere diferite au cerinţe diferite şi acestea sunt
adesea contradictorii.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 40


Schimbarea cerinţelor
⚫ O prioritate a cerinţelor din puncte de vedere
diferite se pot modifica în timpul procesului
de dezvoltare.
⚫ Clienţii pot specifica cerinţele sistemului de
la o perspectivă de afaceri în conflict cu
cerinţele utilizatorului final.
⚫ Mediul de afaceri şi tehnica sistemului se
pot modifica în timpul dezvoltării.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 41


Requirements evolution

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 42


Durata şi cerinţele volatile
⚫ Cerințe de durată. Cerințe stabile derivate
din activitatea de bază a organizației
clientului. De exemplu, un spital va avea
întotdeauna medici, asistente medicale, etc.
Pot fi derivate din modelele de domeniu.
⚫ Cerințe volatile. Cerințe care se schimbă în
timpul dezvoltării sau atunci când sistemul
este utilizat. Într-un spital, cerințe derivate
din politica de ingrijire a sănătății

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 43


Requirements classification

Requirement Description
Type
Mutable Requirements that change because of changes to the environment in which the
requirements organisation is operating. For example, in hospital systems , the funding of patient
care may change and thus require different treatment information to be collec ted.
Emergent Requirements that emerge as the customer's understanding of the system develops
requirements during the system development. The design process may reveal new emergent
requirements.
Consequential Requirements that result from the introduction of the computer system. Introducing
requirements the computer system may change the organisations processes and open up new ways
of working which generate new system requirements
Compatibility Requirements that depend on the particular systems or business processes within an
requirements organisation. As these change, the compatibility requirements on the commissioned
or delivered system may also have to evolve.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 44


Cerinţele de planificare de
management
⚫ În timpul procesului de cerințele de inginerie, trebuie
să ai un plan:
⚫ Identificarea cerințelor
⚫ Cum cerințele sunt identificate individual;
• Un proces de management al schimbării
• Procesul urmeaza atunci când se analizează o schimbare a
cerințelor;
• Politicile de trasabilitate
• Cantitatea de informații despre cerințele care se mențin;
• Instrumente de sprijin
• Sprijinul instrumentului necesar pentru a ajuta la gestionarea
schimbării cerințelor ;

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 45


Traceability
⚫ Traceability is concerned with the relationships
between requirements, their sources and the system
design
⚫ Source traceability
• Links from requirements to stakeholders who proposed
these requirements;
⚫ Requirements traceability
• Links between dependent requirements;
⚫ Design traceability
• Links from the requirements to the design;

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 46


A traceability matrix

Req. 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2


id
1.1 D R
1.2 D D D
1.3 R R
2.1 R D D
2.2 D
2.3 R D
3.1 R
3.2 R

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 47


Cazul suportului dispozitivului
⚫ Cerinţele de stocare
⚫ Cerinţele trebuie gestionate în siguranţă, gestionate de
stocarea datelor.
⚫ Managementul schimbării
⚫ Procesul de management al schimbării este un proces de flux
de lucru ale cărui etape pot fi definite și fluxul de informații între
aceste etape parțial automatizate.
⚫ Management de trasabilitate
⚫ Preluarea legăturilor dintre cerinţe.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 48


Cerințe managementul schimbării

⚫ Trebuie să se aplice toate modificările


propuse pentru cerințe.
⚫ Etapele principale
• Analiza problemelor. Discuta cerințelor
problemă și propunerea modificărilor;
• Schimbarea analizei și a costurilor. Evaluarea
efectelor schimbărilor asupra altor cerințe;
• Schimba implementarea. Modifica cerințele
documentelor și alte documente pentru a
reflecta schimbarea.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 49


Change management

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 50


Puncte cheie
⚫ Cerinţele de inginerie proces includ un studiu
de fezabilitate, cerinţele de gasire şi analiză,
cerinţe conform specificaţiei şi cerinţele de
management.
⚫ Identificarea și analiza cerințelor este
iterativă care implică înțelegerea domeniului,
colectarea cerințelor, clasificarea,
structurarea, prioritizarea și validare.
⚫ Sistemele au mai multe părți interesate cu
cerințe diferite.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 51


Puncte cheie
⚫ Factorii sociali și organizarea influențează
cerințele de sistem.
⚫ Cerințele controalelor sunt preocupate de
validarea pentru valabilitate, consistență,
completitudinea, realism şi verifiacabilitate.
⚫ Modificările de afaceri duc inevitabil la
schimbarea cerinţelor.
⚫ Planificarea şi gestionarea cerinţelor de
schimbare a gestiunii .

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 52