Ingineria sistemelor soft 2013-2014
Curs 4
Colectarea cerin¸telor
Curs bazat pe B. Bruegge and A.H. Dutoit
"Object-Oriented Software Engineering using UML, Patterns, and Java"
Sumar Curs 4
• Cerin¸te. Ingineria cerin¸telor
• Colectarea cerin¸telor - concepte
• Colectarea cerin¸telor - activit ˘a¸ti tehnice
• Colectarea cerin¸telor - management
Cerint¸e. Ingineria cerint¸elor
• O cerin¸t˘a (eng. requirement) reprezint ˘a un element de func¸tionalitate pe care sistemul trebuie s ˘a îl ofere sau o constrângere pe care trebuie s ˘a o îndeplineasc ˘a
• Ingineria cerin¸telor (eng. requirements engineering) este un subdomeniu al ingineriei softului, având drept scop definirea cerin¸telor sistemelor soft ce urmeaz ˘a a fi construite
• Activit ˘a¸ti ale ingineriei cerin¸telor
◦ Colectarea cerin¸telor (eng. requirements elicitation) - are ca ¸si produs final specifica¸tia sistemului, servind ca ¸si contract între client ¸si dezvoltatori
◦ Analiza cerin¸telor (eng. analysis) - are ca ¸si produs final modelul de analiz ˘a
• Atât specifica¸tia sistemului, cât ¸si modelul de analiz ˘a reflect ˘a aceea¸si informa¸tie, diferen¸tele între acestea constând în rolul lor
¸si nota¸tia utilizat ˘a
◦ Specifica¸tia sistemului este exprimat ˘a în limbaj natural ¸si serve¸ste ca ¸si instrument de comunicare cu clien¸tii/utilizatorii
◦ Modelul de analiz ˘a este exprimat într-o nota¸tie semiformal ˘a sau formal ˘a ¸si
Cerint¸e. Ingineria cerint¸elor (cont.)
• Activit ˘a¸ti ¸si produse ale ingineriei cerin¸telor
(diagram ˘a UML de activit ˘a¸ti)
◦ Activit ˘a¸tile ingineriei cerin¸telor se focuseaz ˘a exclusiv pe aspectele externe ale sistemului (perspectiva utilizatorilor externi asupra
sistemului)
◦ Modelele lor
reprezentând acelea¸si aspecte, cele dou ˘a activit ˘a¸ti se desf ˘a¸soar ˘a concurent ¸si iterativ
Colectarea cerint¸elor
• Colectarea cerin¸telor necesit ˘a colaborarea între grupuri de participan¸ti cu background diferit (clien¸ti/utilizatori - exper¸ti în
domeniul problemei vs. dezvoltatori - exper¸ti în dezvoltare de soft)
◦ Corectarea erorilor de comunicare introduse acum (rezultând în specificarea gre¸sit ˘a a unor func¸tionalit ˘a¸ti, func¸tionalit ˘a¸ti lips ˘a, probleme la nivelul
interfe¸telor utilizator) în etapele ulterioare ale dezvolt ˘arii este deosebit de costisitoare
• Metodele de colectare a cerin¸telor au drept obiectiv perfec¸tionarea comunic ˘arii între aceste grupuri
• Colectarea cerin¸telor bazat ˘a pe scenarii (eng. scenario-based requirements elicitation)
◦ Scenariu = descriere a unui exemplu concret de utilizare a sistemului, în termenii unei secven¸te de interac¸tiuni între utilizator ¸si sistem
◦ Caz de utilizare = abstractizare ce descrie elementele comune ale unei clase de scenarii
Colectarea cerint¸elor bazat ˘a pe scenarii
• Dezvoltatorii colecteaz ˘a cerin¸tele prin observarea ¸si chestionarea utilizatorilor în mediul lor
• Se realizeaz ˘a dou ˘a tipuri de scenarii
◦ Ini¸tial - scenarii descriind modul curent de desf ˘a¸surare a proceselor de lucru în mediul utilizatorilor
◦ Ulterior - scenarii prescriptive, ilustrând func¸tionalitatea ce urmeaz ˘a a fi oferit ˘a de noul sistem
• Scenariile realizate sunt validate de c ˘atre clien¸ti ¸si utilizatori prin inspectare ¸si prin manipularea unor prototipuri ale interfe¸tei
grafice cu utilizatorul, oferite de c ˘atre dezvoltatori
• Pe m ˘asur ˘a ce defini¸tia sistemului se stabilizeaz ˘a, dezvoltatorii ¸si
clientul convin asupra unei specifica¸tii a sistemului constând în
descrierea cerin¸telor func¸tionale, a celor nefunc¸tionale, a cazurilor
de utilizare ¸si a scenariilor aferente
Activit ˘at¸i ale colect ˘arii bazate pe scenarii
• Identificarea actorilor
◦ Dezvoltatorii identific ˘a diferitele tipuri de utilizatori pe care îi va suporta sistemul
• Identificarea scenariilor
◦ Dezvoltatorii observ ˘a utilizatorii în mediul lor ¸si descriu un set de scenarii detaliate aferente func¸tionalit ˘a¸tilor tipice oferite de noul sistem
◦ Scenariile sunt utilizate pentru comunicarea cu utilizatorii ¸si aprofundarea în¸telegerii domeniului problemei de c ˘atre dezvoltatori
• Identificarea cazurilor de utilizare
◦ Ulterior stabiliz ˘arii scenariilor, dezvoltatorii deriv ˘a din acestea cazurile de utilizare ce definesc viitorul sistem
• Rafinarea cazurilor de utilizare
◦ Dezvoltatorii verific ˘a completitudinea specific ˘arii cerin¸telor prin detalierea fiec ˘arui caz de utlizare ¸si descrierea comportamentului sistemului în situa¸tii de excep¸tie
Activit ˘at¸i ale colect ˘arii bazate pe scenarii (cont.)
• Identificarea rela¸tiilor dintre cazurile de utilizare
◦ Dezvoltatorii identific ˘a dependen¸tele dintre cazurile de utilizare ¸si factorizeaz ˘a comportamentele comune
◦ Aceast ˘a activitate permite verificarea consisten¸tei specifica¸tiei sistemului
• Identificarea cerin¸telor nefunc¸tionale
◦ Dezvoltatorii, clien¸tii ¸si utilizatorii convin asupra constrângerilor legate de performan¸tele sistemului, resursele utilizate, securitatea ¸si calitatea sa, modalitatea de documentare, etc.
Colectarea cerint¸elor - concepte
• Cerin¸te func¸tionale
• Cerin¸te nefunc¸tionale
• Completitudine
• Consisten¸t˘a
• Claritate
• Corectitudine
• Realism
• Verificabilitate
• Trasabilitate
• Inginerie Greenfield
• Re-inginerie
• Ingineria interfe¸telor
Cerint¸e funct¸ionale
• Cerin¸tele func¸tionale (eng. functional requirements) descriu interac¸tiunile dintre sistem ¸si mediul acestuia, independent de implementare
◦ Mediul = utilizatorii + alte sisteme cu care sistemul în cauz ˘a interac¸tioneaz ˘a
• Ex.: Specificarea cerin¸telor func¸tionale ale sistemului SatWatch - ceas care se actualizeaz ˘a automat (f ˘ar ˘a interven¸tii externe)
◦ SatWatch este un ceas de mân ˘a care afi¸seaz ˘a timpul pe baza loca¸tiei
curente. SatWatch utilizeaz ˘a sateli¸ti GPS pentru a determina loca¸tia curent ˘a
¸si structuri interne pentru a asocia acelei loca¸tii un fus orar.
SatWatch actualizeaz ˘a ora ¸si data la schimbarea fusului orar sau a grani¸telor politice. Proprietarul ceasului nu trebuie s ˘a îl reseteze niciodat ˘a, ca urmare ceasul nu are butoane de control.
SatWatch utilizeaz ˘a sateli¸ti GPS pentru determinarea loca¸tiei curente, ca urmare are acelea¸si limit ˘ari ca ¸si restul dispozitivelor GPS (ex. incapacitatea de a determina loca¸tia la anumite momente din zi, în regiunile muntoase). În timpul perioadelor de black-out, SatWatch consider ˘a c ˘a nu se schimb ˘a
fusurile orare sau regiunile politice. Imediat dup ˘a ie¸sirea din intervalul de black-out, se realizeaz ˘a actualiz ˘arile aferente.
Cerint¸e funct¸ionale (cont.)
SatWatch are un afisaj pe dou ˘a linii, cea de sus indicând timpul (ora, minute, secunde, fus orar), iar cea de jos data (zi din sapt ˘amân ˘a, data, luna, an).
În cazul modific ˘arii grani¸telor politice, proprietarul poate actualiza softul
ceasului prin utilizarea dispozitivului WebifyWatch (oferit împreun ˘a cu ceasul)
¸si a unui calculator conectat la Internet.
• Cerin¸tele func¸tionale anterioare surprind doar interac¸tiunile dintre sistemul SatWatch ¸si mediul extern (poprietarul, sateli¸tii GPS,
dispozitivul WebifyWatch), f ˘ar ˘a a referi detalii de implementare
(procesor, limbaj, tehnologie, etc.)
Cerint¸e nefunct¸ionale
• Cerin¸tele nefunc¸tionale (eng. nonfunctional requirements) descriu diverse tipuri de constrângeri impuse asupra sistemului,
ortogonale pe aspectele func¸tionale
• Categorii de cerin¸te nefunc¸tionale (de calitate), conform modelului FURPS+ ([Grady 1992], [IEEE Std. 610.12-1990])
◦ Utilizabilitate (eng. usability )
• Denot ˘a u¸surin¸ta cu care un utilizator poate înv ˘a¸ta s ˘a opereze, s ˘a
preg ˘ateasc ˘a intr ˘ari sau s ˘a interpreteze ie¸siri ale unui sistem sau ale unei componente
• Ex. de cerin¸te privind utilizabilitatea: diferite conve¸tii adoptate la nivelul interfe¸telor grafice (¸sabloane de structurare, scheme de culori, logo-uri, fonturi), help online, ghid de utilizare detaliat
◦ Performan¸t˘a (eng. performance) - refer ˘a atribute cuantificabile, precum:
• timpul de r ˘aspuns (rapiditatea reac¸tiei sistemului la inputul utilizatorului)
• puterea de calcul (volumul de calcule efectuate într-un interval de timp)
• acurate¸tea rezultatelor
• disponibilitatea (m ˘asura în care un sistem este opera¸tional ¸si accesibil atunci când se dore¸ste utilizarea lui)
Cerint¸e nefunct¸ionale (cont.)
◦ Fiabilitate (eng. reliability )
• Reprezint ˘a abilitatea sistemului sau componentei de a îndeplini func¸tiile cerute în condi¸tiile stabilite, pentru o anumit ˘a perioad ˘a de timp
• Ex. de cerin¸te privind fiabilitatea: un timp mediu precizat între e¸securi, abilitatea de a face fa¸t˘a unor atacuri de securitate, etc.
• Mai nou referint ˘a cu termenul de dependability ¸si incluzând, in afara fiabilit ˘a¸tii propriu-zise ¸si robuste¸tea (eng. robustness) - gradul în care un sistem sau o component ˘a poate func¸tiona corect în prezen¸ta unor intr ˘ari invalide sau a unor condi¸tii excep¸tionale ¸si siguran¸ta (eng. safety ) - o m ˘asur ˘a a absen¸tei unor consecin¸te catastrofale în mediu
◦ Suportabilitate (eng. suportability )
• Denot ˘a u¸surin¸ta schimb ˘arii sistemului dup ˘a instalare, incluzând
adaptabilitatea (eng. adaptability ) - abilitatea de a modifica sistemul pentru a opera cu noi concepte din domeniul problemei, mentenabilitatea (eng.
maintainability ) - abilitatea de a schimba sistemul pentru a opera cu noi tehnologii sau a repara defecte ¸si interna¸tionalizarea (eng.
internationalization) - abilitatea de a schimba sistemul penru a opera cu limbi/unit ˘a¸ti de m ˘asur ˘a/formate numerice str ˘aine
Cerint¸e nefunct¸ionale (cont.)
• Categorii adi¸tionale de cerin¸te calificate drept nefunc¸tionale în modelul FURPS+ (pseudo-cerin¸te sau constrângeri)
◦ Cerin¸te de implementare (eng. implementation requirements)
• Sunt constrângeri ce vizeaz ˘a utilizarea unei anumite platforme hardware, a unui anumit limbaj de programare sau a anumitor instrumente
◦ Cerin¸te privind interfa¸ta (eng. interface requirements)
• Sunt constrângeri impuse de alte sisteme cu care sistemul în cauz ˘a interfa¸teaz ˘a
◦ Cerin¸te privind modul de operare (eng. operations requirements)
• Sunt constrângeri privind administrarea ¸si gestiunea sistemului în mediul s ˘au de operare
◦ Cerin¸te privind instalarea (eng. packaging requirements)
• Sunt constrângri legate de livrarea sistemului, cum ar fi suportul folosit pentru instalare
◦ Cerin¸te legale (eng. legal requirements)
• Sunt constrângeri legate de licen¸te, legi, certific ˘ari
• Ex.: cerin¸te privind obligativitatea oferirii accesului la un anumit soft persoanelor cu dizabilit ˘a¸ti
Cerint¸e nefunct¸ionale (cont.)
• Ex.: cerin¸te de calitate pentru SatWatch
◦ Orice utilizator care ¸stie s ˘a citeasc ˘a un ceas digital ¸si cunoa¸ste abrevierile legate de fusurile orare trebuie s ˘a poat ˘a folosi sistemul f ˘ar ˘a manual de utilizare (utilizabilitate)
◦ SatWatch trebuie s ˘a afi¸seze fusul orar corect în maxim 5 minute de la ie¸sirea dintr-o perioad ˘a de black- out (performan¸t˘a)
◦ Deoarece SatWatch nu dispune de butoane, nu trebuie s ˘a apar ˘a nici o eroare care s ˘a necesite resetarea acestuia (fiabilitate)
◦ SatWatch trebuie s ˘a admit ˘a upgrade-uri prin intermediul interfe¸tei seriale WebifyWatch (suportabilitate)
• Ex.: constrângeri pentru SatWatch
◦ Softul SatWatch va fi scris integral în Java, pentru conforman¸t˘a cu standardele companiei (implementare)
◦ SatWatch se conformeaz ˘a interfe¸telor fizice, electrice ¸si soft definite de WebifyWatch 2.0 (interfa¸t˘a)
Completitudine, consistent¸˘a, claritate s¸i corectitudine
• Validarea continu ˘a a cerin¸telor reprezint ˘a un imperativ în procesul de dezvoltare
• Validarea cerin¸telor presupune verificarea completitudinii, consisten¸tei, clarit ˘a¸tii ¸si corectitudinii acestora
◦ Completitudine
• Specificarea cerin¸telor se consider ˘a a fi complet ˘a dac ˘a surprinde toate aspectele de interes pentru clien¸ti/utilizatori (au fost descrise toate scenariile posibile, inclusiv cele de excep¸tie)
◦ Consisten¸t˘a
• Specificarea cerin¸telor se consider ˘a a fi consistent ˘a dac ˘a nu exist ˘a dou ˘a cerin¸te care s ˘a se contrazic ˘a reciproc
◦ Claritate
• Specificarea cerin¸telor se consider ˘a a fi neambigu ˘a dac ˘a o aceea¸si cerin¸t˘a nu admite dou ˘a interpret ˘ari distincte (define¸ste un singur sistem)
◦ Corectitudine
• Specificarea cerin¸telor se consider ˘a a fi corect ˘a dac ˘a reprezint ˘a fidel
interesele clientului ¸si ale dezvoltatorilor, f ˘ar ˘a a include elemente nedorite
• Corectitudinea ¸si completitudinea sunt greu de apreciat/certificat,
mai ales anterior existen¸tei sistemului
Realism, verificabilitate s¸i trasabilitate
• Specificarea cerin¸telor se consider ˘a a fi realist ˘a dac ˘a sistemul poate fi implementat cu constrângerile impuse
• Specificarea cerin¸telor se consider ˘a a fi verificabil ˘a dac ˘a ulterior dezvolt ˘arii sistemului pot fi proiectate teste care s ˘a dovedeasc ˘a conforman¸ta acestuia cu specifica¸tia
◦ Ex.: cerin¸te greu/imposibil de verificat
• Sistemul SatWatch trebuie s ˘a aib ˘a un interval mediu între e¸securi de 100 de ani
• Produsul trebuie s ˘a aib ˘a o interfa¸t˘a utilizator bun ˘a
• Produsul trebuie s ˘a fie f ˘ar ˘a erori
• O specificare a cerin¸telor are proprietatea de trasabilitate dac ˘a fiecare cerin¸t˘a poate fi urm ˘arit ˘a, de-a lungul procesului de
dezvoltare, pân ˘a la func¸tiile sistem care o implementeaz ˘a ¸si reciproc
◦ Trasabilitatea cerin¸telor e o constrângere critic ˘a pentru dezvoltarea testelor ¸si analiza impactului schimb ˘arilor asupra sistemului
Trasabilitatea cerint¸elor
• Trasabilitatea (eng. traceability ) reprezint ˘a abilitatea de a urm ˘ari evolu¸tia unei cerin¸te
◦ Presupune urm ˘arirea cerin¸tei de la origine (cine a introdus-o? c ˘arei nevoi client corespunde?) pân ˘a la nivelul acelor componente ale sistemului pe care le afecteaz ˘a (ce componente implementeaz ˘a cerin¸ta? ce cazuri de test
verific ˘a îndeplinirea sa?)
◦ Trasabilitatea permite dezvoltatorilor s ˘a motiveze completitudinea sistemului, testerilor s ˘a justifice conforman¸ta acestuia cu cerin¸tele, proiectan¸tilor s ˘a
înregistreze argumentele din spatele deciziilor luate ¸si echipelor de între¸tinere s ˘a evalueze efectul schimb ˘arilor
• Trasabilitatea poate fi urm ˘arit ˘a prin între¸tinerea de referin¸te între documente, modele ¸si cod
◦ Fiecare element individual (cerin¸t˘a, component ˘a, clas ˘a, opera¸tie, caz de test ) prime¸ste un identificator unic
◦ O dependen¸t˘a este apoi documentat ˘a prin intermediul unei referin¸te con¸tinând identificatorii componentelor surs ˘a ¸si destina¸tie
Inginerie Greenfield, re-inginerie, ingineria interfet¸elor
• Caracteristicile activit ˘a¸tii de colectare a cerin¸telor depind de sursa acestora
◦ Ingineria Greenfield
• Procesul de dezvoltare începe de la 0, nu exist ˘a un sistem anterior
• Cerin¸tele sunt furnizate doar de client ¸si utilizatori
◦ Re-inginerie
• Reproiectarea ¸si reimplementarea unui sistem existent, ca urmare a unor modific ˘ari la nivelul proceselor de lucru sau a unor modific ˘ari tehnologice
• Func¸tionalitatea sistemului poate fi eventual extins ˘a, îns ˘a scopul s ˘au r ˘amâne acela¸si; majoritatea cerin¸telor sunt extrase din vechiul sistem
◦ Ingineria interfe¸telor
• Reproiectarea ¸si reimplementarea doar a interfe¸tei unui sistem existent
• În cazul ingineriei Greenfield ¸si a reingineriei, dezvoltatorii trebuie s ˘a acumuleze cât mai multe cuno¸stin¸te relativ la domeniul
problemei
◦ Surse: descrieri ale proceselor de lucru, documenta¸tie distribuit ˘a noilor angaja¸ti, manuale ale vechiului sistem, note ale utilizatorilor, interviuri cu
Colectarea cerint¸elor - activit ˘at¸i tehnice
• Identificarea actorilor
• Identificarea scenariilor
• Identificarea cazurilor de utilizare
• Rafinarea cazurilor de utilizare
• Identificarea rela¸tiilor între cazurile de utilizare
• Identificarea cerin¸telor nefunc¸tionale
Identificarea actorilor
• Permite identificarea frontierei sistemului ¸si a perspectivelor din care acesta trebuie abordat
• Întreb ˘ari utile pentru identificarea actorilor
◦ Care sunt grupurile de utilizatori a c ˘aror activitate este suportat ˘a de sistem?
◦ Care sunt grupurile de utilizatori care execut ˘a func¸tiile principale ale sistemului?
◦ Care sunt grupurile de utilizatori care execut ˘a func¸tii secundare, precum între¸tinere sau administrare?
◦ Care sunt echipamentele hardware ¸si sistemele software externe cu care sistemul curent va interac¸tiona?
• Întreb ˘arile anterioare conduc la identificarea unei liste de entit ˘a¸ti ce urmeaz ˘a a fi rafinat ˘a, în general, într-un num ˘ar mai mic de actori, diferi¸ti din perspectiva utiliz ˘arii sistemului
◦ Se unific ˘a entit ˘a¸tile ce utilizeaz ˘a acelea¸si interfe¸te
◦ Se elimin ˘a entit ˘a¸tile care, cel mai probabil, nu vor interac¸tiona în mod direct cu sistemul
Identificarea scenariilor
• În colectarea cerin¸telor, dezvoltatorii ¸si utilizatorii concep ¸si
rafineaz ˘a o serie de scenarii, pentru a dobândi un nivel comun de în¸telegere relativ la func¸tionalitatea sistemului
• Întreb ˘ari utile pentru identificarea scenariilor
◦ Care sunt sarcinile pe care utilizatorul dore¸ste s ˘a le execute sistemul?
◦ Care sunt informa¸tiile pe care le poate accesa actorul? Cine creeaz ˘a aceste date? Pot fi ele modificate sau ¸sterse? De c ˘atre cine?
◦ Care sunt modific ˘arile externe despre care actorul trebuie s ˘a informeze sistemul? Cât de des? Când?
◦ Care sunt evenimentele despre care sistemul trebuie s ˘a informeze actorul?
Cu ce periodicitate?
• Pentru a r ˘aspunde întreb ˘arilor anterioare, dezvoltatorii consult ˘a diverse documente cu informa¸tii privind domeniul problemei
◦ manuale ale unor sisteme anterioare, manuale procedurale, standarde ale companiei, note ¸si documente elaborate de utilizatori, interviuri cu clien¸tii ¸si utilizatorii
Identificarea scenariilor (cont.)
• Ex.: Scenariul depozitIncendiat al cazului de utilizare Raporteaz ˘aUrgen¸t˘a al SGA
Nume depozitIncendiat
Instan¸te bob, alice : Ofi¸terTeren actori john : Dispecer
Flux 1. Trecând prin dreptul unui depozit, Bob simte miros de fum.
de Partenera sa, Alice, activeaz ˘a func¸tia Raporteaz ˘a urgen¸t˘a pe terminalul SGA.
evenimente 2. Alice introduce adresa cl ˘adirii, o scurt ˘a descriere a loca¸tiei ¸si un nivel de alert ˘a.
Zona fiind aglomerat ˘a, solicit ˘a o echip ˘a de pompieri ¸si mai multe de medici.
Confirm ˘a datele ¸si a¸steapt ˘a confirmarea dispecerului.
3. John, dispecerul, este alertat de un semnal sonor al sta¸tiei sale de lucru.
Verific ˘a informa¸tiile trimise de Alice ¸si confirm ˘a primirea lor.
Aloc ˘a o echip ˘a de pompieri ¸si dou ˘a de medici ¸si ii trimite lui Alice ora estimat ˘a a sosirii acestora.
5. Alice prime¸ste confirmarea ¸si estimarea.
Identificarea cazurilor de utilizare
• Ex.: Cazul de utilizare Raporteaz ˘aUrgen¸t˘a
Nume Raporteaz ˘aUrgen¸t˘a
Participan¸ti Ini¸tiat de Ofi¸terTeren Comunic ˘a cu Dispecerul
Flux de evenimente 1. Ofi¸terul activeaz ˘a func¸tia Raporteaz ˘a urgen¸t˘a a terminalului.
2. Sistemul SGA afi¸seaz ˘a un formular Ofi¸terului.
3. Ofi¸terul completeaz ˘a formularul, inserând
nivelul de alert ˘a, tipul, loca¸tia ¸si o scurt ˘a descriere a situa¸tiei.
Descrie ¸si posibile r ˘aspunsuri la situa¸tia de urgen¸t˘a.
Dup ˘a completare, Ofi¸terul trimite formularul.
4. Sistemul prime¸ste formularul ¸si notific ˘a Dispecerul.
5. Dispecerul verific ˘a informa¸tia ¸si apeleaz ˘a cazul de utilizare DeschideCazNou. Dispecerul alege un r ˘aspuns ¸si
confirm ˘a primirea formularului.
6. Sistemul afi¸seaz ˘a confirmarea ¸si r ˘aspunsul ales Ofi¸terului.
Condi¸tii de intrare Ofi¸terul este logat în sistem.
Condi¸tii de ie ¸sire Ofi¸terul a primit confirmarea de la Dispecer, SAU o explica¸tie privind motivul e¸secului tranzac¸tiei.
Cerin¸te de calitate Raportul Ofi¸terului este confirmat în maxim 30 de sec.
R ˘aspunsul selectat ajunge în maxim 30 de sec. dup ˘a ce a fost trimis de Dispecer.
Identificarea cazurilor de utilizare (cont.)
• Ghid de descriere a cazurilor de utilizare
◦ Numele cazurilor de utilizare trebuie s ˘a fie construc¸tii verbale care s ˘a indice ce anume încearc ˘a s ˘a ob¸tin ˘a utilizatorul (ex. Raporteaz ˘aUrgen¸t˘a,
Aloc ˘aResurse)
◦ Numele actorilor trebuie s ˘a fie substantive (ex. Ofi¸terTeren, Dispecer )
◦ Frontiera sistemului trebuie s ˘a fie clar ˘a, distingându-se între ac¸tunile utilizatorului ¸si cele ale sistemului
◦ Interac¸tiunile care definesc cazul de utilizare trebuie formulate la modul activ
◦ Rela¸tia de cauzalitate între dou ˘a interac¸tiuni consecutive trebuie s ˘a fie clar ˘a
◦ Un caz de utilizare trebuie s ˘a descrie o tranzac¸tie complet ˘a (ex.: cazul RaportareUrgen¸t˘a descrie to¸ti pa¸sii, de la ini¸tierea raportului ¸si pân ˘a la primirea confirm ˘arii finale)
◦ Excep¸tiile se descriu separat
◦ Descrierea unui caz de utilizare nu trebuie s ˘a fac ˘a nici o referire la interfa¸ta grafic ˘a cu utilizatorul
◦ Descrierea unui caz de utilizare nu trebuie s ˘a dep ˘a¸seasc ˘a dou ˘a-trei pagini. În caz contrar, cazul se descompune, folosind rela¸tiile între cazuri de utilizare
Rafinarea cazurilor de utilizare
• Focusul acestei activit ˘a¸ti îl constituie completitudinea ¸si corectitudinea specific ˘arii cerin¸telor
◦ Dezvoltatorii identific ˘a func¸tionalit ˘a¸ti neacoperite de scenariile descrise (cazuri rare sau excep¸tii) ¸si le documenteaz ˘a prin rafinarea cazurilor de utilizare existente sau introducerea unor noi cazuri
◦ Spre deosebire de identificarea ini¸tial ˘a a actorilor ¸si cazurilor de utilizare, focusat ˘a pe definirea frontierei sistemului, etapa de rafinare introduce detalii suplimentare privind func¸tionalit ˘a¸tile oferite de sistem ¸si constrângerile
asociate
• Sunt detaliate urm ˘atoarele aspecte
◦ Informa¸tia manipulat ˘a de sistem
◦ Intera¸tiunile dintre actori ¸si sistem
◦ Drepturile de acces (ce cazuri de utilizare poate invoca fiecare actor)
◦ Cazurile de excep¸tie (sunt identificate ¸si specificate)
◦ Func¸tionalitatea comun ˘a (este factorizat ˘a)
Rafinarea cazurilor de utilizare (cont.)
• Ex.: Rafinarea cazului de utilizare Raporteaz ˘aUrgen¸t˘a
Nume Raporteaz ˘aUrgen¸t˘a
Participan¸ti Ini¸tiat de Ofi¸terTeren Comunic ˘a cu Dispecerul
Flux de evenimente 1. Ofi¸terul activeaz ˘a func¸tia Raporteaz ˘a urgen¸t˘a a terminalului.
2. Sistemul SGA afi¸seaz ˘a un formular Ofi¸terului. Formularul include componente privind tipul urgen¸tei (general, foc,
accident auto), loca¸tia, descrierea ¸si resursele solicitate.
3. Ofi¸terul completeaz ˘a formularul, inserând cel pu¸tin nivelul de alert ˘a
¸si descrierea situa¸tiei. El poate descrie ¸si posibile r ˘aspunsuri la situa¸tia de urgen¸t˘a ¸si poate s ˘a solicite anumite resurse.
Dup ˘a completare, Ofi¸terul trimite formularul.
4. Sistemul prime¸ste formularul ¸si notific ˘a Dispecerul printr-o caset ˘a pop-up.
5. Dispecerul verific ˘a informa¸tia primit ˘a ¸si creeaz ˘a un nou Eveniment în baza de date prin invocarea cazului de utilizare DeschideCazNou.
Toate informa¸tiile din formularul primit sunt asociate automat evenimentului creat. Dispecerul alege un r ˘aspuns prin alocarea de resurse la eveniment (prin cazul de utilizare AlocareResurse)
¸si confirm ˘a primirea formularului printr-un scurt mesaj c ˘atre ofi¸ter.
6. Sistemul afi¸seaz ˘a confirmarea ¸si r ˘aspunsul ales Ofi¸terului.
...
Identificarea relat¸iilor
• Identificarea rela¸tiilor dintre actori ¸si cazurile de utilizare (comunicare, incluziune, extindere, generalizare) permite
reducerea complexit ˘a¸tii modelului, eliminarea redundan¸telor ¸si a poten¸tialelor inconsisten¸te
• Euristici privind folosirea rela¸tiilor de incluziune ¸si extindere
◦ Utilizarea rela¸tiei de extindere pentru modelarea comportamentului op¸tional, excep¸tional sau cu frecven¸t˘a redus ˘a de apari¸tie
◦ Utilizarea rela¸tiei de includere pentru factorizarea comportamentului comun mai multor cazuri de utilizare
◦ Utilizarea judicioas ˘a a rela¸tiilor, pentru a evita suprastructurarea modelului func¸tional. Un singur caz de utilizare mai complex se poate dovedi a fi mai inteligibil decât un num ˘ar prea mare de cazuri mai simple
Identificarea cerint¸elor nefunct¸ionale
• Întreb ˘ari ce permit identificarea cerin¸telor nefunc¸tionale aferente modelului FURPS+
◦ Utilizabilitate
• Care este nivelul de expertiz ˘a al utilizatorilor?
• Ce standarde de interfe¸te sunt familiare utilizatorilor?
• Ce documenta¸tie trebuie pus ˘a la dispozi¸tia utilizatorilor?
◦ Fiabilitate (incluzând robuste¸te, siguran¸t˘a ¸si securitate)
• Cât de fiabil/robust trebuie s ˘a fie sistemul?
• Este repornirea sistemului o alternativ ˘a viabil ˘a în cazul unui e¸sec?
• Sunt admisibile pierderi de date? Ce volum?
• Cum trebuie s ˘a gestioneze sistemul excep¸tiile?
• Exist ˘a cerin¸te privind siguan¸ta?
• Exist ˘a cerin¸te privind securitatea?
◦ Suportabilitate
• Care sunt extinderile probabile ale sistemului?
• Cine între¸tine sistemul?
• Exist ˘a probabilitatea de a porta sistemul pe alte platforme hardware/software?
Identificarea cerint¸elor nefunct¸ionale (cont.)
◦ Performan¸t˘a
• Exist ˘a sarcini critice din punct de vedere al timpului?
• Câ¸ti utilizatori concuren¸ti trebuie s ˘a suporte sistemul?
• Ce dimensiuni se estimeaz ˘a c ˘a va avea depozitul de date?
• Care este cel mai slab timp de r ˘aspuns acceptat de utilizatori?
◦ Implementare
• Exist ˘a constrângeri privind platforma hardware?
• Exist ˘a constrângeri impuse echipei de testare?
• Exist ˘a constrângeri impuse echipei de între¸tinere?
◦ Interfa¸t˘a
• Va interac¸tiona sistemul cu alte sisteme?
• Cum sunt exportate/importate datele la nivelul sistemului?
• Exist ˘a standarde utilizate de client care se aplic ˘a noului sistem?
◦ Instalare
• Cine va instala sistemul?
• Pe câte sta¸tii va fi sistemul instalat?
• Exist ˘a constrângeri de timp privind instalarea?
Identificarea cerint¸elor nefunct¸ionale (cont.)
◦ Operare
• Cine gestioneaz ˘a sistemul dup ˘a punerea în exploatare?
◦ Legal
• Care este procedura de licen¸tiere?
• Exist ˘a taxe rezultând din utilizarea anumitor componente/algoritmi?
• Exist ˘a penaliz ˘ari în cazul c ˘aderii sistemului?
Colectarea cerint¸elor - management
Metoda JAD
• JAD (Joint Application Design [WoodSilver 1989]) este o metod ˘a de colectare a cerin¸telor dezvoltat ˘a la IBM la sfâr¸situl anilor ’70
• Eficacitatea sa provine din faptul c ˘a activitatea de colectare a cerin¸telor se desf ˘a¸soar ˘a într-o singur ˘a sesiune workshop, cu participarea tuturor celor interesa¸ti în dezvoltarea sistemului (clien¸ti, utilizatori, dezvoltatori), precum ¸si a unui moderator de sesiune specializat
• Produsul final al workshopului (documentul final JAD) reprezint ˘a specifica¸tia complet ˘a a sistemului
• Fiind un document redactat de comun acord cu toti participan¸tii, specifica¸tia JAD minimizeaz ˘a riscul unor modific ˘ari ulterioare ale cerin¸telor în procesul de dezvoltare
• Succesul unei sesiuni JAD depinde, de cele mai multe ori, de
calificarea moderatorului
Metoda JAD (cont.)
• Activit ˘a¸ti JAD
Activit ˘at¸i JAD
• Project definition
◦ Moderatorul JAD intervieveaz ˘a project managerul ¸si clientul, pentru a identifica scopul ¸si obiectivele proiectului, informa¸tiile fiind re¸tinute în Management Definition Guide
• Research
◦ Moderatorul JAD intervieveaz ˘a utilizatorii sistemului, colecteaz ˘a informa¸tii relativ la domeniul problemei ¸si elaboreaz ˘a un prim set de cazuri de utilizare.
De asemenea, deschide o list ˘a de probleme ce se doresc a fi abordate în cadrul workshop-ului. Rezultatele acestei activit ˘a¸ti sunt reprezentare de Session agenda - agenda de lucru ¸si Preliminary specification - specifica¸tia preliminar ˘a a sistemului
• Preparation
◦ Moderatorul JAD preg ˘ate¸ste sesiunea de lucru, creeaz ˘a o prim ˘a versiune a documentului final JAD - Working document ¸si compune o echip ˘a constând din project manager, client, utilizatori ¸si dezvoltatori selecta¸ti.
Activit ˘at¸i JAD
• Session
◦ Moderatorul JAD coordoneaz ˘a echipa în elaborarea specifica¸tiei sistemului.
O sesiune JAD dureaz ˘a 3-5 zile. Se definesc scenariile, cazurile de utilizare ¸si prototipurile interfe¸tei cu utilizatorul. Toate deciziile sunt documentate (=>
Scribe forms).
• Final document preparation
◦ Moderatorul preg ˘ate¸ste documentul final - Final document, revizuind documentul de lucru pentru a include toate deciziile luate în sesiune.
Documentul final reprezint ˘a specifica¸tia complet ˘a sistemului, aprobat ˘a în cadrul sesiunii. Acesta este distribuit participan¸tilor pentru inspectare.
Urmeaz ˘a o sesiune de 1-2 ore în care participan¸tii dezbat modific ˘arile ¸si finalizeaz ˘a documentul.
