what is requirement analysis
Acest tutorial explică ce este analiza cerințelor, pașii de analiză a cerințelor, exemple și obiectivele colectării cerințelor în SDLC:
Dezvoltarea software-ului este o sarcină imensă care creează un produs software funcțional.
Produsul software este construit conform cerințelor clientului. În cea mai mare parte, acest produs software respectă ceea ce se aștepta clientul / utilizatorul final, în timp ce uneori acest produs nu respectă în totalitate ceea ce se așteptase clientul / utilizatorul final.
Ce veți învăța:
Ce este analiza cerințelor?
Să înțelegem analiza cerințelor cu ajutorul unui exemplu.
Așteptările clientului / utilizatorului final:
Clientul / utilizatorul final primesc:
După cum puteți analiza din imaginile de mai sus, există o nepotrivire între produsul final și așteptările clienților. Acest lucru s-ar putea datora unor nenumărate motive, și anume. implementarea incorectă a cerințelor clienților, proiectarea defectuoasă, o înțelegere greșită a cerințelor clienților de către programatori și echipa de calitate etc.
Cu toate acestea, după cum puteți vedea, indiferent dacă este un motiv pentru livrarea greșită a produsului, motivul principal se referă la cerință. Prin urmare, dacă s-ar face înțelegerea, capturarea, implementarea și testarea corectă a cerințelor, ar fi contribuit la atenuarea livrării eronate și incomplete a produsului către client / utilizator final.
O livrare bună a produsului necesită colectarea corectă a cerințelor, examinarea eficientă a cerințelor colectate și, în cele din urmă, o documentație clară a cerințelor, ca condiție prealabilă. Acest întreg proces este, de asemenea, numit ca Analiza cerințelor în ciclul de viață al dezvoltării software-ului (SDLC)
Etape / pași de analiză a cerințelor
După cum puteți vedea, Analiza cerințelor este prima activitate din SDLC urmată de Specificații funcționale și așa mai departe. Analiza cerințelor este un pas vital în SDLC, deoarece rezonează cu testarea acceptării, care este esențială pentru acceptarea produselor de către clienți.
În acest tutorial, vom explica cum se face analiza cerințelor în SDLC. De asemenea, vom vedea diferiții pași implicați, rezultate, provocări și măsuri corective în analiza cerințelor.
Analiza cerințelor începe cu:
- Adunarea cerințelor care se mai numește și elicitare.
- Aceasta este urmată de analizand cerințele colectate pentru a înțelege corectitudinea și fezabilitatea transformării acestor cerințe într-un posibil produs.
- Și, în sfârșit, documentarea cerințele colectate.
# 1) Adunarea cerințelor
Pentru a vă asigura că toți pașii menționați mai sus sunt executați corespunzător, trebuie colectate de la client cerințe clare, concise și corecte. Clientul ar trebui să fie capabil să-și definească cerințele în mod corespunzător, iar analistul de afaceri ar trebui să fie capabil să le colecteze în același mod în care acesta intenționează să le transmită.
De multe ori nu este posibil ca colectarea cerințelor să fie realizată eficient de către analiștii de afaceri de la client. Acest lucru s-ar putea datora dependenței de mulți oameni în legătură cu produsul final, instrumentele, mediul așteptat etc. Astfel, este întotdeauna o idee bună să implicați toți factorii interesați care ar putea influența sau ar putea fi influențați de produsul final.
Grupul posibil al părților interesate ar putea fi inginerii calității software (atât QC, cât și QA), orice furnizor terț care ar putea oferi asistență în cadrul proiectului, utilizatorul final pentru care este destinat produsul, programatorii de software, o altă echipă din cadrul organizației care ar putea oferi un modul sau o platformă software, biblioteci software etc. pentru dezvoltarea produselor.
Exemplu: Într-o organizație, dezvoltă un produs ADAS (sistem de cameră surround-view pentru un OEM de prestigiu) de care are nevoie Stiva Autosar și Bootloader binare care sunt primite de la un alt furnizor.
Implicarea diferitelor părți interesate în etapa de colectare a cerințelor ajută la înțelegerea diferitelor dependențe una de cealaltă și orice posibil conflict viitor ar putea fi evitat.
Uneori, este o idee bună să creați un model prototip al produsului intenționat planificat și să îl arătați clientului. Acesta este un mod excelent de a transmite clienților ce produs așteaptă și cum poate arăta ulterior. Acest lucru îl ajută pe client să vizualizeze produsul pe care îl așteaptă și îl ajută să vină cu cerințe clare.
Această creație de prototip depinde de două tipuri de produse:
- Un produs similar pe care îl intenționau clienții, există în cadrul organizației.
- Produs nou care urmează să fie dezvoltat.
(i) În primul caz, este mai ușor să arăți clientului cum ar arăta produsul final și cum ar fi dezvoltat. În ADAS auto, este posibil să le arătați clienților un alt produs care este deja pe piață și a fost dezvoltat în cadrul organizației.
De exemplu, Un sistem de cameră surround cu vedere dezvoltat pentru un OEM (GM, Volkswagen, BMW etc.) și poate fi prezentat unui alt OEM.
Vă rugăm să rețineți , nu este înțelept să afișați produsul / produsul proto către clientul care este în curs de dezvoltare, deoarece ar putea încălca Acordul de nedivulgare semnat cu un alt client pentru care produsul respectiv este dezvoltat. De asemenea, poate duce la o confuzie juridică inutilă.
Alt exemplu ar putea fi cel al sistemului de infotainment, dezvoltat de organizație și care se află deja pe piață. Analiștii de afaceri și alte părți interesate din cadrul unei organizații pot planifica o demonstrație de atelier pentru client, afișând sisteme de infotainment cu HMI tangibil, porturi pentru conector de dispozitiv, sandbox etc.
Acest lucru îl va ajuta pe client să înțeleagă cum ar arăta produsul final și să le ofere cerințele mult mai clar.
(ii) Al doilea caz poate fi realizat prin crearea unui model de lucru de bază prin realizarea de codificare și asamblare simple (majoritatea caracteristicilor de aici sunt codificate în programe software) sau prin crearea unei diagrame sau diagrame care ar putea convinge clientul cum ar arăta produsul.
În orice caz, ar fi un suflu pentru procesul de colectare a cerințelor, întrucât clientul știe acum ce dorește.
Analistul de afaceri poate organiza acum întâlniri oficiale de solicitare a cerințelor, în care toți factorii interesați ar putea fi invitați și astfel poate nota diversele cerințe furnizate de client (în unele cazuri, dacă părțile interesate sunt mai numeroase, ar putea fi numit un scrib separat care să noteze clientul cerințele sau poveștile utilizatorilor, astfel încât analistul de afaceri să se poată concentra pe moderarea întâlnirii).
Cerințele colectate pot fi sub formă de povestirile utilizatorilor (în dezvoltare agilă), cazuri de utilizare, documente de limbaj natural ale clienților, diagrame, diagrame etc. Poveștile utilizatorilor devin populare în ciclul de viață modern al dezvoltării software-ului. Poveștile utilizatorilor sunt practic un set de intrări ale clienților în limbajul lor natural.
Exemplu de colectare a cerințelor: În sistemul de camere surround ADAS, o posibilă poveste a utilizatorului ar putea fi: „În calitate de utilizator, ar trebui să pot vedea ce este acolo în spatele mașinii mele”.
Ar putea fi multe 'De ce,' întrebări adresate cu privire la fiecare poveste a utilizatorului, care vor ajuta clientul să ofere informații mai detaliate despre cerință.
În povestea utilizatorului de mai sus, dacă un client spune „În calitate de utilizator, ar trebui să pot vedea ce este acolo în spatele mașinii mele”, punând o întrebare 'De ce 'Ar putea da' În calitate de utilizator, ar trebui să pot vedea ce este acolo în spatele mașinii mele, astfel încât să-mi pot parca mașina în siguranță ”.
Punând întrebarea 'De ce' ajută, de asemenea, la crearea de cerințe obiective și atomice din declarațiile limbajului natural oferite de client. Acest lucru poate fi ușor implementat mai târziu în cod.
cel mai bun software gratuit de rezervă pentru Windows 7 pe 64 de biți
Un alt mod de a colecta cerința este sub forma cazuri de utilizare . Un caz de utilizare este o abordare pas cu pas pentru a obține un anumit rezultat. Acest lucru nu spune cum va funcționa software-ul la intrarea utilizatorului, mai degrabă spune, ce se așteaptă de la intrările utilizatorului.
Exemplu:
# 2) Analizarea cerințelor colectate
Colectarea după cerințe, analiza cerințelor începe. În acest stadiu, diferite părți interesate stau și fac o sesiune de brainstorming. Ei analizează cerințele adunate și caută fezabilitatea implementării acestora. Ei discută între ei și orice ambiguitate este rezolvată.
Acest pas este important în procesul de analiză a cerințelor datorită următoarelor motive principale:
(i) Clientul poate furniza unele cerințe care ar putea fi imposibil de implementat din cauza diferitelor dependențe.
Exemplu: Cliențipoate solicita să vizualizați sistemul de cameră cu o funcție de cameră de spate care vă va ajuta parcare mașina. De asemenea, clientul poate solicita Remorcă caracteristică de cuplare care folosește și camera din spate pentru a funcționa.
Dacă clientul declară o cerință pentru care camera retrovizoare parcare asistența ar trebui să funcționeze oricând fără excepție, apoi Remorcă caracteristica nu ar funcționa niciodată și invers.
(ii) Un analist de afaceri ar fi putut înțelege cerința din client diferit de modul în care a programator ar fi interpretat.
Deoarece programatorii consideră experți tehnici, este întotdeauna posibil ca cerințele clienților să fie convertite incorect în specificații funcționale care ulterior vor fi făcute incorect în arhitectură și documente de proiectare și ulterior în cod. Impactul este exponențial și, prin urmare, trebuie verificat.
O posibilă măsură de remediere ar putea fi urmărirea unei metode agile de dezvoltare a software-ului, urmărirea cazurilor de utilizare oferite de client etc.
# 3) Documentarea cerințelor analizate
Odată ce analiza cerințelor este finalizată, începe documentația cerințelor. Din analiza cerințelor ies diverse tipuri de cerințe.
Unele dintre acestea sunt:
(i) Specificația cerințelor clientului.
(ii) Cerință de arhitectură software.
Exemplu:
(iii) Cerință de proiectare software.
Exemplu:
(iv) Specificația cerinței funcționale (derivată direct din specificațiile clientului.)
Exemplu: „Când utilizatorul atinge pictograma Bluetooth pe Infotainment HMI, ecranul Bluetooth ar trebui să fie afișat”
(v) Specificația cerințelor nefuncționale (și anume performanța, stresul, sarcina etc.).
Exemplu: „Ar trebui să fie posibilă asocierea a 15 dispozitive Bluetooth cu un sistem de infotainment fără degradarea performanței sistemului”.
(noi) Cerințe de interfață utilizator.
Exemplu: „Pe ecranul Tuner FM, ar trebui să fie furnizat un buton pentru a selecta diferite posturi”
Cerințele de mai sus sunt înregistrate și documentate în instrumente de gestionare a cerințelor, cum ar fi IBM DOORS, HP QC. Uneori organizațiile au instrumentele lor de gestionare a cerințelor personalizate pentru a reduce costurile.
Să analizăm acum procesul de conversie Cerințe de afaceri la Cerințe software (funcțional și nefuncțional).
Conversia cerințelor comerciale în cerințe software
Cerințele de afaceri, așa cum s-a discutat mai sus, sunt cerințe de nivel înalt care vorbesc despre ceea ce dorește utilizatorul final de la o acțiune definită asupra sistemului software. Dezvoltarea întregului sistem software pe baza acestor cerințe nu este posibilă, deoarece nu este menționată o descriere detaliată a modului în care sistemul software sau componenta vor fi implementate.
Astfel, cerințele comerciale trebuie împărțite în cerințe software mai detaliate, care vor fi detaliate în continuare la cerințele funcționale și nefuncționale.
Pentru a face acest lucru, ar putea fi urmați următorii pași:
- Descompuneți cerințele comerciale la nivel înalt la povești detaliate ale utilizatorilor.
- Derivarea unei diagrame pentru a defini fluxul de activități.
- Furnizarea condiției care justifică poveștile utilizatorilor derivate.
- Diagrame Wireframe pentru a explica fluxul de lucru al obiectelor.
- Definirea cerințelor nefuncționale din cerințele afacerii.
Să începem luând un exemplu de sistem de infotainment pentru automobile.
Cerința afacerii spune: „Utilizatorul final ar trebui să poată accesa caseta widget de navigare din HMI a sistemului Infotainment și ar trebui să poată seta adresa de destinație”.
Deci, pașii enumerați mai sus pot fi implementați ca:
# 1) Descompuneți cerințele comerciale la nivel înalt la povești detaliate ale utilizatorilor.
Permiteți-ne să transformăm această cerință comercială într-o poveste de utilizator la nivel înalt, „ Ca utilizator, ar trebui să pot accesa caseta widget Navigare, astfel încât să pot introduce adresa de destinație ”. Această poveste a utilizatorului spune ce este necesar utilizatorului final. Vom încerca să definim cum să implementăm această cerință.
Să începem prin a pune posibile întrebări acestei povești de utilizator și anume.
- Cine sunt utilizatorii?
- Cum pot accesa Navigația, la bord (de pe cardul SD) sau de pe SmartPhone?
- Ce fel de intrări de destinație pot introduce?
- Ar trebui să mi se permită să intru la destinație chiar și atunci când mașina este în parcare?
Acestea sunt povești de utilizator de nivel mai detaliat derivate din povești de utilizator de nivel înalt și ne-ar ajuta să obținem mai multe informații despre cerința noastră de afaceri.
În acest moment, putem prelua una dintre sub-poveștile utilizatorilor și putem începe să ne întrebăm. Să luăm (nr. 3):
- Pot introduce intrări de destinație, cum ar fi coordonatele geografice, adresa poștală, prin recunoaștere vocală etc.?
- Am nevoie de GPS pentru introducerea coordonatelor geografice?
- Pot introduce adresa de destinație curentă căutând din istoricul adreselor?
# 2) Derivarea unei diagrame pentru a defini fluxul de activități.
Acum putem vedea că cerința de afaceri este defalcat în cazuri de utilizare foarte detaliate, care pot fi marcate în diagrama de mai jos:
# 3) Furnizarea de condiții care justifică poveștile utilizatorilor derivate.
Putem vedea că informații mai detaliate apar din cauza descompunerii cerinței de afaceri la nivel înalt în povestiri detaliate ale utilizatorilor la nivel scăzut și a diagramei. Din această diagramă, putem obține detaliile tehnice necesare pentru implementare și anume.
- Timpul de încărcare a ecranului pentru afișarea intrării destinației ar trebui să fie de 1 sec.
- Tastatura de introducere a destinației trebuie să aibă caractere alfanumerice și simboluri speciale.
- Butonul de activare / dezactivare GPS trebuie să fie prezent pe ecranul de intrare a destinației de navigare.
Informațiile de mai sus satisfac poveștile utilizatorilor și fac posibil ca cerința să fie testată discret și măsurabil evitând orice confuzie cu cerința în timp ce este implementată ca funcții.
# 4) Diagrame Wireframe pentru a explica fluxul de lucru al obiectelor.
Din cazul de utilizare de mai sus, vom obține o diagramă wireframe care va face interfața utilizatorului mai clară.
# 5) Definirea cerințelor nefuncționale din cerințele afacerii.
Este imperativ ca cerințele detaliate de software să fie derivate din cerințele de business la nivel înalt, dar de multe ori sunt identificate numai cerințe funcționale, care spune cum se va comporta un sistem față de un anumit utilizator de intrare / acțiune.
Cu toate acestea, cerințele funcționale nu clarifică performanța sistemelor și alți parametri calitativi precum disponibilitatea, fiabilitatea etc.
Exemple:
a) Vom lua exemplul sistemului de infotainment auto de mai sus.
algoritm de sortare a selecției c ++
Dacă șoferul (utilizatorul final) al mașinii redă muzică de pe USB și îndrumarea de navigare este în curs, primește și un apel primit prin Bluetooth în modul Mâini libere, atunci încărcarea procesorului și consumul de RAM crește la un nivel maxim pe măsură ce procesele multiple sunt alergând în fundal.
În acest moment, dacă șoferul atinge o interfață cu ecran tactil a unui sistem de infotainment pentru a respinge apelurile primite prin SMS de răspuns automat (la fel ca în telefoanele noastre mobile), sistemul ar trebui să poată îndeplini această sarcină și nu ar trebui să se blocheze sau să se blocheze. Aceasta este performanța sistemului atunci când sarcina este mare și testăm disponibilitatea și fiabilitatea.
b) Un alt caz este scenariul de stres.
Luați un exemplu, sistemul de infotainment primește SMS-uri înapoi în spate (poate 20 de SMS-uri în decurs de 10 secunde) prin intermediul telefonului Bluetooth conectat. Sistemul de infotainment ar trebui să poată gestiona toate mesajele SMS primite și în niciun moment nu ar trebui să rateze niciuna dintre notificările SMS primite pe HMI Infotainment.
Exemplele de mai sus sunt cazuri de cerințe nefuncționale care nu au putut fi testate numai prin cerințe funcționale. Deși uneori, clienților le lipsește furnizarea acestor cerințe nefuncționale. Este responsabilitatea organizației să le furnizeze aceste informații atunci când un produs este livrat clientului.
Înțelegerea cazurilor de cerințe nefuncționale
Tabelul de mai jos explică cerințele nefuncționale:
SL nr | Caracteristică / caz de utilizare | Sarcina procesorului (max) | Utilizarea RAM (maxim din 512 MB) | Parametrii de performanță |
---|---|---|---|---|
1 | Max nr. de dispozitive Bluetooth care pot fi asociate cu sistemul Infotainment | 75% | 300 MB | 10 dispozitive Bluetooth |
Două | Este timpul să descărcați 2000 de contacte telefonice în sistemul Infotainment după conectarea și conectarea Bluetooth | 90% | 315 MB | 120 de secunde |
3 | Timp pentru scanarea tuturor posturilor FM disponibile în Tuner în sistem de infotainment | cincizeci% | 200 MB | 30 de secunde |
Cerințele nefuncționale, spre deosebire de cerințele funcționale, necesită ciclul complet de viață al unui proiect pentru a fi implementat, deoarece acestea sunt implementate incremental în Sprinturile Agile respective sau în diferite iterații.
Deci, așa derivăm cerințele software din cerințele de afaceri.
Diferența dintre cerințele de afaceri și cerințele de software
Am văzut mai sus cum să derivăm cerințele software din cerințele de afaceri la nivel înalt. Cerințele software permit programatorului și inginerului de testare să dezvolte sistemul și să îl testeze eficient. Deci, știm acum că cerințele de afaceri sunt cerințe de limbă naturală pentru clienți la nivel înalt, în timp ce cerințele de software sunt cerințe detaliate de nivel scăzut care ajută la implementarea sistemului software.
Să analizăm diferența detaliată dintre cele două tipuri de cerințe.
Cerințe de afaceri | Cerințe software |
---|---|
Acestea sunt cerințe la nivel ridicat de către un client care spune „ce” ar trebui să facă sistemul. Aceste cerințe nu spun „cum” ar trebui să funcționeze cerințele. | Se concentrează pe aspectul „cum” al cerințelor clienților. Aceste cerințe explică modul în care sistemul ar funcționa / implementa. |
Aceste cerințe se referă la obiectivul de afaceri al unei organizații. Exemplu: Utilizatorul ar trebui să poată seta destinația de navigare. | Aceste cerințe explică cunoștințele tehnice ale cerințelor. Exemplu: Atunci când utilizatorul dă clic pe pictograma destinație de navigare, baza de date ar trebui să încarce detaliile destinației pe care utilizatorul să le introducă. |
Cerințele de afaceri se concentrează pe beneficiul organizației. Exemplu: Utilizatorul ar trebui să primească informații pentru actualizarea funcției de navigare de la dealer în sistemul Infotainment dacă Navigarea nu este prezentă în sistem și utilizatorul atinge pictograma Navigare. | Cerințele software se referă la detaliile de implementare a cerințelor de afaceri din sistem. Exemplu: Când utilizatorul face clic pe pictograma de navigare din sistemul Infotainment, ar trebui inițiat un apel API pentru afișarea unui mesaj către utilizator pentru actualizarea sistemului. |
Cerințele comerciale sunt scrise în mod normal în limbaj natural sau în povești de utilizator la nivel înalt. | Cerințele software sunt funcționale și nefuncționale. Exemplu: dintre cerințele nefuncționale sunt performanța, stresul, portabilitatea, utilizabilitatea, optimizarea memoriei, aspectul, etc. |
Concluzie
Analiza cerințelor este coloana vertebrală a oricărui model SDLC.
O problemă ratată în timpul analizei cerințelor și surprinsă la testarea unității ar putea costa zeci de mii de dolari pentru o organizație și acest cost ar putea duce la milioane de dolari dacă vine de pe piață ca apel invers (în 2017, SUA a taxat producătorul de airbaguri, Takata a amendă de 1 miliard de dolari datorită exploziei airbagurilor).
Organizația ar sfârși prin a efectua sarcini de control al daunelor, cum ar fi analiza cauzei rădăcină, pregătind 5 de ce documente, analiza arborelui de defecțiuni, document 8D etc.
În cele mai grave cazuri, organizația ar fi târâtă în procesele intentate de client dacă caracteristica afectată este legată de securitate / siguranță, cum ar fi accesul la securitate, airbag, ABS (sistem de frânare antiblocare) etc.
Lectură recomandată
- Fazele, metodologiile, procesele și modelele SDLC (Ciclul de viață al dezvoltării software-ului)
- Caracteristici ale cerințelor funcționale și ale cerințelor nefuncționale
- Cum se testează specificațiile cerințelor software (SRS)?
- 5 greșeli mortale în gestionarea cerințelor și cum să le depășești
- Cum se testează o aplicație fără cerințe?
- Măsuri pentru SSDLC (Secure Software Development Life Cycle)
- Model în spirală - Ce este modelul în spirală SDLC?
- Ce este modelul de cascadă SDLC?