Analiza softverskih zahtjeva s primjerom

Softverski zahtjev je funkcionalna ili nefunkcionalna potreba koja se mora implementirati u sustavu. Funkcionalno znači pružanje određene usluge korisniku.

Na primjer, u kontekstu bankarske aplikacije, funkcionalni zahtjev je da kada korisnik odabere "Prikaži stanje", treba moći vidjeti svoje najnovije stanje računa.

Softverski zahtjev može biti i nefunkcionalan, poput zahtjeva za performansama. Na primjer, nefunkcionalni zahtjev može navoditi da se svaka stranica sustava treba učitati za korisnike unutar 5 sekundi.

Dakle, u osnovi softverski zahtjev je a

• Funkcionalno ili
• Nefunkcionalno

trebati koji se mora implementirati u sustav. Softverski zahtjevi se obično izražavaju kao izjave.

Vrste zahtjeva

Poslovni zahtjeviOvo su zahtjevi visoke razine preuzeti iz poslovnog slučaja projekta. Na primjer, sustav mobilnog bankarstva pruža bankarske usluge jugoistočnoj Aziji. Poslovni zahtjev određen za Indiju je sažetak računa i prijenos sredstava, dok je za Kinu to sažetak računa i plaćanje računa.

Država	Tvrtka koja pruža bankarske funkcije ili usluge
Indija	Sažetak računa i prijenos sredstava
Kina	Sažetak računa i Bill Plaćanje

Archizahtjevi strukture i dizajnaOvi zahtjevi su detaljniji od poslovnih zahtjeva i pokreću arhitekturu rješenja. Oni određuju cjelokupni dizajn potreban za implementaciju poslovnog zahtjeva. Za obrazovnu organizaciju, tipični arhitektonski i dizajnerski slučajevi upotrebe uključuju prijavu, detalje o tečaju i upis. Zahtjev bi bio prikazan u nastavku.

Slučaj korištenja u bankarstvu

Zahtjev

Bill Plaćanje

Ovaj slučaj upotrebe opisuje kako se klijent može prijaviti u net banking i koristiti Bill Mogućnost plaćanja. Korisnik može vidjeti nadzornu ploču s nepodmirenim računima za registrirane platitelje. Korisnik može dodavati, mijenjati i brisati podatke o platiteljima. Korisnik može konfigurirati SMS i e-mail upozorenja za različite radnje naplate. Korisnik može pregledati povijest prošlih plaćenih računa. Akteri koji započinju ovaj slučaj upotrebe su bankovni klijenti ili osoblje za podršku.

Zahtjevi sustava i integracijeNa najnižoj razini imamo sistemske i integracijske zahtjeve. Pruža detaljan opis svakog zahtjeva. Može se prikazati kao korisničke priče napisane svakodnevnim poslovnim jezikom. Zahtjevi sadrže obilje detalja tako da programeri mogu započeti s kodiranjem. Bill Primjer modula za plaćanje u nastavku prikazuje zahtjev za dodavanje izdavatelja računa.

Bill Plaćanje	Zahtjevi
dodati BillERS	Naziv pružatelja komunalnih usluga, broj korisnika, automatska plaćanja – Da/Ne, plaćanje u cijelosti Bill – Da/Ne, Ograničenje automatskog plaćanja – Ne plaćajte ako Bill je iznad navedenog iznosa

Ponekad za projekt možda nećete dobiti nikakve zahtjeve ili dokumente za rad. Čak i tada, postoje drugi izvori informacija o zahtjevima na koje se možete osloniti kao osnovu za dizajn softvera ili testiranja. Ostali izvori zahtjeva na koje se možete osloniti navedeni su u nastavku.

Drugi izvori zahtjeva

