Skip to content

Vaatimusmäärittely runko

Täydennä seuraavat kentät!

  • [SIJOITA TOIMEKSIANNON KOODI TÄHÄN]
  • Nimimerkkisi/gitlab tunnus
  • Dokumentin versionumero X.Y
  • Vaatimusmäärittely pohjan versio 2.1 - 17.09.2020 (NarsuMan)

Ohjeita määrittelytyön tekijälle

Pidä sisällysluettelo kunnossa, eli päivitä tarvittaessa MarkDown-ankkurilinkitys.

Dokumentin sisällä viitataan useissa kohdissa kansioon "/pohjat". Kyseinen kansio sisältää ns. "templaatti"-tiedostoja joita käytetään apuna eri määrittelyjen kirjaamisessa. Tämä tarkoittaa, että tuosta kansiosta voi tarvittasessa kopioida tiedostoja.

PlantUML-työkalun avulla on mahdollista piirtää esim. UML-kuvauskielen mukaisia kuvauksia ja liittää ne osaksi MarkDown-kuvauksia. Kurssin aikana on hyödyllistä tutustua sen käyttöön http://plantuml.com/ ja pyrkiä soveltamaan sitä mahdollisimman paljon eri osa-alueilla.

HUOMIO! Älä käytä PlantUML-kuvauksissa skandinaavisia merkkejä, koska tämä johtaa ongelmiin CI/CD-prosessin aikana

Tutustu seuraavan linkin takaa löytyvään MindMap-kuvaan, siitä miten eri käsitteet liittyvät toisiinsa. Kannattaa keskittyä ymmärtämään yhteyksien merkitys, eli kysyminen kannattaa aina :) Kuvaus voi päivittyä kurssin aikana!

http://ttos0100.pages.labranet.jamk.fi/amk-2020/kurssimateriaali/kasitekartta/

HUOMIO! Kun teet harjoitusta, niin poista ennen lopullista luovutusta kaikki ohjekommentit ja video-linkit sisällöstä.

Tiedostojen nimeämisestä: Kannattaa pyrkiä nimeämään kaikki tiedostot säännönmukaisesti esim. use-case-001.md, profiili_asiakas-2, ominaisuus-ft1.md__ etc Itse MarkDown -tiedostossa ylä otsikko kannattaa täyttää myös samalla menetelmällä.
Use Case: Uuden käyttäjän kirjautuminen Profiili: Asiakas 2 Ominaisuus: Raportti generaattori Tämä helpottaa hahmottamaan myöhemmin koko vaatimusmäärittelyn rakennetta

Sisällysluettelo

  1. Johdanto
  2. Toimeksiantaja
  3. Vaatimusmäärittelyn tekijä
  4. Palvelukuvaus
  5. Sidosryhmäkartta
  6. Sidosryhmät ja profiilit
  7. Tunnistetut riskit
  8. Valitut asiakastarinat
  9. Palveluun liittyviä asiakaspolkuja
  10. Oleelliset käyttötapaukset
  11. Tärkeimmät yleiset ominaisuudet/toiminnallisuudet
  12. MockUp-prototyyppi
  13. Alustavat Käyttäjätarinat
  14. Palvelun järjestelmävaatimukset
  15. Palveluun vaikuttavat rajaukset
  16. Palvelun liityvät laitevaatimukset
  17. Palvelun suoritusympäristöön liittyvät vaatimukset
  18. Palvelun määritellyt ominaisuudet/toiminnnallisuudet
  19. Palvelun toiminnalliset vaatimukset
  20. Palvelun ei-toiminnalliset vaatimukset
  21. Palvelun alustava arkkitehtuuri
  22. Palvelun alustava sijoittelunäkymä
  23. Palvelun alustava tietokantakuvaus)
  24. Palvelun integraatiot muihin järjestelmiin
  25. Palvelun laadun varmistuksesta
  26. Palvelun hyväksyntätestit
  27. Julkaisusuunnitelma
  28. Aiheeseen liityvä standardit ja lähteet

Johdanto

Kuvaa millaisesta projektista on kyse, hieman taustaa ja aiheeseen olennaisesti liittyviä asioita? Jos kyseessä harjoitustehtävä, niin tarkista voitko käytää todellisten tilaajien oikeita nimiä! Muuta aina oletuksena henkilötiedot ja toimeksiantajan viralliset tiedot

Toimeksiantaja

Kuka on vaatimusmäärittelyn tilaaja? Muista vaihtaa oikeat tilaajan nimet ja tiedot omiin keksittyihin!

Vaatimusmäärittelyn tekijästä

Kerro lyhyesti itsestäsi (tarvittaessa pseudonyyminä) tai esim. kuvitteellisen yrityksen työntekijänä.

Palvelukuvaus

Mitä palvelun avulla voidaan tehdä? Millaisia ovat sen käyttäjät? Mikä sen tehtävä on yleisesti eri sidosryhmien kannalta? Kannattaa nostaa esiin lyhyesti mahdolliset loppukäyttäjä ja oleellisiin palvelusta hyötyviin sidosryhmät

