Ce este Analiza cerințelor și colectarea în SDLC?

acest Tutorial explică ceea ce este analiza cerință, pași de analiză cerință, exemple, și obiectivele de colectare cerință în SDLC:

dezvoltarea de Software este o sarcină humongous care creează un produs software de lucru.

Produsul software este construit conform cerințelor clientului. În mare parte, acest produs software respectă ceea ce se aștepta Clientul/Utilizatorul final, în timp ce uneori acest produs nu respectă pe deplin ceea ce se aștepta Clientul/Utilizatorul final.

ce este Analiza cerințelor?

să înțelegem Analiza cerințelor cu ajutorul unui exemplu.

așteptările clientului/utilizatorului final:

client / utilizator final primi:

după cum puteți analiza din imaginile de mai sus că există o nepotrivire în produsul final cu așteptările clienților. Acest lucru s-ar putea datora nenumăratelor motive, și anume. implementarea incorectă a cerințelor clienților, proiectarea defectuoasă, înțelegerea greșită a cerințelor clienților de către programatori și echipa de calitate etc.

cu toate acestea, după cum puteți vedea, fie că este vorba de orice motiv pentru livrarea greșită a produsului, motivul principal merge la cerință. Prin urmare, dacă s-ar face înțelegerea corectă a cerințelor, captarea, implementarea și testarea, aceasta ar fi ajutat la atenuarea livrării eronate și incomplete a produsului către client/utilizatorul final.