• Prijenos znanja od kolega ili zaposlenika koji već rade na tom projektu
• Razgovarajte o projektu s poslovnim analitičarom, voditeljem proizvoda, voditeljem projekta i razvojnim inženjerima
• Analizirajte prethodnu verziju sustava koja je već implementirana
• Analizirajte starije dokumente zahtjeva iz projekta
• Revpregledajte prošla izvješća o greškama; neka izvješća o greškama pretvaraju se u zahtjeve za poboljšanja koja se mogu implementirati u trenutnoj verziji
• Provjerite vodič za instalaciju, ako je dostupan, kako biste vidjeli koje su instalacije potrebne
• Analizirajte znanje domene ili industrije koje tim pokušava implementirati

Bez obzira na izvor zahtjeva koji koristite, dokumentirajte ih u zajedničkom formatu i neka ih pregledaju iskusni članovi tima.

Kako analizirati zahtjeve

Razmotrimo primjer obrazovnog softverskog sustava u kojem se student može prijaviti za različite tečajeve.

Proučimo kako analizirati zahtjeve. Svaki zahtjev mora održavati skup standardnih atributa kvalitete, koji uključuju sljedeće:

• Atomic
• Jedinstveno identificiran
• potpun
• Dosljedno i nedvosmisleno
• Tracmoguće
• Prioriteti
• Može se testirati

Sljedeća tablica ilustrira svaki atribut s tri stupca:

1. Prvi stupac označava - "kvaliteta zahtjeva"
2. Drugi stupac označava - "loš zahtjev s nekim problemom"
3. Treći stupac prikazuje isti zahtjev „pretvoren u dobar zahtjev“.

Kvaliteta zahtjeva	Primjer lošeg zahtjeva	Primjer dobrog zahtjeva
Atomic	Studenti će moći upisivati ​​preddiplomske i poslijediplomske studije	Studenti će se moći upisati na preddiplomske studije. Studenti će se moći upisati na poslijediplomske studije.
Jedinstveno identificiran	1- Studenti će se moći upisati na preddiplomske studije. 1- Studenti će se moći upisati na poslijediplomske studije.	Upis na tečajeve. Studenti će se moći upisati na preddiplomske tečajeve. Studenti će se moći upisati na poslijediplomske tečajeve.
potpun	Korisnik profesor prijavit će se u sustav unosom svog korisničkog imena, lozinke i drugih relevantnih podataka	Korisnik profesor prijavit će se u sustav unosom svog korisničkog imena, lozinke i šifre odjela
Dosljedno i nedvosmisleno	Student će imati ili dodiplomske ili poslijediplomske tečajeve, ali ne oboje. Neki tečajevi bit će otvoreni i za preddiplomske i za poslijediplomske	Student će imati ili dodiplomski ili postdiplomski studij, ali ne oboje
Tracmoguće	Održavati informacije o studentima mapirane na BRD req.ID?	Održavajte informacije o studentima - mapirano na BRD req ID 4.1
Prioriteti	Registrirani student - Prioritet 1. Održavanje korisničkih podataka - Prioritet 1. Upis tečajeva - Prioritet 1. Pregled svjedodžbe - Prioritet 1	Registracija učenika - Prioritet 1. Održavanje korisničkih podataka - Prioritet 2. Upis tečajeva - Prioritet 1. Pregled svjedodžbe - Prioritet 3
Može se testirati	Svaka stranica sustava će se učitati u prihvatljivom vremenskom okviru	Stranice sustava za registraciju učenika i upis tečajeva učitat će se unutar 5 sekundi

Razumijemo svaki od ovih atributa detaljnije, počevši s Atomik.

Atomic

Svaki zahtjev treba biti atomski, što znači da mora biti na najnižoj razini detalja i ne može se dalje raščlaniti na komponente. Sljedeći primjeri uspoređuju atomske i neatomske zahtjeve.

Nastavak s primjerom sustava obrazovne domene: Ovdje je loš zahtjev „Studenti će se moći upisati na preddiplomske i poslijediplomske studije“. Ovo je loš zahtjev jer nije atomski - miješa dva različita entiteta, preddiplomske i poslijediplomske studije. Odgovarajući dobar zahtjev dijeli ga na dva zahtjeva. Jedan zahtjev pokriva upis na preddiplomske studije, a drugi pokriva upis na poslijediplomske studije.

