Câteva greșeli în documentarea cerințelor - stadopedia

Opțiuni pentru formalizarea cerințelor

În general, cerințele ca atare sunt unele abstractizări. În practică, ele există întotdeauna sub forma unei reprezentări - a unui document, a unui model, a unei specificări formale, a unei liste etc. Cerințele sunt importante ca atare, pentru că se termină în formă de a înțelege nevoile clientului și dezvoltatorii viitorilor utilizatori ai sistemului creat. Dar, deoarece există multe aspecte diferite, tipuri de activitate și faze de dezvoltare într-un proiect software, această înțelegere poate avea opinii foarte diferite. Fiecare cerințele de depunere efectuează o sarcină specifică, de exemplu, servește ca un acorduri de fixare „punte“ între diferite grupuri de profesioniști sau utilizate pentru gestionarea operațională a proiectului (pentru a viziona în care punerea în aplicare de fază este o cerință specială, care este responsabil pentru ea, și așa mai departe.); Or Este folosit pentru verificare și testare orientată spre model. Și, în primul și în al doilea și al treilea exemplu, avem de a face cu cerințele, dar ele vor fi formalizate în diferite moduri.







Astfel, formalizarea cerințelor proiectului pot fi foarte diferite - depinde de valoarea procesului de proiectare a primit, instrumentele utilizate, precum și acele sarcini care rezolvă cerințele formale. În plus, pot exista mai multe formalizări paralele care rezolvă diferite probleme. Luați în considerare opțiunile.

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 acestuia, 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 (Enterprise Architect). 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.

Modelul cerințelor formale pentru verificare, testarea orientată spre model, etc.

Fiecare modalitate de prezentare a reclamațiilor trebuie să răspundă la următoarele întrebări:

- cine este utilizatorul (utilizatorul) acestei vizualizări;

- exact cum (în ce scop) este folosit acest punct de vedere.

Să enumerăm o serie de greșeli care apar la elaborarea sarcinilor tehnice și a altor documente cu cerințe.

1) Descrierea soluțiilor posibile în locul cerințelor.

2) cerințe fuzzy care nu permit un test lipsit de ambiguitate, nerostite stânga, au sfaturi umbra, discuții, recomandări, „Poate că are sens să pună în aplicare un bine ... ..“, „etc“.

3) Ignorarea publicului pentru care se intenționează prezentarea cerințelor. De exemplu, în cazul în care caietul de sarcini al inginerului de client, se constată adesea o supra-abundență de informații cu privire la echipamentul, care trebuie să funcționeze sistem software nu este un glosar de termeni și definiții ale conceptelor de bază, utilizate numeroase sinonime, etc. Sau există prea multă părtinire față de programare, ceea ce face ca această specificație să nu fie înțeleasă pentru toți cei care nu sunt programatori.

4) Lipsesc aspecte importante legate de cerințele nefuncționale, în special, informații despre mediul sistemului, despre momentul de pregătire a altor sisteme cu care ar trebui să interacționeze acest sistem. Aceasta din urmă se întâmplă, de exemplu, atunci când acest sistem software face parte dintr-un proiect mai amplu. Probleme tipice când se creează sisteme software și hardware, atunci când echipamentul nu are timp la timp și software-ul nu poate fi testat, iar în termeni și cerințe acest lucru nu este furnizat.







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: