Analiza cerintelor este prima etapa în procesul de parametrizare si customizare a unui sistem software ERP. De cele mai multe ori, acest proces de parametrizare si customizare este numit proces de implementare, dar in fapt, implementarea este doar o faza a acestuia.
Analiza cerintelor cuprinde acele operatiuni care au ca scop determinarea necesitatilor unei companii, tinând cont de eventualele conflicte ce pot aparea din partea diferitelor parti interesate, cum ar fi beneficiari sau utilizatori. Analiza cerintelor este esentiala pentru succesul unui proiect de dezvoltare. Cerintele trebuie sa fie aplicabile, masurabile, testabile, legate de nevoile de bussiness sau de oportunitatile identificate, si definite la un nivel de detaliu suficient pentru ca sistemul sa poata fi proiectat.
Prezentare generala
Conceptual, analiza cerintelor include trei tipuri de activitati:
-
Identificarea cerintelor:
-
se concretizeaza prin comunicarea cu clientii si cu utilizatorii pentru a se determina care sunt cerintele lor. Acest lucru este uneori numit colectarea cerintelor
-
-
Analiza cerintelor:
-
stabileste daca cerintele declarate si identificate sunt ambigue, incomplete sau contradictorii, apoi presupune rezolvarea acestor probleme.
-
-
Înregistrarea cerintelor:
-
cerintele pot fi documentate în diferite forme, cum ar fi documente in limbaj natural, use-cases, user stories sau un specificatii de proces.
-
Analiza cerintelor poate fi un proces lung si dificil în care mai multe competente sunt implicate. Noile sisteme aduc schimbarea mediului si a relatiilor dintre oameni, de aceea este important de a se identifica toate partile interesate, sa se ia în considerare toate nevoile lor si sa se asigure ca acestea înteleg implicatiile noului sistem. Analistii pot folosi mai multe tehnici pentru a obtine cerintele de la client. În trecut, aceasta se efectua prin tinerea de interviuri, de ateliere de lucru, sau intocmirea de liste de cerinte.
Mai multe tehnici moderne includ dezvoltarea de prototipuri si de use-cases. În cazul în care este necesar, analistul va folosi o combinatie a acestor metode de stabilire a cerintelor exacte ale partilor interesate, astfel încât sistemul sa corespunda nevoilor de afaceri.
Elemente specifice analizei cerintelor
Identificarea partilor interesate
Un nou accent major în anii 1990 a fost pus pe identificarea partilor interesate. Este din ce în ce mai recunoscut faptul ca partile interesate nu sunt limitate la compania care va deveni beneficiarul noului sistem. Alte parti interesate pot fi:
-
acele organizatii care se integreaza (sau ar trebui sa se integreze) orizontal cu organizatia beneficiara
-
orice sistem de back office sau care este folosit la nivel organizational
-
Senior management.
Intervievarea partilor interesate
Intervievarea partilor interesate este o metoda des utilizata în Analiza Cerintelor. Aceste interviuri pot evidentia cerinte care nu au fost avute în vedere anterior, care nu apartin de sfera de aplicare a proiectului, precum si cerinte care pot fi contradictorii. Cu toate acestea, fiecare din partile interesate vor avea o idee despre asteptarile lor sau vor putea vizualiza cererile lor.
Documentarea Cerintelor
Un mod traditional de documentare a cerintelor a fost Lista de cerinte stil contract. Într-un astfel de sistem complex listele de cerinte pot ajunge la sute de pagini.
Definirea de Obiective masurabile
Cele mai bune practici recomanda utilizarea listelor de cerinte create doar ca indicii, si folosirea în mod repetat a intrebarii „de ce?” pâna cand este descoperit adevaratul scop. Partile interesate si implementatiorii pot apoi sa conceapa teste pentru a masura nivelul in care fiecare obiectiv a fost atins astfel. Astfel de obiective se schimba mai lent decât lista lunga de cerinte specifice, dar care nu pot fi masurabile. Odata ce un mic set de obiective critice masurabile a fost stabilit, se pot dezvolta rapid prototipuri si scurta fazele de implementare iterative. Astfel, se poate livra efectiv partilor interesate obiective de valoare cu mult înainte de a se ajunge la jumatatea proiectului .
Prototipuri
La mijlocul anilor 1980, prototipurile au fost percepute ca o solutie la problema Analizei Cerintelor. Prototipurile sunt machete ale sistemului final. Machetele permit utilizatorilor de a vizualiza o aplicatie care nu a fost înca implementata. Prototipurile ajuta utilizatorii în a avea o idee despre cum va arata sistemul fara a astepta ca sistemul sa fie implementat. Odata cu introducerea de prototipuri, s-au remarcat imbunatatiri majore în comunicarea dintre utilizatori si implementatori. Vizualizarea initiala a permis rafinarea cerintelor si a dus la mai putine modificari mai târziu si, prin urmare, a redus considerabil costurile totale. Cu toate acestea, în urmatorul deceniu, în timp ce s-au dovedit a fi o tehnica utila, prototipurile nu a rezolvat problema cerintelor: Managerii, odata ce vor vedea un prototip, pot intelege greu ca finalizarea proiectului va dura ceva timp. Implementatorii de multe ori se simt obligat sa foloseasca patch-uri ale prototipului în sistemul real, pentru ca se tem sa nu „piarda timpul” luind-o de la inceput. Prototipurile ajuta in principal la luarea deciziilor de dezvoltare si proiectare a interfetei cu utilizatorul. Cu toate acestea, ele nu pot spune ce cerinte au fost initial. Implementatorii si utilizatorii finali se pot concentra prea mult pe interfata si prea putin cu privire la producerea unui sistem care serveste în procesele de bussiness. Prototipurile sunt folositoare pentru definirea interfetei pentru utilizator, dar nu sunt la fel de utile pentru procesele de prelucrare in masa sau asincrone care pot implica actualizari complexe a bazei de date si / sau a calculelor. Prototipurile pot fi realizate prin schite draft fie prin aplicatii cu functionalitati sintetizate. Schitele draft adesea elimina elementele de culoare din versiunea finala (de exemplu, se utilizeaza o paleta de culori in tonuri de gri) în cazurile în care software-ul final este de asteptat sa aiba design grafic aplicat. Aceasta ajuta la prevenirea confuziei cu privire la aspectul final vizual.
Use cases
Un use case este o tehnica de documentare a potentialului cerintelor unui sistem software. Fiecare use case prevede una sau mai multe scenarii care conduc la modul în care sistemul ar trebui sa interactioneze cu utilizatorul final sau cu un alt sistem pentru a atinge un anumit scop de afaceri. Use case-urile evita de obicei jargonul tehnic, preferând în locul acestuia terminologia utilizatoruli final sau a domeniului de expertiza. Use case-urile sunt de multe ori elaborate in colaborare de catre analisti si reprezentanti ai partilor interesate. Use case-urile sunt unelte extrem de simple pentru a descrie comportamentul software-ului sau al sistemelor. Un Use case contine o descriere textuala destinata utilizatorilor care ar putea lucra cu software-ul sau cu sistemul. Use case-urile nu descriu modul intern de functionare a sistemului, si nici nu explica cum acest sistem va fi implementat. Ei pur si simplu arata pasii pe care un utilizator ii urmeaza pentru ca sa efectueze o activitate. Toate modalitatile prin care utilizatorii interactioneaza cu un sistem pot fi descrise în acest mod.
Software requirements specification
Un Software requirements specification (SRS) reprezinta o descriere completa a comportamentului sistemului. Acesta include o serie de use-case-uri care descriu toate interactiunile pe care utilizatorii le vor avea cu software-ul.
Use-case-urile sunt de asemenea cunoscute sub numele de Cerinte functionale. În plus fata de use-case-uri, SRS contine, de asemenea, cerinte nonfunctionale (sau suplimentare). Cerintele non-functionale sunt cerintele care impun constrângeri cu privire la proiectare sau implementare (cum ar fi cerintele de performanta, standardele de calitate, etc).
Probleme in Analiza Cerintelor
Probleme ale partilor interesate
Utilizatorii insisi pot inhiba colectarea cerintelor:
-
Utilizatorii care nu înteleg ceea ce doresc sau utilizatorii care nu au o idee clara a cerintelor.
-
Utilizatorii nu vor sa se angajeze la o serie de cerinte în scris
-
Utilizatorii care insista asupra noilor cerinte dupa ce costul si programul de implemnetare au fost stabilite
-
Comunicarea cu utilizatorii este lenta
-
Utilizatorii care trebuie de multe ori sa participe la interviuri si sunt în incapacitate de a face acest lucru
-
Utilizatorii nu sunt din punct de vedere tehnic avansati
-
Utilizatorii care nu înteleg procesul de implementare
-
Utilizatorii care nu stiu despre tehnologia prezenta
Acest lucru poate duce la situatia în care cerintele utilizatorilor sa fie in continua schimbare, chiar si atunci când sistemul a fost început a fi implementat.
Probleme ale analistilor si consultantilor de implementare
Posibile probleme cauzate de ingineri si programatori în timpul analiza cerintelor sunt: Personalul tehnic si utilizatorii finali pot avea diferite vocabulare. În consecinta, ei pot în mod eronat considera ca se afla în in perfect acord pâna la livrarea produsului finit. Ingineri si programatori pot încerca sa faca cerintele sa se supuna unui sistem existent sau model, mai degraba decât sa dezvolte un sistem pe nevoile specifice ale clientului. Analiza poate fi deseori efectuata de ingineri programatori sau, mai degraba de personal cu abilitati si cunostinte in domeniu pentru a întelege un client în mod corespunzator.
Solutii posibile
O solutie pentru problemele de comunicare a fost de a angaja specialisti în afaceri sau in analiza de sistem. Tehnicile introduse în anii 1990, cum ar fi prototipurile, Unified Modeling Language (UML), use-cases, etc. sunt destinate de asemenea ca solutii la problemele întâmpinate cu metodele anterioare. De asemenea, o noua clasa de simulatoare de aplicatii sau instrumente de definire a aplicatiilor au intrat pe piata. Aceste instrumente sunt concepute pentru a construi un pod de comunicare care sa umple decalajul dintre utilizatori si consultanti si, de asemenea, pentru a permite aplicatiilor sa fie „test marketed”, înainte de a fi definite efectiv.
Sursa: Wikipedia