what is requirement analysis
Ovaj vodič objašnjava što je analiza zahtjeva, koraci analize zahtjeva, primjeri i ciljevi prikupljanja zahtjeva u SDLC-u:
Razvoj softvera velik je zadatak koji stvara radni softverski proizvod.
Softverski proizvod izrađen je prema zahtjevu kupca. Ovaj softverski proizvod uglavnom je u skladu s onim što je očekivao krajnji kupac / korisnik, dok ponekad ovaj proizvod nije u potpunosti u skladu s onim što su očekivali kupac / krajnji korisnik.
Što ćete naučiti:
Što je analiza zahtjeva?
Razumijemo analizu zahtjeva uz pomoć primjera.
Očekivanje kupca / krajnjeg korisnika:
Kupac / krajnji korisnik prima:
Kao što iz gornjih slika možete analizirati da postoji krajnji neusklađenost krajnjeg proizvoda s očekivanjima kupaca. To bi moglo biti zbog bezbrojnih razloga, naime. netočna primjena zahtjeva kupaca, neispravan dizajn, pogrešno razumijevanje zahtjeva kupaca od strane programera i tima za kvalitetu itd.
Međutim, kao što vidite, bilo da je to razlog pogrešne isporuke proizvoda, primarni razlog odnosi se na zahtjev. Stoga, da su napravljeni ispravni zahtjevi za razumijevanje, hvatanje, implementaciju i testiranje, to bi pomoglo ublažiti pogrešnu i nepotpunu isporuku proizvoda kupcu / krajnjem korisniku.
Dobra isporuka proizvoda kao preduvjet zahtijeva ispravno prikupljanje zahtjeva, učinkovito ispitivanje prikupljenih zahtjeva i konačno jasnu dokumentaciju o zahtjevima. Čitav ovaj postupak naziva se i Analiza zahtjeva u životnom ciklusu razvoja softvera (SDLC)
Faze / koraci analize zahtjeva
Kao što vidite, Analiza zahtjeva prva je aktivnost u SDLC-u koju slijede Funkcionalne specifikacije i tako dalje. Analiza zahtjeva vitalni je korak u SDLC-u jer odjekuje testiranjem prihvaćanja koje je ključno za prihvaćanje proizvoda od strane kupaca.
U ovom uputstvu objasnit ćemo kako se u SDLC radi analiza zahtjeva. Također ćemo vidjeti različite uključene korake, ishode, izazove i korektivne mjere u analizi zahtjeva.
Analiza zahtjeva započinje sa:
- Prikupljanje zahtjeva što se naziva i izvlačenjem.
- Nakon toga slijedi analizirajući prikupljeni zahtjevi za razumijevanje ispravnosti i izvedivosti pretvaranja tih zahtjeva u mogući proizvod.
- I konačno, dokumentiranje prikupljeni zahtjevi.
# 1) Okupljanje zahtjeva
Da biste bili sigurni da su svi gore navedeni koraci pravilno izvedeni, od kupca se moraju prikupiti jasni, sažeti i ispravni zahtjevi. Kupac bi trebao biti u mogućnosti pravilno definirati svoje zahtjeve, a poslovni analitičar trebao bi ih moći prikupiti na isti način na koji to namjerava prenijeti.
Često poslovni analitičari od kupaca učinkovito obavljaju prikupljanje zahtjeva. To bi moglo biti posljedica ovisnosti mnogih ljudi o očekivanom krajnjem proizvodu, alatima, okolišu itd. Stoga je uvijek dobra ideja uključiti sve dionike koji bi mogli utjecati ili bi mogli utjecati na krajnji proizvod.
Moguća skupina dionika mogli bi biti inženjeri za kvalitetu softvera (i QC i QA), bilo koji dobavljač treće strane koji bi mogao pružiti podršku u projektu, krajnji korisnik kojem je proizvod namijenjen, programeri softvera, drugi tim u organizaciji koji bi mogao pružiti modul ili softverska platforma, softverske knjižnice itd. za razvoj proizvoda.
Primjer: U nekoj organizaciji razvijaju ADAS proizvod (sustav kamera za okružujući pogled za prestižnog OEM-a) koji treba Slog Autosar i Bootloader binarne datoteke koje su primljene od drugog dobavljača.
Uključivanje različitih dionika u fazu prikupljanja zahtjeva pomaže u razumijevanju različitih međusobnih ovisnosti i svaki se mogući budući sukob može izbjeći.
Ponekad je dobra ideja stvoriti prototip modela planiranog proizvoda i pokazati ga kupcu. Ovo je izvrstan način da kupcima prenesete kakav proizvod očekuju i kako može izgledati kasnije. To kupcu pomaže u vizualizaciji proizvoda koji očekuje i pomaže mu da postavi jasne zahtjeve.
Izrada ovog prototipa ovisi o dvije vrste proizvoda:
- U organizaciji postoji sličan proizvod koji su kupci namjeravali.
- Novi proizvod koji treba razviti.
(i) U prvom je slučaju kupcu lakše pokazati kako bi izgledao krajnji proizvod i kako bi se razvijao. U automobilskom ADAS-u kupcima je moguće pokazati još jedan proizvod koji je već na tržištu i razvijen je unutar organizacije.
Na primjer, Sustav surround kamera razvijen za OEM-a (GM, Volkswagen, BMW itd.) I može se predstaviti drugom OEM-u.
Molim Zabilježite , nije pametno proizvod / proto proizvod pokazati kupcu koji je u fazi izrade, jer to može kršiti Ugovor o neotkrivanju podataka potpisan s drugim kupcem za kojeg se taj proizvod razvija. To također može rezultirati nepotrebnim pravnim sporovima.
Još jedan primjer može biti onaj informacijsko-zabavnog sustava koji razvija organizacija i koji je već na tržištu. Poslovni analitičari i drugi dionici u organizaciji mogu planirati demonstraciju radionice za kupca, prikazujući infotainment sustave s opipljivim HMI-jem, priključke za priključke uređaja, pješčanik itd.
To će kupcu pomoći da shvati kako bi izgledao krajnji proizvod i puno jasnije pružiti svoje zahtjeve.
(ii) Drugi slučaj može se postići stvaranjem osnovnog radnog modela jednostavnim kodiranjem i sastavljanjem (većinom su ovdje značajke kodirane u softverskim programima) ili stvaranjem dijagrama toka ili dijagrama koji bi kupca mogao uvjeriti kako bi proizvod izgledao.
U svakom slučaju, to bi bilo oduška za postupak prikupljanja zahtjeva jer kupac sada zna što želi.
Poslovni analitičar sada može organizirati formalne sastanke za prikupljanje zahtjeva, na koje bi se mogle pozvati sve zainteresirane strane, pa na taj način može zabilježiti razne zahtjeve koje pruža kupac (u nekim slučajevima, ako je dionika više, mogao bi se imenovati zasebni zapisničar koji će zabilježiti kupca zahtjevi ili korisničke priče kako bi se poslovni analitičar mogao koncentrirati na moderiranje sastanka).
Prikupljeni zahtjevi mogu biti u obliku korisničke priče (u agilnom razvoju), slučajevi korištenja, kupčevi dokumenti na prirodnom jeziku, dijagrami, dijagrami toka itd. Korisničke priče postaju popularne u suvremenom životnom ciklusu razvoja softvera. Priče o korisnicima u osnovi su skup korisničkih unosa na njihovom prirodnom jeziku.
Primjer prikupljanja zahtjeva: U sustavu ADAS surround-pogleda kamera jedna moguća korisnička priča mogla bi biti: 'Kao korisnik trebao bih moći vidjeti što se nalazi u stražnjem pogledu mog automobila'.
Moglo bi ih biti mnogo 'zašto,' pitanja koja se postavljaju za svaku korisničku priču, što će pomoći kupcu u pružanju detaljnijih informacija o zahtjevu.
U gornjoj korisničkoj priči, ako kupac kaže 'Kao korisnik, trebao bih moći vidjeti što se nalazi u retrovizoru mog automobila', postavljajući pitanje 'zašto 'Mogao dati' Kao korisnik, trebao bih moći vidjeti što se nalazi u retrovizoru mog automobila, kako bih mogao sigurno parkirati svoj automobil '.
Postavljajući pitanje 'zašto' također pomaže u stvaranju objektivnih i atomskih zahtjeva iz ogromnih izjava na prirodnom jeziku koje daje kupac. To se lako može implementirati kasnije u kodu.
što se c ++ koristi danas
Drugi način prikupljanja zahtjeva je u obliku slučajevi upotrebe . Slučaj upotrebe korak je po korak za postizanje određenog rezultata. To ne govori kako će softver raditi na korisničkom unosu, već kaže, što se očekuje od korisničkih unosa.
Primjer:
# 2) Analiza prikupljenih zahtjeva
Nakon prikupljanja zahtjeva, započinje analiza zahtjeva. U ovoj fazi različiti dionici sjede i održavaju brainstorming. Oni analiziraju prikupljene zahtjeve i traže mogućnost njihove provedbe. Oni međusobno razgovaraju i svaka nejasnoća se riješi.
Ovaj je korak važan u procesu analize zahtjeva zbog sljedećih glavnih razloga:
(i) Kupac može pružiti neke zahtjeve koje bi zbog različitih ovisnosti moglo biti nemoguće provesti.
Primjer: Kupcimože zatražiti da sistem za okruživanje pregleda s funkcijom kamere za stražnji pogled koja će vam pomoći parkiralište kola. Kupac također može zatražiti Prikolica značajka zakačenja koja također koristi stražnju kameru za rad.
Ako kupac navede zahtjev da kamera za stražnji pogled za parkiralište pomoć bi trebala raditi cijelo vrijeme bez iznimke, a zatim Prikolica značajka nikad ne bi funkcionirala i obrnuto.
(ii) Poslovni analitičar možda je razumio zahtjev iz kupac drugačije nego kako a programer bi protumačio.
Budući da programeri misle kao tehnički stručnjaci, uvijek je moguće da se zahtjevi kupaca pogrešno pretvore u funkcionalne specifikacije koje će kasnije biti pogrešno postavljene u arhitekturi i projektnim dokumentima, a zatim u kodu. Utjecaj je eksponencijalan i zato ga treba provjeriti.
Moguća popravna mjera može biti slijeđenje agilne metode razvoja softvera, praćenje slučajeva korištenja koje kupac itd.
# 3) Dokumentiranje analiziranih zahtjeva
Nakon što se izvrši analiza zahtjeva, započinje dokumentacija sa zahtjevima. Analizom zahtjeva proizlaze razne vrste zahtjeva.
Neki od njih su:
(i) Specifikacija zahtjeva kupca.
(ii) Zahtjev za softverskom arhitekturom.
Primjer:
(iii) Zahtjev za dizajn softvera.
Primjer:
(iv) Specifikacija funkcionalnih zahtjeva (izravno izvedena iz specifikacija kupaca.)
Primjer: 'Kad korisnik dodirne ikonu Bluetooth na Infotainment HMI-u, trebao bi se prikazati Bluetooth zaslon'
(v) Nefunkcionalna specifikacija zahtjeva (odnosno performanse, naprezanje, opterećenje itd.).
Primjer: 'Trebalo bi biti moguće upariti 15 Bluetooth uređaja s informacijsko-zabavnim sustavom bez pogoršanja performansi sustava'.
(mi) Zahtjevi korisničkog sučelja.
Primjer: 'Na zaslonu tunera FM trebao bi biti dostupan gumb za odabir različitih postaja'
Gore navedeni zahtjevi zabilježeni su i dokumentirani u alatima za upravljanje zahtjevima, poput IBM DOORS, HP QC. Ponekad organizacije imaju vlastite alate za upravljanje zahtjevima kako bi smanjile troškove.
Pogledajmo sada proces pretvorbe Poslovni zahtjevi do Zahtjevi softvera (funkcionalni i nefunkcionalni).
Pretvaranje poslovnih zahtjeva u softverske
Poslovni zahtjevi, kao što je gore spomenuto, zahtjevi su visoke razine koji govore o tome što krajnji korisnik želi od definirane radnje na softverskom sustavu. Razvoj cijelog softverskog sustava na temelju ovih zahtjeva nije moguć jer se ne spominje detaljan opis načina na koji će se softverski sustav ili komponenta implementirati.
Stoga se poslovni zahtjevi moraju raščlaniti na detaljnije softverske zahtjeve koji će se dalje detaljno pretvoriti u funkcionalne i nefunkcionalne zahtjeve.
Da biste to učinili, mogli bi se slijediti sljedeći koraci:
- Podijelite poslovne zahtjeve na visokoj razini na detaljne korisničke priče.
- Izvođenje dijagrama toka za definiranje tijeka aktivnosti.
- Pružanje uvjeta koji opravdavaju izvedene korisničke priče.
- Okvirni dijagrami koji objašnjavaju tijek rada objekata.
- Utvrđivanje nefunkcionalnih zahtjeva izvan poslovnih zahtjeva.
Krenimo od uzimanja primjera Automotive Infotainment sustava.
Poslovni zahtjev kaže: 'Krajnji korisnik trebao bi moći pristupiti navigacijskom okviru s HMI-ja Infotainment sustava i trebao bi biti u mogućnosti postaviti adresu odredišta'.
Dakle, gore navedeni koraci mogu se provesti kao:
# 1) Podijelite poslovne zahtjeve na visokoj razini na detaljne korisničke priče.
Pretvorimo ovaj poslovni zahtjev u korisničku priču na visokoj razini, “ Kao korisnik, trebao bih moći pristupiti okviru widgeta Navigacija kako bih mogao unijeti odredišnu adresu '. Ova korisnička priča govori što je krajnjem korisniku potrebno. Pokušat ćemo definirati kako primijeniti ovaj zahtjev.
Počnimo s postavljanjem mogućih pitanja ovoj korisničkoj priči, naime.
- Tko su korisnici?
- Kako mogu pristupiti navigaciji, na brodu (sa SD kartice) ili sa SmartPhone-a?
- Kakve unose odredišta mogu unijeti?
- Treba li mi dopustiti ulazak na odredište čak i kada je automobil na parkingu?
Ovo su detaljnije korisničke priče izvedene iz korisničkih priča na visokoj razini i pomogle bi nam da dobijemo bolji uvid u naše poslovne zahtjeve.
U ovom trenutku možemo uzeti jednu od korisničkih potpriča i započeti ispitivanje. Uzmimo (br. 3):
- Mogu li unijeti odredišne unose poput Geo koordinata, poštanske adrese, prepoznavanjem govora itd.?
- Treba li mi GPS za unos geo-koordinata?
- Mogu li unijeti trenutnu adresu odredišta pretraživanjem iz povijesti adresa?
# 2) Izvođenje dijagrama toka kako bi se definirao tijek aktivnosti.
Sada možemo vidjeti da se poslovni zahtjev raščlanjuje na vrlo detaljne slučajeve upotrebe koji se u dijagramu toka mogu označiti kao dolje:
# 3) Pružanje uvjeta koji opravdavaju izvedene korisničke priče.
Možemo vidjeti da se pojavljuju detaljnije informacije zbog raščlanjivanja poslovnih zahtjeva na visokoj razini u detaljne korisničke priče na niskoj razini i dijagrama toka. Iz ove sheme toka možemo dobiti tehničke detalje potrebne za provedbu, naime.
- Vrijeme učitavanja zaslona za prikaz unosa odredišta trebalo bi biti 1 sekunda.
- Tipkovnica za unos odredišta trebala bi imati alfanumeričke znakove i posebne simbole.
- Gumb za uključivanje / isključivanje GPS-a trebao bi biti prisutan na zaslonu za unos odredišta za navigaciju.
Navedene informacije zadovoljavaju korisničke priče i omogućuju diskretno i mjerljivo testiranje zahtjeva, izbjegavajući bilo kakvu zbrku sa zahtjevom dok se provodi kao značajke.
# 4) Okvirni dijagrami koji objašnjavaju tijek rada objekata.
Iz gornjeg slučaja uporabe izvući ćemo dijagram žice koji će korisničko sučelje učiniti jasnijim.
# 5) Utvrđivanje nefunkcionalnih zahtjeva izvan poslovnih zahtjeva.
Nužno je da se detaljni softverski zahtjevi izvode iz poslovnih zahtjeva visoke razine, ali često se identificiraju samo funkcionalni zahtjevi koji govore kako će se sustav ponašati prema određenom korisničkom unosu / radnji.
Međutim, funkcionalni zahtjevi ne pojašnjavaju izvedbu sustava i druge kvalitativne parametre poput dostupnosti, pouzdanosti itd.
Primjeri:
a) Uzet ćemo primjer gornjeg automobilskog infotainment sustava.
Ako vozač (krajnji korisnik) automobila pušta glazbu s USB-a, a navigacija je u tijeku, također prima dolazni poziv putem Bluetootha u načinu rada bez ruku, a zatim se opterećenje CPU-a i RAM-a povećava na maksimalnu razinu jer se odvija više procesa trčanje u pozadini.
U ovom trenutku, ako vozač tapka na sučelje zaslona osjetljivog na dodir informacijskog sustava za odbijanje dolaznog poziva putem automatskog odgovora SMS-om (na isti način kao što to radimo na svojim mobilnim telefonima), sustav bi trebao moći izvršiti ovaj zadatak i ne bi se trebao objesiti ili srušiti. Ovo su performanse sustava kada je opterećenje veliko i testiramo dostupnost i pouzdanost.
b) Drugi slučaj je stresni scenarij.
Uzmimo primjer, informacijsko-zabavni sustav prima back-to-back SMS-ove (možda 20 SMS-ova u roku od 10 sekundi) putem povezanog Bluetooth telefona. Infotainment sustav trebao bi biti u mogućnosti rukovati svim dolaznim SMS-ovima i ni u jednom trenutku ne smije propustiti nijednu obavijest o dolaznom SMS-u na Infotainment HMI-u.
Gornji primjeri su slučajevi nefunkcionalnih zahtjeva koji se ne mogu testirati samo putem funkcionalnih zahtjeva. Iako ponekad kupci propuštaju pružiti ove nefunkcionalne zahtjeve. Odgovornost je organizacije da im dostavi ove podatke kada se proizvod isporuči kupcu.
Razumijevanje slučajeva nefunkcionalnih zahtjeva
Tablica u nastavku objašnjava nefunkcionalne zahtjeve:
SL br | Značajka / slučaj upotrebe | Opterećenje procesora (maks.) | Korištenje RAM-a (maksimalno od 512 MB) | Parametri izvedbe |
---|---|---|---|---|
1 | Max br. Bluetooth uređaja koji se mogu upariti s Infotainment sustavom | 75% | 300 MB | 10 Bluetooth uređaja |
dva | Vrijeme je za preuzimanje 2000 telefonskih kontakata u Infotainment sustav nakon Bluetooth uparivanja i povezivanja | 90% | 315 MB | 120 sekundi |
3 | Vrijeme je za skeniranje svih dostupnih FM postaja u tuneru u infotainment sustavu | pedeset% | 200 MB | 30 sekundi |
Nefunkcionalni zahtjevi, za razliku od funkcionalnih zahtjeva, trebaju puni životni ciklus projekta da bi se implementirali, jer se postupno primjenjuju u odgovarajućim agilnim sprintima ili u različitim iteracijama.
Dakle, ovako izvodimo softverske zahtjeve iz poslovnih zahtjeva.
Razlika između poslovnih zahtjeva i softverskih zahtjeva
Gore smo vidjeli kako izvući zahtjeve za softverom iz poslovnih zahtjeva visoke razine. Softverski zahtjevi omogućavaju programeru i inženjeru za ispitivanje da razviju sustav i učinkovito ga testiraju. Dakle, sada znamo da su poslovni zahtjevi zahtjevi prirodnog jezika kupaca na visokoj razini, dok su softverski zahtjevi detaljni zahtjevi niske razine koji pomažu u implementaciji softverskog sustava.
Pogledajmo detaljnu razliku između dvije vrste zahtjeva.
Poslovni zahtjevi | Zahtjevi softvera |
---|---|
To su zahtjevi na visokoj razini od strane kupca koji govori 'što' sustav treba učiniti. Ovi zahtjevi ne govore 'kako' bi zahtjevi trebali raditi. | Koncentriraju se na aspekt 'kako' zahtjeva kupaca. Ovi zahtjevi objašnjavaju kako bi sustav radio / implementirao. |
Ovi se zahtjevi bave poslovnim ciljem organizacije. Primjer: Korisnik bi trebao biti u mogućnosti postaviti odredište za navigaciju. | Ovi zahtjevi objašnjavaju tehničku know-how zahtjeva. Primjer: Kad korisnik klikne na ikonu odredišta za navigaciju, baza podataka treba učitati detalje o odredištu koje će korisnik unijeti. |
Poslovni se zahtjevi usredotočuju na korist organizacije. Primjer: Korisniku treba pružiti informacije o nadogradnji značajke Navigacija od trgovca u Infotainment sustavu ako Navigacija nije prisutna u Sustavu, a korisnik dodirne ikonu Navigacija. | Softverski zahtjevi bave se detaljima implementacije poslovnih zahtjeva u sustav. Primjer: Kada korisnik klikne na ikonu Navigacija na sustavu Infotainment, trebao bi se pokrenuti API poziv za prikaz poruke korisniku za nadogradnju sustava. |
Poslovni se zahtjevi obično pišu na prirodnom jeziku ili na korisničkim pričama na visokoj razini. | Softverski zahtjevi su funkcionalni i nefunkcionalni. Primjer: nefunkcionalni zahtjevi su izvedba, stres, prenosivost, upotrebljivost, optimizacija memorije, izgled i dojam itd. |
Zaključak
Analiza zahtjeva okosnica je svakog SDLC modela.
razlika između sit i uat testiranja
Problem propušten tijekom analize potreba i uhvaćen na testiranju u jedinici mogao bi koštati desetke tisuća dolara za organizaciju, a taj bi trošak mogao dovesti do milijuna dolara ako dolazi s tržišta kao povratni poziv (2017. američki proizvođač zračnih jastuka, Takata a novčana kazna od milijardu dolara zbog eksplozije zračnih jastuka).
Na kraju bi organizacija izvršavala zadatke kontrole štete, poput analize uzroka uzroka, pripremajući 5 dokumenata, analizu stabla kvara, 8D dokument, itd., Umjesto da se koncentrira na razvoj softvera i kvalitetu.
U najgorim slučajevima, organizacija bi se uvukla u pravne tužbe koje je podnio kupac ako je pogođena značajka povezana sa sigurnošću / sigurnošću, poput sigurnosnog pristupa, zračnog jastuka, ABS-a (antiblokirni sustav) itd.
Preporučena literatura
- SDLC (životni ciklus razvoja softvera) faze, metodologije, procesi i modeli
- Značajke funkcionalnih zahtjeva i nefunkcionalnih zahtjeva
- Kako testirati specifikaciju softverskih zahtjeva (SRS)?
- 5 smrtonosnih grešaka u upravljanju zahtjevima i kako ih prevladati
- Kako testirati prijavu bez zahtjeva?
- Mjere za SSDLC (životni ciklus sigurnog razvoja softvera)
- Spiralni model - što je SDLC spiralni model?
- Što je SDLC model vodopada?