Ohjelmistovaatimusten analyysi esimerkin avulla
Charles Moore
Esimerkiksi pankkisovelluksen yhteydessä toiminnallinen vaatimus tulee olemaan, kun asiakas valitsee "Näytä saldo", hänen on voitava tarkastella viimeisintä tilisaldoaan.
Ohjelmistovaatimus voi olla myös ei-toiminnallinen, se voi olla suorituskykyvaatimus. Esimerkiksi ei-toiminnallinen vaatimus on, että järjestelmän jokaisen sivun tulee olla käyttäjille 5 sekunnin sisällä.
Periaatteessa ohjelmistovaatimus on a
- Toimiva tai
- Ei-toiminnallinen
tarve joka on otettava käyttöön järjestelmään. Ohjelmistovaatimukset ilmaistaan yleensä lausuntoina.
Vaatimustyypit
- Liiketoimintavaatimukset: Ne ovat korkean tason vaatimuksia, jotka on poimittu projekteista. Esimerkiksi mobiilipankkipalvelujärjestelmä tarjoaa pankkipalveluita Kaakkois-Aasiaan. Intiassa päätettävä liiketoimintavaatimus on tiliyhteenveto ja varojen siirto, kun taas Kiinassa tiliyhteenveto ja laskun maksaminen päätetään liiketoimintavaatimuksena
| Maa | Yritys, joka tarjoaa pankkitoimintoja tai -palveluita |
|---|---|
| Intia | Tilin yhteenveto ja varojen siirto |
| Kiina | Tilin yhteenveto ja Bill Maksu |
- Archirakenne- ja suunnitteluvaatimukset: Nämä vaatimukset ovat yksityiskohtaisempia kuin liiketoiminnan vaatimukset. Se määrittää liiketoiminnan vaatimuksen toteuttamiseen tarvittavan kokonaissuunnittelun. Koulutusorganisaatiollemme arkkitehtuurin ja suunnittelun käyttötapaukset olisivat kirjautuminen, kurssin yksityiskohdat jne. Vaatimus olisi alla kuvattu.
| Pankkitoiminnan käyttötapaus | Vaatimus |
|---|---|
| Bill Maksu | Tämä käyttötapaus kuvaa kuinka asiakas voi kirjautua verkkopankkiin ja käyttää verkkopankkia Bill Maksuväline.
Asiakas näkee kojetaulun rekisteröityjen laskuttajien maksamattomista laskuista. Hän voi lisätä, muokata ja poistaa laskuttajan tietoja. Asiakas voi määrittää tekstiviestit, sähköposti-ilmoitukset erilaisiin laskutustoimintoihin. Hän näkee aiempien maksettujen laskujen historian. Tämän käyttötapauksen aloittavat toimijat ovat pankin asiakkaita tai tukihenkilöstöä. |
- Järjestelmä- ja integrointivaatimukset: Alimmalla tasolla meillä on järjestelmä- ja integraatiovaatimukset. Se on yksityiskohtainen kuvaus jokaisesta vaatimuksesta. Se voi olla käyttäjätarinoiden muodossa, mikä todella kuvaa jokapäiväistä liikekieltä. Vaatimukset ovat runsaasti yksityiskohtia, jotta kehittäjät voivat aloittaa koodauksen. Tässä esimerkki Bill Maksumoduuli, jossa mainitaan vaatimus a Biller
| Bill Maksu | vaatimukset |
|---|---|
| Lisää Billers |
|
Joskus joissakin projekteissa et ehkä saa vaatimuksia tai asiakirjoja. Mutta silti on olemassa muita vaatimuksia, joita voit harkita vaatimukselle tai tiedolle, jotta voit perustaa ohjelmistosi tai testisuunnittelusi näihin vaatimuksiin. Joten muut vaatimuksen lähteet, joihin voit luottaa, ovat
Muut vaatimusten lähteet
- Tiedonsiirto kollegoilta tai työntekijöiltä, jotka jo työskentelevät projektin parissa
- Keskustele projektista yritysanalyytikolle, tuotepäällikölle, projektipäälliköksi ja kehittäjille
- Analysoi aiempi järjestelmäversio, joka on jo toteutettu järjestelmään
- Analysoi projektin vanhempi vaatimusasiakirja
- Katso aiempia virheraportteja, joista osa virheraporteista on muutettu parannuspyynnöksi, joka voidaan ottaa käyttöön nykyisessä versiossa
- Katso asennusoppaasta, jos se on saatavilla, jotta näet, mitä asennusta tarvitaan
- Analysoi toimialueen tai toimialan tietämystä, jota tiimi yrittää toteuttaa
Riippumatta vaatimuksen lähteestä, varmista, että dokumentoit ne jossain muodossa, pyydä ne muilta kokeneilta ja asiantuntevilta tiimin jäseniltä.
Kuinka analysoida vaatimuksia
Harkitse esimerkkiä koulutusohjelmistojärjestelmästä, jossa opiskelija voi ilmoittautua eri kursseille.
Tutkitaan kuinka vaatimukset analysoidaan. Vaatimusten tulee säilyttää vaatimuksensa vakiolaatu, erityyppiset vaatimukset laatu sisältää
- Atomic
- Yksilöllisesti tunnistettu
- Täydellinen
- Johdonmukainen ja yksiselitteinen
- jäljitettävissä
- Priorisoitu
- Testattava
Ymmärrä tämä esimerkillä, tässä näytetyssä taulukossa on kolme saraketta,
- Ensimmäinen sarake osoittaa - "laatuvaatimus"
- Toinen sarake osoittaa - "huono vaatimus jossain ongelmassa"
- Kolmas sarake on sama kuin toinen sarake, mutta "muunnettu hyväksi vaatimukseksi".
| Vaatimus Laatu | Esimerkki huonosta vaatimuksesta | Esimerkki hyvästä vaatimuksesta |
|---|---|---|
| Atomic |
|
|
| Yksilöllisesti tunnistettu | 1- Opiskelijat voivat ilmoittautua peruskursseille1- Opiskelijat voivat ilmoittautua jatkokursseille |
|
| Täydellinen | Professorin käyttäjä kirjautuu järjestelmään antamalla käyttäjätunnuksensa, salasanansa ja muut asiaankuuluvat tiedot | Professorin käyttäjä kirjautuu järjestelmään antamalla käyttäjätunnuksensa, salasanansa ja laitoskoodinsa |
| Johdonmukainen ja yksiselitteinen | Opiskelijalla on joko perustutkinto- tai jatkokurssit, mutta ei molempia. Jotkut kurssit ovat avoimia sekä perustutkintoa suorittaville että jatko-opiskelijoille | Opiskelijalla on joko perustutkinto- tai jatkotutkinto, mutta ei molempia |
| jäljitettävissä | Säilytetäänkö opiskelijatiedot BRD:n req.ID-kartoituksella? | Säilytä opiskelijatiedot - Kartoitettu BRD:n vaatimukseen ID 4.1 |
| Priorisoitu | Rekisteröity opiskelija - Prioriteetti 1Käyttäjätietojen ylläpito - Prioriteetti 1 Ilmoittaudu kursseille - Prioriteetti 1Näytä raporttikortti - Priority 1 | Rekisteröidy opiskelija-prioriteetti 1Käyttäjätietojen ylläpito-Priority 2Rekisteröidy kursseille-Priority 1Näytä raporttikortti-Priority3 |
| Testattava | Jokainen järjestelmän sivu latautuu hyväksyttävässä ajassa | Rekisteröi opiskelija ja ilmoittaudu kursseille. Järjestelmän sivut latautuvat 5 sekunnissa |
Ymmärretään nyt jokainen näistä vaatimuksista yksityiskohtaisesti alkaen Atomic.
Atomic
Joten jokaisen vaatimuksesi tulee olla atomaarinen, mikä tarkoittaa, että sen tulee olla erittäin alhainen yksityiskohtien tasolla, eikä sitä pitäisi olla mahdollista erottaa komponenteiksi. Tässä näemme kaksi esimerkkiä vaatimuksista osoitteessa Atomic ja yksilöllisesti tunnistetut vaatimukset.
Jatketaan siis esimerkillä järjestelmän rakentamisesta koulutusalueelle. Tässä huono vaatimus on "Opiskelijat voivat ilmoittautua perustutkinto- ja jatkokursseille" . Tämä on huono vaatimus, koska se ei ole ydin, koska se puhuu kahdesta eri kokonaisuudesta perustutkinto- ja jatkokurssista. Joten ilmeisesti se ei ole hyvä vaatimus vaan huono vaatimus, joten kirjeenvaihdon hyvä vaatimus olisi erottaa se kahdeksi vaatimukseksi. Joten yksi puhuu ilmoittautumisesta perustutkinto-opintoihin, kun taas toinen puhuu ilmoittautumisesta jatko-opintoihin.
Yksilöllisesti tunnistettu
Vastaavasti seuraava laatuvaatimus on tarkistaa yksilöllisesti tunnistetut tiedot. Tässä meillä on kaksi erillistä vaatimusta, mutta molemmilla on sama ID#1. Jos siis viittaamme vaatimukseen viitaten ID#-numeroon, mutta ei ole selvää mitä vaatimusta tarkalleen tarkoitamme asiakirjaan tai muuhun järjestelmän osaan, koska molemmilla on sama ID#1. Erotetaan siis yksilöllisillä tunnuksilla, joten hyvä vaatimus palautetaan jakso 1 - kurssi-ilmoittautumisina, ja sillä on kaksi vaatimusta 1.1 id on ilmoittautuminen perustutkinto-opintojen kursseille ja 1.2 id on ilmoittautuminen jatko-opintoihin.
Täydellinen
Lisäksi jokaisen vaatimuksen tulee olla täydellinen. Esimerkiksi tässä huono vaatimus sanoo, että "professori käyttäjä kirjautuu järjestelmään antamalla käyttäjätunnuksensa, salasanansa ja muut asiaankuuluvat tiedot". Muut asiaankuuluvat tiedot eivät ole tässä selkeitä, joten muut asiaankuuluvat tiedot on täsmennettävä hyvässä vaatimuksessa, jotta vaatimus olisi täydellinen.
Johdonmukainen ja yksiselitteinen
Seuraavaksi jokaisen vaatimuksen tulee olla johdonmukainen ja yksiselitteinen, joten esimerkiksi täällä meillä on vaatimukset "Opiskelijalla on joko perustutkinto- tai jatkokurssit, mutta ei molempia" tämä on yksi vaatimus, on toinen vaatimus, joka sanoo "Jotkin kurssit olla avoin sekä perustutkintoa suorittaville että jatko-opiskelijoille."
Tämän vaatimuksen ongelmana on, että ensimmäisestä vaatimuksesta lähtien kurssit näyttävät jaettuna kahteen luokkaan jatko- ja jatkokurssien alla ja opiskelija voi valita jommankumman kahdesta, mutta ei molempia. Mutta kun luet toisen vaatimuksen, se on ristiriidassa ensimmäisen vaatimuksen kanssa ja kertoo, että jotkut kurssit ovat avoinna sekä jatko- että perustutkintoa suorittaville.
Joten on ilmeistä muuttaa tämä huono vaatimus hyväksi vaatimukseksi, joka on "Opiskelijalla on joko perustutkinto- tai jatkokurssit, mutta ei molempia". Tämä tarkoittaa, että jokainen kurssi merkitään joko perustutkinto- tai jatkokurssiksi
jäljitettävissä
Jokaisen vaatimuksen tulee olla jäljitettävissä, koska vaatimuksia on jo eri tasoilla, näimme jo, että huipulla meillä oli liiketoimintavaatimuksia, ja sitten meillä on arkkitehtuuri- ja suunnitteluvaatimukset, joita seuraavat järjestelmäintegraatiovaatimukset.
Nyt kun muunnamme liiketoiminnan vaatimukset arkkitehtuuri- ja suunnitteluvaatimuksiksi tai muunnamme arkkitehtuuri- ja suunnitteluvaatimukset järjestelmäintegraatiovaatimuksiksi, jäljitettävyyttä on oltava. Tämä tarkoittaa, että meidän pitäisi pystyä ottamaan kaikki liiketoiminnan vaatimukset ja kohdistamaan ne vastaavaan yhteen tai useampaan ohjelmistoarkkitehtuuri- ja suunnitteluvaatimuksiin. Joten tässä on esimerkki huonosta vaatimuksesta, jossa lukee "Säilytä opiskelijatiedot – yhdistetty BRD-vaatimustunnukseen?" vaatimustunnusta ei anneta tässä.
Joten kun se muunnetaan hyväksi vaatimukseksi, se sanoo saman asian, mutta se on kartoitettu vaatimustunnuksella 4.1. Joten kartoitus pitäisi olla olemassa jokaista vaatimusta varten. Samalla tavalla meillä on korkean ja matalan tason kartoitusvaatimus, kartoitus on olemassa myös järjestelmän ja integrointivaatimuksen välillä koodiin, joka toteuttaa kyseisen vaatimuksen, ja myös järjestelmän ja integrointivaatimuksen välillä on kartoitus testitapaukseen, joka testaa kyseisen vaatimuksen. .
Joten tämä jäljitettävyys koskee koko projektia
Priorisoitu
| Priorisoitu | Rekisteröity opiskelija-prioriteetti 1 Säilytä käyttäjätiedot - prioriteetti 1 Ilmoittaudu kursseille - Prioriteetti 1 Näytä raporttikortti - Prioriteetti 1 |
Rekisteröidy opiskelijaprioriteetti 1 Säilytä käyttäjätiedot - prioriteetti 2 Ilmoittaudu kursseille - Prioriteetti 1 Näytä raporttikortti-Priority3 |
Sitten jokainen vaatimus on priorisoitava, joten tiimillä on ohje, mikä vaatimus voidaan toteuttaa ensin ja mikä voidaan tehdä myöhemmin. Täältä näet huonon prioriteetin on rekisteröidy opiskelija, ylläpitää käyttäjätietoja ja jokainen vaatimus on antanut prioriteetti-1. Kaikki ei voi olla samalla prioriteetilla, joten vaatimukset voidaan priorisoida. Joten esimerkki hyvästä vaatimuksesta tässä on opiskelijan rekisteröinti ja kursseille ilmoittautuminen on korkein prioriteetti 1, kun taas ylläpitokäyttäjätiedot ovat alla prioriteetilla 2 ja sitten meillä on tarkastella raporttikorttia prioriteetilla 3
Testattava
| Testattava | Jokainen järjestelmän sivu latautuu hyväksyttävässä ajassa | Rekisteröi opiskelija ja ilmoittaudu kursseille. Järjestelmän sivut latautuvat 5 sekunnissa |
Jokaisen vaatimuksen tulee olla testattavissa, tässä huono vaatimus on "Järjestelmän jokainen sivu latautuu hyväksyttävässä ajassa". Nyt tähän vaatimukseen liittyy kaksi ongelmaa, ensinnäkin se, että jokainen sivu tarkoittaa, että sivuja voi olla useita, mikä räjäyttää testaustyöt. Toinen ongelma on, että sanotaan, että sivu latautuu hyväksyttävässä ajassa, mikä nyt on hyväksyttävä aika? Hyväksytään kenelle. Joten meidän on muutettava ei-testattavissa oleva argumentti testattavaksi argumentiksi, joka kertoo nimenomaan millä sivulla puhumme "rekisteröidy opiskelija- ja ilmoittautumissivuille" ja annetaan myös hyväksyttävä aika, joka on 5 sekuntia.
Yhteenveto
Joten näin meidän on tarkasteltava jokaista vaatimusta sopivalla tasolla. Esimerkiksi, jos aiomme rakentaa ohjelmiston järjestelmä- ja integrointivaatimusten suhteen. Meidän on tarkasteltava ohjelmistovaatimusspesifikaatioissa tai käyttäjätarinoissa annettuja järjestelmä- ja integraatiovaatimuksia ja sovellettava jokaista vaatimuksen laatua. Tarkista sitten, onko jokainen vaatimus atomaarinen, yksilöllisesti tunnistettu ja täydellinen ja niin edelleen.