techIT.ro Do we have a problem? Let's tech it!    












Daca ai impresia ca educatia e scumpa,
atunci încearca sa vezi cum e ignoranta.
Andy McIntyre









Home  |  Dictionar IT  |  Download  |  Forum  |  Despre noi  |  Contact

Tipuri de informaţii primite de la client

În şedinţele de analiză cu reprezentanţii clientului, analistul este moderatorul discuţiei. El trebuie să aibă în permanenţă controlul asupra derulării şedinţei, pe care trebuie să o considere o resursă preţioasă – de aici vin informaţiile pentru dezvoltarea specificaţiei şi tot de aici vine feed-back-ul pentru validarea lor.

Să menţii controlului asupra derulării şedinţei înseamnă, nu numai să ai abilităţi de moderator, dar şi să ştii unde te afli în orice moment şi încotro vrei să îndrepţi lucrurile. În acest capitol vom vedea ce tipuri de informaţii ne transmite clientul, ceea ce ne arată în orice moment al discuţiei unde ne aflăm şi dacă trebuie să insistăm pentru a avea mai multă informaţie sau, dimpotrivă, dacă trebuie să redirecţionăm discuţia către altceva.


Tipurile de informaţii furnizate de clienţi sunt:

1. Cerinţe de business

Cerinţe de business sunt cerinţe de nivel înalt, importante pentru Analiză. Aceste cerinţe de business pot fi, de exemplu, legate de "reducerea stocurilor", "retenţia clienţilor", "îmbunătăţirea cash-flow-ului" şi sunt independente se sistemul informatic, în sensul că sistemul informatic poate fi una dintre multiplele soluţii ale acelei probleme. Aceste cerinţe sunt, mai degrabă, răspunsuri la întrebarea "De ce se investesc bani în acest sistem informatic?".

2. Scenarii de business, task-uri

Pentru majoritatea utilizatorilor viitorului sistem este cel mai uşor să îşi exprime cerinţele vorbind despre propriile lor task-uri şi despre modalităţile în care îşi rezolvă problemele. Analistul nu trebuie să uite niciodată întrebările: "Care sunt sarcinile dumneavoastră, care sunt out-put-urile activităţii dumneavoastră şi cum este evaluată această activitate?", "Cum rezolvaţi problema X în prezent?". Exprimarea acestor cerinţe ia forma unor Use Case-uri simplificate care conduc la rezolvarea task-ului. Se prezintă modul în care lucrurile se întâmplă în prezent sau cum trebuie să se întâmple în viitor, în urma automatizării unor paşi.

3. Reguli de business (business rules)

Aceste cerinţe exprimă nişte constrângeri existente în derularea task-urilor de business. Acestea indică cine şi în ce condiţii poate face un anumit lucru.
De exemplu, dacă se negociază valoarea unui contract şi aceasta este mai mică de 1000 de EURO, persoana responsabilă de negociere este Agentul de vânzare iar dacă valoarea probabilă depăşeşte 1000 de EURO, persoana responsabilă de negociere este Managerul de vânzări.
Unele dintre aceste reguli se transformă în cerinţe pentru sistemul informatic, altele rămân la nivelul procedurilor de lucru interne ale clientului.

4. Cerinţe funcţionale

Cerinţele funcţionale exprimă cât se poate de direct modul de interacţiune al utilizatorului cu sistemul. Deşi interacţiunea utilizator-sistem nu poate lipsi total din discuţii (mai ales dacă este preconizat ca noul sistem să schimbe anumite procese ale clientului), este absolut necesar ca toate aceste cerinţe să fie bine justificate – analistul trebuie să se asigure că aceste cerinţe au o raţiune de a fi, extrem de clară.
Cerinţele funcţionale, aşa cum sunt documentate în specificaţie, trebuie să fie rezultatul procesului de analiză şi dezvoltare a cerinţelor, nu sugestiile primite de la client în mod direct ca propuneri de soluţii.

5. Atribute de calitate

Îndeplinirea task-urilor de business va depinde în mare măsură, după apariţia sistemului informatic, şi de capacitatea acestuia de a răspunde, nu doar prin existenţa funcţiilor ci şi prin disponibilitatea acestora şi corectitudinea modului în care rezolvă cerinţele.
La acest tip de cerinţă, există în permanenţă riscul de a fi precizate vag sau incomplet. De pildă, este insuficient să se spună că sistemul trebuie să meargă "cât mai repede posibil", "fără erori" sau "să fie disponibil cât mai mult timp".

De asemenea este important de precizat că aceste cerinţe, duse la extremă ("sistemul va funcţiona 24 de ore din 24, fără întreruperi", "sistemul va funcţiona fără erori", "timpul de răspuns nu va depăşi o secundă chiar dacă sunt conectaţi toţi cei 1000 de angajaţi simultan şi operează documente sau rulează orice rapoarte") înseamnă costuri pe care un buget obişnuit nu le poate suporta şi care, de obicei, sunt nejustificate.
Atributele de calitate sunt cerinţe de tipul cerinţe nefuncţionale.

6. Constrângeri externe

Aici am inclus toate constrângerile impuse de interfaţarea sistemului cu alte sisteme externe, dispozitive sau echipamente externe (case de marcat, cititoare de coduri de bare), constrângeri de tehnologie (clientul doreşte să folosească o anumită tehnologie), formate de date, configuraţii hardware, reţele sau mijloace de comunicare speciale, fără ca lista să se limiteze la acestea.
Analistul trebuie să se asigure că nu introduce restricţii nejustificate, de nici un fel. Orice asemenea constrângeri conduc la limitarea posibilităţilor de alegere în faza de concepere a soluţiei.
Constrângerile externe sunt cerinţe de tipul cerinţe nefuncţionale.

7. Structuri de date (data definition)

Modul în care sunt definite anumite entităţi, atributele acestora cu restricţiile posibil de aplicat, sunt cerinţe obişnuite care trebuie preluate şi incluse în specificaţie, în mod normal într-o secţiune aparte, denumită dicţionar de date.
În felul lor, aceste cerinţe sunt tot nişte constrângeri. Ele sunt de genul: "câmpul X este de tipul Y, cu limitele a şi b".

8. Posibile soluţii

Cu voia dumneavoastră, ultima pe listă, se află posibilele soluţii. Deşi ultima pe listă, acest tip de cerinţă exprimată de clienţi, se insinuează foarte adesea în miezul discuţiei şi capătă ponderea cea mai mare. Posibilele soluţii trebuie tratate ca nişte sugestii (şi tratate cu atenţie pentru că sunt venite din parte unor persoane care nu sunt specialişti în software), nu ca nişte cerinţe reale.
Oricât de bune idei ar părea, aceste posibile soluţii pot ascunde viitoare dezvoltări care nu sunt necesare sau pot conduce la ratarea unor cerinţe reale. Întotdeauna trebuie testată raţiunea de a fi a unei asemenea cerinţe.

techit.ro





Colecţia:  Analiza cerinţelor software

Articolul precedent:  Realizarea interviurilor la client
Articolul următor:  Semnarea specificaţiilor software



  


  Adauga un comentariuSpune-ti parerea despre acest articol!