* Vaatimusmäärittely pohjan versio 1.8 - 5.9.2019 (NarsuMan)
* Vaatimusmäärittely pohjan versio 2.1 - 09.09.2020 (NarsuMan)
## Ohjeita määrittelijälle
## Ohjeita määrittelytyön tekijälle
> Pidä sisällysluettelo kunnossa, eli päivitä tarvittaessa MarkDown-ankkurilinkitys.
...
...
@@ -24,7 +22,7 @@ hyödyllistä tutustua sen käyttöön http://plantuml.com/ ja pyrkiä soveltama
> 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ä.
...
...
@@ -35,7 +33,6 @@ Kuvaus voi päivittyä kurssin aikana!
> __Ominaisuus: Raportti generaattori__
> Tämä helpottaa hahmottamaan myöhemmin koko vaatimusmäärittelyn rakennetta
## Sisällysluettelo
1.[Johdanto](#johdanto)
...
...
@@ -67,15 +64,14 @@ Kuvaus voi päivittyä kurssin aikana!
1.[Julkaisusuunnitelma](#Julkaisusuunnitelma)
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
käytää todellisten tilaajien oikeita nimiä! Muuta aina oletuksena henkilötiedot ja toimeksiantajan viralliset tiedot
## Toimeksiantaja
>Kuka on vaatimusmäärittelyn tilaaja?
>Kuka on vaatimusmäärittelyn tilaaja? Muista vaihtaa oikeat tilaajan nimet ja tiedot omiin keksittyihin!
## Vaatimusmäärittelyn tekijästä
...
...
@@ -88,8 +84,6 @@ käytää todellisten tilaajien oikeita nimiä! Muuta tarvittaessa henkilötiedo
>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?
...
...
@@ -100,6 +94,7 @@ ko. sidosryhmän/edustajan palveluun liittyvä motivaatio. Kuvauksen voi laatia
> 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!**
@@ -130,23 +127,27 @@ joilla voi olla eroja motiiveissa/arvoissa, mutta ne kuuluvat kuitenkin olennais
**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ä
| [Henkilö profiili 1](pohjat/pohja-profiilikuvaus.md) | Vai onko kyseessä ainut [Sidosryhmän-X](pohjat/pohja-profiilikuvaus.md)edustaja |
## 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?
> 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 tarvise häslätä |
| 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 ||
...
...
@@ -155,7 +156,10 @@ joilla voi olla eroja motiiveissa/arvoissa, mutta ne kuuluvat kuitenkin olennais
## Liiketoiminnan vaatimukset/tavoitteet?
> 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
> 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 |
|:-:|:-:|:-:|
...
...
@@ -165,25 +169,23 @@ joilla voi olla eroja motiiveissa/arvoissa, mutta ne kuuluvat kuitenkin olennais
| 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
> Avainsanat SWOT, Riskianalyysi
**VAPAAEHTOINEN**
> Avainsanat SWOT, Riskianalyysi
## Valitut asiakastarinat
>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 :)
>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](pohjat/pohja-profiilikuvaus.md)-kuvauksiin.**
@@ -195,20 +197,19 @@ Alla olevassa videossa näet millaisia tarinoita **ei** ole tarkoitus kirjata t
[Asiakas-tyyppi 3](pohjat/pohja-profiilikuvaus.md) 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..
>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
>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
@@ -217,7 +218,6 @@ Käy läpi tekemäsi kuvausta jonkun toisen henkilön kanssa yhdessä? Käy läp
> Kokeillaan luonnostella asiakaspolkua PlantUML-työkalun avulla. Kannattaa kokeilla ehdottomasti myös muita tapoja!
> Sovella esim. PlantUML SDL/Swimlane kuvausta?
```plantuml
[*] --> Step1
...
...
@@ -233,12 +233,13 @@ Step2 --> Step3
Step3 --> [*]
```
> 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ä tapahtumia. Tilanteet joissa käsitellään itse ohjelmistpalvelun
sähköisiä rajapintoja/käyttöliittymiä voidaan kuvata käyttötapauksien (Use Case) avulla.
> Ohjelmistosuunnittelussa **Käyttötapaus** (Use Case) ymmärretään helposti väärin, koska se liitetään helposti pelkästään tuotteen
> 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.
...
...
@@ -276,7 +277,7 @@ helpommin koko järjestelmää. Huomio! Laajemmassa järjestelmä kokonaisuudess
> 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 | Ominaisuus? |
| Käyttötapaus | Osa-alue | toiminnallisuus/ominaisuus johon UC -liittyy |
@@ -285,28 +286,35 @@ laaditaan itsenäinen tiedosto.
## 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ää:
> On hyödyllistä laatia toimeksiantajan kanssa yhdessä tiivistelmä (A4-kokoa), josta löytyy tarvittaessa koko tuote kiteytettynä
> 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
...
...
@@ -339,61 +347,51 @@ Sen avulla kuvataan palveluun liittyvää toiminnallisuutta, jolle käyttäjäll
* 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
## Palvelun liittyvät tuotannolliset ja tekniset vaatimukset
**Tämä osa-alue vielä kesken**
> 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.
> 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 näppäräksi koettu ratkaisu
voi osoittatua kalliiksi palvelun tuotteistamisvaiheessa.
> Tässä osiossa Kannattaa pohtia esim seuraavia kohti
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 tuotetaan? SAAS/PAAS/IAAS/HOSTED-palveluna etc
- 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
-Onko kyseessä ns. Hybridi-palvelu, joka hyödyntää useampia erillis palvelua
- Miten palvelu on oltava saatavilla 24/7h 100% ? Niin onko tuo edes mahdollista :) ?
-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 tuotanto tuottaa?
- Miten paljon kustannuksia saa palvelun tuotannolle sallitaan ?
- 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
> Millaisia tuotantoympäristöjä/teknologisia ratkaisuja käyteään käytetään oikeasti? Voit tutkia esimerkkejä [Stack Share](https://stackshare.io/):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 | |
### 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).
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](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 |
...
...
@@ -407,14 +405,34 @@ saataa olla varsin ratkaiseva pitemmällä tähtäimella. Esimerkkinä [EU GDPR-
>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.
| 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) |
### Palvelun ohjelmiston ominaisuudet, eli "featuret"
> 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.
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
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.
...
...
@@ -455,26 +473,6 @@ Tämä ei tarkoita, että kyseessä on tuoteeen ohjelmiston yksi ominaisuus vaan
| 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) |
| 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](ft1-ominaisuus.md) |
...
...
@@ -537,6 +537,11 @@ Esimerkkinä voidaan miettiä logien hallintaa, niiden keräämistä, alkutilant