Sidosryhmäkartta

Mietitään tarkemmin millaisia käyttäjä/sidosryhmiä liittyy suunniteltuun ohjelmisto/palvelukokonaisuuteen? Näitä selkeyttääksemme kirjataan kaikki sidosryhmät sidosryhmäkartan muotoon. Nostetaan samalla esiin mikä on ko. sidosryhmän/edustajan palveluun liittyvä motivaatio. Kuvauksen voi laatia esim. piirtämällä, MindMap-muodossa tai soveltaen sopivaa UML-notaatiota.

Voit tutustu nyt aiemmin mainittuun PlantUML-työkaluun ja kokeilla luoda sidosryhmäkartta käyttäen (http://plantuml.com/) Huomaa! PlantUML-lohkon määrittelyssä käytetään Gitlab-ympäristössä eri avainsanoja @startuml/@enduml- rivien sijaan
Älä käytä skandinaavisia merkkejä PlantUML-kuvauksessa,koska niiden julkaisu www-sivulla ei toimi!**

uml diagram

Voit kuvata sidosryhmät myös esimerkiksi piirtämällä kuvan, jolloin eri profiilien erot tulevat ehkä "selkeämmin" esiin! Jos kuitenkin hyödynnät PlantUML kuvausta, niin päivitys ja kuvauksen ylläpito on huomattavasti nopeampaa

Sidosryhmät ja profiilit

Määritellään tarkemmin hahmotellusta sidosryhmäkartasta oleelliset sidosryhmät/profiilit. Huomio, että isossa yksittäisessä sidosryhmässä voi olla tarve määritellä useampia eri profiileja. Tämä tarkoittaa sitä, että laaja sidosryhmä, kuten esim. asiakaskunta voi käsittää useita erilaisia asiakasprofiileja, joilla voi olla eroja motiiveissa/arvoissa, mutta ne kuuluvat kuitenkin olennaisesti asiakaskuntaan.

Huomaa! Kaikki määritellyt profiilikuvaukset kirjoitetaan itsenäiseksi MarkDown-tiedostoksi, koska tämä helpottaa niihin viittaamista muualla dokumentaatiossa esim. Loppukäyttäjä - Keijo Korhonen Alla olevat profiili/sidosryhmätkuvaukset vain suuntaa antavia! Nimeä ne tarkoituksenmukaisiksi. Varmista, että ne ovat löydettävissä sidosryhmäkartasta!

Tässä kohtaa on aika etsiä profiilikuvauksen runkoa /pohjat kansiosta Profiili voi olla siis henkilö tai selkeä sidosryhmä edustaja. Tärkeää on nostaa nämä alkuvaiheessa ja käyttää niitä sitten määrittelyn edetessä

Sidosryhmä/Profiili Lisätietoa
Sidosryhmä-1 Edustaa esim x % asiakkaista
Sidosryhmä-2 Edustaa esim y % asiakaskunnasta
Henkilö profiili 1 Mieti edustaako profiili joitan määrättyä Sidosryhmä-2
Henkilö profiili 1 Edustaako profiili jotain sidosryhmän osaa Sidosryhmä-3
Henkilö profiili 1 Vai onko kyseessä ainut Sidosryhmän-X edustaja

Asiakkaan tarpeet/toiveet?

Pohdi millaisia toiveita/tarpeita on loppukäyttäjällä liittyen palveluun? Mitä kuulet asiakkaan / loppukäyttäjän suusta, kun haastattelet ko. henkilöä? Haastattele henkilöitä todellisessa tilanteessa? Millaisia toiveita hänellä on palvelua kohtaan? Kun keskustelet mahdollisen loppukäyttäjän (palvelun yksi sidosryhmä) kanssa on harvoin vastauksena tekninen toteutustapa tai muus syvälle menevä ratkaisu liittyen palveluun. Vastauksena voit kuitenkin saada kasan toiveita, joita asiakas odottaa palvelulta. Nämä kannattaa kirjata tässä vaiheessa talteen.

VaatimusID Tyyppi Kuvaus
CUSTOMER-REQ-0001 Customer Requirement Käyttäjänä haluan kirjautua käyttäen Facebook-tunnuksia, ettei tarvitse turhaan häslätä
CUSTOMER-REQ-0002 Customer Requirement
CUSTOMER-REQ-0003 Customer Requirement
CUSTOMER-REQ-0004 Customer Requirement
CUSTOMER-REQ-0005 Customer Requirement

Liiketoiminnan vaatimukset/tavoitteet?

Pohdi millaisia toiveita/tarpeita on Liiketoiminnan näkökulmasta liittyen palveluun? Jos mitään ei tule mieleen, niin pohdi millä perusteilla "kassaan" saadaa rahaa palvelusta? Saavutetaanko palvelulla kustannushyötyjä? Parantaako kustannustehokkuutta ? Antaako se jotain loppukäyttäjlle, josta hän selkeästi hyötyy ? Jos voit osoittaa selkeitä hyötyjä, niin ne antavat "liiketoiminnalle" merkityksen tuottaa palvelua.

VAPAAEHTOINEN

VaatimusID Tyyppi Kuvaus
BUSINESS-REQ-0001 Business Requirement Palvelun kirjautuminen tulee olla helppoa, että voimme saavuttaa laajan käyttäjäkunnan = 35% kohderyhmästä
BUSINESS-REQ-0002 Business Requirement
BUSINESS-REQ-0003 Business Requirement
BUSINESS-REQ-0004 Business Requirement
BUSINESS-REQ-0005 Business Requirement

Tunnistetut riskit

Millaisia riskeja liittyy tuoteen kehittämiseen, tuotteen markkinoihin, mahdollisiin kilpailijoihin, resursseihin? Nämä on hyvä tunnistaa alkuvaiheessa

VAPAAEHTOINEN

Avainsanat SWOT, Riskianalyysi

Valitut asiakastarinat

Haastattele tai "kuvittele" haastattelevasi palvelun kannalta olleellisia profiili/sidosryhmän edustajia ja pyydä heitä kuvaamaan palvelun käyttöön liittyviä oleellisia tilanteita. Miten henkilö/sidosryhmä hyötyy/käyttää palvelua. Kirjoita tämä tarinan muotoon. Kerro mitä palvelun käyttö käytännössä tarkoittaa asiakkaan, pääkäyttäjän etc. näkökulmasta! Alla olevassa videossa näet millaisia tarinoita ei ole tarkoitus kirjata tähän osioon :)

Pyri kirjoittamaan auki tarina vain valitun profiilin/sidosryhmän näkökulmasta (toiset profiilit/sidosryhmät saattavat kyllä esiintyä tarinassa). Tarinassa on kätevä viitata jo aiemmin luotuihin Profiili-kuvauksiin.** HUOMIO! Älä sekoita asiakastarinaa (Customer story) käyttäjätarinaan (User Story)

Asiakastarina 1

Profiili 1 herää aamusta ja tarkistaa puhelimellaan onko X-palvelussa tilaa aamupäivästä. Huomatessaan, että palvelussa on vapaa aika klo 11:00.........

Asiakastarina 2

Asiakas-tyyppi 3 käynnistää iltapäivällä rakennustyömaalla sementtimyllyä, kun hänelle tulee viesti X-palvelusta.........

Palveluun liittyviä asiakaspolkuja

Mieti auki aiemmin kirjoittamaasi asiakastarinaa ja piirrä sen pohjalta hahmotelma asiakaspolusta. Mitä tapahtumia siihen liittyy? Mieti palvelua laajempana kokonaisuutena! Asiaspolkukuvauksen avulla kuvataan tapahtuma sarjaa joka käydään jossain valitussa tilanteessa läpi palvelun käytön aikana. Asiakas kohtaisia palvelupolkuja voi olla useita, mutta tärkeintä on tunnistaa alkuvaiheessa oleellisimmat. Palvelupolkua kuvattaessa voi hyödyntää esim. Swim lane/BluePrint/tilakone-kuvausta tai muuta sopivaksi katsottua kuvausta. Tärkeää on kuitenkin kuvata polku ja käyttää sitä tarvittaessa selkeyttämään ymmärrystä tavoitellusta palvelusta. Käy läpi tekemäsi kuvausta jonkun toisen henkilön kanssa yhdessä? Käy läpi polku ja kerro mitä sen aikana tapahtuu..

Asiakaspolun luonnostelu on hyvä aloittaa esim. asiakastarinan pohjalta. Polkuja laaditaan tarvittaessa useampia eri profiilien/tilanteiden näkökulmasta. Yhteen kuvaukseen ei siis kannata upottaa liikaa tapahtumia

asiakaspolku PlantUML-esimerkki tilakoneena

Kokeillaan luonnostella asiakaspolkua PlantUML-työkalun avulla. Kannattaa kokeilla ehdottomasti myös muita tapoja! Sovella esim. PlantUML SDL/Swimlane kuvausta?

uml diagram

Palvelupolkujen kuvauksissa voi tarvittaessa soveltaa myös muita työkaluja. Esim. https://canvanizer.com, PowerPoint etc Tutustu esim. Blueprint-kuvaukseen

Oleelliset käyttötapaukset

Palvelupolun kuljettaessa käydään läpi laajempi ketju palveluun käyttöön liittyviä käyttötilanteitaa. Näitä tilanteita, joissa käsitellään itse ohjelmistopalvelua sähköisten rajapintojen/käyttöliittymien kautta kuvata ns. käyttötapauksien (Use Case) avulla.
Käyttötapaus (Use Case) ymmärretään helposti väärin, koska se liitetään usein pelkästään tuotteen käyttötarkoituksen kuvaamiseen. Palvelusta ensi kertaa keskusteltaessa puhutaan sen eri käyttötarkoituksista, eli sitä mihin ohjelmistoa/palvelua voidaan hyödyntää. Kun puhutaan palvelun määrittelystä ja siihen liittyvien käyttötapauksien tunnistamisesta on kyseessä hieman eri asia. Käyttötapauksessa keskitytään tarkastelmaan palvelun käyttöä varsin rajatussa tilanteessa. Käyttötapaukset (Use Case) kuvaataan UML-kuvauskielen avulla.

UML Use Case-kuvaus voidaan tehdä PlantUML-kuvauksena, mutta tarkempi käyttötapauksen avaaminen vaatii erillisen kuvaus dokumentin

uml diagram

On hyödyllistä kirjata kaikki oleelliset käyttötapaukset yhteen laajempaan Use Case-kuvaukseen, koska sen avulla voi tarkastella helpommin koko järjestelmää. Huomio! Laajemmassa järjestelmä kokonaisuudessa saattaa olla useita satoja eri käyttötapauksia.

Käyttötapauksen tarkempi kuvaus harjoitusympäristössä tapahtuu käyttötapaus-kohtaisen pohja-tiedoston avulla. Jokaista käyttötapausta varten laaditaan itsenäinen tiedosto.

Käyttötapaus Osa-alue toiminnallisuus/ominaisuus johon UC -liittyy
Käyttötapaus 1 - Tilauksen muokkaus Tilausten hallinta Tilaushallinta-paneeli
Käyttötapaus 2 - Tilauksen tarkistaminen Tilausten hallinta Tilaushallinta-paneeli
Käyttötapaus 2 - Tilauksen siirto Tilausten hallinta Tilaushallinta-paneeli

Tärkeimmät ominaisuudet/toiminnallisuudet

Hahmotellaan tähän kohtaan ominaisuudet pelkästään "ranskalaisilla viivoilla", eli mitä palvelulla mielestäsi on mahdollista tehdä? Mieti tilannetta, kun joku kysyy mitä palvelulla voi tehdä? Mitä vastaat ja mitkä toiminnot nostatat esiin ehdottomasti valtteina verrattuna muihin vastaaviin palveluihin? Päivitä lista myöhemmin, kun se tarkentuu? Tässä kohtaa kannattaa tarkistaa mitä olivat asiakkaan esittämät toiveet palvelusta? Niistä voisi löytyä ehkä joitain tässä vaiheessa? Tarkemmat toiminnallisuudet tarkentuvat myöhemmin dokumentissa.
Tässä vaiheessa riittää:

  • Oleellisia toimintoja
    • Asiaksi-profiili-1 voi lähettää postia toiselle henkilölle
    • Asiakas-profiili-2 voi saada tietoa aiemmin tehdyistä valinnoista
    • Ylläpito-henkilö voi poistaa laskun
    • Ylläpito-henkilö voi luoda uuden laskun
    • muita?

MockUp-prototyyppi

Suunniteltavan palvelun toimintoja määriteltäessä voi olla hyödyllistä piirtää avuksi MockUp-kuvausta käyttötilanteen tai toiminnallisuuksien hahmottamiseksi. Kun palvelun käyttöliittymää tai palvelupolkua käydään läpi mockup-kuvauksen kautta voi ymmärtää helpommin mitä tarvittavia toimintoja on kirjattava myös vaatimusmäärittelyyn. MockUp-kuvaus on myös hyödyllinen apuväline tilaajan/toimeksiantajan väliseen keskusteluun.

Kun laadit harjoitustehtävään MockUp-näkymän pohdi haluatko kuvata koko palvelua vai keskittyä yksittäisen toiminnallisuuden tarkasteluun? Harjoitustehtävän kannalta on oleellista, että käytät MockUp-kuvausta tarpeellisen asian esittämiseen. Pyri kuvaamaan kokonaisuutta ja esittämään siinä tunnistamiesi toimintojen tarkoituksen mukaisuutta. Jos huomaat piirtämisvaiheessa puutteita vaatimuksissa tai tarvetta kirjata niitä lisää, niin se on juuri tarkoitus. Vaatimusmäärittely tarkentuu tekemällä aktiivista hahmottelua vaaditusta kokonaisuudesta.

Voit kokeilla myös PlantUML-kuvausta rajatuissa kohdissa

uml diagram

Alustavat käyttäjätarinat

NYT HUOMIO! Tähän kohtaan kannattaa keskittyä vasta kun kaikki muut osiot on käyty läpi! Kyseessä ei ole asiakastarina vaan ketterässä kehityksessä (Agile Development) käytettävä käyttäjätarina - User Story. Sen avulla kuvataan palveluun liittyvää toiminnallisuutta, jolle käyttäjälle on tarvetta.

Aiheesta löytyy pohdintoja eri muodossa

Palvelun liittyvät tuotannolliset ja tekniset vaatimukset

Tämä osa-alue vielä kesken

Sähköisiä palveluita määriteltäessa teknisestä vaatimukset liittyvät tarvittaviin teknologioihin, laitteistoihin tai palvelun vaatimiin fyysisiin rakenteisiin. Ohjelmistopalvelua määriteltäessä kannattaa tunnistaa ajoissa puhtaasti tekniset/tuotannolliset vaatimukset ja kirjata ne vaatimusmäärittelyyn niille varattuun osaan. Liiallinen keskittyminen teknisten tuotanto/toteutusvaatimusten kirjaukseen ei ole välttämättä suositeltavaa, koska suunnittelun aikana ohjelmistoa/palvelun toteutusvaatimukset voivat vielä muuttua. Kehitysvaiheessa kätevästi koettu ratkaisu voi osoittatua kalliiksi palvelun tuotteistamisvaiheessa. Usein määrittelyn avuksi pyydetään erilaisia asiantuntijalausuntoja liittyen esimerkiksi järjestelmän arkkitehtuuriin ja tuotantoalustaan Yleisesti ottaen tässä osiossa voidaan pohtia esim seuraavia kysymyksiä.

  • Miten palvelu tullaan tuottamaan? Pilvessä, omilla palvelimilla etc?
  • Onko tarkoistus tarjota esim. SAAS/HOSTED-palveluna etc
  • Käytetäänkö Pilvipalveluita osana ratkaisua vai hyödynnetäänkö omia palvelimia
  • Mitä muita palveluita tarvitaan ko. palvelun tueksi? Käyttäjien tunnistamis palvelut?
  • Miten palvelu on oltava saatavilla 24/7h 100% ?
  • Millainen SLA palvelulle laaditaan?
  • Miten paljon kustannuksia saa palvelun tuotannolle sallitaan ?
  • Millaiset tiedonsäilytys/arkistointi tarpeet liittyvät palveluun?

Millaisia tuotantoympäristöjä/teknologisia ratkaisuja käyteään käytetään oikeasti? Voit tutkia esimerkkejä Stack Share:palvelussa Esim. millainen on tekninen ratkaisu toteutukselle ja miten eri teknologioita tullaan hyödyntämään. Harjoitustehtävässä tekniset vaatimukset jäävät tarkoituksella sivuasemaan. Keskitymme ohjelmiston vaatimuksiin! Voit kuitenkin miettiä millaisia vaatimuksia esim. tuotantoympäristöllä on?

VaatimusID Tyyppi Kuvaus Ominaisuus johon vaikuttaa
SYSTEM-HW-REQ-0002 System Technical Requirement Palvelun tärkeimpien palvelujen on oltava vähintään kahdennettu N+1
SYSTEM-HW-REQ-0003 System Technical Requirement Palvelimien vähimmäis muistikapasiteeti >32GB
SYSTEM-HW-REQ-0004 System Technical Requirement Prosessorin tyyppi Intel/AMD x64
SYSTEM-HW-REQ-0005 System Technical Requirement Palvelimen fyysinen sijainti on kotimaassa (FI)
SYSTEM-HW-REQ-0005 System Technical Requirement Verkkoyhteyden nopeus palveluun vähintään >100MB/s
SYSTEM-HW-REQ-0005 System Technical Requirement Palvelinkaapin suositeltava koko 1m X 1m X 2m

Palvelun toteuttamisen kannalta tärkeät oleelliset rajaukset ja standardit

Rajaus/rajoite = Constrain

Eri ohjelmistojena/palvelujen toteutusta ja käyttöä ohjaavat usein lait ja säädökset. Näiden edellyttämät vaatimukset voidaan kirjataan tarvittaessa vaatimusmäärittelyyn. Rajausten vaikutus koskee usein palvelun jonkin osa-kokonaisuuden toteuttamista. Tästä syystä eri rajoitteet on tunnistettava ajoissa, koska vaikutus saataa olla varsin ratkaiseva pitemmällä tähtäimella. Esimerkkinä tästä on viime vuonna voimaan tullut EU GDPR-säädös. Kannattaa tutkia esimerkiksi https://www.sfs.fi/aihealueet/terveydenhuolto/laakinnalliset_laitteet tai http://docs.jhs-suositukset.fi/jhs-suositukset/JHS190/JHS190.html

Id Vaatimuksen kuvaus kategoria Vastuullinen
CONSTRAINT-REQ-S00000 Constrain Palvelun kirjautumisprosessin on noudatettava XYZ-käytäntöjä Kirjautuminen ft1
CONSTRAINT-REQ-S00001 Constrain On huomioitava Standardi ZZZ osana palvelun tapahtuma login talletusta Log-palvelin
CONSTRAINT-REQ-S00002 Constrain
CONSTRAINT-REQ-S00003 Constrain
CONSTRAINT-REQ-S00004 Constrain
CONSTRAINT-REQ-S00005 Constrain
CONSTRAINT-REQ-S00006 Constrain

Palvelun toiminnalliset vaatimukset (Functional Requirements)

