Tarkvaranõuete analüüs näitega
Charles Moore
Näiteks pangarakenduse kontekstis on funktsionaalne nõue, kui klient valib "Vaata saldot", peab tal olema võimalik vaadata oma viimast kontojääki.
Tarkvaranõue võib olla ka mittefunktsionaalne, see võib olla jõudlusnõue. Näiteks mittefunktsionaalne nõue on see, et süsteemi iga leht peaks olema kasutajatele nähtav 5 sekundi jooksul.
Nii et põhimõtteliselt tarkvara nõue on a
- Funktsionaalne või
- Mittefunktsionaalne
vajadus mis tuleb süsteemi juurutada. Tarkvaranõuet väljendatakse tavaliselt väidetena.
Nõuete tüübid
- Ärinõuded: Need on kõrgetasemelised nõuded, mis on võetud projektide ärimudelist. Näiteks mobiilipangateenuste süsteem pakub pangateenuseid Kagu-Aasiasse. India puhul on ärinõue konto kokkuvõte ja rahaülekanne, Hiina puhul aga konto kokkuvõte ja arvete tasumine on ärinõue.
| Riik | Pangafunktsioone või -teenuseid pakkuv ettevõte |
|---|---|
| India | Konto kokkuvõte ja rahaülekanne |
| Hiina | Konto kokkuvõte ja Bill Makse |
- Archikonstruktsiooni- ja disaininõuded: need nõuded on üksikasjalikumad kui ärinõuded. See määrab ettevõtte nõuete rakendamiseks vajaliku üldise disaini. Meie haridusorganisatsiooni jaoks on arhitektuuri ja disaini kasutusjuhtumiteks sisselogimine, kursuse üksikasjad jne. Nõue oleks selline, nagu allpool näidatud.
| Panganduse kasutamise juhtum | Nõue |
|---|---|
| Bill Makse | See kasutusjuht kirjeldab, kuidas klient saab netipanka sisse logida ja seda kasutada Bill Maksemehhanism.
Klient näeb registreeritud arve esitajate tasumata arvete armatuurlauda. Ta saab lisada, muuta ja kustutada arve esitaja üksikasju. Klient saab erinevate arveldustoimingute jaoks seadistada SMS-i, e-posti märguandeid. Ta näeb varasemate tasutud arvete ajalugu. Selle kasutusjuhtumiga alustajad on pangakliendid või tugipersonal. |
- Süsteemi ja integratsiooni nõuded: Madalaimal tasemel on meil süsteemi- ja integratsiooninõuded. See on iga nõude üksikasjalik kirjeldus. See võib olla kasutajalugude kujul, mis tõesti kirjeldavad igapäevast ärikeelt. Nõuded on palju üksikasju, et arendajad saaksid alustada kodeerimist. Siin on näide Bill Maksemoodul, kus mainitakse a lisamise nõuet Biller
| Bill Makse | Nõuded |
|---|---|
| lisama Billtv |
|
Mõnikord ei pruugi te mõne projekti puhul saada mingeid nõudeid ega dokumente, millega töötada. Kuid siiski on ka muid nõuete allikaid, mida saate nõude või teabe puhul arvesse võtta, et saaksite oma tarkvara või katsekujunduse nendele nõuetele tugineda. Nii et muud nõuete allikad, millele võite tugineda, on
Muud nõuete allikad
- Teadmiste edasiandmine kolleegidelt või töötajatelt, kes juba selle projekti kallal töötavad
- Rääkige projektist ärianalüütikule, tootejuhile, projektijuhile ja arendajatele
- Analüüsige eelmist süsteemi versiooni, mis on juba süsteemi juurutatud
- Analüüsige projekti vanemat nõuete dokumenti
- Vaadake varasemaid veaaruandeid, mõned veaaruanded on muudetud täiustustaotluseks, mida saab rakendada praeguses versioonis
- Vaadake installijuhendist, kui see on saadaval, et näha, millised installid on vajalikud
- Analüüsige domeeni või valdkonna teadmisi, mida meeskond püüab rakendada
Olenemata nõuete allikast, dokumenteerige need kindlasti mingil kujul, paluge need teistelt kogenud ja asjatundlikult meeskonnaliikmetelt üle vaadata.
Kuidas nõudeid analüüsida
Mõelge näiteks haridustarkvarasüsteemile, kus õpilane saab registreeruda erinevatele kursustele.
Uurime, kuidas nõudeid analüüsida. Nõuded peavad säilitama oma nõude standardkvaliteedi, hõlmab erinevat tüüpi kvaliteedinõudeid
- Atomic
- Unikaalselt tuvastatud
- täielik
- Järjepidev ja üheselt mõistetav
- Jälgitav
- Esikohale seatud
- Katsetatav
Mõistke seda näitega, siin näidatud tabelis on kolm veergu,
- Esimene veerg tähistab - "nõude kvaliteet"
- Teine veerg näitab - "halb nõue mõne probleemiga"
- Kolmas veerg on sama, mis teine veerg, kuid – „teiserdatud heaks nõudeks”.
| Nõue kvaliteet | Halva nõude näide | Hea nõude näide |
|---|---|---|
| Atomic |
|
|
| Unikaalselt tuvastatud | 1- Õpilased saavad registreeruda bakalaureuseõppe kursustele1- Õpilased saavad registreeruda kraadiõppesse |
|
| täielik | Professori kasutaja logib süsteemi sisse, esitades oma kasutajanime, parooli ja muu asjakohase teabe | Professori kasutaja logib süsteemi sisse, sisestades oma kasutajanime, parooli ja osakonna koodi |
| Järjepidev ja üheselt mõistetav | Üliõpilasel on kas bakalaureuse- või kraadiõppe kursused, kuid mitte mõlemad. Mõned kursused on avatud nii bakalaureuse- kui ka magistriõppe lõpetajatele | Üliõpilasel on kas bakalaureuse- või magistriõppe lõpetajad, kuid mitte mõlemad |
| Jälgitav | Kas säilitada õpilaste teave kaardistatud BRD req.ID-ga? | Säilitage õpilase teave – kaardistatud BRD nõudega ID 4.1 |
| Esikohale seatud | Registreeritud üliõpilane - Prioriteet 1 Säilitage kasutajateavet - Prioriteet 1 Registreeruge kursustele - Prioriteet 1 Kuva aruandekaart - Prioriteet 1 | Registreerige üliõpilane-prioriteet 1. Kasutajateabe säilitamine - prioriteet 2. Registreeruge kursustele - Prioriteet 1 Kuva aruandekaart - Prioriteet3 |
| Katsetatav | Süsteemi iga leht laaditakse vastuvõetava aja jooksul | Registreerige üliõpilased ja registreeruge kursustele. Süsteemi lehed laaditakse 5 sekundi jooksul |
Nüüd mõistame kõiki neid nõudeid üksikasjalikult, alustades Atomjää.
Atomic
Seega peaks iga teie nõue olema tuumakas, mis tähendab, et see peaks olema väga madala detailitasemega ja seda ei tohiks olla võimalik komponentideks eraldada. Siin näeme kahte nõuete näidet, aadressil Atomic ja üheselt tuvastatud nõuete tasemed.
Nii et jätkame haridusvaldkonna süsteemi ehitamise näitega. Siin on halb nõue "Õpilased saavad registreeruda bakalaureuse- ja magistriõppesse". See on halb nõue, sest see ei ole tuumakas, sest see räägib kahest erinevast üksusest bakalaureuse- ja magistriõppes. Nii et ilmselgelt pole see hea, vaid halb nõue, nii et kirjavahetuse hea nõue oleks selle eraldamine kaheks nõudeks. Nii et üks räägib registreerumisest bakalaureuseõppesse, teine aga magistriõppesse registreerumisest.
Unikaalselt tuvastatud
Sarnaselt on järgmise kvaliteedinõudeks kordumatu tuvastamise kontrollimine. Siin on meil kaks eraldi nõuet, kuid mõlemal on sama ID#1. Seega, kui viitame oma nõudele viidates ID#-le, kuid pole selge, millist täpselt nõuet me viitame dokumendile või muule süsteemi osale, kuna mõlemal on sama ID#1. Eraldades kordumatu ID-ga, tagastatakse nii hea nõue uuesti jaotisesse 1 – kursusele registreerumine ja sellel on kaks nõuet: 1.1 id on registreerumine bakalaureuseõppesse ja 1.2 id on registreerumine magistriõppesse.
täielik
Samuti peaksid kõik nõuded olema täidetud. Näiteks siin ütleb halb nõue "professor kasutaja logib süsteemi sisse, esitades oma kasutajanime, parooli ja muu asjakohase teabe". Siin ei ole muu asjakohane teave selge, seega tuleks muu asjakohane teave nõude täielikuks muutmiseks selgelt välja tuua.
Järjepidev ja üheselt mõistetav
Järgmisena peaksid kõik nõuded olema järjepidevad ja üheselt mõistetavad, nii et näiteks siin on meil nõuded: "Üliõpilasel on kas bakalaureuseõppe või magistriõppe kursused, kuid mitte mõlemad" see on üks nõue, on veel mõni nõue, mis ütleb: "Mõnel kursusel on olema avatud nii bakalaureuse- kui ka magistriõppe üliõpilastele”.
Selle nõude probleem seisneb selles, et alates esimesest nõudest näib, et kursused jagunevad kraadiõppe ja kraadiõppe kursuste alla kahte kategooriasse ning üliõpilasel on võimalik valida kahest, kuid mitte mõlemast. Kuid kui lugeda muud nõuet, on see vastuolus esimese nõudega ja ütleb, et mõned kursused on avatud nii magistri- kui ka bakalaureuseõppe üliõpilastele.
Seega on ilmne muuta see halb nõue heaks nõudeks, milleks on "üliõpilasel on kas bakalaureuse- või kraadiõppe kursused, kuid mitte mõlemad". Mis tähendab, et iga kursus märgitakse kas bakalaureuseõppeks või kraadiõppeks
Jälgitav
Iga nõue peaks olema jälgitav, kuna nõuete tasemed on juba erinevad, nägime juba, et meil olid ülaosas ärinõuded ja seejärel on meil arhitektuuri- ja disaininõuded, millele järgnesid süsteemiintegratsiooni nõuded.
Nüüd, kui muudame ärinõuded arhitektuuri- ja disaininõueteks või muudame arhitektuuri- ja disaininõuded süsteemiintegratsiooninõueteks, peab olema jälgitavus. Mis tähendab, et me peaksime suutma võtta kõik ärinõuded ja kaardistada need vastava ühe või mitme tarkvaraarhitektuuri- ja disaininõudega. Siin on näide halvast nõudest, mis ütleb: „Säilitada üliõpilasteave – vastendatud BRD req ID-ga?” nõude ID-d pole siin antud.
Nii et selle heaks nõudeks teisendamine ütleb sama asja, kuid see on kaardistatud nõude ID-ga 4.1. Seega peaks kaardistamine olema iga nõude jaoks olemas. Samamoodi on meil kõrge ja madala taseme vastendamise nõue, vastendus on olemas ka süsteemi ja integratsiooninõude vahel koodiga, mis seda nõuet rakendab, ning süsteemi ja integratsiooninõude vahel on vastendus testjuhtumiga, mis seda konkreetset nõuet testib. .
Seega on see jälgitavus kogu projekti ulatuses
Esikohale seatud
| Esikohale seatud | Registreeritud üliõpilane – 1. prioriteet Kasutajateabe säilitamine – prioriteet 1 Registreeru kursustele – 1. prioriteet Kuva aruandekaart – prioriteet 1 |
Registreerige õpilase prioriteet 1 Kasutajateabe säilitamine – prioriteet 2 Registreeru kursustele – 1. prioriteet Kuva aruandekaart-Priority3 |
Seejärel tuleb iga nõue prioriteediks seada, nii et meeskonnal on juhised, milliseid nõudeid saab kõigepealt rakendada ja milliseid saab teha hiljem. Siin on näha õpilase registreerimise halb prioriteet, kasutajateabe haldamine ja igale nõudele on antud prioriteet-1. Kõik ei saa olla sama prioriteediga, seega saab nõudeid prioriteediks seada. Nii et siin on hea nõude näide registreerida üliõpilane ja registreeruda kursustele on kõrgeim prioriteet 1, samas kui kasutajateabe säilitamine on prioriteediga 2 allpool ja siis on meil aruande kaart prioriteet-3
Katsetatav
| Katsetatav | Süsteemi iga leht laaditakse vastuvõetava aja jooksul | Registreerige üliõpilased ja registreeruge kursustele. Süsteemi lehed laaditakse 5 sekundi jooksul |
Iga nõue peaks olema testitav, siin on halb nõue "iga süsteemi leht laaditakse vastuvõetava aja jooksul". Nüüd on selle nõudega kaks probleemi, esiteks on see, et iga leht võib olla palju, mis ajab testimispüüdlused õhku. Teine probleem on see, et öeldakse, et leht laaditakse vastuvõetava aja jooksul, milline on nüüd vastuvõetav ajavahemik? Kellele vastuvõetav. Seega peame mittetestitava argumendi teisendama testitavaks argumendiks, mis annab konkreetselt teada, millisest leheküljest me räägime "registreerige õpilane ja registreeruge kursustele" ning antakse ka vastuvõetav ajavahemik, mis on 5 sekundit.
Järeldus
Nii et me peame vaatama igat nõuet sobival tasemel. Näiteks kui kavatseme luua tarkvara, mis on seotud süsteemi- ja integratsiooninõuetega. Peame uurima tarkvaranõuete spetsifikatsioonides või kasutajalugudes toodud süsteemi- ja integratsiooninõudeid ning rakendama iga nõude kvaliteeti. Seejärel kontrollige, kas iga nõue on aatomiline, unikaalselt identifitseeritud ja täielik jne.