Jedinstveno identificiran

Sljedeći atribut kvalitete je jedinstvena identifikacija. U lošem primjeru, dva odvojena zahtjeva dijele isti ID#1. Ako tim referencira zahtjev prema njegovom ID-u, postaje nejasno na koji se od ta dva misli. Dobar zahtjev ih pregrupira pod Odjeljak 1 - Upis na kolegije, s podzahtjevima 1.1 (upis na preddiplomske kolegije) i 1.2 (upis na poslijediplomske kolegije).

potpun

Svaki zahtjev mora biti potpun. Na primjer, ovdje loš zahtjev kaže da će se „profesor korisnik prijaviti u sustav unosom svog korisničkog imena, lozinke i drugih relevantnih informacija“. „Ostale relevantne informacije“ su nejasne. Potpuni zahtjev navodi točna polja, poput šifre odjela, koja profesor mora navesti.

Dosljedno i nedvosmisleno

Svaki zahtjev treba biti dosljedan i nedvosmislen. U lošem primjeru, jedan zahtjev navodi „Student će imati ili preddiplomske ili poslijediplomske kolegije, ali ne oboje“, dok drugi navodi „Neki kolegiji bit će otvoreni i za preddiplomske i za poslijediplomske studente“.

Prvi zahtjev podrazumijeva da su kolegiji podijeljeni u dvije ekskluzivne kategorije, ali drugi zahtjev mu proturječi otvarajući neke kolegije objema skupinama.

Dobar zahtjev rješava sukob jasno navodeći da je svaki kolegij označen ili kao preddiplomski ili kao poslijediplomski, a student se može upisati samo na kolegije jedne kategorije.

Tracmoguće

Svaki zahtjev mora biti tracmoguće jer zahtjevi postoje na više razina: poslovnoj, arhitektonskoj i dizajnerskoj te sistemskoj i integracijskoj.

Kada pretvorite poslovni zahtjev u arhitektonske i dizajnerske zahtjeve ili arhitektonske i dizajnerske zahtjeve u sistemske i integracijske zahtjeve, tracMogućnost rada mora se očuvati. Svaki poslovni zahtjev trebao bi se mapirati na jedan ili više arhitektonskih i dizajnerskih zahtjeva. U lošem primjeru „Održavati podatke o studentima – mapirano na BRD ID zahtjeva?“, nedostaje ID zahtjeva.

Zahtjev za dobar sadržaj bilježi istu izjavu, ali se eksplicitno preslikava na BRD zahtjev ID 4.1. Svaki zahtjev mora imati trackarta mogućnostipingSistemski i integracijski zahtjevi također bi se trebali preslikavati na kod koji ih implementira i na testne slučajeve koji ih provjeravaju.

TracStoga se jednostavnost provodi od početka do kraja kroz cijeli projekt.

Prioriteti

Svaki zahtjev mora imati prioritet kako bi tim znao što prvo implementirati, a što može pričekati. U lošem primjeru, Registracija učenika, Održavanje korisničkih podataka, Upis tečajeva i Pregled izvješća postavljeni su na Prioritet 1. Sve ne može biti Prioritet 1, stoga zahtjevi moraju biti realno rangirani. Dobar primjer daje Registraciji učenika i Upisu tečajeva najviši Prioritet 1, Održavanju korisničkih podataka Prioritet 2 i Pregledu izvješća Prioritet 3.

Može se testirati

Svaki zahtjev treba biti testiran. Loš primjer, „svaka stranica sustava će se učitati u prihvatljivom vremenskom okviru“, nije testiran iz dva razloga. Prvo, „svaka stranica“ može značiti desetke stranica, što dodatno povećava napor testiranja. Drugo, „prihvatljiv vremenski okvir“ je nedefiniran - prihvatljiv kome i u odnosu na koju referentnu vrijednost? Dobar zahtjev rješava oba problema imenovanjem određenih stranica („stranice za registraciju studenata i upis tečajeva“) i postavljanjem mjerljivog cilja od 5 sekundi.

Pitanja i odgovori