Mitä toimintoja palveluun liittyy? Nämä kannattaa kirjata ensi ns. toiminnallisina vaatimuksina? Toiminnallisilla vaatimuksilla kuvataan ohjelmistolta/järjestelmältä vaadittuja toimintoja. Toiminnalliset vaatimukset ovat helpoimmin tunnistettavia. Vältä useamman vaatimuksen kirjaamista samaan lauseeseen! Jokainen vaatimus erikseen.

VaatimusID Tyyppi Kuvaus Ominaisuus johon vaikuttaa
FUNCTIONAL-REQ-C0001 Functional Requirement Käyttäjänä (Asiakas Profiilit 1-4) voin kirjautua käyttäen Facebook-tunnuksia Kirjautuminen ft1
FUNCTIONAL-REQ-C0002 Functional Requirement Käyttöliittymän on toimittava myös ääniohjattuna, koska käyttäjillä saattaa olla näkövammoja Kirjautuminen ft1, Tilaushallinta
FUNCTIONAL-REQ-C0003 Functional Requirement
FUNCTIONAL-REQ-C0004 Functional Requirement
FUNCTIONAL-REQ-C0005 Functional Requirement
FUNCTIONAL-REQ-C0006 Functional Requirement
FUNCTIONAL-REQ-C0007 Functional Requirement
FUNCTIONAL-REQ-C0008 Functional Requirement
FUNCTIONAL-REQ-C0009 Functional Requirement
FUNCTIONAL-REQ-C0010 Functional Requirement

Palvelun ohjelmiston ominaisuudet, eli "featuret"

Yllä olevassa listassa on kirjattu muistiin erilaisia toiminteita, joita palvelum avulla voi suorittaa. Mieti seuraavaksi, mitkä näistä toiminnoista liittyvät isompii toiminnallisuuksiin.
Kirjaa alla olevaan taulukkoon nämä päätoiminnot. Niitä voidaan kutsua "Featureiksi" ja on tärkeää ymmärtää eri toimintojen kokoluokat. Tunnistat karkeasti päätoiminnallisuuden kun mietit mitä palvelulla on oleellisinta saada aikaan. Ylempänä määritellyt toiminnalliset vaatimukset mahdollisesti tarkentavat tai liittyä oleellisesti päätoiminnallisuuteen.
Esimerkkinä Verkkopankki palvelussa on oleellinen toiminto "maksu tililtä", joka on käytännössä tärkeä palvelun ominaisuus. Tähän toiminnallisuuteen liittyy useita muita pienempiä ja tarkentavia toiminnallisia vaatimuksia. Mieti millä eri tavoin maksu tililtä toimintoa voi käyttää?

Jos sinulta kysytään mitä palvelulla/ohjelmistolla voi tehdä pyri tunnistamaan tärkeimmät toiminnot! Ne ovat melko varmasti oleelliset ominaisuudet. Mieti mitä toimintoja pysyt tekemään esim. verkkopankin sivulla? Mitkä ovat tärkeimmät toiminnot, joita käytät useimmin?

Kannataa pohtia määrittelyvaiheessa ovatko kaikki ominaisuudet tarpeellisia? Kannattaa pyrkiä ryhmittelemään tärkeimmät ominaisuudet ensin. Ominaisuuksia voidaa tarkentaa toiminnallisilla vaatimuksilla, jotka ns. laajentavat ominaisuuden kuvausta. Ominaisuudet ovat käytännössä isompia kokonaisuuksia, joista koko palvelu/ohjelmisto on muodostunut. Suomenkielen sana ominaisuus saattaa olla hieman harhaan johtava, koska usein tuotteita esiteltäessä pyritään korostamaan tuotteen ominaisuutena sen "tietoturvallisutta". Tämä ei tarkoita, että kyseessä on tuoteeen ohjelmiston yksi ominaisuus vaan yleinen "suunnittelu filosofia". Tuote voi sisältää ominaisuuksia, joiden myötä sitä voidaan kutsua voidaan tietoturvalliseksi.

Tuotteen ominaisuus vai toiminto?

Ominaisuuksien todellinen tarve?

Ylikirjoita pohjalla olevat ehdotuksen ja toimintoja toimeksiantoon pohjautuen ja priorisoi niistä tärkeimmät toiminnot, joita määrittelet tarkemmin.

Priorisoi oleelliset ominaisuudet/toiminnot

  • P1 = Pakollinen
  • P3 = Tarpeellinen
  • P5 = Tehdään, kun tarve ilmenee
Ominaisuus Prioriteetti Ominaisuuteen liittyvät vaatimukset/käyttötapaukset
Feature 1 - raportti-generaattori P1 Esim FUNCTIONAL-REQ-C0001
Feature 2 - lasku-arkisto P1 Esim FUNCTIONAL-REQ-C0011
Feature 3 - avatar-valinta P2 Esim FUNCTIONAL-REQ-C0023
Feature 4 - oikeushallinta P3 Esim FUNCTIONAL-REQ-C0133
Feature 5 P4 Esim FUNCTIONAL-REQ-C0231
Feature 6 P5 Esim FUNCTIONAL-REQ-C0221
Feature 7 P5 Esim FUNCTIONAL-REQ-C0021
Feature 8 P5 EEsim FUNCTIONAL-REQ-C0301
Feature 9 P5 Esim FUNCTIONAL-REQ-C0401
Feature 10 P5 Esim FUNCTIONAL-REQ-C0401

