Formalizarea cerințelor în proiect poate fi foarte diferită - depinde de mărimea acesteia, de procesul de dezvoltare adoptat, de instrumentele utilizate și, de asemenea, de sarcinile care sunt rezolvate prin cerințe formalizate.
- Declarație neoficială a cerințelor în corespondență prin e-mail. Funcționează bine în proiecte mici, cu implicarea clientului în dezvoltare (de exemplu, echipa efectuează subcontractarea). Este, de asemenea, bun la acest stil, atunci când există înțelegere reciprocă între client și echipa, adică formalitățile inutile nu sunt necesare. Cu toate acestea, e-mailurile dintr-o astfel de situație se dovedesc a fi adesea documente importante - este important să puteți efectua corespondența de afaceri, să rezumați, să păstrați scrisori importante și să le folosiți pentru dezacorduri. De asemenea, este important să înțelegem în timp când această metodă încetează să mai funcționeze și sunt necesare abordări formale.
- Cerințe sub forma unui document - o descriere a zonei subiectului și a proprietăților sale, termenii de referință ca anexă la contract, o specificație funcțională pentru dezvoltatori etc.
- Cerințe sub forma unui grafic cu dependențe într-unul din mijloacele de susținere a cerințelor (IBM Rational RequisitePro, DOORS, Borland CaliberRM și altele). O astfel de reprezentare este convenabilă pentru schimbări frecvente în cerințe, atunci când se urmărește îndeplinirea cerințelor, atunci când se organizează "legarea" cerințelor de sarcini, oameni, teste, cod. De asemenea, este important să puteți crea cu ușurință astfel de grafice din documentele text și invers, pentru a crea documente de prezentare pentru astfel de grafice.
- Cerințe formale de model pentru verificare. modelare orientată spre model, etc.
Articole similare
Trimiteți-le prietenilor: