Proiectarea cerintelor aplicatiilor web

Proiectarea cerintelor acopera activitati care sunt critice pentru proiectarea web. Cerinte incomplete, ambigue sau incorecte pot conduce la dificultati in dezvoltare sau chiar cauza anularea proiectului. Proiectarea cerintelor presupune luarea in discutie a principiilor, metodelor si utilitarelor pentru extragerea, descrierea, validarea si managementul cerintelor.

Cerintele joaca un rol cheie in dezvoltarea aplicatiilor web, deseori fiind descrise in mod neadecvat. Consecintele specificarii cerintelor intr-o asemenea maniera sunt: esecul planificarii si arhitecturi software neadecvate.

Exista un acord general privitor la importanta cerintelor pentru dezvoltarea cu succes a sistemelor, de-a lungul anilor oferindu-se numeroase standarde, abordari, modele, limbaje de descriere si utilitare.

In continuare vom discuta principiile proiectarii cerintelor pentru dezvoltarea aplicatiilor web si vom studia modul in care metodele de proiectare a cerintelor pot fi adaptate la particularitatile proiectelor web.

1 Elemente fundamentale

1.1 Provenienta cerintelor

Obiectivele individuale si asteptarile imputernicitilor (partilor interesate) sunt punctul de pornire ale procesului de descoperire a cerintelor sistemului. Imputernicitii sunt indivizii sau organizatiile care au o influenta directa sau indirecta asupra cerintelor in dezvoltarea sistemului . Principalii imputerniciti sunt clientii, utilizatorii si dezvoltatorii. Imputernicitii reprezentativi pentru aplicatiile web includ autorii de continut, expertii in domeniu, experti in caracterul utilizabil sau profesionistii in domeniul marketing-ului. Obiectivele si asteptarile imputernicitilor sunt de obicei diverse, asa cum o demonstreaza urmatoarele exemple:

- aplicatia web trebuie sa fie disponibila online pana la 1 septembrie 2007 (constrangerea clientului);

- aplicatia web trebuie sa suporte minim 2500 utilizatori concurenti (obiectiv de calitate a clientului);

- PHP trebuie folosit ca platforma de dezvoltare (perspectiva tehnologica a dezvoltatorilor);

- toate datele clientilor trebuie trimise securizat (obiectiv de calitate al utilizatorului);

- interfata utilizator trebuie sa suporte layout-uri pentru grupuri diferite de clienti (obiectiv de calitate al clientului);

- orice utilizator trebuie sa poata cauta produsul dorit in mai putin de trei minute (obiectiv privind caracterul utilizabil pentru client);

- utilizatorul trebuie sa aiba posibilitatea sa selecteze o iconita care sa afiseze articolele incluse in card-ul de cumparaturi in orice moment (obiectiv privind capacitatea utilizatorului).

Identificarea si implicarea cu succes a imputernicitilor este sarcina principala a managementului proiectelor. O mare provocare o constituie intelegerea si aplanarea frecventelor conflicte privind obiectivele, asteptarile si ordinea de zi. De exemplu, pot exista conflicte intre setul dorit de functionalitati si bugetul disponibil; intre setul de functionalitati, planul proiectului si calitatea dorita; sau intre tehnologia de dezvoltare dorita si aptitudinile si experientele dezvoltatorilor. Intelegerea si rezolvarea din timp a acestor contradictii si conflicte este hotaratoare si este importanta pentru managementul riscului. Exista o serie de tehnici de negociere pentru a suporta aceasta sarcina. In acest proces, dezvoltarea unei viziuni impartasite intre imputerniciti este o conditie pentru succes.

Obiectivele imputernicitilor sunt deseori prezentate neoficial si ofera baza pentru cerinte derivate mult mai detaliate.

O cerinta descrie proprietatea de a fi cunoscuta sau a unui serviciu de a fi furnizat de catre un sistem. IEEE 610.12 defineste o cerinta ca:

- o conditie sau aptitudine necesara unui utilizator pentru a rezolva o problema sau a duce la bun sfarsit un obiectiv;

- o conditie sau aptitudine care trebuie indeplinita sau posedata de un sistem sau componenta sistem pentru a satisface un contract, standard, specificatie sau alte documente solicitate formal;

- o reprezentare documentata a unei conditii sau aptitudini.