Ohjelmiston/palveluun ei-toiminnallisia vaatimuksia

Mitä olivat ei-toiminnalliset vaatimukset? Voit esittää eri vaatimuksia erillisessä taulukossa tai viitata tässä yhteen laajempaan taulukkoon. Ei-toiminnalliset vaatimukset sisältää laajan joukko eri näkökulmia ohjelmiostotuotteeseen liittyen. Tärkeimmät kirjoittajan näkökulmasta ovat seuraavat: Suorituskyky, käytettävyys, tietoturva ja ylläpidettävyys Voit esittää eri vaatimuksia erillisessä taulukossa tai viitata tässä yhteen laajempaan taulukkoon.. Miten hyvin palvelu/komponentti tai muu osa-alue palvelusta suoriutuu kuormituksen aikana? Mitkä ovat pullonkaulat. Mihin vaatimuksiin palvelun tulee kyetä vastaamaan?

Millaisia vaatimuksia palveluun kohdistuu suorituskyvyn näkökulmasta?

VaatimusID Tyyppi Kuvaus Ominaisuus johon vaikuttaa
PERFORMANCE-REQ-0000 Non-Functional Performance Kirjautuminen on mahdollista yhtäaikaa 100 käyttäjällä (100 request/s) Kirjautuminen ft1
PERFORMANCE-REQ-0001 Non-Functional Performance
PERFORMANCE-REQ-0002 Non-Functional Performance
PERFORMANCE-REQ-0003 Non-Functional Performance
PERFORMANCE-REQ-0004 Non-Functional Performance
PERFORMANCE-REQ-0005 Non-Functional Performance

Millaisia vaatimuksia palveluun kohdistuu tietoturvan näkökulmasta?

Tutustu Ssecurity cards-metodiin

VaatimusID Tyyppi Kuvaus Ominaisuus johon vaikuttaa
SECURITY-REQ-0001 Non-Functional Security Salasanassa on käytettävä vähintään MD5-tason salausta, koska standardi XY112 sitä edellyttää Kirjautuminen ft1
SECURITY-REQ-0002 Non-Functional Security
SECURITY-REQ-0003 Non-Functional Security
SECURITY-REQ-0004 Non-Functional Security
SECURITY-REQ-0005 Non-Functional Security
SECURITY-REQ-0006 Non-Functional Security
SECURITY-REQ-0007 Non-Functional Security
SECURITY-REQ-0008 Non-Functional Security
SECURITY-REQ-0009 Non-Functional Security
SECURITY-REQ-0010 Non-Functional Security

Mitä tarkoitetaan käyttävyydellä? Millaisia asioita/ohjeistuksia on otettava huomioon palvelua toteutettaessa?

VaatimusID Tyyppi Kuvaus Ominaisuus johon vaikuttaa
USABILITY-REQ-0000 Non-Functional Usability Kirjautuminen ft1
USABILITY-REQ-0001 Non-Functional Usability Käytettävyys
USABILITY-REQ-0002 Non-Functional Usability Käytettävyys
USABILITY-REQ-0003 Non-Functional Usability Käytettävyys
USABILITY-REQ-0004 Non-Functional Usability
USABILITY-REQ-0005 Non-Functional Usability Käytettävyys

Millaisia asioita on otettava huomioon tuotteen laadunvarmistamisen kannalta?. Kehityksen aikana ohjelmistotuotteeseen on luotava tarvittavat rajapinnat tai työkalu-ohjelmistoja, joiden avulla voidaan hallita testikohteena olevaa tuoteversiota. Nämä vaatimukset on kirjattava ajoissa, koska ne vaikuttavat ratkaisevasti tuotteen testausmahdollisuuksiin. Esimerkkinä voidaan miettiä logien hallintaa, niiden keräämistä, alkutilanteeseen saattamista.

VaatimusID Tyyppi Kuvaus Ominaisuus johon vaikuttaa
TESTABILITY-REQ-0000 Non-Functional Testability Käyttäjärekisteri on kyettävä palauttamaan alkutilaan ennen testien ajoa Kirjautuminen ft1
TESTABILITY-REQ-0001 Non-Functional Testability Lisätietoa
TESTABILITY-REQ-0002 Non-Functional Testability Lisätietoa
TESTABILITY-REQ-0003 Non-Functional Testability Lisätietoa
TESTABILITY-REQ-0004 Non-Functional Testability Lisätietoa
TESTABILITY-REQ-0005 Non-Functional Testability Lisätietoa

Extra

Kannattaa tutustua :) https://www.etteplan.com/services/testing-and-test-laboratory/product-safety-and-training

Ohjelmiston arkkitehtuuri, sijoittelunäkymä, tietokantakuvaus ja integraatiot

