> 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.
## Johdatus
> 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.
>Kerro millaisesta projektista on kyse, hieman taustaa ja aiheeseen olennaisesti liittyviä asioita? Älä käytä harjoitustehtävässä tilaajien oikeita nimiä vaan muuta henkilötiedot ja toimeksiantajan viralliset tiedot
> 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 :)
> HUOMIO! Kun teet harjoitusta, niin poista ennen lopullista luovutusta kaikki ohjekommentit ja video-linkit sisällöstä.
## Vaatimusmäärittelytyön toimeksiantaja/tilaaja
> 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
1.[Aiheeseen liityvä standardit ja lähteet](#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 tarvittaessa henkilötiedot ja toimeksiantajan viralliset tiedot
## Toimeksiantaja
## Vaatimusmäärittelyn toimittaja
>Kuka on vaatimusmäärittelyn tilaaja?
>Kerro lyhyesti itsestäsi (tarvittaessa pseudonyyminä) tai esim. kuvitteellisen yrityksen työntekijänä
## Vaatimusmäärittelyn tekijästä
>Kerro lyhyesti itsestäsi (tarvittaessa pseudonyyminä) tai esim. kuvitteellisen yrityksen työntekijänä.
## Palvelukuvaus
>Mitä palvelun avulla voidaan tehdä? Mikä sen tehtävä on sidosryhmän kannalta? Kannattaa keskittyä loppukäyttäjiin tai oleellisiin palvelusta hyötyviin sidosryhmiin
>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.
>Mietitään ensin millaisia käyttäjiä/sidosryhmiä liittyy suunniteltuun palvelukokonaisuuteen? Näitä selkeyttääksemme kerätään kaikki sidosryhmät yhteen sidosryhmä-kuvaan ja tarkastellaan samalla mikä on ko. ryhmän/edustajan palveluun liittyvä motivaatio
**Mieti mitä oleellista yllä olevasta kuvasta puuttuu? Yritä tulkita kuvaa nykymuodossaan?**
## 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](profiili-loppukayttaja.md)
**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
| Henkilö 1 | [Profiili 1](pohjat/pohja-profiilikuvaus.md) | Edustaa sidosryhmää [Sidosryhmä-2](pohjat/pohja-profiilikuvaus.md) |
| Henkilö 2 | [Profiili 1](pohjat/pohja-profiilikuvaus.md) | Edustaa sidosryhmää [Sidosryhmä-2](pohjat/pohja-profiilikuvaus.md) |
| Henkilö 3 | [Profiili 1](pohjat/pohja-profiilikuvaus.md) | [Sidosryhmä-1](pohjat/pohja-profiilikuvaus.md) |
## Asiakkaan tarpeet/toiveet?
> Täydennä tätä jatkuvasti kurssin aikana!
> Pohdi millaisia toiveita/tarpeita on loppukäyttäjällä liittyen palveluun? Haastattele henkilöitä todellisessa tilanteessa?
| VaatimusID | Tyyppi | Kuvaus |
|:-:|:-:|:-:|
| CUSTOMER-REQ-0001 | Customer Requirement | Käyttäjänä haluan kirjautua käyttäen Facebook-tunnuksia, ettei tarvise 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?
## Valitut sidosryhmät ja profiilit (Profiles/Stakeholders)
> Pohdi millaisia toiveita/tarpeita on Liiketoiminnan näkökulmasta liittyen palveluun?
> Jos mitään ei tule mieleen, niin pohdi kenen "kassaan" raha tulee palvelusta? Saavutetaanko palvelulla kustannushyötyjä? Parantaako kustannustehokkuutta? etc
| 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 ||
>Valitaan aiemmin määritellystä sidosryhmäkuvauksesta tarkempaan tarkasteluun tärkeäksi koetut sidosryhmät/profiilit. Jokainen valittu sidosryhmä kuvataa itsenäisenä profiilikuvauksena ja tallennetaan omaksi tiedostokseen
>Jokainen profiili kuvaus tallennetaan itsenäisenä tiedostona, koska tämä helpottaa tulevaisuudessa niihin viittaamista dokumentaatiossa esim. [Loppukäyttäjä - Keijo Korhonen](..pohjat/pohja-profiilikuvaus.md)
## Tunnistetut riskit
**Muista kirjata kuvauksiin erityisesti sidosryhmän motivaatio! Eli miksi sidosryhmä syy käyttää/soveltaa palvelua**
> Millaisia riskeja liittyy tuoteen kehittämiseen, tuotteen markkinoihin, mahdollisiin kilpailijoihin, resursseihin?
Nämä on hyvä tunnistaa alkuvaiheessa
*[Sidosryhmä](..pohjat/pohja-profiilikuvaus.md)
*[Profiili 1](..pohjat/pohja-profiilikuvaus.md)
*[Profiili 2](..pohjat/pohja-profiilikuvaus.md)
*[Profiili 3](..pohjat/pohja-profiilikuvaus.md)
> Avainsanat SWOT, Riskianalyysi
## Valitut asiakastarinat
>Valitaan tarvittava määrä eri sidosryhmiä/profiileja ja kirjoitetaan auki valitulle profiilille/sidosryhmälle "asiakastarina". Tavoitteena on kuvata sitä, miten valittu profiili/sidosryhmä käytännössä hyödyntää palvelua. Tavoite ei ole kehua sitä vaan käydä läpi syitä palvelun käyttöön ja miten se auttaa ko. sidosryhmää/profiilia.
>Haastattele tai kuvittele haastattelevasi profiili/sidosryhmän edustajaa ja kirjaa suunnittelemasi palvelun käyttöön liittyviä tilanteita.
Miten henkilö/sidosryhmä hyötyy/käyttää palvelua. Kirjoita tämä asiakastarinaksi. Kerro mitä se 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 :)
>Muista kirjoittaa tarina auki pelkästään valitun sidosryhmän näkökulmasta (toiset sidosryhmät saattavat esiintyä tarinassa)
> 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](pohjat/pohja-profiilikuvaus.md)-kuvauksiin.**
*[Profiili 1](..pohjat/pohja-profiilikuvaus.md): Profiili 1 haluaa tuottaa iloa....
*[Profiili 2](..pohjat/pohja-profiilikuvaus.md): Profiili 2 aloitaa aamulla palvelun käytön ...
*[Sidosryhmä 1](..pohjat/pohja-profiilikuvaus.md): Sidosryhmä 1:en kannalta palvelun...
**Asiakastarina 1**
[Profiili 1](pohjat/pohja-profiilikuvaus.md) herää aamusta ja tarkistaa puhelimellaan onko X-palvelussa tilaa aamupäivästä. Huomatessaan, että palvelussa on vapaa aika klo 11:00.........
## Palvelun tärkeimmät asiakaspolut (Customer Journey/Path)
**Asiakastarina 2**
>Tarkennetaan tarinaa ja nostetaan oleelliset profiilit tarkasteluun palvelupolun näkökulmasta.
Tämän "polun" tarkoituksena on kuvata sitä tapahtumien sarjaa joka käydään läpi palvelua käytettäessä.
Palvelupolkuja voi olla useita, mutta tärkeintä on kuvata oleellisimmat aluksi. Palvelu polku kuvauksessa voidaan hyödyntää Swimlane/BluePrint/tilakone-kuvausta tai muuta sopivaksi katsottua visualisointi tapaa.
Tärkeää on kuvata polku ja käydä sen avulla eri vaiheet läpi
[Asiakas-tyyppi 3](pohjat/pohja-profiilikuvaus.md) käynnistää iltapäivällä rakennustyömaalla sementtimyllyä, kun hänelle tulee viesti X-palvelusta.........
>Asiakaspolkukua on hyvä lähteä luonnostelemaan esim. asiakastarinan pohjalta. Polkuja kannattaa määritellä tarvittaessa useampia eri tilanteiden näkökulmasta.
Yhteen kuvaukseen ei kannata upottaa liikaa tapahtumia
>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..
>Palvelupolkujen kuvaukseen voidaan hyödyntää myös erillisiä työkaluja. Mieti onko mahdollista hyödynnetään jotain ulkopuolista palvelua kuvauksen apuna?
>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
>**Käyttötapaukset** (Use Case) on hyvä erottaa **käyttötarkoituksesta** (Use Case)! Yleensä palvelusta ensi kertaa keskusteltaessa puhutaan sen eri käyttötarkoituksista, eli sitä
mihin ohjelmistoa/palvelua voidaan hyödyntää. Kun puhutaan palvelun määrittelystä käyttötapauksien kannalta on kyseessä eri asia. Käyttötapauksessa keskitytään
tarkastelmaan palvelun käyttöä varsin rajatussa tilanteessa. On oleellista kirjata alkuvaiheessa tärkeimmät käyttötapaukset yhteen kuvaukseen. Tähän hyödynnetään UML- Use Case-diagrammia.
> Kokeillaan luonnostella asiakaspolkua PlantUML-työkalun avulla. Kannattaa kokeilla ehdottomasti myös muita tapoja!
> Sovella esim. PlantUML SDL/Swimlane kuvausta?
**Millaisia ovat tärkeimmät käyttötapaukset (Use Caset) tuotteeseen/palveluun liittyen? Muista, ettei käyttötapauksella ei tarkoiteta käyttökohdetta/soveltamiskohdetta**
* User Story: [Käyttäjänä haluan, että voin luoda raportin tekemistäni ostoista viimeisen kuukauden ajalta, koska se helpottaa oman talouteni hallintaa]()
* User Story: [Pääkäyttäjän haluan poistaa vanhat tunnukset kokonaan, koska se selkeyttää ylläpitoa]()
* Käytännössä ylempi kuvaus on hieman jäykkä ja on järkevitä kirjata storyt suoraan esim. GitLab-issuen muotoon!
* Kokeile osoittaa hiirelle linkkejä oikealla ja avaa ne tämän jälkeen ---> #25 tai #26
## Palvelun järjestelmävaatimukset
Esimerkki User Story issuesta #1
## Ohjelmiston/palvelun tekniset vaatimukset
> Järjestelmävaatimukset ovat korkeamman tason vaatimuksia, joiden pohjalta järjestelmä kokonaisuutta lähdetään määrittelemään.
> Palveluita suunniteltaessa nousevat teknisestä näkökulmasta tarkasteltuna esiin vaatimukset, jotka liittyvät eri
teknologioihin, laitteistoihin tai totetuksen fyysisiin rakenteisiin. Ohjelmistopalvelua määriteltäessä
kannattaa tunnistaa ajoissa puhtaasti järjestelmän tekniset/tuotannolliset vaatimukset ja kirjata ne vaatimusmäärittelyyn.
Liiallinen keskittyminen teknisten tuotanto/toteutusvaatimusten kirjaukseen ei ole välttämättä suositeltavaa, koska
suunnittelun aikana ohjelmistoa/palvelun toteutusvaatimukset voivat vielä muuttua. Kehitysvaiheessa näppäräksi koettu ratkaisu
voi osoittatua kalliiksi palvelun tuotteistamisvaiheessa.
>Ohjelmistoja ja palveluita suunniteltaessa usein tulevat esiin vaatimukset, jotka liittyvät eri teknologioihin, laitteistoon ja fyysiseen rakenteeseen. Näiden rinnalla pohditaan
mitä toiminnallisuuksia ratkaisun tulee pitää sisällään. Tästä johtuen kannattaa alkuvaiheessa pyrkiä tunnistamaan puhtaasti tekniset vaatimukset ja kirjata ne vaatimusmäärittelyyn.
Liiallinen keskittyminen alussa teknisten vaatimusten kirjaamiseen ei välttämättä ole kannattavaa, koska suunnittelun aikana ohjelmistoa/palvelun tekniset vaatimukset tarkentuvat
ja tarpeet saattavat muuttua. Kehityskäytössä näppärä ratkaisu voi osoittatua kalliiksi, kun se tuotteistetaan.
> Tässä osiossa Kannattaa pohtia esim seuraavia kohti
**Teknisiä järjestelmävaatimuksia**
- Miten palvelu tuotetaan? SAAS/PAAS/IAAS/HOSTED-palveluna etc
- Käytetäänkö Pilvipalveluita osana ratkaisua vai hyödynnetäänkö omia palvelimia
- Onko kyseessä ns. Hybridi-palvelu, joka hyödyntää useampia erillis palvelua
- Miten palvelu on oltava saatavilla 24/7h 100% ? Niin onko tuo edes mahdollista :) ?
- Millainen SLA palvelulle laaditaan?
- Miten paljon kustannuksia saa palvelun tuotanto tuottaa?
- Millaiset tiedonsäilytys/arkistointi tarpeet liittyvät palveluun?
> Järjestelmä tason vaatimuksissa tarkastellaan ohjelmistoa/palvelua kokonaisuutena ja sen pohjalta määritellään
esim. tekniset vaatimukset suoritusympäristölle, vaadittaville resursseille palvelun ylläpitoa varten.
> Järjestelmän suoritusympäristön vaatimukset käsittävät esimerkiksi laitevaatimukset tuotantoympäristöstä tai
järjestelmän ajoympäristön vaatimuksia, joihin voivat sisältyä vaatimukset suorituskyvystä, ylläpidosta, varmennuksista etc
> Millaisia suoritusympäristöjä sitten käytetään esim. kaupallisissa ratkaisuissa ? Voit tutkia esimerkkejä [Stack Share](https://stackshare.io/):palvelussa
> Esim. millainen on tekninen ratkaisu toteutukselle ja miten eri teknologioita tullaan hyödyntämään.
| VaatimusID | Tyyppi | Kuvaus | Ominaisuus johon vaikuttaa |
|:-:|:-:|:-:|:-:|
...
...
@@ -175,45 +382,91 @@ ja tarpeet saattavat muuttua. Kehityskäytössä näppärä ratkaisu voi osoitta
| SYSTEM-HW-REQ-0005 | System Technical Requirement | Verkkoyhteyden nopeus >100MB/s ||
| SYSTEM-HW-REQ-0005 | System Technical Requirement | Laitekaapin suositeltava koko 1m X 1m X 2m ||
>Eri ohjelmistojena/palvelujen toteutusta ja käyttöä ohjaavat usein lait ja säädökset. Näiden edellyttämät vaatimukset kirjataan yleensä rajoitteina
### Palvelun suunnitteluun vaikuttavat rajaukset ja standardit
> Eri ohjelmistojena/palvelujen toteutusta ja käyttöä ohjaavat usein lait ja säädökset. Näiden edellyttämät vaatimukset kirjataan yleensä rajoitteina
ja niiden vaikutus koskee usein koko ohjelmiston/järjestelmän toteuttamista. Tästä syystä ne kannattaa tunnistaa ja selvittää ajoissa, koska vaikutus
saataa olla varsin ratkaiseva pitemmällä tähtäimella. Esimerkkinä [EU GDPR-säädös](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation).
> 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 |
> Kirjataan taulukkoon "kaikki" toiminnot, joista osaa tullaan käsittelemään myöhemmin tuotteen toiminnallisina ominaisuuksina.
Kannattaa huomata, että osa toiminnallista vaatimuksista ovat käytännössä oleellisia toimintoja, eli ne voidaan "korottaa" ominaisuuksiksi.
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
> 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.
> 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 |
| 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](pohjat/pohja-ominaisuus.md), [Tilaushallinta](pohjat/pohja-ominaisuus.md)|
>Mitä olivat ei-toiminnalliset vaatimukset? Voit esittää eri vaatimuksia erillisessä taulukossa tai viitata tässä [yhteen](pohjat/pohja-vaatimuslistalle.md) laajempaan taulukkoon.
[Ei-toiminnalliset vaatimukset](https://en.wikipedia.org/wiki/Non-functional_requirement) 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
### Suorituskyky? (Performance)
>Voit esittää eri vaatimuksia erillisessä taulukossa tai viitata tässä [yhteen](pohjat/pohja-vaatimuslistalle.md) laajempaan taulukkoon..
Miten hyvin palvelu/komponentti tai muu osa-alue palvelusta suoriutuu kuormituksen aikana? Mitkä ovat pullonkaulat. Mihin vaatimuksiin palvelun tulee kyetä vastaamaan?
>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 | Käyttöliittymän on toimittava myös ääniohjattuna, koska käyttäjillä saattaa olla näkövammoja | [Kirjautuminen ft1](ft1-ominaisuus.md) | |
>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](ft1-ominaisuus.md) |
>Tähän kirjataan vaatimuksia, joiden merkitys tulee esiin vasta tuotteen julkaisun jälkeen. Miten tuotteen ylläpidettävyyttä parannetaan? Mitä pitää ottaa huomioon, että ylläpidettävyys on helpompaa
## Ohjelmiston arkkitehtuuri, sijoittelunäkymä, tietokantakuvaus ja integraatiot
| Id | Vaatimuksen kuvaus | kategoria | Vastuullinen |
|:-:|:-:|:-:|:-:|
| MAINT-REQ00x | Vaatimus? | Ylläpito | Kuka vastaa |
| MAINT-REQ00x | Vaatimus? | Tekninen | Kuka vastaa |
| MAINT-REQ00x | Vaatimus? | Käytettävyys | Kuka vastaa |
| MAINT-REQ00x | Vaatimus? | Käytettävyys | Kuka vastaa |
| MAINT-REQ00x | Vaatimus? | Käytettävyys | Kuka vastaa |
>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
## Tärkeimmät tunnistetut ominaisuudet/piirteet (Features)
>Sijoittelunäkyvän avulla voi kuvata miten eri palvelu osat toimivat sen ollessa toiminnassa.
>>Kannataa pohtia määrittely vaiheessa ovatko kaikki ominaisuudet tarpeellisia? Osa toiminnallisista vaatimuksista on oletuksena ominaisuuksia. 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.
>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**
## Palvelu MockUp-prototyyppi
```plantuml
' hide the spot
hide circle
' avoid problems with angled crows feet
skinparam linetype ortho
entity "Entity01" as e01 {
*e1_id : number <<generated>>
--
*name : text
description : text
}
entity "Entity02" as e02 {
*e2_id : number <<generated>>
--
*e1_id : number <<FK>>
other_details : text
}
entity "Entity03" as e03 {
*e3_id : number <<generated>>
--
*e1_id : number <<FK>>
other_details : text
}
e01 ||..o{ e02
e01 |o..o{ e03
```
>Suunnittellun palvelun/ohjelmiston yleinen näkymä kannataa esitellä MockUp-muodossa. Tarkemmin määritellyissä ominaisuuskuvauksissa voi esitellä tarkemmin jotain toimintoa.
MockUp-kuvaus on hyödyllinen apuväline palvelun tilaajan/toimeksiantajan kanssa käydyissä keskusteluissa.
### Integraatiot muihin järjestelmiin
Kokonaispalvelun MockUp-kuva?
>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.
>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.
>Tuotteen/ohjelmiston eri ominaisuuksista kehitetään usein eri versioita ja tämä johtaa usein erilaisiin tuotekokonaisuuksiin. Puhutaan ns. tuotekonfiguraatiosta, jonka avulla pyritään kiinnittämään eri
ohjelmiston ominaisuusversiot yhteen version.
>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.
Seuraavassa taulukossa on esitelty eri versioissa julkaistavat ominaisuudet taulukon muodossa.
> Alla olevassa taulukossa on esitelty julkaisuun "EarlyAdopter - Versio 1.0" valitut toiminnallisuudet
**Julkaisu "EarlyAdopter - Versio 1.0"**
| Ominaisuus | Versio | Testattavissa | Julkaistaan |
|:-:|:-:|:-:|:-:|
| [Feature 1]() | 1.0 | x.y.201z | x+2,y+3.201z |
| [Feature 2]() | 1.0 | x.y.201z | x+2,y+3.201z |
| [Feature 3]() | 1.1 | x.y.201z | x+2,y+3.201z |
| [Feature 4]() | 1.1 | x.y.201z | x+2,y+3.201z |
| [Feature 5]() | 2.3 | x.y.201z | x+2,y+3.201z |
| [Feature 6]() | 0.9 | x.y.201z | x+2,y+3.201z |
| [Feature 7]() | 1.1 | x.y.201z | x+2,y+3.201z |
Seuraavassa julkaisussa on mukana muutamia parannettuja ominaisuuksia, jotka ovat kehittyneet eteenpäin. Näistä on valittu sopiva kokonaisuus asiakas julkaisuun.
**Julkaisu "Enhanced - Versio 1.1"**
| Ominaisuus | Versio | Testattavissa | Julkaistaan |
| Ominaisuus/toiminnallisuus | Versio | Milloin testattavissa | Julkaisu |
|:-:|:-:|:-:|:-:|
| [Feature 1]() | 1.1 | x.y.201z | x+2,y+3.201z |
| [Feature 2]() | 1.1 | x.y.201z | x+2,y+3.201z |
| [Feature 3]() | 1.2 | x.y.201z | x+2,y+3.201z |
| [Feature 4]() | 1.4 | x.y.201z | x+2,y+3.201z |
| [Feature 5]() | 2.6 | x.y.201z | x+2,y+3.201z |
| [Feature 6]() | 1.2 | x.y.201z | x+2,y+3.201z |
| [Feature 7]() | 1.1 | x.y.201z | x+2,y+3.201z |
# Palvelun/ohjelmiston arkkitehtuuri
>Millainen on tekninen toteutus ja miten eri teknologioita tullaan hyödyntämään.
## Yleinen sijoittelunäkymä (Deployment diagram )
>Sijoittelunäkyvän avulla voi kuvata miten eri palvelu osat toimivat sen ollessa toiminnassa.
>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.
| Id | Vaatimuksen kuvaus | kategoria | Vastuullinen |
|:-:|:-:|:-:|:-:|
| REQ00x | Vaatimus? | Testattavuus | Kuka vastaa |
| REQ00x | Vaatimus? | Testattavuus | Kuka vastaa |
| REQ00x | Vaatimus? | Testattavuus | Kuka vastaa |
| REQ00x | Vaatimus? | Testattavuus | Kuka vastaa |
| REQ00x | Vaatimus? | Testattavuus | Kuka vastaa |
# Tunnistetut riskit ja testikohteet
>Millaisia riskeja liittyy tuoteen kehittämiseen, tuotteen markkinoihin, mahdollisiin kilpailijoihin, resursseihin? Nämä on hyvä tunnistaa alkuvaiheessa
> 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
