Analiza softverskih zahtjeva s primjerom
Na primjer, u kontekstu bankovne aplikacije funkcionalni zahtjev bit će kada korisnik odabere "Prikaži stanje" da mora moći pogledati svoje posljednje stanje na računu.
Softverski zahtjev također može biti nefunkcionalan, može biti zahtjev za performansama. Na primjer, nefunkcionalni zahtjev je da svaka stranica sustava bude vidljiva korisnicima unutar 5 sekundi.
Dakle, u osnovi softverski zahtjev je a
- Funkcionalni odn
- Nefunkcionalno
trebati koji se mora implementirati u sustav. Softverski zahtjevi obično se izražavaju kao izjave.
Vrste zahtjeva
- Poslovni zahtjevi: To su zahtjevi visoke razine koji su preuzeti iz poslovnog slučaja iz projekata. Na primjer, sustav usluga mobilnog bankarstva pruža bankarske usluge jugoistočnoj Aziji. Poslovni zahtjev koji se odlučuje za Indiju je sažetak računa i prijenos sredstava, dok se za Kinu odlučuje sažetak računa i plaćanje računa kao poslovni zahtjev
Zemlja | 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 dizajna: Ovi zahtjevi su detaljniji od poslovnih zahtjeva. Određuje sveukupni dizajn potreban za implementaciju poslovnog zahtjeva. Za našu obrazovnu organizaciju slučajevi upotrebe arhitekture i dizajna bili bi prijava, detalji tečaja itd. Zahtjevi bi bili kao što je prikazano 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.
Kupac će moći vidjeti kontrolnu ploču nepodmirenih računa registriranih izdavatelja računa. On može dodavati, mijenjati i brisati podatke o naplativu. Kupac može konfigurirati SMS, e-mail upozorenja za različite radnje naplate. Može vidjeti povijest prošlih plaćenih računa. Akteri koji pokreću ovaj slučaj upotrebe su klijenti banke ili pomoćno osoblje. |
- Zahtjevi sustava i integracije: Na najnižoj razini imamo sustavne i integracijske zahtjeve. To je detaljan opis svakog zahtjeva. Može biti u obliku korisničkih priča koje zapravo opisuju svakodnevni poslovni jezik. Zahtjevi su u izobilju detalja tako da programeri mogu početi kodirati. Ovdje je primjer Bill Modul plaćanja gdje će biti spomenut zahtjev za dodavanjem a Biller
Bill Plaćanje | Zahtjevi |
---|---|
dodati BillERS |
|
Ponekad za neki projekt možda nećete dobiti nikakve zahtjeve ili dokumente za rad. Ali još uvijek postoje drugi izvori zahtjeva koje možete uzeti u obzir za zahtjeve ili informacije, tako da svoj softver ili testni dizajn možete temeljiti na tim zahtjevima. Drugi izvori zahtjeva na koje se možete osloniti su
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 programerima
- Analizirajte prethodnu verziju sustava koja je već implementirana u sustav
- Analizirajte stariji dokument zahtjeva projekta
- Pogledajte prošla izvješća o pogreškama, neka su izvješća o pogreškama pretvorena u zahtjev za poboljšanje koji se može implementirati u trenutnu verziju
- Pogledajte vodič za instalaciju ako je dostupan da vidite koja je instalacija potrebna
- Analizirajte domenu ili znanje o industriji koje tim pokušava implementirati
Koji god izvor zahtjeva dobili, svakako ih dokumentirajte u nekom obliku, neka ih pregledaju drugi iskusni i obrazovani članovi tima.
Kako analizirati zahtjeve
Razmotrite primjer obrazovnog softverskog sustava u kojem se student može registrirati za različite tečajeve.
Proučimo kako analizirati zahtjeve. Zahtjevi moraju održavati standardnu kvalitetu svojih zahtjeva, uključujući različite vrste kvalitete zahtjeva
- Atomic
- Jedinstveno identificiran
- potpun
- Dosljedno i nedvosmisleno
- ući u trag
- Prioriteti
- Može se testirati
Da to shvatimo na primjeru, u tablici prikazanoj ovdje postoje tri stupca,
- Prvi stupac označava - "kvaliteta zahtjeva"
- Drugi stupac označava - "loš zahtjev s nekim problemom"
- Treći stupac isti je kao drugi stupac, ali – „pretvoren u dobar zahtjev“.
Kvaliteta zahtjeva | Primjer lošeg zahtjeva | Primjer dobrog zahtjeva |
---|---|---|
Atomic |
|
|
Jedinstveno identificiran | 1- Studenti će moći upisivati preddiplomske studije1- Studenti će moći upisivati poslijediplomske studije |
|
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 |
ući u trag | 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 podataka o korisniku-Prioritet 1 Upis predmeta-Prioritet 1 Pregled kartice izvješća-Prioritet 1 | Registrirajte se student-Prioritet 1 Održavanje korisničkih podataka-Prioritet 2Upis predmeta-Prioritet 1Pogledajte izvještajnu karticu-Prioritet3 |
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 |
Sada ćemo detaljno razumjeti svaki od ovih zahtjeva počevši od Atomik.
Atomic
Dakle, svaki zahtjev koji imate trebao bi biti atomičan, što znači da bi trebao biti na vrlo niskoj razini detalja da ne bi trebalo biti moguće razdvojiti na komponente. Ovdje ćemo vidjeti dva primjera za zahtjeve, na Atomic i jedinstveno identificirane razine zahtjeva.
Pa nastavimo s primjerom izgradnje sustava za domenu obrazovanja. Ovdje je loš uvjet “Studenti će moći upisivati dodiplomske i poslijediplomske studije” . Ovo je loš zahtjev jer nije atomičan jer govori o dva različita entiteta dodiplomski i poslijediplomski studij. Dakle, očito to nije dobar zahtjev, već loš zahtjev, tako da bi dobar zahtjev za dopisivanje bio razdvojiti ga na dva zahtjeva. Dakle, jedan govori o upisu na preddiplomski studij, a drugi o upisu na poslijediplomski studij.
Jedinstveno identificiran
Slično sljedećem zahtjevu kvalitete je provjera jedinstvene identificiranosti, ovdje imamo dva odvojena zahtjeva, ali oba imaju isti ID#1. Dakle, ako upućujemo na naš zahtjev s referencom na ID#, ali nije jasno na koji točan zahtjev mislimo na dokument ili drugi dio sustava jer oba imaju isti ID#1. Dakle, odvajanje s jedinstvenim ID-ovima, tako dobar zahtjev će se ponovno vratiti kao odjeljak 1- upisi na tečajeve, i ima dva zahtjeva: 1.1 id je upis na dodiplomske tečajeve dok je 1.2 id upis na poslijediplomske tečajeve.
potpun
Također, svaki zahtjev treba biti potpun. Na primjer, ovdje loš zahtjev kaže da će se "profesorski korisnik prijaviti u sustav davanjem svog korisničkog imena, lozinke i drugih relevantnih informacija". Ovdje druge relevantne informacije nisu jasne, pa bi ostale relevantne informacije trebale biti navedene u dobrom zahtjevu kako bi zahtjev bio potpun.
Dosljedno i nedvosmisleno
Dalje, svaki pojedini zahtjev trebao bi biti dosljedan i nedvosmislen, tako da ovdje, na primjer, imamo zahtjeve "Student će imati ili dodiplomske ili poslijediplomske tečajeve, ali ne oboje" ovo je jedan zahtjev postoji neki drugi zahtjev koji kaže "Neki kolegiji će biti otvoren i za studente dodiplomskih i poslijediplomskih studija”.
Problem u ovom zahtjevu je taj što se iz prvog zahtjeva čini da su kolegiji podijeljeni u dvije kategorije pod diplomskim kolegijima i poslijediplomskim tečajevima i student može izabrati jedno od dva, ali ne oboje. Ali kada pročitate drugi zahtjev, on je u sukobu s prvim zahtjevom i govori da će neki tečajevi biti otvoreni i za poslijediplomske i za preddiplomske.
Dakle, očito je pretvoriti ovaj loš zahtjev u dobar zahtjev koji glasi "Student će imati ili dodiplomske ili poslijediplomske tečajeve, ali ne oboje". Što znači da će svaki predmet biti označen kao preddiplomski ili poslijediplomski
ući u trag
Svaki pojedini zahtjev trebao bi se moći pratiti jer već postoje različite razine zahtjeva, već smo vidjeli da na vrhu imamo poslovne zahtjeve, a zatim imamo arhitektonske i dizajnerske zahtjeve nakon kojih slijede zahtjevi za integraciju sustava.
Sada kada pretvaramo poslovne zahtjeve u arhitektonske i dizajnerske zahtjeve ili pretvaramo arhitektonske i dizajnerske zahtjeve u zahtjeve integracije sustava, mora postojati sljedivost. Što znači da bismo trebali biti u mogućnosti uzeti svaki poslovni zahtjev i preslikati ga na odgovarajući jedan ili više softverskih arhitektonskih i dizajnerskih zahtjeva. Dakle, ovdje je primjer lošeg zahtjeva koji kaže "Održavanje podataka o studentu – preslikano na BRD req ID?" ovdje se ne navodi ID zahtjeva.
Dakle, pretvarajući ga u dobar zahtjev, kaže se ista stvar, ali je preslikan s ID-om zahtjeva 4.1. Dakle, mapiranje bi trebalo postojati za svaki zahtjev. Na isti način na koji imamo zahtjev za mapiranje visoke i niske razine, preslikavanje također postoji između sustava i integracijskog zahtjeva na kod koji implementira taj zahtjev i također postoji preslikavanje između sustava i integracijskog zahtjeva na testni slučaj koji testira taj određeni zahtjev .
Dakle, ova sljedivost postoji kroz cijeli projekt
Prioriteti
Prioriteti | Prijavljeni student-Prioritet 1 Održavanje korisničkih informacija - prioritet 1 Upis tečajeva-Prioritet 1 Pregledajte karticu izvješća - prioritet 1 |
Registrirajte studentski prioritet 1 Održavanje korisničkih informacija - prioritet 2 Upis tečajeva-Prioritet 1 Pregledajte izvještajnu karticu-Prioritet3 |
Tada se svakom pojedinom zahtjevu mora dati prioritet, tako da tim ima smjernicu koji zahtjev može prvi implementirati, a koji kasnije. Ovdje možete vidjeti loš prioritet koji ima registraciju učenika, održavanje korisničkih podataka i svakom pojedinom zahtjevu dat je prioritet-1. Sve ne može imati isti prioritet, tako da se zahtjevima može dati prioritet. Dakle, primjer dobrog zahtjeva ovdje je registracija studenta i upis tečajeva s najvišim prioritetom 1, dok su podaci o održavanju korisnika ispod s prioritetom 2, a zatim imamo pregled izvješća s prioritetom 3
Može se testirati
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 |
Svaki zahtjev bi se trebao moći testirati, ovdje je loš zahtjev "svaka stranica sustava će se učitati u prihvatljivom vremenskom okviru". Sada postoje dva problema s ovim zahtjevom, prvi je da svaka stranica znači da može postojati mnogo stranica, što će povećati napor testiranja. Drugi problem je što kaže da će se stranica učitati u prihvatljivom vremenskom okviru, koji je prihvatljivi vremenski okvir? Kome prihvatljivo. Dakle, moramo pretvoriti argument koji se ne može testirati u argument koji se može testirati, koji konkretno govori o kojoj stranici govorimo o "stranicama za registraciju studenata i upis tečajeva", a također je dan prihvatljivi vremenski okvir koji iznosi 5 sekundi.
Zaključak
Dakle, ovako moramo gledati na svaki zahtjev na odgovarajućoj razini. Na primjer, ako ćemo izraditi softver s obzirom na zahtjeve sustava i integracije. Moramo proučiti sustav i integracijske zahtjeve dane u specifikacijama softverskih zahtjeva ili korisničkim pričama i primijeniti na svaki pojedini zahtjev kvalitete. Zatim provjerite je li svaki zahtjev atomski, jedinstveno identificiran i potpun i tako dalje.