Ohjelmistovaatimusten analyysi esimerkin avulla
Charles Moore
⚡ Älykäs yhteenveto
Ohjelmistovaatimusten analyysi jakaa sidosryhmien tarpeet toiminnallisiin ja ei-toiminnallisiin lausekkeisiin, luokittelee ne liiketoiminta-, arkkitehtuuri- ja järjestelmätasolla ja tarkistaa sitten jokaisen laatuominaisuuksien perusteella testattavan, trackäyttökelpoinen, priorisoitu erittely.
Ohjelmistovaatimus on toiminnallinen tai ei-toiminnallinen tarve, joka on toteutettava järjestelmässä. Toiminnallinen tarkoittaa tietyn palvelun tarjoamista käyttäjälle.
Esimerkiksi pankkisovelluksen yhteydessä toiminnallinen vaatimus on, että kun asiakas valitsee ”Näytä saldo”, hänen pitäisi voida nähdä viimeisin tilinsä saldo.
Ohjelmistovaatimus voi olla myös ei-toiminnallinen, kuten suorituskykyvaatimus. Ei-toiminnallinen vaatimus voi esimerkiksi edellyttää, että järjestelmän jokainen sivu latautuu käyttäjille viiden sekunnin kuluessa.
Periaatteessa ohjelmistovaatimus on a
- Toiminnallinen tai
- Ei-toiminnallinen
tarve joka on otettava käyttöön järjestelmään. Ohjelmistovaatimukset ilmaistaan yleensä lausekkeina.
Vaatimustyypit
LiiketoimintavaatimuksetNämä ovat projektin liiketoimintatapauksesta poimittuja yleisiä vaatimuksia. Esimerkiksi mobiilipankkipalvelujärjestelmä tarjoaa pankkipalveluita Kaakkois-Aasiaan. Intian osalta liiketoimintavaatimukseksi on valittu tiliyhteenveto ja varojen siirto, kun taas Kiinan osalta se on tiliyhteenveto ja laskujen maksaminen.
| Maa | Yritys, joka tarjoaa pankkitoimintoja tai -palveluita |
|---|---|
| Intia | Tilin yhteenveto ja varojen siirto |
| Kiina | Tilin yhteenveto ja Bill Maksu |
Archirakenne- ja suunnitteluvaatimuksetNämä vaatimukset ovat yksityiskohtaisempia kuin liiketoimintavaatimukset ja ohjaavat ratkaisun arkkitehtuuria. Ne määrittävät liiketoimintavaatimuksen toteuttamiseen tarvittavan kokonaissuunnittelun. Koulutusorganisaatiossa tyypillisiä arkkitehtuurin ja suunnittelun käyttötapauksia ovat kirjautuminen, kurssitiedot ja ilmoittautuminen. Vaatimus olisi alla olevan mukainen.
| Pankkitoiminnan käyttötapaus | Vaatimus |
|---|---|
| Bill Maksu | Tämä käyttötapaus kuvaa kuinka asiakas voi kirjautua verkkopankkiin ja käyttää verkkopankkia Bill Maksutapa. Asiakas voi nähdä rekisteröityneiden laskuttajien maksamatta olevat laskut. Asiakas voi lisätä, muokata ja poistaa laskuttajan tietoja. Asiakas voi määrittää tekstiviesti- ja sähköposti-ilmoituksia eri laskutustoiminnoille. Asiakas voi tarkastella aiemmin maksettujen laskujen historiaa. Tämän käyttötapauksen aloittavat toimijat ovat pankkiasiakkaita tai tukihenkilöstöä. |
Järjestelmä- ja integrointivaatimuksetAlimmalla tasolla meillä on järjestelmä- ja integraatiovaatimukset. Se tarjoaa yksityiskohtaisen kuvauksen jokaisesta vaatimuksesta. Se voidaan tallentaa käyttäjätarinoina, jotka on kirjoitettu arkipäiväisellä liiketoiminnan kielellä. Vaatimukset sisältävät runsaasti yksityiskohtia, jotta kehittäjät voivat aloittaa koodaamisen. The Bill Alla oleva maksumoduulin esimerkki näyttää laskuttajan lisäämisen vaatimuksen.
| Bill Maksu | vaatimukset |
|---|---|
| Lisää Billers | Palveluntarjoajan nimi, asiakassuhteen numero, automaattiset maksut – kyllä/ei, maksa kokonaan Bill – Kyllä/Ei, automaattisen maksun raja – Älä maksa, jos Bill on yli määritellyn määrän |
Joskus projektia varten ei välttämättä saada lainkaan vaatimuksia tai dokumentteja, joiden kanssa työskennellä. Silti on olemassa muita vaatimustietolähteitä, joihin voit luottaa ohjelmistosi tai testisuunnittelusi pohjana. Muut vaatimuslähteet, joihin voit luottaa, on lueteltu alla.
Muut vaatimusten lähteet
- Tiedonsiirto kollegoilta tai työntekijöiltä, jotka jo työskentelevät projektin parissa
- Keskustele projektista liiketoiminta-analyytikon, tuotepäällikön, projektipäällikön ja kehittäjien kanssa
- Analysoi jo toteutettua järjestelmän aiempaa versiota
- Analysoi projektin vanhempia vaatimusasiakirjoja
- Revtarkastella aiempia virheraportteja; jotkin virheraportit muunnetaan parannuspyynnöiksi, jotka voidaan toteuttaa nykyisessä versiossa
- Tarkista asennusoppaasta, jos sellainen on saatavilla, mitä asennuksia tarvitaan.
- Analysoi toimiala- tai toimialaosaamista, jota tiimi yrittää soveltaa
Käytitpä mitä tahansa vaatimusten lähdettä tahansa, dokumentoi ne jaettuun muotoon ja anna kokeneiden tiimin jäsenten tarkistaa ne.
Kuinka analysoida vaatimuksia
Tarkastellaan esimerkkiä koulutusohjelmistosta, jossa opiskelija voi ilmoittautua eri kursseille.
Tutkitaanpa, miten vaatimuksia voidaan analysoida. Jokaisen vaatimuksen on täytettävä joukko vakiolaatuominaisuuksia, joihin kuuluvat seuraavat:
- Atomic
- Yksilöllisesti tunnistettu
- Täydellinen
- Johdonmukainen ja yksiselitteinen
- Trackyvykäs
- Priorisoitu
- Testattava
Seuraava taulukko havainnollistaa kutakin ominaisuutta kolmella sarakkeella:
- Ensimmäinen sarake osoittaa - "laatuvaatimus"
- Toinen sarake osoittaa - "huono vaatimus jossain ongelmassa"
- Kolmannessa sarakkeessa sama vaatimus on ”muunnettu hyväksi vaatimukseksi”.
| Vaatimus Laatu | Esimerkki huonosta vaatimuksesta | Esimerkki hyvästä vaatimuksesta |
|---|---|---|
| Atomic | Opiskelijat voivat ilmoittautua perustutkinto- ja jatko-opintoihin | Opiskelijat voivat ilmoittautua kandidaattitason kursseille. Opiskelijat voivat ilmoittautua jatko-opintojen kursseille. |
| Yksilöllisesti tunnistettu | 1- Opiskelijat voivat ilmoittautua kandidaattitason kursseille. 1- Opiskelijat voivat ilmoittautua jatko-opintoihin. | Kurssille ilmoittautuminen. Opiskelijat voivat ilmoittautua kandidaattitason kursseille. Opiskelijat voivat ilmoittautua jatko-opintojen kursseille. |
| 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 |
| Trackyvykäs | Säilytetäänkö opiskelijatiedot BRD:n req.ID-kartoituksella? | Säilytä opiskelijatiedot - Kartoitettu BRD:n vaatimukseen ID 4.1 |
| Priorisoitu | Rekisteröitynyt opiskelija - Prioriteetti 1. Käyttäjätietojen ylläpito - Prioriteetti 1. Kursseille ilmoittautuminen - Prioriteetti 1. Arviointikortin tarkastelu - Prioriteetti 1 | Rekisteröi opiskelija - Prioriteetti 1. Ylläpidä käyttäjätietoja - Prioriteetti 2. Ilmoittaudu kursseille - Prioriteetti 1. Näytä raportti - Prioriteetti 3 |
| 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ärrämme jokaisen näistä ominaisuuksista tarkemmin, aloittaen Atomic.
Atomic
Jokaisen vaatimuksen tulisi olla atomi, eli sen on oltava mahdollisimman yksityiskohtainen eikä sitä voida jakaa edelleen komponentteihin. Seuraavissa esimerkeissä vertaillaan atomi- ja ei-atomisia vaatimuksia.
Jatketaan koulutusjärjestelmäesimerkillä: Tässä huono vaatimus on ”Opiskelijat voivat ilmoittautua sekä perustutkinto- että jatko-opintoihin”. Tämä on huono vaatimus, koska se ei ole atomaarinen – se sekoittaa kaksi eri kokonaisuutta, perustutkinto- ja jatko-opinnot. Vastaava hyvä vaatimus jakaa sen kahdeksi vaatimukseksi. Toinen vaatimus kattaa ilmoittautumisen perustutkinto-opintoihin ja toinen jatko-opintoihin.
Yksilöllisesti tunnistettu
Seuraava laatuattribuutti on yksilöllinen tunniste. Huonossa esimerkissä kahdella erillisellä vaatimuksella on sama ID#1. Jos tiimi viittaa vaatimukseen sen ID:llä, on epäselvää, kumpaa näistä kahdesta tarkoitetaan. Hyvässä vaatimuksessa ne on ryhmitelty osioon 1 – Kurssille ilmoittautuminen, ja siihen kuuluvat alavaatimukset 1.1 (ilmoittautuminen perustutkinto-opintoihin) ja 1.2 (ilmoittautuminen jatko-opintoihin).
Täydellinen
Jokaisen vaatimuksen tulee olla täydellinen. Esimerkiksi tässä huonossa vaatimuksessa sanotaan, että "professorikäyttäjä kirjautuu järjestelmään antamalla käyttäjätunnuksensa, salasanansa ja muut asiaankuuluvat tiedot". "Muut asiaankuuluvat tiedot" on epämääräinen. Täydellinen vaatimus listaa tarkat kentät, kuten laitoksen koodin, jotka professorin on annettava.
Johdonmukainen ja yksiselitteinen
Jokaisen vaatimuksen tulee olla johdonmukainen ja yksiselitteinen. Huonossa esimerkissä yhdessä vaatimuksessa todetaan: ”Opiskelijalla on joko perustutkinto- tai jatko-opintoihin liittyviä kursseja, mutta ei molempia”, kun taas toisessa vaatimuksessa todetaan: ”Jotkut kurssit ovat avoimia sekä perustutkinto- että jatko-opiskelijoille”.
Ensimmäinen vaatimus tarkoittaa, että kurssit jaetaan kahteen eksklusiiviseen kategoriaan, mutta toinen vaatimus on ristiriidassa sen kanssa avaamalla jotkin kurssit molemmille ryhmille.
Hyvä vaatimus ratkaisee ristiriidan toteamalla selvästi, että jokainen kurssi merkitään joko kandidaatti- tai maisterivaiheen kurssiksi ja että opiskelija voi ilmoittautua vain yhden kategorian kursseille.
Trackyvykäs
Jokaisen vaatimuksen on oltava tracmahdollista, koska vaatimuksia on useilla tasoilla: liiketoiminnan, arkkitehtuurin ja suunnittelun sekä järjestelmän ja integraation tasolla.
Kun muunnat liiketoimintavaatimuksen arkkitehtuuri- ja suunnitteluvaatimuksiksi tai arkkitehtuuri- ja suunnitteluvaatimukset järjestelmä- ja integraatiovaatimuksiksi, tracSuoritettavuus on säilytettävä. Jokaisen liiketoimintavaatimuksen tulisi vastata yhtä tai useampaa arkkitehtuuri- ja suunnitteluvaatimusta. Huonossa esimerkissä ”Ylläpidä opiskelijatietoja – yhdistetty BRD-pyyntötunnukseen?” vaatimuksen tunnus puuttuu.
Hyvä vaatimus tallentaa saman lausekkeen, mutta se on eksplisiittisesti yhdistetty BRD-vaatimukseen ID 4.1. Jokaisella vaatimuksella on oltava tractoimintakykykarttapingJärjestelmä- ja integrointivaatimusten tulisi myös vastata niitä toteuttavaa koodia ja niitä todentavia testitapauksia.
TracToimivuus ulottuu siis koko projektin ajan päästä päähän.
Priorisoitu
Jokainen vaatimus on priorisoitava, jotta tiimi tietää, mitä toteutetaan ensin ja mikä voi odottaa. Huonossa esimerkissä Rekisteröi opiskelija, Ylläpidä käyttäjätietoja, Ilmoita kursseista ja Näytä raportti on kaikki asetettu prioriteettitasolle 1. Mikään ei voi olla prioriteettitasolla 1, joten vaatimukset on asetettava realistisesti järjestykseen. Hyvässä esimerkissä Rekisteröi opiskelija ja Ilmoita kursseista -toiminnolle annetaan korkein prioriteettitaso 1, Ylläpidä käyttäjätietoja -toiminnolle prioriteettitaso 2 ja Näytä raporttitasolle prioriteettitaso 3.
Testattava
Jokaisen vaatimuksen tulisi olla testattavissa. Huono esimerkki, ”järjestelmän jokainen sivu latautuu hyväksyttävässä ajassa”, ei ole testattavissa kahdesta syystä. Ensinnäkin ”jokainen sivu” voi tarkoittaa kymmeniä sivuja, mikä paisuttaa testaustyötä. Toiseksi ”hyväksyttävä aika” on määrittelemätön – kenelle se on hyväksyttävä ja mitä vertailuarvoa vasten? Hyvä vaatimus korjaa molemmat ongelmat nimeämällä sivut (”rekisteröidy opiskelijaksi ja ilmoittaudu kursseille” -sivut) ja asettamalla mitattavan viiden sekunnin tavoitteen.