Ohjelmiston toteutus vaatimuksiin voidaan asettaa ennalta määriteltyjä teknologioita, joita on noudatettava kehityksessä. Tämä tilanne tulee usein eteen, kun ohjelmisto liittyy aiemmin toteutettuun ratkaisuun

Palvelun sijoittelunäkymä (Deployment diagram )

Sijoittelunäkyvän avulla voi kuvata miten eri palvelu osat toimivat sen ollessa toiminnassa.

Tietokantakuvaus (Database ER-diagram)

Palvelua määriteltäessä on yleistä kuvata tarvittavan tietovaraston karkeaa rakennetta esim. ER-kaavion muodossa. Tämä antaa kuvaa siitä millainen ratkaisu tarvitaan Voit soveltaa PlantUML-kuvausta ER-kaavion tuottamiseen.

Esimerkki

uml diagram

Integraatiot muihin järjestelmiin

Vaatimusmäärittelyssä on kuvata palvelun/tuoteen riippuvuus muista järjestelmistä. Onko joitain palvelun osia tarkoitus ostaa ulkopuoliselta palvelun tarjoajalta. Esimerkkeinä virtuaalikoneet, laskutusjärjestelmät, valvonta ja muut palvelutuotannon ratkaisut.

uml diagram

Integraation kuvaaminen sekvenssikaaviona

Järjestelmien välisiä tapahtumia voi kuvata tarvittaessa esim. sekvenssikaavion muodossa.

uml diagram

Palvelun laadun varmistus

Ohjelmisto

Palvelun/Ohjelmiston alustavat hyväksyntätestit

Hyväksyntätesteissä keskitytään yleisesti asiakkaan/loppukäyttäjän näkökulmaan. Tavoitteena on kelpuuttaa, eli validoida , onko tuote asiakkaan toiveiden mukainen ja täyttääkö se asetetut vaatimukset. Hyväksyntätesteillä voidaan selvittää onko tuote myös riittävän suorituskykyinen, käytettävä tai tietoturvallinen asiakkaiden käyttötarkoitukseen.

Kiinnitetään alustavat hyväksyntätestit vaatimuksiin taulukon muodossa.

Lähde Testitapaus Id Kuvaus Tyyppi
Feature 1, FUNCTIONAL-REQ-0001 Testitapaus 1 esim. Tarkista kirjautuminen palveluun uutena käyttäjänä Hyväksyntätesti
Feature 2, FUNCTIONAL-REQ-0201, USE-CASE-017 Testitapaus 2 esim. Tarkista kenkilökohtaisten tietojen poisto Hyväksyntätesti
Feature 3, Testitapaus 101 esim. Takista Kirjautuminen toimivalla salasanalla Hyväksyntätesti

Julkaisusuunnitelma

Julkaisusuunnitelman visualisoidulla muodolla on helpompi esittää ominaisuuksien julkaisut kehityksen aikanan. Alla oleva kuva on luotu hyödyntäen PlantUML-työkalua. Sen avulla on luoto ns. Gantt-kaavio ominaisuuksien julkaisuajankohdista.

Oletamme, että tuotteessa on muutamia ominaisuuksia, joiden järjestys on mietitty ennakkoon..

uml diagram

Tuotteen/ohjelmiston eri ominaisuuksista kehitetään usein eri versioita ja tämä johtaa usein erilaisiin tuotekokonaisuuksiin. Puhutaan ns. tuotekonfiguraatiosta, jonka avulla kiinnitetään eri ominaisuusversiot yhteen ohjelmiston julkaisu versionn.

Alla olevassa taulukossa on esitelty julkaisuun "EarlyAdopter - Versio 1.0" valitut toiminnallisuudet

Ominaisuus/toiminnallisuus Versio Milloin testattavissa Julkaisu
Feature 1 1.0 15.6.2019 V1.0
Feature 2 1.0 1.7.2019 V1.0
Feature 3 1.1 15.7.2019 V1.0
Feature 4 1.1 20.7.2019 V1.0
Feature 5 2.3 23.7.2019 V1.0

Standardit ja lähteet

Vaatimusmäärittelyn osana on oleellista tuoda esiin tärkeät lähteet, joista on hyötyä tai merkitystä kokonaisuuden kannalta. Standardit ja ennalta jaetut ohjeistukset ovat hyödyllisiä lähteitä ja tarvittaessa selkeyttävät vaatimusten merkitystä.

ID Linkki
JHS 165 ICT http://www.jhs-suositukset.fi/c/document_library/get_file?uuid=b8118ad7-8ee4-459a-a12b-f56655e4ab9d&groupId=14 Vaatimusmäärittely
SO 9241-11 https://fi.wikipedia.org/wiki/K%C3%A4ytett%C3%A4vyys Käytettävyys
ISO9001 https://www.sfs.fi/julkaisut_ja_palvelut/tuotteet_valokeilassa/iso_9000_laadunhallinta/iso_9001_2015 -
- - -