Cerintele sunt clasificate deseori in cerinte functionale, cerinte non-functionale si constrangeri[2]. Cerintele functionale definesc capacitatea sistemelor si serviciilor, in timp ce cerintele non-functionale descriu nivelul de calitate dorit ("Cat este de securizat?", "Cat este de usor de folosit?"). Constrangerile sunt conditii non-negociabile care afecteaza proiectul. Exemple de constrangeri sunt nivelul de pricepere a echipei de dezvoltare, bugetul disponibil, data livrarii sau infrastructura de calculatoare existenta in echipa de dezvoltare.

Un document cu solicitarile rezuma toate cerintele si constrangerile dintre contractor si client. Abordarile uzitate in proiectarea cerintelor pun accentul pe identificarea si implicarea imputernicitilor, negocierea si descoperirea cerintelor pe baza de scenarii, analiza contextului organizational si social anterior modelarii detaliate si o definire clara a constrangerilor care afecteaza dezvoltarea[3].

1.2 Activitatile proiectarii cerintelor

Proiectarea cerintelor implica extragerea, documentarea, verificarea si validarea, dar si managementul cerintelor de pe parcursul procesului de dezvoltare.

Extragerea cerintelor si negocierea

Lowe si Eklund[4] au demonstrat ca cerintele nu pot fi colectate prin intrebari adecvate ci sunt rezultatul procesului de invatare si construirii pe baza de consens. In acest proces, comunicarea dintre imputerniciti este esentiala. Un set larg de metode si utilitare colaborative sunt disponibile pentru a facilita comunicarea si schimbul cunoasterii in proiectarea cerintelor. Astfel de exemple sunt tehnici de creativitate, metode bazate pe scenarii, procese pentru decizii multicriteriu, interviuri sau analiza documentelor.

Documentarea cerintelor

Daca imputernicitii ajung la un consens, acordul dintre acestia trebuie rafinat si descris intr-un document al cerintelor in functie de gradul detaliilor si formalismelor adecvate contextului proiectului. Alegerea gradului adecvat de detalii si a formalismelor depinde de riscurile identificate ale proiectului, de experienta si aptitudinile presupusilor cititori.

Verificarea cerintelor si validarea

