BABOK (Business Analyst Body of Knowledge, un fel de Biblie a BA-ului) specifică mai multe tipuri de requirement așa cum vei vedea mai jos. Ca BA, treaba ta este de a aduna, documenta și a reliefa în documentele livrate cât mai multe informații din categoriile următoare.
- business requirements/rules – scopul persoanele din nivelul business este găsirea unei soluții la o problemă întâlnită în timpul funcționării afacerii. Ele se nasc din probleme existente (vrem ca sistemul să răspundă mai repede pentru a putea procesa mai multe plăți concomitent) sau din dorința de dezvoltare (se dorește implementarea plății cu PayPal pentru a deservi și clienții care vor să plătească așa). O altă parte a acestora pot fi și cea legală în care businessul își desfășoară activitatea, de exemplu constrângeri legislative, modificarea modului de raportare către state a documentelor fiscale, etc; uneori dacă dezavantajul a nu avea respectivul feature este prea mic, s-ar putea ca businessul să nu vrea un anume feature și din când în când să plătească amenzi.
- user requirements – scopul acestui tip de requirement este de a descrie și propune soluții pentru ca un utilizator al aplicației să poată să își desfășoare activitatea. Pot fi descrise sumar doar ca intenție de a avea un feature (vreau să pot emite o factură pentru un produs). Pentru un user requirement pot exista o serie mai largă de functional requirements.
- functional requirements – acestea sunt comportamente specifice (vreau să se execute x,y,z, când fac operațiunea q). Există posibilitatea ca acestea să specifice și noțiuni de design sau de implementare deși nu este scopul lor, în fond ele trebuind să descrie necesitatea de business (vreau să pot să specific pe factură și o dată de trimitere).
- architecture requirements – în acest tip de requirement se explică modul de structurare al aplicației, componentele, căile de comunicare între componentele ei, etc.
- system requirement – surprind în detaliu necesitățile de sistem ca mediul de operare (desktop, web), tehnologii suportate de server (.Net, JS, html, etc.), procesor, RAM și alte asemenea.
- quality requirements – eeeh, acest tip de requirement e cel mai greu de surprins pentru că de obicei beneficiarii nu se gândesc la asta. Pentru ei aplicația trebuie să meargă, punct. Ce ar trebui menționat aici include dar nu se limitează la numărul de probleme apărute (buguri?), timpul de răspuns, modul de răspuns la o eroare, cât de scalabil e sistemul, care este uptime-ul.
- transition requirements – trebuie specificat destul de exhaustiv care ar fi pașii ce necesită executați pentru a face tranziția de la starea curentă la o stare viitoare, pași care după această tranziție nu mai sunt necesari (de exemplu adoptarea unui noi sistem de CRM prin copierea și adaptarea datelor din vechiul sistem).
Hewlett-Packard a dezvoltat un alt mod de categorisire a requirementurilor iar pentru o mai ușoară ținere minte poți folosi acronimul FURPS (sau FURPS+) care vine de la:
- Functionality – ce vrea clientul
- Usability – cât de ușor folosibil este software-ul din punct de vedere al end-userilor: destul de arătos, destul de documentat modul de folosire.
- Reliability – ce înseamnă acceptabil ca perioadă de downtime, cât de rar/des rezultatele sunt corecte, dacă aplicația crapă cât de repede, ușor își revine și care e controlul daunelor.
- Performance – cât de rapid trebuie să fie produsul, câte cereri suportă pentru procesare, ce response time are overall, cât de mult spațiu/memorie ocupă
- Supportability – cât de ușor este de menținut și dezvoltat aplicația, e testabilă, configurabilă, extensibilă, monitorizată
Pentru FURPS+ se mai adaugă câteva tipuri
- Design Constaints – se referă la limitări și condiții pe care clientul le poate avea referitor la tehnologii, timp, buget, hardware și sisteme de operare pe care să ruleze
- Implementation Requirements – condiții referitoare la anumite standarde dorite (TDD, BDD, etc), componente thrid party ce trebui folosite, platforme suportate și limbaje de programare
- Interface Requirements – scheme de culori, layout-uri, rezoluții, shortcuturi de tastatură, funcții speciale pentru persoane cu dizabilități, traduceri
- Physical Requirements – cum să arate device-urile, greutate. Foarte probabil să nu întâlnești în munca ta astfel de requirement-uri iar dacă faci web development cu atât mai mult.
Nu fi egoist, dă mai departe să ajungă la tot poporul