o livrare bună a produsului necesită colectarea corectă a cerințelor, examinarea eficientă a cerințelor colectate și, în final, documentația cerinței clare, ca condiție prealabilă. Acest întreg proces este, de asemenea, numit ca analiza cerință în ciclul de viață de dezvoltare Software (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 produsului de către clienți.

în acest tutorial, vom explica modul în care analiza cerințelor se face în SDLC. Vom vedea, de asemenea, diferitele etape implicate, rezultate, provocări și măsuri corective în analiza cerințelor.

Analiza cerințelor începe cu:

1. cerința de colectare, care este, de asemenea, numit ca elicitation.
2. aceasta este urmată de analizarea cerințelor colectate pentru a înțelege corectitudinea și fezabilitatea transformării acestor cerințe într-un produs posibil.
3. și, în final, documentarea cerințelor colectate.

#1) colectarea cerințelor

pentru a vă asigura că toți pașii menționați mai sus sunt executați în mod corespunzător, trebuie colectate cerințe clare, concise și corecte de la client. Clientul ar trebui să poată defini cerințele lor în mod corespunzător și analist de afaceri ar trebui să fie capabil să-l colecteze în același mod clientul intenționează să transmită.

de multe ori nu este posibil ca colectarea cerințelor să se facă eficient de către analiștii de afaceri de la client. Acest lucru se poate datora dependenței de multe persoane legate de produsul final așteptat, instrumente, mediu etc. Astfel, este întotdeauna o idee bună să implicăm toate părțile interesate care ar putea influența sau ar putea fi influențate de produsul final.

grupul posibil al părților interesate ar putea fi ingineri de calitate Software (atât QC, cât și QA), orice furnizor terț care ar putea oferi asistență în proiect, utilizator final pentru care este destinat produsul, programatori software, O altă echipă din cadrul organizației care ar putea oferi un modul sau o platformă software, biblioteci software etc. pentru dezvoltarea produsului.

exemplu: într-o organizație, ei dezvoltă un produs ADAS (sistem de cameră surround-view pentru un OEM de prestigiu) care are nevoie de fișiere binare Autosar și bootloader 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 unele de altele și orice posibil conflict viitor ar putea fi evitat.

uneori, este o idee bună să creați un model prototip al produsului planificat și să îl arătați clientului. Acesta este un mod excelent de a transmite clienților ce produs așteaptă și cum ar putea arăta mai târziu. Acest lucru ajută clientul în vizualizarea produsului pe care îl așteaptă și îi ajută să vină cu cerințe clare.

această creație prototip depinde de două tipuri de produse:

1. un produs similar pe care clienții îl intenționează, există în cadrul organizației.
2. produs nou care urmează să fie dezvoltat.

(i) în primul caz, este mai ușor să arătați clientului cum ar arăta produsul final și cum ar fi dezvoltat. În ADAS auto, este posibil să se arate clienților un alt produs care este deja pe piață și a fost dezvoltat în cadrul organizației.

de exemplu, un sistem de camere cu vedere surround dezvoltat pentru un OEM (GM, Volkswagen, BMW etc.) și poate fi prezentat la un alt OEM.

vă rugăm să rețineți că nu este înțelept să arătați produsul/Produsul proto clientului care este în curs de dezvoltare, deoarece poate încălca acordul de Confidențialitate semnat cu un alt client pentru care produsul este dezvoltat. Aceasta poate duce, de asemenea, la o încăierare juridică inutilă.

un alt exemplu ar putea fi cel al sistemului de infotainment, dezvoltat de organizație și care este 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 de conectare a dispozitivului, sandbox etc.

acest lucru va ajuta clientul să înțeleagă cum ar arăta produsul final și să ofere cerințele lor mult mai clar.

(ii) cel de-al doilea caz poate fi realizat prin crearea unui model de lucru de bază prin codarea și asamblarea simplă (în mare parte caracteristicile 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 o pauză pentru procesul de colectare a cerințelor, deoarece clientul știe acum ce dorește.

analistul de afaceri poate organiza acum întâlniri formale de solicitare a cerințelor, în care toate părțile interesate ar putea fi invitate și astfel pot nota diferitele cerințe furnizate de client (în unele cazuri, dacă părțile interesate sunt mai numeroase, ar putea fi numit un scrib separat pentru a nota cerințele clienților sau poveștile utilizatorilor, astfel încât analistul de afaceri să se poată concentra pe moderarea întâlnirii).

cerințele adunate pot fi sub formă de povești ale 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ță al dezvoltării software-ului modern. 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 cu vizualizare surround ADAS, o posibilă poveste a utilizatorului ar putea fi: „ca utilizator, ar trebui să pot vedea ce este acolo în retrovizoarea mașinii mele”.

ar putea exista multe „de ce”, întrebări adresate pe fiecare poveste de utilizator, care va ajuta clientul în furnizarea de informații mai detaliate cu privire la cerința.

în povestea utilizatorului de mai sus, dacă un client spune „ca utilizator, ar trebui să pot vedea ce este acolo în retrovizorul mașinii mele”, punând o întrebare „de ce” ar putea da „ca utilizator, ar trebui să pot vedea ce este acolo în retrovizorul mașinii mele, astfel încât să-mi pot parca mașina în siguranță”.

a pune întrebarea „De ce” ajută, de asemenea, la crearea cerințelor obiective și atomice din declarațiile de limbaj natural humongous date de client. Acest lucru poate fi implementat cu ușurință mai târziu în cod.

un alt mod de colectare a cerinței este sub formă de cazuri de utilizare. Un caz de utilizare este o abordare pas cu pas pentru obținerea unui anumit rezultat. Acest lucru nu spune modul în care software-ul va lucra la intrare de utilizator, mai degrabă se spune, ceea ce se așteaptă de intrări de utilizator.

exemplu:

#2) analizând cerințele adunate

colectarea cerințelor Post, începe analiza cerinței. În această etapă, diverse părți interesate stau și fac o sesiune de brainstorming. Ei analizează cerințele adunate și caută fezabilitatea pentru a le pune în aplicare. Ei discută între ei și orice ambiguitate este rezolvată.

acest pas este important în procesul de analiză a cerințelor din următoarele motive principale:

(i) Clientul poate oferi unele cerințe care ar putea fi imposibil de implementat din cauza diferitelor dependențe.

exemplu: clienții pot cere să surround-vizualizați sistemul camerei cu o caracteristică a camerei retrovizoare care vă va ajuta să parcați mașina. Clientul poate solicita, de asemenea, caracteristica cârlig remorcă care utilizează, de asemenea, camera din spate pentru a lucra.

dacă clientul afirmă o cerință ca camera retrovizoare pentru asistența la parcare să funcționeze în orice moment fără excepție, atunci caracteristica remorcii nu va funcționa niciodată și invers.

(ii) un analist de afaceri ar fi putut înțelege cerința de la client diferit de modul în care un programator ar fi interpretat.

deoarece programatorii gândesc ca 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 documente de arhitectură și proiectare și ulterior în cod. Impactul este exponențial și deci ar trebui verificat.

o posibilă măsură de remediere ar putea fi urmarea unei metode agile de dezvoltare de software, urmărirea cazurilor de utilizare furnizate de client etc.

#3) documentarea cerințelor analizate

odată ce analiza cerințelor se face documentația cerință începe. Diferite tipuri de cerințe provin din analiza cerințelor.

unele dintre acestea sunt:

(i) specificația cerințelor clienților.

(ii) cerința de Arhitectură Software.

exemplu:

(iii) cerința de proiectare Software.

exemplu:

(iv) specificația cerințelor funcționale (derivată direct din specificațiile clientului.)

exemplu: „când utilizatorul apasă pe pictograma Bluetooth pe Infotainment HMI, ecranul Bluetooth ar trebui să fie afișat”

(v) specificația cerințelor nefuncționale (și anume. performanță, stres, sarcină etc.).

exemplu: „ar trebui să fie posibilă asocierea a 15 Dispozitive Bluetooth cu sistem de infotainment fără degradarea performanței sistemului”.

(vi) cerințe privind interfața cu utilizatorul.

exemplu: „Pe ecranul tuner FM, trebuie furnizat un buton pentru a selecta diferite stații”

cerințele de mai sus sunt înregistrate și documentate în instrumentele de gestionare a cerințelor, cum ar fi IBM DOORS, HP QC. Uneori, organizațiile au instrumentele de gestionare a cerințelor personalizate pentru a reduce costurile.

Să analizăm acum procesul de conversie a cerințelor de afaceri la cerințele Software (funcționale și nefuncționale).

conversia cerințelor de afaceri la cerințele 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 dintr-o acțiune definită asupra sistemului software. Dezvoltarea întregului sistem software bazat pe aceste cerințe nu este posibilă, deoarece nu este menționată o descriere detaliată a modului în care va fi implementat sistemul sau componenta software.

astfel, cerințele de afaceri trebuie defalcate pe cerințe software mai detaliate, care vor fi detaliate în continuare cerințelor funcționale și nefuncționale.

pentru a face acest lucru, următorii pași ar putea fi urmați:

1. defalcați cerințele de afaceri la nivel înalt la poveștile detaliate ale utilizatorilor.
2. derivând o diagramă pentru a defini fluxul de activități.
3. furnizarea condiției care justifică poveștile derivate ale utilizatorilor.
4. diagrame Wireframe pentru a explica fluxul de lucru al obiectelor.
5. definirea cerințelor nefuncționale din cerințele de afaceri.

să începem prin a lua un exemplu de sistem de Infotainment auto.

cerința de afaceri spune, „utilizatorul final ar trebui să poată accesa caseta widget de navigare din Sistemul de Infotainment HMI și ar trebui să poată seta adresa de destinație”.

deci, pașii de mai sus înrolat pot fi puse în aplicare ca:

#1) defalcați cerințele de afaceri la nivel înalt la poveștile detaliate ale utilizatorilor.

să convertim această cerință de afaceri într-o poveste de utilizator la nivel înalt, „ca utilizator, ar trebui să pot accesa caseta widget de navigare, astfel încât să pot introduce adresa de destinație”. Această poveste de utilizator spune ceea ce este necesar de către utilizatorul final. Vom încerca să definim modul de implementare a acestei cerințe.

să începem prin a pune întrebări posibile acestei povești de utilizator și anume.

1. cine sunt utilizatorii?
2. Cum pot accesa navigarea, la bord (de pe cardul SD) sau de pe SmartPhone?
3. ce fel de intrări de destinație pot introduce?
4. ar trebui să mi se permită să intru în destinație chiar și atunci când mașina este în parcare?

acestea sunt povești de utilizator la nivel mai detaliat derivate din povești de utilizator la nivel înalt și ne-ar ajuta să obținem mai multe informații despre cerințele noastre de afaceri.

în acest moment, putem prelua una dintre sub-poveștile utilizatorilor și putem începe să punem întrebări. Să luăm (nu. 3):

1. pot introduce intrări de destinație, cum ar fi coordonatele geografice, adresa poștală, prin recunoașterea vorbirii etc.?
2. am nevoie de GPS pentru introducerea Geo-coordonatelor?
3. pot introduce adresa de destinație curentă căutând din istoricul adreselor?

#2) derivând o diagramă 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 derivate ale utilizatorilor.

putem vedea că apar informații mai detaliate datorită descompunerii cerinței de afaceri la nivel înalt în povești detaliate ale utilizatorilor de nivel scăzut și în diagrama de flux. Din această diagramă, putem obține detaliile tehnice necesare pentru implementarea viz.

• timpul de încărcare a ecranului pentru afișarea intrării în destinație trebuie să fie de 1 sec.
• tastatura intrării în destinație trebuie să aibă caractere alfanumerice și simboluri speciale.
• butonul de comutare activare/dezactivare GPS trebuie să fie prezent pe ecranul de introducere a destinației de navigare.

informațiile de mai sus satisfac poveștile utilizatorilor și fac posibilă testarea discretă și măsurabilă a cerinței, evitând orice confuzie cu cerința în timp ce este implementată ca caracteristici.

#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 cu utilizatorul mai clară.

#5) definirea cerințelor nefuncționale din cerințele de afaceri.

este imperativ ca cerințele software detaliate să fie derivate din cerințele de afaceri la nivel înalt, dar de multe ori sunt identificate doar cerințe funcționale care spun cum se va comporta un sistem la o anumită intrare/acțiune a utilizatorului.

cu toate acestea, cerințele funcționale nu clarifică performanța sistemelor și alți parametri calitativi, cum ar fi disponibilitatea, fiabilitatea etc.

Exemple:

a) vom lua exemplul sistemului de infotainment auto de mai sus.

dacă șoferul(utilizatorul final) al mașinii redă muzică de pe USB și îndrumarea de navigare este în desfășurare, primește și un apel primit prin Bluetooth în modul Hands-free, apoi încărcați pe CPU și consumul RAM crește la un nivel maxim, deoarece mai multe procese rulează în fundal.

în acest moment, dacă șoferul atinge o interfață touchscreen a sistemului de infotainment pentru a respinge apelul primit prin SMS cu răspuns automat (la fel cum facem în telefoanele noastre mobile), sistemul ar trebui să poată îndeplini această sarcină și nu ar trebui să se blocheze sau să se prăbușească. 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 spate în spate (poate 20 SMS în 10 sec) prin intermediul telefonului Bluetooth conectat. Sistemul de Infotainment ar trebui să poată gestiona toate SMS-urile primite și în niciun moment nu ar trebui să rateze niciuna dintre notificările SMS primite pe Infotainment HMI.

exemplele de mai sus sunt cazuri de cerințe nefuncționale care nu au putut fi testate doar prin cerințe funcționale. Deși uneori, clienții ratează 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 cerințelor nefuncționale cazuri

tabelul de mai jos explică cerințele nefuncționale:

cerințe nefuncționale, spre deosebire de cerințele funcționale, luați ciclul de viață complet al unui proiect pentru a fi implementat, deoarece acestea sunt implementate treptat în sprinturile Agile respective sau în diferite iterații.

deci, acesta este modul în care 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 de 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, acum știm că cerințele de afaceri sunt cerințe de limbaj natural la nivel înalt ale clienților, în timp ce cerințele 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.

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 unei organizații, iar acest cost ar putea duce la milioane de dolari dacă vine de pe piață ca apel invers (în 2017, producătorul de airbag-uri taxat din SUA, Takata o amendă de 1 miliard de dolari din cauza airbag-urilor care explodează).

organizația ar ajunge să efectueze sarcini de control al daunelor, cum ar fi analiza cauzei rădăcinii, pregătirea 5 de ce documente, analiza arborelui de erori, documentul 8d etc. în loc să se concentreze pe dezvoltarea de software și de calitate.

în cele mai grave cazuri, organizația ar fi târâtă în procese legale 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.