Tarkvaranõuete analüüs näitega
Charles Moore
⚡ Nutikas kokkuvõte
Tarkvaranõuete analüüs jagab sidusrühmade vajadused funktsionaalseteks ja mittefunktsionaalseteks osadeks, järjestab need äri-, arhitektuuri- ja süsteemitasandil ning seejärel kontrollib igaüht neist kvaliteediomaduste suhtes, et tagada testitav ja tracteostatav, prioriteetidega spetsifikatsioon.
Tarkvaranõue on funktsionaalne või mittefunktsionaalne vajadus, mis tuleb süsteemis rakendada. Funktsionaalne tähendab kasutajale konkreetse teenuse pakkumist.
Näiteks pangarakenduse kontekstis on funktsionaalne nõue, et kui klient valib „Kuva saldo“, peaks ta saama vaadata oma viimast konto saldot.
Tarkvaranõue võib olla ka mittefunktsionaalne, näiteks jõudlusnõue. Näiteks võib mittefunktsionaalne nõue sätestada, et süsteemi iga leht peaks kasutajatele laadima 5 sekundi jooksul.
Nii et põhimõtteliselt tarkvara nõue on a
- Funktsionaalne või
- Mittefunktsionaalne
vajadus mis tuleb süsteemi juurutada. Tarkvaranõuded väljendatakse tavaliselt avaldustena.
Nõuete tüübid
ÄrinõudedNeed on projekti äriplaanist võetud üldised nõuded. Näiteks mobiilne pangateenuste süsteem pakub pangateenuseid Kagu-Aasias. India puhul on ärinõudeks konto kokkuvõte ja rahaülekanne, Hiina puhul aga konto kokkuvõte ja arvete maksmine.
| 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õudedNeed nõuded on detailsemad kui ärinõuded ja juhivad lahenduse arhitektuuri. Need määravad ärinõude rakendamiseks vajaliku üldise disaini. Haridusasutuse puhul hõlmavad tüüpilised arhitektuuri ja disaini kasutusjuhud sisselogimist, kursuse üksikasju ja registreerumist. Nõue oleks allpool näidatud.
| Panganduse kasutamise juhtum | Nõue |
|---|---|
| Bill Makse | See kasutusjuht kirjeldab, kuidas klient saab netipanka sisse logida ja seda kasutada Bill Maksevõimalus. Klient näeb registreeritud arvete esitajate tasumata arvete juhtpaneeli. Klient saab arve esitaja andmeid lisada, muuta ja kustutada. Klient saab seadistada SMS- ja e-posti teel saadetavaid märguandeid erinevate arveldustoimingute jaoks. Klient saab vaadata varasemate tasutud arvete ajalugu. Selle kasutusjuhtumi algatajateks on pangakliendid või tugipersonal. |
Süsteemi ja integratsiooni nõudedMadalaimal tasemel on meil süsteemi- ja integratsiooninõuded. See annab iga nõude üksikasjaliku kirjelduse. Seda saab jäädvustada igapäevases ärikeeles kirjutatud kasutajalugudena. Nõuded sisaldavad rohkelt detaile, et arendajad saaksid kodeerima hakata. Bill Allolev maksemooduli näide illustreerib arve esitaja lisamise nõuet.
| Bill Makse | Nõuded |
|---|---|
| lisama Billtv | Kommunaalteenuse pakkuja nimi, kliendi number, automaatsed maksed – jah/ei, kogu summa tasumine Bill – Jah/Ei, automaatse makse limiit – Ära maksa, kui Bill on üle määratud summa |
Mõnikord ei pruugi te projekti jaoks saada mingeid nõudeid ega dokumente, millega töötada. Isegi siis on olemas ka teisi nõueteabe allikaid, millele saate oma tarkvara või testi kujundamisel toetuda. Muud nõuete allikad, millele saate toetuda, on loetletud allpool.
Muud nõuete allikad
- Teadmiste edasiandmine kolleegidelt või töötajatelt, kes juba selle projekti kallal töötavad
- Arutage projekti ärianalüütiku, tootejuhi, projektijuhi ja arendajatega
- Analüüsige juba rakendatud süsteemi eelmist versiooni
- Analüüsi projekti vanemaid nõuete dokumente
- Revvaadake varasemaid veateateid; mõned veateated teisendatakse täiustustaotlusteks, mida saab praeguses versioonis rakendada
- Vajalike paigalduste kohta vaata paigaldusjuhendit (kui see on saadaval).
- Analüüsige valdkonda või valdkonda puudutavat teadmist, mida meeskond püüab rakendada
Olenemata sellest, millist nõuete allikat te kasutate, dokumenteerige need ühises vormingus ja laske kogenud meeskonnaliikmetel need üle vaadata.
Kuidas nõudeid analüüsida
Vaatleme haridustarkvara süsteemi näidet, kus õpilane saab registreeruda erinevatele kursustele.
Uurime, kuidas nõudeid analüüsida. Igal nõudel peab olema standardsete kvaliteediomaduste kogum, mis hõlmab järgmist:
- Atomic
- Unikaalselt tuvastatud
- täielik
- Järjepidev ja üheselt mõistetav
- Tracvõimeline
- Esikohale seatud
- Katsetatav
Järgmises tabelis on iga atribuut illustreeritud kolme veeru abil:
- Esimene veerg tähistab - "nõude kvaliteet"
- Teine veerg näitab - "halb nõue mõne probleemiga"
- Kolmas veerg näitab sama nõuet „teisendatud heaks nõudeks”.
| Nõue kvaliteet | Halva nõude näide | Hea nõude näide |
|---|---|---|
| Atomic | Õpilased saavad registreeruda bakalaureuse- ja magistriõppesse | Tudengid saavad registreeruda bakalaureuseõppe kursustele. Tudengid saavad registreeruda magistriõppe kursustele. |
| Unikaalselt tuvastatud | 1- Tudengid saavad registreeruda bakalaureuseõppe kursustele. 1- Tudengid saavad registreeruda magistriõppe kursustele. | Kursusele registreerumine. Tudengid saavad registreeruda bakalaureuseõppe kursustele. Tudengid saavad registreeruda magistriõppe kursustele. |
| 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 |
| Tracvõimeline | 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. Kasutajateabe haldamine – prioriteet 1. Kursustele registreerumine – prioriteet 1. Hinnetelehe vaatamine – prioriteet 1 | Õpilase registreerimine – prioriteet 1. Kasutajateabe haldamine – prioriteet 2. Kursustele registreerimine – prioriteet 1. Hinnetelehe vaatamine – prioriteet 3 |
| Katsetatav | Süsteemi iga leht laaditakse vastuvõetava aja jooksul | Registreerige üliõpilased ja registreeruge kursustele. Süsteemi lehed laaditakse 5 sekundi jooksul |
Vaatleme kõiki neid omadusi üksikasjalikumalt, alustades Atomjää.
Atomic
Iga nõue peaks olema atomaarne, mis tähendab, et see peab olema võimalikult detailne ja seda ei saa edasi komponentideks jagada. Järgmised näited võrdlevad atomaarseid ja mitteatomaarseid nõudeid.
Jätkates haridusvaldkonna süsteemi näitega: siin on halb nõue „Tudengid saavad registreeruda bakalaureuse- ja magistriõppesse“. See on halb nõue, kuna see ei ole atomaarne – see segab kahte erinevat üksust, bakalaureuse- ja magistriõppe kursusi. Vastav hea nõue jagab selle kaheks nõudeks. Üks nõue hõlmab registreerumist bakalaureuseõppesse ja teine magistriõppesse.
Unikaalselt tuvastatud
Järgmine kvaliteediatribuut on unikaalne identifikaator. Halvas näites on kahel eraldi nõudel sama ID#1. Kui meeskond viitab nõudele selle ID järgi, jääb selgusetuks, millist kahest silmas peetakse. Heas nõude puhul on need koondatud 1. jaotisse – Kursustele registreerumine – alanõuetega 1.1 (bakalaureuseõppesse registreerumine) ja 1.2 (magistriõppesse registreerumine).
täielik
Kõik nõuded peaksid olema täidetud. Näiteks siin ütleb halb nõue, et „professori kasutaja logib süsteemi sisse oma kasutajanime, parooli ja muu asjakohase teabe sisestamisega“. „Muu asjakohane teave“ on ebamäärane. Täielik nõue loetleb täpsed väljad, näiteks osakonna koodi, mida professor peab esitama.
Järjepidev ja üheselt mõistetav
Iga nõue peaks olema järjepidev ja üheselt mõistetav. Halvas näites on üks nõue, mille kohaselt „üliõpilasel on kas bakalaureuse- või magistriõppe kursused, aga mitte mõlemad“, samas kui teises nõudes on kirjas: „Mõned kursused on avatud nii bakalaureuse- kui ka magistriõppe üliõpilastele“.
Esimene nõue viitab kursuste jagamisele kahte eksklusiivsesse kategooriasse, kuid teine nõue on sellega vastuolus, avades mõned kursused mõlemale rühmale.
Hea nõue lahendab konflikti, sätestades selgelt, et iga kursus on märgitud kas bakalaureuse- või magistriõppe kursusena ning üliõpilane saab registreeruda ainult ühe kategooria kursustele.
Tracvõimeline
Iga nõue peab olema tracteostatav, kuna nõuded eksisteerivad mitmel tasandil: ärilisel, arhitektuurilisel ja disainilisel ning süsteemi ja integratsiooni tasandil.
Kui teisendate ärinõude arhitektuuri- ja disaininõueteks või arhitektuuri- ja disaininõuded süsteemi- ja integratsiooninõueteks, tracToimivus tuleb säilitada. Iga ärinõue peaks olema seotud ühe või mitme arhitektuuri- ja disaininõudega. Halvas näites „Üliõpilase teabe haldamine – kas see on seotud BRD nõude ID-ga?“ puudub nõude ID.
Hea nõue salvestab sama lause, aga on otseselt seotud BRD nõude ID 4.1-ga. Igal nõudel peab olema tracvõimekuskaartpingSüsteemi- ja integratsiooninõuded peaksid olema seotud ka neid rakendava koodi ja neid kontrollivate testidega.
TracSeega hõlmab teostatavus kogu projekti vältel otsast lõpuni.
Esikohale seatud
Iga nõue tuleb tähtsuse järjekorda seada, et meeskond teaks, mida kõigepealt rakendada ja mis võib oodata. Halvas näites on „Registreeri õpilane“, „Säilita kasutajainfo“, „Registreeri kursused“ ja „Vaata hinnetelehte“ prioriteediks 1. Kõik ei saa olla prioriteediga 1, seega tuleb nõuded realistlikult järjestada. Heas näites on „Registreeri õpilane“ ja „Registreeri kursused“ kõrgeim prioriteet 1, „Säilita kasutajainfo“ prioriteet 2 ja „Vaata hinnetelehte“ prioriteet 3.
Katsetatav
Iga nõue peaks olema testitav. Halb näide „süsteemi iga leht laadib vastuvõetava aja jooksul” ei ole testitav kahel põhjusel. Esiteks võib „iga leht” tähendada kümneid lehekülgi, mis paisutab testimise pingutust. Teiseks on „vastuvõetav ajaraam” määratlemata – kellele see on vastuvõetav ja millise võrdlusaluse suhtes? Hea nõue lahendab mõlemad probleemid, nimetades konkreetsed lehed („üliõpilaste registreerimise ja kursustele registreerumise lehed”) ja seades mõõdetava eesmärgiks 5 sekundit.
