Analiza cerințelor software cu exemplu
Charles Moore
⚡ Rezumat inteligent
Analiza cerințelor software împarte nevoile părților interesate în declarații funcționale și nefuncționale, le clasifică la nivel de business, arhitectural și de sistem, apoi verifică fiecare în raport cu atributele de calitate pentru a garanta o calitate testabilă. tracspecificație facilă și prioritizată.
O cerință software este o nevoie funcțională sau nefuncțională care trebuie implementată în sistem. Funcțional înseamnă furnizarea unui anumit serviciu utilizatorului.
De exemplu, în contextul unei aplicații bancare, cerința funcțională este ca, atunci când un client selectează „Vizualizare sold”, să poată vizualiza cel mai recent sold al contului său.
O cerință software poate fi, de asemenea, nefuncțională, cum ar fi o cerință de performanță. De exemplu, o cerință nefuncțională ar putea stabili că fiecare pagină a sistemului ar trebui să se încarce pentru utilizatori în termen de 5 secunde.
Deci, practic cerința software este a
- Funcțional sau
- Nefuncțional
nevoie care trebuie implementat în sistem. Cerințele software sunt de obicei exprimate sub formă de declarații.
Tipuri de cerințe
Cerințe de afaceriAcestea sunt cerințe de nivel înalt preluate din studiul de caz pentru proiect. De exemplu, un sistem de servicii bancare mobile oferă servicii bancare în Asia de Sud-Est. Cerința de afaceri decisă pentru India este rezumatul contului și transferul de fonduri, în timp ce pentru China este rezumatul contului și plata facturilor.
| Țară | Companie care furnizează Funcționalități sau servicii bancare |
|---|---|
| India | Rezumatul contului și transferul de fonduri |
| China | Rezumatul contului și Bill Plată |
Archicerințele tehnice și de proiectareAceste cerințe sunt mai detaliate decât cerințele de business și determină arhitectura soluției. Ele determină designul general necesar pentru implementarea cerințelor de business. Pentru o organizație educațională, cazurile tipice de utilizare arhitecturală și de design includ autentificarea, detaliile cursului și înscrierea. Cerința ar fi prezentată mai jos.
| Caz de utilizare bancar | Cerinţă |
|---|---|
| Bill Plată | Acest caz de utilizare descrie modul în care un client se poate conecta la net banking și poate utiliza Bill Facilitate de plată. Clientul poate vedea un tablou de bord cu facturile restante pentru emitenții de facturi înregistrați. Clientul poate adăuga, modifica și șterge detaliile unui facturant. Clientul poate configura alerte SMS și e-mail pentru diferite acțiuni de facturare. Clientul poate vizualiza un istoric al facturilor plătite în trecut. Actorii care inițiază acest caz de utilizare sunt clienții băncii sau personalul de asistență. |
Cerințe de sistem și integrareLa cel mai scăzut nivel, avem cerințe de sistem și de integrare. Acesta oferă o descriere detaliată a fiecărei cerințe. Acestea pot fi surprinse sub formă de povești ale utilizatorilor scrise în limbaj de afaceri obișnuit. Cerințele conțin detalii abundente, astfel încât dezvoltatorii să poată începe să programeze. Bill Exemplul de modul de plată de mai jos arată cerința pentru adăugarea unui facturator.
| Bill Plată | Cerinţe |
|---|---|
| Adăuga Billers | Numele furnizorului de utilități, numărul clientului relație, plăți automate – Da/Nu, plată integrală Bill – Da/Nu, Limită de plată automată – Nu plătiți dacă Bill este peste suma specificată |
Uneori, pentru un proiect, este posibil să nu primiți cerințe sau documente cu care să lucrați. Chiar și așa, există și alte surse de informații despre cerințe pe care vă puteți baza pentru a vă baza software-ul sau designul de testare. Celelalte surse de cerințe pe care vă puteți baza sunt enumerate mai jos.
Alte surse de cerințe
- Transferul de cunoștințe de la colegii sau angajații care lucrează deja la acel proiect
- Discutați proiectul cu analistul de afaceri, managerul de produs, liderul de proiect și dezvoltatorii
- Analizați versiunea anterioară a sistemului deja implementată
- Analizați documentele de cerințe mai vechi din proiect
- RevVizualizați rapoartele de erori anterioare; unele rapoarte de erori sunt convertite în solicitări de îmbunătățire care pot fi implementate în versiunea curentă
- Verificați ghidul de instalare, dacă este disponibil, pentru a vedea ce instalații sunt necesare
- Analizați cunoștințele din domeniu sau industrie pe care echipa încearcă să le implementeze
Indiferent de sursa de cerințe pe care o utilizați, documentați-le într-un format comun și solicitați revizuirea lor de către membri experimentați ai echipei.
Cum se analizează cerințele
Luați în considerare exemplul unui sistem software educațional în care un student se poate înscrie la diferite cursuri.
Să studiem cum se analizează cerințele. Fiecare cerință trebuie să mențină un set de atribute standard de calitate, care includ următoarele:
- Atomic
- Identificat unic
- Completa
- Consecvent și lipsit de ambiguitate
- Traccapabil
- Prioritizat
- Testabil
Următorul tabel ilustrează fiecare atribut cu trei coloane:
- Prima coloană indică „calitate cerință”
- A doua coloană indică „cerință necorespunzătoare cu o problemă”
- A treia coloană arată aceeași cerință „convertită într-o cerință bună”.
| Cerință Calitate | Exemplu de cerință proastă | Exemplu de cerință bună |
|---|---|---|
| Atomic | Studenții se vor putea înscrie la cursuri de licență și postuniversitare | Studenții se vor putea înscrie la cursuri de licență. Studenții se vor putea înscrie la cursuri postuniversitare. |
| Identificat unic | 1- Studenții se vor putea înscrie la cursuri de licență. 1- Studenții se vor putea înscrie la cursuri postuniversitare. | Înscrierea la cursuri. Studenții se vor putea înscrie la cursuri de licență. Studenții se vor putea înscrie la cursuri postuniversitare. |
| Completa | Un utilizator profesor se va conecta în sistem furnizând numele său de utilizator, parola și alte informații relevante | Un utilizator profesor se va autentifica în sistem furnizând numele său de utilizator, parola și codul de departament |
| Consecvent și lipsit de ambiguitate | Un student va avea fie cursuri universitare, fie cursuri postuniversitare, dar nu ambele. Unele cursuri vor fi deschise atât pentru studii universitare, cât și pentru cele postuniversitare | Un student va avea fie licență, fie absolvenți postuniversitari, dar nu ambele |
| Traccapabil | Păstrați informațiile despre studenți mapate la BRD req.ID? | Menține informațiile despre studenți-Cartografiate la ID-ul solicitat BRD 4.1 |
| Prioritizat | Student înregistrat - Prioritate 1. Menținerea informațiilor utilizatorului - Prioritate 1. Înscrierea la cursuri - Prioritate 1. Vizualizare fișă de raport - Prioritate 1 | Înregistrare student - Prioritate 1. Menținerea informațiilor utilizator - Prioritate 2. Înscriere cursuri - Prioritate 1. Vizualizare fișă de raport - Prioritate 3 |
| Testabil | Fiecare pagină a sistemului se va încărca într-un interval de timp acceptabil | Înregistrarea studenților și înscrierea cursurilor paginile sistemului se vor încărca în 5 secunde |
Să înțelegem fiecare dintre aceste atribute mai detaliat, începând cu AtomIC.
Atomic
Fiecare cerință ar trebui să fie atomică, adică trebuie să fie la cel mai scăzut nivel de detaliu și nu poate fi defalcată în componente. Următoarele exemple compară cerințele atomice și cele neatomice.
Continuând cu exemplul sistemului din domeniul educației: Aici, cerința nepotrivită este „Studenții vor putea să se înscrie la cursuri de licență și postuniversitare”. Aceasta este o cerință nepotrivită deoarece nu este atomică - combină două entități diferite, cursuri de licență și postuniversitare. Cerința bună corespunzătoare o separă în două cerințe. O cerință acoperă înscrierea la cursuri de licență, iar cealaltă acoperă înscrierea la cursuri postuniversitare.
Identificat unic
Următorul atribut de calitate este identificarea unică. În exemplul negativ, două cerințe separate au același ID#1. Dacă o echipă face referire la o cerință prin ID-ul său, devine neclar care dintre cele două este vorba. Cerința bună le regrupează în Secțiunea 1 — Înscrierea la cursuri, cu subcerințele 1.1 (înscrierea la cursuri de licență) și 1.2 (înscrierea la cursuri postuniversitare).
Completa
Fiecare cerință ar trebui să fie completă. De exemplu, aici cerința greșită spune că „un profesor se va conecta la sistem furnizând numele de utilizator, parola și alte informații relevante”. „Alte informații relevante” este vag. O cerință completă listează câmpurile exacte, cum ar fi codul departamentului, pe care profesorul trebuie să le furnizeze.
Consecvent și fără ambiguitate
Fiecare cerință ar trebui să fie consecventă și lipsită de ambiguitate. În exemplul negativ, o cerință prevede „Un student va avea fie cursuri de licență, fie cursuri postuniversitare, dar nu ambele”, în timp ce o alta prevede „Unele cursuri vor fi deschise atât studenților de licență, cât și celor de masterat”.
Prima cerință implică împărțirea cursurilor în două categorii exclusive, dar a doua cerință o contrazice prin deschiderea unor cursuri pentru ambele grupuri.
Cerința „bună” rezolvă conflictul prin precizarea clară a faptului că fiecare curs este marcat fie ca licență, fie ca studii postuniversitare, iar un student se poate înscrie doar la cursuri dintr-o singură categorie.
Traccapabil
Fiecare cerință trebuie să fie tracposibil deoarece cerințele există la mai multe niveluri: de afaceri, arhitectural și de design, precum și de sistem și integrare.
Când convertiți o cerință de afaceri în cerințe arhitecturale și de design sau cerințe arhitecturale și de design în cerințe de sistem și integrare, tracEficacitatea trebuie menținută. Fiecare cerință de business ar trebui să fie corelată cu una sau mai multe cerințe arhitecturale și de design. În exemplul greșit „Mențineți informațiile despre studenți – corelate cu ID-ul cerinței BRD?”, ID-ul cerinței lipsește.
Cerința bună înregistrează aceeași declarație, dar se mapează explicit la cerința BRD ID 4.1. Fiecare cerință trebuie să conțină un trachartă de posibilitatepingCerințele de sistem și de integrare ar trebui să fie, de asemenea, corelate cu codul care le implementează și cu cazurile de testare care le verifică.
TracPrin urmare, ebilitatea se desfășoară de la un capăt la altul al proiectului.
Prioritizat
Fiecare cerință trebuie prioritizată, astfel încât echipa să știe ce să implementeze mai întâi și ce poate aștepta. În exemplul negativ, opțiunile Înregistrare student, Menținere informații utilizator, Înscriere cursuri și Vizualizare raport sunt toate setate la Prioritatea 1. Nu se poate ca nimic să aibă Prioritatea 1, așa că cerințele trebuie clasificate realist. Exemplul bun acordă opțiunilor Înregistrare student și Înscriere cursuri cea mai mare Prioritate 1, Menținere informații utilizator Prioritate 2 și Vizualizare raport Prioritate 3.
Testabil
Fiecare cerință ar trebui să fie testabilă. Exemplul negativ, „fiecare pagină a sistemului se va încărca într-un interval de timp acceptabil”, nu este testabil din două motive. În primul rând, „fiecare pagină” poate însemna zeci de pagini, ceea ce suprasolicită efortul de testare. În al doilea rând, „intervalul de timp acceptabil” este nedefinit - acceptabil pentru cine și în funcție de ce criteriu de referință? Cerința bună rezolvă ambele probleme prin denumirea paginilor specifice („paginile de înregistrare a studenților și de înscriere la cursuri”) și prin stabilirea unei ținte măsurabile de 5 secunde.