Cerintele trebuie validate ("S-au specificat cerintele corecte?") si verificate ("S-au specificat corect cerintele?). Exista o serie de metode conventionale in acest scop, cum ar fi revizuirile, verificarile sau prototipizarea. In proiectarea web, deschiderea pe care o ofera Internetul faciliteaza noi forme de participare directa a utilizatorilor in validarea cerintelor, cum ar fi colectiile online ale feedback-urilor utilizatorilor[5].

Managementul cerintelor

Cerintele sunt supuse schimbarilor frecvente. Principalele caracteristici ale siturilor web sunt schimbarile permanente ale cerintelor si constrangerile. Metodele si instrumentele folosite pentru managementul cerintelor suporta atat integrarea noilor cerinte cat si modificarea celor existente. Datorita dificultatilor care apar in managementul cerintelor pentru sistemele complexe, este necesara utilizarea anumitor instrumente pentru a sprijini aceasta sarcina.

2 Cerinte specifice proiectarii web

La suprafata diferentele dintre proiectarea cerintelor pentru web si proiectarea cerintelor pentru sistemele software traditionale par a fi neglijabile. Desi exista multe diferente intre dezvoltarea web si dezvoltarea software, exista si multe similaritati (de exemplu extragerea cerintelor). In cele ce urmeaza vom insista pe diferentele dintre acestea, pe baza caracteristicilor aplicatiilor web prezentate in capitolul anterior.

Multidisciplinaritatea

Dezvoltarea aplicatiilor web necesita participarea expertilor din diferite discipline: experti multimedia, autorii de continut, arhitecti software, experti in usurinta de folosire, specialisti in baze de date sau experti intr-un anumit domeniu. Eterogenitatea si multidisciplinaritatea imputernicitilor devine un subiect interesant in realizarea acordului privind definirea cerintelor.

Indisponibilitatea imputernicitilor

Majoritatea imputernicitilor, cum ar fi potentialii utilizatori web, sunt necunoscuti pe parcursul activitatilor de proiectare a cerintelor. Managementul proiectelor trebuie sa gaseasca caracteristici adecvate care sa ofere la randul lor cerinte cat mai realiste. De exemplu, deseori exista un spectru larg de posibili utilizatori in proiectele web si gasirea unor caracteristici adecvate este dificila.

Caracterul schimbator al cerintelor si constrangerilor

Cerintele si constrangerile (ex. proprietatile platformelor de lucru sau protocoale de comunicatie) sunt adesea mai usor de definit pentru sistemele software traditionale comparativ cu aplicatiile web.

Aplicatiile web si mediul in care acestea functioneaza sunt extrem de dinamice, din acest motiv cerintele si constrangerile fiind greu de stabilit. Cele mai frecvente exemple de astfel de schimbari sunt inovatiile tehnologice cum ar fi introducerea noilor platforme si standarde de dezvoltare sau noile dispozitive pentru utilizatorii finali.

Mediul operational imprevizibil

Mediul operational al aplicatiilor web este de asemenea foarte dinamic si greu de anticipat. Pentru dezvoltatori este dificil sau chiar imposibil sa controleze factori importanti, decisivi pentru calitatea aplicatiei web perceputa de utilizator. De exemplu, modificarea latimii de banda afecteaza timpul de raspuns pentru aplicatiile mobile dar acest lucru nu depinde de echipa de dezvoltare.

Impactul sistemelor de mostenire

Dezvoltarea aplicatiilor web este caracterizata prin integrarea componentelor software existente cum ar fi produsele comerciale autonome sau software-ul open source. In particular, dezvoltatorii web se confrunta frecvent cu integrarea sistemelor de mostenire, de exemplu atunci cand vor sa faca un sistem IT existent al unei companii accesibil pe web. Dezvoltatorii au posibilitatea sa utilizeze componentele existente si din motive economice. Componentele care trebuie integrate influenteaza cerintele si arhitectura viitorului sistem. In aceste situatii o abordare in cascada care sa mosteneasca arhitectura sistemului din cerinte nu va avea succes, deoarece componentele, serviciile si infrastructura existenta stabilesc o serie de posibilitati si limitari pentru dezvoltatori. Prin aceasta intelegem ca atunci cand se identifica si definesc cerintele, dezvoltatorii web trebuie sa fie constienti de arhitectura sistemului si de constrangerile arhitecturale. O abordare iterativa este propusa de modelul Twin Peaks si este adecvata intr-un asemenea context (vezi figura).

Figura: Modelul Twin-Peaks[6]

Importanta aspectelor calitative

Aspectele calitative sunt decisive pentru succesul aplicatiilor web. Exemple: performanta unei aplicatii web, securitatea in sistemele de e-commerce, disponibilitatea sau usurinta in folosire. In ciuda importantei aspectelor calitative, dezvoltatorii trebuie sa se confrunte cu faptul ca o specificare exacta a cerintelor de calitate este dificil de stabilit inaintea construirii sistemului. De exemplu timpul de raspuns al unei aplicatii web depinde de multi factori, care nu pot fi controlati de echipa de dezvoltare. O abordare realizabila pentru definirea cerintelor de calitate implica specificarea criteriilor pentru testul de acceptare, specificand daca o cerinta a fost indeplinita sau nu. (vezi de asemenea un exemplu al unui criteriu de acceptare pentru o cerinta a calitatii in tabelul 2-1).

Tabel: Specificatii de formatare

Calitatea interfetei utilizator

Calitatea interfetei utilizator este un alt aspect hotarator pentru succesul aplicatiilor web. Cand realizeaza aplicatii web dezvoltatorii trebuie sa fie constienti de urmatorul fenomen: utilizatorii nu vor fi capabili sa inteleaga si sa aprecieze o aplicatie web uitandu-se la modele si specificatii abstracte; ei trebuie sa experimenteze. De aceea, este esential sa completam definitia si descrierea cerintelor prin adaugarea unor prototipuri pentru scenariile importante ale aplicatiei[7].

Calitatea continutului

Majoritatea metodelor de proiectare a cerintelor traditionale neglijeaza continutul web desi este un aspect important al aplicatiilor web. Pe langa problemele generate de tehnologia software dezvoltatorii trebuie sa aiba in vedere continutul si in special crearea si intretinerea acestuia. In contextul proiectarii cerintelor este esential sa specificam nivelul de calitate cerut. Cele mai importante caracteristici de calitate includ acuratetea, obiectivitatea, credibilitatea, relevanta, actualitatea, caracterul complet sau claritatea. Sistemele de management al continutului (CMS) au devenit importante si permit reprezentarea concisa si consistenta a continutului prin separarea continutului de layout si oferirea utilitarelor de editare a continutului.

Lipsa de experienta a dezvoltatorilor

Majoritatea tehnologiilor de baza din aplicatiile web sunt relativ noi. Lipsa de experienta cu instrumentele de dezvoltare care folosesc aceste tehnologii, standardele si limbajele pot conduce la estimari gresite cand se ia in discutie fezabilitatea si costul implementarii cerintelor.

Date fixe de livrare

Multe proiecte web au o data fixa de livrare, toate activitatile si deciziile trebuind sa fie finalizate pana la un termen limita. Negocierea si stabilirea unei ordini de prioritate a cerintelor este esentiala in aceste conditii.

3 Principii pentru proiectarea cerintelor aplicatiilor web

In aceasta sectiune vom descrie principiile de baza ale proiectarii cerintelor aplicatiilor web. Aceste principii deriva din stabilitatea modelului in spirala in care castiga toti partenerii (modelul win-win), un model al ciclului de viata iterativ si orientat pe risc care pune accentul pe implicarea imputernicitilor si pe extragerea si rezolvarea cerintelor. Modelul in spirala win-win a influentat multe modele bazate pe procese, inclusiv Procesul Unificat Rational (RUP) de la IBM. Dezvoltatorii web trebuie sa aiba in vedere urmatoarele principii pe parcursul activitatilor de proiectare a cerintelor:

Intelegerea contextului sistemului

Multe aplicatii web sunt inca dezvoltate ca solutii tehnice izolate, fara o intelegere a rolului si impactului acestora intr-un context general. O aplicatie web nu poate fi o finalitate prin ea insasi; ea trebuie sa tina cont de obiectivele afacerii clientului. Pentru ca aplicatia web sa aiba succes este important sa clarificam contextul sistemului(de exemplu prin analizarea si descrierea proceselor de afaceri existente) si motivul pentru care sistemul va fi dezvoltat. ("Pentru ce facem acest lucru?"). Dezvoltatorii trebuie sa inteleaga modul in care sistemul este implementat in mediul sau. Analiza afacerii poate stabili valoarea unei aplicatii web in relatie cu resursele pe care le utilizeaza cerintele. Intelegerea contextului sistemului ajuta la identificarea imputernicitilor, familiarizarea cu scopul aplicatiei si analizarea constrangerilor .

Implicarea imputernicitilor

Imputernicitii sau reprezentantii lor reprezinta inima proiectarii cerintelor, iar cooperarea acestora activa si directa pentru identificarea si negocierea cerintelor este importanta pentru fiecare faza a proiectului. Managerii de proiect trebuie sa evite situatiile in care participantii individuali la proiect castiga pe seama altora. S-a demonstrat ca asemenea situatii castig-pierdere conduc adesea la situatii pierdere-pierdere, determinand in final esecul intregului proiect.

Obiectivele, asteptarile si cerintele imputernicitilor trebuie stabilite si negociate in mod repetat pentru a se adapta schimbarilor dinamice care apar in proiecte. Anterior am aratat ca multidisciplinaritatea si indisponibilitatea imputernicitilor sunt specifice proiectarii cerintelor pentru web. Aceste caracteristici conduc la stabilirea urmatoarelor cerinte pentru contextul aplicatiilor web:

identificarea imputernicitilor sau reprezentantilor acestora

intelegerea obiectivelor si asteptarilor imputernicitilor

negocierea asteptarilor, experientelor si cunostintelor (multidisciplinaritate).

Metodele si utilitarele de proiectare a cerintelor trebuie sa fie in concordanta cu aceste cerinte si trebuie sa contribuie la schimbul efectiv de cunostinte dintre participantii la proiect, sa permita un proces de instruire in echipa, dezvoltarea unei viziuni comune printre imputerniciti si sa ajute la detectarea din timp a conflictelor.

Definirea iterativa a cerintelor

Abordarea in cascada a cerintelor nu functioneaza intr-un mediu dinamic, iar cerintele trebuie dobandite in mod iterativ in dezvoltarea aplicatiilor web. Cerintele trebuie sa fie in concordanta cu alte rezultate ale dezvoltarii (arhitectura, interfata utilizator, continut, testari etc.). La initierea proiectului, cerintele cheie sunt de obicei definite la un nivel inalt de abstractizare. Aceste cerinte preliminare pot fi utilizate pentru a dezvolta arhitecturi fezabile, scenarii de utilizare a sistemului si planurile initiale ale proiectului. Pe masura ce proiectul progreseaza rezultatul dezvoltarii poate fi rafinat in mod gradat prin specificarea unor termeni mai concreti, asigurand in continuare consistenta lor. O abordare iterativa este necesara in special intr-un mediu in care cerintele si constrangerile sunt schimbatoare, pentru a putea reactiona intr-un mod flexibil pe masura ce proiectul evolueaza. Daca termenul limita fixat este trimis echipei de dezvoltare, atunci o abordare de dezvoltare iterativa permite selectarea cerintelor cheie care trebuie implementate primele.

Focalizarea pe arhitectura sisitemului

Tehnologiile existente si solutiile de mostenire au un impact sporit asupra cerintelor aplicatiilor web. Intelegerea solutiilor tehnice impreuna cu posibilitatile si limitarile lor sunt esentiale. Extragerea cerintelor nu poate avea loc separat de arhitectura si trebuie luata in discutie cand definim cerintele. Luarea in considerare a arhitecturii sistemului permite dezvoltatorilor sa inteleaga mai bine impactul solutiilor existente asupra cerintelor si sa estimeze fezabilitatea acestora. Modelul Twin-Peaks (vezi figura) propune perfectionarea cerintelor si arhitecturii sistemului in maniera iterativa prin sporirea continua a nivelului de detaliere.

Riscuri

Problemele nedetectate, cele nerezolvate si conflictele dintre cerinte reprezinta riscuri majore ale proiectelor. Problemele obisnuite de risc sunt integrarea componentelor existente in aplicatia web, anticiparea aspectelor de calitate a sistemului sau lipsa de experienta a dezvoltatorilor. De aceea evaluarea riscului trebuie adaptata pentru toate cerintele. Odata identificate, riscurile trebuie administrate pe parcursul proiectului, pentru a ne asigura ca nu sunt urmate alternative riscante pentru sistem. Diminuarea riscului trebuie realizata cat mai rapid. Aceasta poate include de exemplu prototipizarea, lansarea rapida a aplicatiei web pentru a colecta feedback-ul utilizatorilor sau incorporarea precoce a componenetelor externe pentru a elimina problemele majore ale integrarii tardive.

4 Adaptarea metodelor de proiectare a cerintelor dezvoltarii aplicatiilor web

In prezent sunt disponibile numeroase metode, ghiduri, notatii, cataloage si utilitare pentru toate activitatile de proiectare a cerintelor. Dezvoltatorii trebuie sa evite o abordare unitara, metodele de proiectare a cerintelor trebuind adaptate permanent specificului proiectarii web si situatiilor care apar in anumite proiecte. Principiile descrise anterior ne conduc la definirea unei abordari de proiectare a cerintelor specifice proiectelor. Dezvoltatorii trebuie sa clarifice urmatoarele aspecte pe parcursul procesului de adaptare:

- Ce tipuri de cerinte sunt importante pentru aplicatiile web?

- Cum vor fi descrise si documentate cerintele pentru aplicatiile web?

- Care sunt gradele utile ale detalierii?

- Trebuie avuta in vedere folosirea utilitarelor si care dintre acestea sunt potrivite pentru nevoile specifice ale proiectului?

4.1 Tipuri de cerinte

Organizatiile de standardizare si organizatiile comerciale au dezvoltat un numar mare de taxonomii pentru definirea si clasificarea diferitelor tipuri de cerinte (de exemplu Volere sau IEEE 830-1998). Majoritatea taxonomiilor fac distinctie intre cerintele functionale si cele non-functionale. Cerintele functionale descriu capacitatile sistemelor si serviciilor (de exemplu utilizatorul poate selecta o iconita pentru a vizualiza articolele din cosul de cumparaturi in orice moment). Cerintele non-functionale descriu proprietatile capacitatilor si nivelul dori al serviciilor (de exemplu aplicatia web ar trebui sa suporte cel putin 2500 de utilizatori concurenti). Alte cerinte non-functionale se refera la constrangerile proiectului si interfata sistem.

In continuare vom discuta de scurt tipurile de cerinte de o relevanta deosebita pentru dezvoltarea proiectelor web:

Cerintele functionale

Cerintele functionale specifica capacitatile si serviciile pe care un sistem ar trebui sa le ofere (de exemplu transferul de bani intr-o aplicatie de online banking). Cerintele functionale sunt frecvent descrise utilizand scenariile de tip utilizare de caz (use case) si specificatiile de formatare .

Cerinte privind continutul

Cerintele privind continutul specifica continutul care trebuie sa-l prezinte aplicatia web. Continutul poate fi descris, de exemplu, sub forma unui glosar.

Cerinte privind calitatea

Cerintele privind calitatea descriu nivelul calitatii serviciilor si specifica proprietati importante ale sistemului cum ar fi securitatea, performanta sau usurinta in folosire[11]. Standardul international ISO/IEC 9126 defineste un model independent de tehnologie pentru calitatea softului care cuprinde 6 caracteristici de calitate, fiecare fiind impartit intr-un set de subcaracteristici.

Cele sase caracteristici sunt:

. Functionalitatea - descrie prezenta functiilor care indeplinesc proprietatile definite. Subcaracteristicile sunt oportunitatea, corectitudinea, interoperabilitatea, conformitatea si securitatea.

. Siguranta - descrie capacitatea unui produs software de a-si mentine nivelul de performanta in anumite conditii pe o perioada definita de timp. Subcaracteristicile sunt maturitatea, toleranta la erori si posibilitatea de recuperare.

. Usurinta in folosire - descrie efortul necesar pentru a utiliza un produs software si evaluarea sa individuala de catre un grup de utilizatori definit sau presupus. Subcaracteristicile sunt usurinta in intelegere, in invatare si operare.

. Eficienta - descrie raportul intre nivelul de performanta al produsului software si resursele pe care acesta le utilizeaza in anumite conditii. Subcaracteristicile includ comportamentul in timp si comportamentul resurselor.

. Intretinerea - descrie efortul necesar pentru a implementa modificari prestabilite intr-un produs software. Subcaracteristicile includ posibilitatea de analiza, schimbare, stabilitate si testare.

. Portabilitatea - descrie capacitatea unui produs software de a fi mutat dintr-un mediu in altul. Subcaracteristicile includ capacitatea de adaptare, instalare, potrivire si inlocuire. Au fost facute diverse incercari de catre cercetatori pentru a extinde acest model de baza la caracteristicile specifice web-ului. In capitolele ulterioare vom insista asupra usurintei in folosire, performantei si securitatii, care reprezinta aspecte de calitate critice in general si pentru aplicatiile web in particular.

Cerintele mediului sistem

Aceste cerinte descriu modul in care o aplicatiile web este inclusa in cadrul tinta si cum aceasta interactioneaza cu componentele externe, incluzand de exemplu sistemele de mostenire, componentele comerciale autonome sau hardware-ul special. De exemplu, daca o aplicatie web se presupune ca este disponibila global, atunci cerintele de mediu trebuie sa specifice detaliile.

Cerintele interfetei utilizator

Deoarece se presupune ca utilizatorii web folosesc aplicatia web fara o instruire formala, ghidarea intuitiva si autoexplicativa a utilizatorilor este esentiala pentru acceptarea aplicatiei. Cerintele privitoare la interfata utilizator definesc modul in care o aplicatie web interactioneaza cu tipuri diferite de clase de utilizatori. Principalele aspecte sunt hipertextul (structura de navigare) si prezentarea (interfata utilizator). Detaliile de navigare si prezentare sunt definite in mod normal in procesul de modelare, dar deciziile initiale privind proiectarea interfetei utilizator trebuie luate pe parcursul extragerii cerintelor. Prototipurile sunt cele mai potrivite in aceasta situatie. Constantine si Lockwood sugereaza ca utilizatorii trebuie sa coopereze in proiectarea scenariilor pentru anumite sarcini specifice. Proiectarea centrata pe utilizare se bazeaza pe crearea si rafinarea iterativa de modele pentru roluri, sarcini si interactiuni[12].

Cerintele privind evolutia

Produsele software in general si aplicatiile web in particular sunt subiectul unei evolutii si imbunatatiri continue. Din acest motiv dezvoltatorii web trebuie sa anticipeze cerintele care ar putea apare dupa folosirea planificata pe termen scurt a aplicatiei. De exemplu, o cerinta de calitate prin care se cere suplimentarea cu 5000 de utilizatori concurenti in urmatorii doi ani trebuie avuta in vedere atunci prin definirea unei arhitecturi a sistemului scalabile. Cerintele privind evolutia sunt posibile pentru toate tipurile de cerinte discutate (de exemplu capacitatile viitoare, cerintele de securitate viitoare).

Constrangerile proiectului

Constrangerile proiectului nu sunt negociabile pentru imputernicitii proiectului si includ de obicei bugetul si planul, limitarile tehnice, standardele, tehnologia de dezvoltare folosita, regulile de desfasurare, aspectele de intretinere, constrangerile operationale si aspectele legale sau culturale care afecteaza proiectul.

4.2 Notatii

Sunt disponibile diferite notatii pentru specificarea cerintelor la nivele diferite de detaliere si formalitate. Exemple: relatari, specificatii de formatare, specificatii formale.

Riscurile identificate ale proiectului ofera repere in alegerea nivelului potrivit al specificatiilor de calitate (de exemplu stabilirea gradului de specificare a cerintelor dintr-un anumit proiect). In general abordarile informale si semiformale sunt adecvate pentru aplicatiile web, iar tabelul urmator (vezi tabelul) prezinta notatii diferite pentru cerinte.

Tabel: Compararea concordantei diferitelor notatii

Relatarile

Relatarile - sunt descrieri colocviale ale proprietatilor dorite; ele sunt utilizate pentru a stabili termenii comuni dintre clienti si dezvoltatori. Exemple: relatarile utilizatorilor din Extreme Programming . Relatarea unui utilizator este formulata de catre un client folosind terminologie si limbaj propriu si descrie problemele pe care sistemul ar trebui sa le rezolve pentru acel client.

Un exemplu de scenariu din perspectiva clientului poate fi urmatorul: Un utilizator ale un produs si il adauga in cosul de cumparaturi online. Datele de intrare sunt validate atunci cand utilizatorul opteaza pentru <Continuare>. Daca nu sunt gasite erori comanda va fi acceptata si va fi trimisa utilizatorului o confirmare prin email.

Cerintele specificate

Cerintele specificate sunt simple specificatii in limbajul natural. Fiecare cerinta are un identificator unic. Un bun exemplu este descrierea unui element de tip data specificat in IEEE/EIA-J-STD- 016.

Specificatiile de formatare

Specificatiile de formatare utilizeaza o sintaxa bine definita dar permit si descrieri in limbajul natural. Exemple: descrierile de tip use case din UML (Unified Modeling Language), RDD-100 Requirements Specification Language, ghidurile MBASE SSRD sau Volere Shell.

Tabelul in care am prezentat specificatiile de formatare prezinta un exemplu de specificatie de formatare. Principalele atribute sunt: descriere, prioritate, rationament si istoricul versiunii. Fiecare cerinta este identificata individual si poate fi referita pe parcursul procesului in orice moment utilizand un ID unic. Interdependentele cu alte cerinte si rezultate ale dezvoltarii (cum ar fi documentele sau planurile arhitecturii) sunt retinute pentru a sustine identificarea.

Cazurile de utilizare UML sunt utile pentru a descrie cerintele fuctionale. Un caz de utilizare descrie o functie a sistemului din pespectiva actorilor acestuia si conduce la un rezultat care poate fi perceput de catre actori. Un actor este o entitate externa sistemului care interactioneaza cu sistemul. O diagrama de utilizare de caz reprezinta relatia intre cazurile de utilizare a sistemului si actori. Diagramele de utilizare de caz sunt utile pentru a reprezenta dependentele de nivel inalt dintre cazurile de utilizare si actori; detaliile cazului de utilizare sunt definite prin specificatii de formatare. Atributele descriu numarul si numele cazului de utilizare, actorii implicati, conditiile anterioare si posterioare si progresul, exceptiile si erorile, variatiile, sursa, rationamentul, si interdependentele cu alte diagrame UML.

Specificatiile formale

Specificatiile formale sunt scrise intr-un limbaj care utilizeaza o sintaxa si semantici definite formal. Cel mai bun exemplu este "Z" (ISO/IEC13,568:2002). Specificatiile formale sunt greu de utilizat pentru aplicatiile web.

Oportunitatea

Tabelul anterior compara diferite notatii in ceea ce priveste exactitatea atributelor, usurinta validarii, raportul eficacitate-cost, folosirea de catre non-experti si scalabilitatea. O exactitate de la scazut la mediu va fi suficienta pentru specificarea cerintelor aplicatiilor web si o validare formala nu este necesara. Este important sa pastram scazut efortul de extragere si management a cerintelor, iar aceste cerinte sa fie intelese si de catre non-experti.

Scalabilitatea este o problema pusa pe seama complexitatii ridicate a aplicatiilor web. In tabelul anterior putem observa ca descrierile informale si semi-formale (relatarile, listele de cerinte si specificatiile de formatare) sunt adecvate pentru aplicatiile web.

4.3 Utilitare

Exista numeroase categorii de utilitare care folosesc activitatile de proiectare a cerintelor descrise. Utilitare de proiectare a cerintelor existente nu sunt limitate la aplicatiile web si pot fi adaptate la tipicul dezvoltarii aplicatiilor.

Extragerea cerintelor

Metodele si utilitarele de negociere au fost dezvoltate si explorate in multe discipline. EasyWinWin este o abordare bazata pe groupware care indruma o echipa de imputerniciti pentru achizitionarea si negocierea cerintelor. EasyWinWin defineste un set de activitati pentru procesul de negociere, un moderator indrumand imputernicitul pe parcursul intregului proces. Aceasta abordare utilizeaza tehnici de incurajare a grupurilor de lucru care sunt suportate de utilitarele colaborative (brainstorming electronic, clasificari, sisteme de votare, etc.). Aceste activitati sunt: revizuirea si extinderea subiectelor de negociere, interesele imputernicitilor; convergenta spre conditiile de castig, extragerea unui vocabular de termeni comuni, stabilirea nivelului de prioritate pentru conditiile de castig, evidentierea problemelor si constrangerilor, identificarea problemelor si optiunilor si negocierea acordurilor.

Validarea cerintelor

Datorita caracterului deschis al Internetului sistemele de raspuns online (feedback) pot suplimenta sau chiar inlocui metode costisitoare cum ar fi intalnirile cu personalul sau interviurile, cand se valideaza cerintele aplicatiei web. De exemplu utilizatorii Internetului pot fi invitati sa participe la un sondaj pe web pentru a comunica gradul lor de multumire fata de aplicatia web. Remarcam in acest context ca datorita spontaneitatii comportamentului interactiv deseori nu putem observa o aprobare sau o negare ci doar indiferenta. Daca un unui utilizator ii va place aplicatia web o va utiliza dar va fi reticent la trimiterea unui feedback (de exemplu informatii privind erorile gasite) pentru a contribui la dezvoltarea si imbunatatirea aplicatiei.

Managementul cerintelor

Utilitarele pentru managementul cerintelor permit managementul tuturor cerintelor colectate dintr-un proiect intr-un depozit central. Spre deosebire de sistemele de procesare a textului utilitarele de management al cerintelor stocheaza cerintele intr-o baza de date. Asemenea specificatiilor de formatare, atributele relevante sunt administrate pentru fiecare din aceste cerinte (vezi tabelul ). Sistemele de management al cerintelor sunt importante pentru schimbarea managementului si identificarii cerintelor. O trecere in revista a utilitarelor existente poate fi gasita la https://www.paper-review.com/tools/rms/read.php.

5 Concluzii

In acest capitol am surprins cateva tendinte in proiectarea cerintelor entru aplicatiile web:

. Disparitia granitei intre dezvoltarea si utilizarea sistemelor: aplicatiile web pot fi disponibile utilizatorilor pe parcursul dezvoltarii si ele pot evolua in acest timp. Separarea stricta a dezvoltarii sistemului de utilizarea lui - des intalnita in sistemele traditionale va deveni mai putin importanta in viitor.

. O integrare mai buna a cerintelor si arhitecturilor: cercetatorii au dezvoltat abordari pentru modelarea relatiilor si interdependentelor complexe intre cerintele, componentele si proprietatile arhitecturii sistemului. In viitor vor fi necesare modalitati mai bune pentru a modela cerintele non-functionale si constrangerile.

. Noi instrumente pentru proiectarea cerintelor distribuite: facilitatile Internetului si noile forme de cooperare internationala din comert si industrie demonstreaza ca cerintele vor fi definite de echipe distribuite geografic, conducand la noi schimbari in procesul de proiectare a cerintelor.

. Proiectarea cerintelor in sistemele deschise: aplicatiile web contin diverse componente (de exemplu serviciile web) care sunt proiectate, dezvoltate si folosite de diferite grupuri de imputerniciti. Aceste grupuri pot urmari obiective diferite sau in schimbare atunci cand folosesc aplicatia web, comportamentul in ansamblu al acestora fiind greu de anticipat.