Analiza cerințelor software cu exemplu
De exemplu, în contextul aplicației bancare, cerința funcțională va fi atunci când clientul selectează „Vedeți soldul” trebuie să poată vedea cel mai recent sold al contului.
Cerința software poate fi, de asemenea, o cerință nefuncțională, poate fi o cerință de performanță. De exemplu, o cerință nefuncțională este aceea în care fiecare pagină a sistemului ar trebui să fie vizibilă pentru utilizatori în 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 ca declarații.
Tipuri de cerințe
- Cerințe de afaceri: Sunt cerințe de nivel înalt care sunt preluate din cazul de afaceri din proiecte. De exemplu, un sistem de servicii bancare mobile oferă servicii bancare în Asia de Sud-Est. Cerința de afaceri care este decisă pentru India este rezumatul contului și transferul de fonduri, în timp ce pentru China rezumatul contului și plata facturii sunt hotărâte ca o cerință comercială
Ț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 proiectare: Aceste cerințe sunt mai detaliate decât cerințele de afaceri. Determină designul general necesar pentru a implementa cerințele de afaceri. Pentru organizația noastră educațională, cazurile de utilizare arhitecturale și de design ar fi autentificarea, detaliile cursului etc. Cerința ar fi așa cum se arată 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 Facilitatea de plată.
Clientul va putea vedea un tablou de bord cu facturile restante ale facturatorilor înregistrați. El poate adăuga, modifica și șterge un detaliu de facturator. Clientul poate configura SMS-uri, alerte prin e-mail pentru diferite acțiuni de facturare. El poate vedea istoricul facturilor plătite anterioare. Actorii care pornesc acest caz de utilizare sunt clienții băncii sau personalul de asistență. |
- Cerințe de sistem și integrare: La cel mai de jos nivel, avem cerințe de sistem și de integrare. Este o descriere detaliată a fiecărei cerințe. Poate fi sub formă de povești ale utilizatorilor care descriu într-adevăr limbajul de afaceri de zi cu zi. Cerințele sunt în detalii abundente, astfel încât dezvoltatorii să poată începe codificarea. Aici, de exemplu Bill Modul de plată în care se va menționa cerințele pentru adăugarea unui Biller
Bill Plată | Cerinţe |
---|---|
Adăuga Billers |
|
Uneori, pentru un anumit proiect, este posibil să nu primiți cerințe sau documente cu care să lucrați. Dar totuși există și alte surse de cerințe pe care le puteți lua în considerare pentru cerință sau informații, astfel încât să vă puteți baza software-ul sau proiectarea de testare pe aceste cerințe. Deci, celelalte surse de cerință pe care vă puteți baza sunt
Alte surse de cerințe
- Transferul de cunoștințe de la colegii sau angajații care lucrează deja la acel proiect
- Vorbiți despre proiect cu analist de afaceri, manager de produs, lider de proiect și dezvoltatori
- Analizați versiunea anterioară a sistemului care este deja implementată în sistem
- Analizați documentul de cerințe mai vechi al proiectului
- Uitați-vă la rapoartele de erori din trecut, unele dintre rapoartele de erori sunt transformate în cereri de îmbunătățire care pot fi implementate în versiunea actuală
- Consultați ghidul de instalare dacă este disponibil pentru a vedea care sunt instalarea necesară
- Analizați cunoștințele de domeniu sau industrie pe care echipa încearcă să le implementeze
Indiferent de sursa de cerință pe care o obțineți, asigurați-vă că le documentați într-o formă oarecare, consultați-le de la alți membri ai echipei cu experiență și cunoștințe.
Cum se analizează cerințele
Luați în considerare un exemplu de sistem software educațional în care un student se poate înregistra la diferite cursuri.
Să studiem cum să analizăm cerințele. Cerințele trebuie să mențină o calitate standard a cerinței sale, diferite tipuri de cerințe de calitate includ
- Atomic
- Identificat unic
- Completa
- Consecvent și lipsit de ambiguitate
- Trasabil
- Prioritizat
- Testabil
Să înțelegem asta cu un exemplu, există trei coloane în tabelul prezentat aici,
- Prima coloană indică „calitate cerință”
- A doua coloană indică „cerință necorespunzătoare cu o problemă”
- A treia coloană este la fel ca a doua coloană, dar – „convertită într-o cerință bună”.
Cerință Calitate | Exemplu de cerință proastă | Exemplu de cerință bună |
---|---|---|
Atomic |
|
|
Identificat unic | 1- Studenții se vor putea înscrie la cursuri de licență1- 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 |
Trasabil | 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 1Păstrarea informațiilor despre utilizator-Prioritate 1Înscriere la cursuri-Prioritate 1Vizualizare buletin-Prioritate 1 | Înregistrare student-Prioritate 1Păstrarea informațiilor despre utilizator-Prioritate 2Înscriere la cursuri-Prioritate 1Vizualizare bilanț-Prioritate3 |
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 |
Acum să înțelegem fiecare dintre aceste cerințe în detalii, începând cu AtomIC.
Atomic
Deci, fiecare cerință pe care o aveți ar trebui să fie atomică, ceea ce înseamnă că ar trebui să fie la un nivel foarte scăzut de detalii, nu ar trebui să fie posibil să fie separate în componente. Aici vom vedea cele două exemple pentru cerințe, la Atomniveluri de cerințe ic și identificate în mod unic.
Deci, să continuăm cu exemplul de construire a sistemului pentru domeniul educațional. Aici, cerința proastă este „Studenții se vor putea înscrie la cursuri universitare și postuniversitare”. Aceasta este o cerință proastă, deoarece nu este atomică, deoarece vorbește despre două entități diferite, cursuri de licență și postuniversitare. Deci, evident, nu este o cerință bună, ci o cerință proastă, așa că o cerință bună a corespondenței ar fi să o separați în două cerințe. Deci unul vorbește despre înscrierea la cursurile de licență în timp ce celălalt vorbește despre înscrierea la cursurile postuniversitare.
Identificat unic
În mod similar, următoarea cerință de calitate este să verificăm identificarea unic, aici avem două cerințe separate, dar ambele au același ID#1. Deci, dacă ne referim la cerința noastră cu referire la ID#, dar nu este clar la ce cerință exactă ne referim la document sau la altă parte a sistemului, deoarece ambele au același ID#1. Deci, separând cu ID-uri unice, cerința atât de bună va fi returnată ca secțiunea 1 - înscrieri la cursuri și are două cerințe 1.1 id este înscrierea la cursuri de licență, în timp ce 1.2 id este înscrierea la cursuri postuniversitare.
Completa
De asemenea, fiecare cerință ar trebui să fie completă. De exemplu, aici cerința proastă spune că „un utilizator profesor se va conecta în sistem furnizând numele său de utilizator, parola și alte informații relevante”. Aici, celelalte informații relevante nu sunt clare, astfel încât celelalte informații relevante ar trebui specificate în condiții bune pentru a completa cerința.
Consecvent și fără ambiguitate
În continuare, fiecare cerință ar trebui să fie consecventă și lipsită de ambiguitate, deci aici, de exemplu, avem cerințe „Un student va avea fie cursuri universitare, fie cursuri postuniversitare, dar nu ambele” aceasta este o cerință, există o altă cerință care spune „Unele cursuri vor avea să fie deschisă atât studenților de licență, cât și studenților postuniversitari”.
Problema în această cerință este că din prima cerință se pare că cursurile sunt împărțite în două categorii sub cursuri postuniversitare și cursuri postuniversitare iar studentul poate opta pe oricare dintre două, dar nu pe ambele. Dar când citiți o altă cerință, aceasta intră în conflict cu prima cerință și vă spune că unele cursuri se vor deschide atât pentru studii postuniversitare, cât și pentru licență.
Deci, este evident să convertiți această cerință proastă într-o cerință bună, care este „Un student va avea fie cursuri universitare, fie cursuri postuniversitare, dar nu ambele”. Ceea ce înseamnă că fiecare curs va fi marcat fie ca curs universitar, fie ca curs postuniversitar
Trasabil
Fiecare cerință ar trebui să fie urmăribilă pentru că deja există diferite niveluri de cerință, deja am văzut că la vârf aveam cerințe de business, iar apoi avem o cerință de arhitectură și proiectare urmată de cerințe de integrare a sistemului.
Acum, când transformăm cerințele de afaceri în cerințe arhitecturale și de proiectare sau transformăm cerințele arhitecturale și de proiectare în cerințe de integrare a sistemului, trebuie să existe trasabilitate. Ceea ce înseamnă că ar trebui să fim capabili să luăm toate cerințele de afaceri și să le mapam la una sau mai multe cerințe de arhitectură și design software corespunzătoare. Așadar, iată un exemplu de cerință proastă care spune „Menține informațiile despre elev – mapate la ID-ul solicitării BRD?” id-ul cerinței nu este dat aici.
Deci, convertind-o într-o cerință bună, spune același lucru, dar este mapat cu id-ul cerinței 4.1. Deci cartografierea ar trebui să existe pentru fiecare cerință. În același mod, avem cerințe de mapare de nivel înalt și de nivel scăzut, maparea este, de asemenea, între cerința de sistem și de integrare la codul care implementează acea cerință și, de asemenea, există o mapare între cerința de sistem și de integrare la cazul de testare care testează acea cerință specială. .
Deci, această trasabilitate este pe întregul proiect
Prioritizat
Prioritizat | Student înscris-Prioritate 1 Menține informațiile utilizatorului - Prioritatea 1 Inscrie-te la cursuri - Prioritatea 1 Vizualizați raportul-Prioritate 1 |
Înregistrare Student-Prioritate 1 Menține informațiile utilizatorului - Prioritatea 2 Inscrie-te la cursuri - Prioritatea 1 Vizualizați raportul-Prioritate3 |
Apoi, fiecare cerință trebuie să fie prioritizată, astfel încât echipa să aibă linii directoare, astfel încât ce cerință poate fi implementată mai întâi și care poate fi făcută mai târziu. Aici puteți vedea prioritatea proastă a înregistrării studenților, menținerea informațiilor despre utilizator și fiecare cerință a acordat prioritate-1. Totul nu poate fi la aceeași prioritate, așa că cerințele pot fi prioritizate. Deci exemplul de cerință bună de aici este înregistrarea studentului și cursurile de înscriere au cea mai mare prioritate 1, în timp ce menținerea informațiilor despre utilizator este mai jos la prioritatea 2 și apoi avem vizualizarea raportului la prioritatea-3
Testabil
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 |
Fiecare cerință ar trebui să fie testabilă, aici cerința proastă este „fiecare pagină a sistemului se va încărca într-un interval de timp acceptabil”. Acum, există două probleme cu această cerință, în primul rând, că fiecare pagină înseamnă că pot exista multe pagini, ceea ce va face să arunce în aer eforturile de testare. Cealaltă problemă este că se spune că pagina se va încărca într-un interval de timp acceptabil, acum care este intervalul de timp acceptabil? Acceptabil pentru cine. Așadar, trebuie să convertim argumentul netestabil într-un argument testabil, care spune în mod specific despre ce pagină vorbim „înregistrează student și înrolează paginile cursurilor” și este dat și intervalul de timp acceptabil care este de 5 secunde.
Concluzie
Deci, așa trebuie să privim fiecare cerință la nivelul corespunzător. De exemplu, dacă vom construi un software în ceea ce privește cerințele de sistem și de integrare. Trebuie să ne uităm la cerințele de sistem și de integrare date în specificațiile cerințelor software sau în poveștile utilizatorilor și să aplicăm fiecărei cerințe de calitate. Apoi verificați dacă fiecare cerință este atomică, identificată în mod unic și completă și așa mai departe.