From 1d1beb5eb7da82137d6c1817556c968e10328eb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marko=20Rintam=C3=A4ki?= <marko.rintamaki@jamk.fi>
Date: Tue, 8 Oct 2019 10:25:16 +0300
Subject: [PATCH] Update requirement-specification.md
---
.../requirement-specification.md | 753 +++++++++++-------
1 file changed, 480 insertions(+), 273 deletions(-)
diff --git a/documentation/20-Requirement-management/requirement-specification.md b/documentation/20-Requirement-management/requirement-specification.md
index c8b33ed..0f453c0 100644
--- a/documentation/20-Requirement-management/requirement-specification.md
+++ b/documentation/20-Requirement-management/requirement-specification.md
@@ -1,170 +1,377 @@
-## Ohjelmiston/palvelun vaatimusmäärittely
+# XYZ - Requirement Specification
-[](http://www.youtube.com/watch?v=jH43MPe1Ceg "")
-Vaatimusmäärittely pohjan versio 1.1 - 24.4.2019
+> Fill the lines !
-## TTOS0800 Kurssi [TOIMEKSIANTO KOODI TÄHÄN]
+* [SIJOITA TOIMEKSIANNON KOODI TÄHÄN]
+* Nimimerkkisi/gitlab tunnus
+* Dokumentin versionumero X.Y
+* Vaatimusmäärittely pohjan versio 1.8 - 5.9.2019 (NarsuMan)
-* Nimimerkki/gitlab tunnus
-* Vuosi
-* Versionumero X.Y
-## Sisällysluettelo
+## Some guidelines for writer of requirement specification
-**Pidä sisällysluettelo kunnossa, eli päivitä sitä tarpeen mukaan! Huomaa MarkDown-ankkurilinkitys**
+> Pidä sisällysluettelo kunnossa, eli päivitä tarvittaessa MarkDown-ankkurilinkitys.
-* [Johdatus](#Johdatus)
-* [Tilaaja](#Vaatimusmäärittelytyön toimeksiantaja/tilaaja)
-* [Toimittaja](#Vaatimusmäärittelyn toimittaja)
-* [Palvelukuvaus](#Palvelukuvaus)
-* [Yleinen sidosryhmäkuvaus]()
-* [Asiakastarina](#Johdatus)
-* [Sidosryhmät ja profiilikuvaukset]()
-* [Sidosryhmäkuva]()
-* [Palvelu/asiakaspolku]()
-* [Alustavat User Story -kuvaukset]()
-* [Yleinen käyttötapaus]()
-* [Yleiset toiminnalliset vaatimukset]()
-* [Yleiset ei-toiminnalliset vaatimukset]()
-* [Palvelu MockUp]()
-* [Tärkeimmät ominaisuudet]()
-* [Julkaisun suunnitelma]()
-* [Palvelun/ohjelmiston arkkitehtuuri]()
-* [Testaus ja laadunvarmistus]()
-* [Lähteet]()
+> 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 :)
+Kuvaus voi päivittyä kurssin aikana!
-[](http://www.youtube.com/watch?v=0zVNZNbphfE "")
+[http://ttos0100.pages.labranet.jamk.fi/eamk-2019/kurssimateriaali/kasitekartta/](http://ttos0100.pages.labranet.jamk.fi/eamk-2019/kurssimateriaali/kasitekartta/)
+> 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
->Kuka on vaatimusmäärittelyn tilaaja?
+## Sisällysluettelo
+
+1. [Johdanto](#johdanto)
+1. [Toimeksiantaja](#toimeksiantaja)
+1. [Vaatimusmäärittelyn tekijä](#vaatimusmäärittelyn-tekijä)
+1. [Palvelukuvaus](#Palvelukuvaus)
+1. [Sidosryhmäkartta](#Sidosryhmäkartta)
+1. [Sidosryhmät ja profiilit](#Sidosryhmät ja profiilit)
+1. [Tunnistetut riskit](#Tunnistetut-riskit)
+1. [Valitut asiakastarinat](#Valitut-asiakastarinat)
+1. [Palveluun liittyviä asiakaspolkuja](#Palveluun-liittyviä-asiakaspolkuja)
+1. [Oleelliset käyttötapaukset](#Oleelliset-käyttötapaukset)
+1. [Tärkeimmät yleiset ominaisuudet/toiminnallisuudet](#Tärkeimmät-ominaisuudet/toiminnallisuudet)
+1. [MockUp-prototyyppi](#MockUp-prototyyppi)
+1. [Alustavat Käyttäjätarinat](#Alustavat-käyttäjätarinat)
+1. [Palvelun järjestelmävaatimukset](#Palvelun-järjestelmävaatimukset)
+1. [Palveluun vaikuttavat rajaukset](#Palveluun vaikuttavat rajaukset)
+1. [Palvelun liityvät laitevaatimukset](#Palvelun liityvät laitevaatimukset)
+1. [Palvelun suoritusympäristöön liittyvät vaatimukset](#Palvelun suoritusympäristöön liittyvät vaatimukset)
+1. [Palvelun määritellyt ominaisuudet/toiminnnallisuudet](#Palvelun määritellyt ominaisuudet/toiminnnallisuudet)
+1. [Palvelun toiminnalliset vaatimukset](#Palvelun toiminnalliset vaatimukset)
+1. [Palvelun ei-toiminnalliset vaatimukset](#Palvelun ei-toiminnalliset vaatimukset)
+1. [Palvelun alustava arkkitehtuuri](#Palvelun alustava arkkitehtuuri)
+1. [Palvelun alustava sijoittelunäkymä](#Palvelun alustava sijoittelunäkymä)
+1. [Palvelun alustava tietokantakuvaus)](#Palvelun alustava tietokantakuvaus)
+1. [Palvelun integraatiot muihin järjestelmiin](#Palvelun integraatiot muihin järjestelmiin)
+1. [Palvelun laadun varmistuksesta](#Palvelun laadun varmistuksesta)
+1. [Palvelun hyväksyntätestit](#Palvelun hyväksyntätestit)
+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
+
+## 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
+[](http://www.youtube.com/watch?v=55H2C0fSiHM "")
+
+>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
-[](http://www.youtube.com/watch?v=fOlmrsp2iRc "")
+## Sidosryhmäkartta
-## Yleinen sidosryhmäkuva (Stakeholder -Map)
+>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
+[](http://www.youtube.com/watch?v=wiNjgClkJoM "")
+
+> 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
+
+```plantuml
+actor profile1
+actor profile3
+actor stake_holder1
+actor stake_holder3
+
+cloud example_of_service
+
+profile1 -- example_of_service : uses
+profile2 -- example_of_service : benefits
+stake_holder1 -- example_of_service : threat
+stake_holder2 -- example_of_service : competitor
+```
+> Voit kuvata sidosryhmät myös vapaamuotoisemmin, jolloin eri profiilien erot tulevat ehkä "selkeämmin" esiin!
-**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.
+
+[](http://www.youtube.com/watch?v=w5oXMtOGcC4 "")
+
+> 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
+
+| Sidosryhmä/Profiili | Linkki | Lisätietoa |
+|:-:|:-:|:-:|
+| Sidosryhmä 1 | [Sidosryhmä-1](pohjat/pohja-profiilikuvaus.md) | |
+| Sidosryhmä 2 | [Sidosryhmä-2](pohjat/pohja-profiilikuvaus.md) | |
+| 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
-[](http://www.youtube.com/watch?v=VmotZXBdrDs "")
+| 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 ||
->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
-[](http://www.youtube.com/watch?v=MCs4dRPtOJU "")
->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 :)
+
+[](http://www.youtube.com/watch?v=KKM_7N1-6Ew "")
-[](http://www.youtube.com/watch?v=m8WEoyyFUww "")
->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.**
+> HUOMIO! Älä sekoita asiakastarinaa (Customer story) käyttäjätarinaan (User Story)
-* [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.........
-[](http://www.youtube.com/watch?v=O04EYNKmEXc "")
->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
+## Palveluun liittyviä asiakaspolkuja
-[](http://www.youtube.com/watch?v=TLFBPQQ95ZE "")
+>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?
+[](http://www.youtube.com/watch?v=kNXjKquK3A0 "")
-**Työkalu esimerkkejä**
+>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
-* [Canvanizer](https://canvanizer.com)
+[](http://www.youtube.com/watch?v=j7U8pqUN9EM "")
-## Tärkeimmät käyttötapaukset (General Use Cases)
+**asiakaspolku PlantUML-esimerkki tilakoneena**
->**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**
-[](http://www.youtube.com/watch?v=rADU4vWTfyY "")
+```plantuml
+[*] --> Step1
+
+Step1 : First contact to service
+Step2 : Under Service
+Step3 : End of service
+Step4 : Queue for service
+
+Step1 --> Step2
+Step1 --> Step4
+Step4 --> Step2
+Step2 --> Step3
+Step3 --> [*]
+```
+> Palvelupolkujen kuvauksissa voi tarvittaessa soveltaa myös muita työkaluja. Esim. https://canvanizer.com, PowerPoint etc
-[](http://www.youtube.com/watch?v=BjQAWfBMpcw "")
+## Oleelliset käyttötapaukset
->On hyvä kerätä tärkeimmät käyttötapaukset yhteen Use Case-kuvaukseen, josta on helpompi tarkastella järjestelmää. Laajemmassa järjestelmässä saattaa
-olla useita satoja käyttötilanteita.
+> 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
+**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
```plantuml
+
+rectangle Tilaus {
Profiili_1--(Tilauksen tekeminen)
Profiili_1--(Tilauksen muokkaus)
Profiili_1--(Tilauksen peruminen)
-Profiili_2--(Tilauksen peruminen)
-Sidosryhmä_1--(Tilauksen muokkaus)
-Sidosryhmä_2--(Tilauksen valvonta)
-Huolto_1--(Tilauksen hyväksyntä)
+}
+
+rectangle Tilausten_hallinta {
+Hallinto_1--(Tilauksien tarkistaminen)
+Hallinto_1--(Tilauksen muokkaus)
+Hallinto_1--(Tilauksen siirto)
+Huolto_1--(Tilauksen manuaalinen poisto)
+Huolto_1--(Tilauksen tyhjennys)
+}
+
```
-* [Käyttötapaus 1 - Tilauksen muokkaus](../pohjat/pohja-kayttotapaus.md)
-* [Käyttötapaus 2 - Tilauksen hyväksyntä](../pohjat/pohja-kayttotapaus.md)
+> 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.
+
+[](http://www.youtube.com/watch?v=DupdE35Ilps "")
+
+[](http://www.youtube.com/watch?v=-3YtgJGuIek "")
+
+[](http://www.youtube.com/watch?v=oVGmIOavB74 "")
+
+> 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 1 - Tilauksen muokkaus](pohjat/pohja-kayttotapaus.md) | Tilausten hallinta | [Tilaushallinta-paneeli](pohjat/pohja-ominaisuus.md) |
+| [Käyttötapaus 2 - Tilauksen tarkistaminen](pohjat/pohja-kayttotapaus.md) | Tilausten hallinta | [Tilaushallinta-paneeli](pohjat/pohja-ominaisuus.md) |
+| [Käyttötapaus 2 - Tilauksen siirto](pohjat/pohja-kayttotapaus.md) | Tilausten hallinta | [Tilaushallinta-paneeli](pohjat/pohja-ominaisuus.md) |
+
+## Tärkeimmät ominaisuudet/toiminnallisuudet
+
+> Hahmotellaan tähän kohtaan ominaisuudet pelkästään "ranskalaisilla viivoilla", eli mitä palvelulla mielestäsi on mahdollista tehdä?
+> Päivitä lista myöhemmin, kun se tarkentuu?
+
+> On hyödyllistä laatia toimeksiantajan kanssa yhdessä tiivistelmä (A4-kokoa), josta löytyy tarvittaessa koko tuote kiteytettynä
+Löydät esimerkin dokumentista [täältä](../pohjat/pohja-tuotekuvaus-a4.md)
+
+> Toiminnallisuudet tullaan kiinnittämään myöhemmin
+
+- Toiminnot
+ - Käyttäjä voi lähettää postia toiselle henkilölle
+ - Asiakas saa tiedot aiemmin tehdyistä valinnoista
+ - Henkilö voi maksaa laskun
+
+## MockUp-prototyyppi
+
+> Suunniteltavan palvelun toimintoja määriteltäessä voi olla hyödyllistä piirtää avuksi MockUp-kuvausta käyttötilanteen
+tai toiminnallisuuden todentamiseksi. Kun palvelun käyttöliittymää tai palvelupolkua käydään läpi mockup-kuvauksen kautta
+voi hahmottaa huomattavasti helpommin tarvittavia toiminnallisuuksia tai tarpeita, joita voidaan kirjata vaatimusmäärittelyyn.
+MockUp-kuvaus on hyödyllinen apuväline palvelun tilaajan/toimeksiantajan kanssa käydyissä keskusteluissa.
+
+[](http://www.youtube.com/watch?v=a5qLMBYWv5A "")
+
+> Kun laadit harjoitustehtävään MockUp-näkymän pohdi haluatko kuvata koko palvelua vai keskittyä yksittäisen toiminnallisuuden tarkasteluun?
-## Alustavat Käyttäjätarinat - User Story
+> Voit kokeilla myös PlantUML-kuvausta rajatuissa kohdissa
+
+```plantuml
+salt
+{
+ Just plain text
+ [This is my button]
+ () Unchecked radio
+ (X) Checked radio
+ [] Unchecked box
+ [X] Checked box
+ "Enter text here "
+ ^This is a droplist^
+}
+```
+
+## 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 käyttäjätarina vaan ketterään kehittämiseen liittyvä Käyttötarina - User Story.
-Sen avulla kuvataan palveluun liittyvää toiminnallisuutta, joka halutaa siinä olevan.
+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](https://suomidigi.fi/kayttajatarinoilla-ryhtia-asiakaslahtoisyyteen/)
+
+[](http://www.youtube.com/watch?v=ndJdF3R7wqI "")
+
+* 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?
+
+[](http://www.youtube.com/watch?v=s7AcxrxcVd0 "")
+
+> 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 ||
-## Arkkitehtuuriin/teknologiaan liityvät vaatimukset
->Nämä voidaan kirjata myös tekniset vaatimukset
-| VaatimusID | Tyyppi | Kuvaus | Ominaisuus johon vaikuttaa |
-|:-:|:-:|:-:|:-:|
-| ARCH-REQ-0002 | Technical Requirement | Palvelun tärkeimpien palvelujen on oltava vähintään kahdennettu N+1 | |
-| ARCH-REQ-0003 | Technical Requirement | Palvelimen muistikapasiteeti >16GB ||
-| ARCH-REQ-0004 | Technical Requirement | Prosessori Intel/AMD x64||
-| ARCH-REQ-0005 | Technical Requirement | Palvelimen fyysinen sijainti on oltava kotimaassa (Suomi) ||
-| ARCH-REQ-0005 | Technical Requirement | Verkkoyhteyden nopeus >100MB/s ||
-| ARCH-REQ-0005 | Technical Requirement | Laitekaapin suositeltava koko 1m X 1m X 2m ||
-## Rajoitteet (Key Requirements and restrictions)
+
+> Avainsanat: pilvipalvelun tuotanto, Palveluiden hallinta, SLA
->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 |
|:-:|:-:|:-:|:-:|
-| CONSTRAINT-REQ-S00000 | Constrain | Palvelun kirjautumisprosessin on noudatettava AC5-2009-käytäntöä | [Kirjautuminen ft1](ft1-ominaisuus.md) |
-| CONSTRAINT-REQ-S00001 | Constrain |||
+| CONSTRAINT-REQ-S00000 | Constrain | Palvelun kirjautumisprosessin on noudatettava XYZ-käytäntöjä | [Kirjautuminen ft1](pohjat/pohja-ominaisuus.md) |
+| CONSTRAINT-REQ-S00001 | Constrain | On huomioitava Standardi ZZZ osana palvelun tapahtuma login talletusta | [Log-palvelin](pohjat/pohja-ominaisuus.md)|
| CONSTRAINT-REQ-S00002 | Constrain |||
| CONSTRAINT-REQ-S00003 | Constrain |||
| CONSTRAINT-REQ-S00004 | Constrain |||
| CONSTRAINT-REQ-S00005 | Constrain |||
| CONSTRAINT-REQ-S00006 | Constrain |||
-## Toiminnalliset vaatimukset (Functional Requirements)
+
+
+
+### Palvelun toiminnallisuudet/ominaisuudet
+
+> 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.
+
+> Tuotteen ominaisuus vai toiminto?
+
+[](http://www.youtube.com/watch?v=6dVrBsvUStg "")
+
+> Ominaisuuksien todellinen tarve?
+
+[](http://www.youtube.com/watch?v=pIDSK21PE9M "")
+
+> 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](pohjat/pohja-ominaisuus.md) | P1 | Esim [FUNCTIONAL-REQ-C0001]() |
+| [Feature 2 - lasku-arkisto](pohjat/pohja-ominaisuus.md) | P1 | Esim [FUNCTIONAL-REQ-C0011]() |
+| [Feature 3 - avatar-valinta](pohjat/pohja-ominaisuus.md) | P2 | Esim [FUNCTIONAL-REQ-C0023]() |
+| [Feature 4 - oikeushallinta](pohjat/pohja-ominaisuus.md) | P3 | Esim [FUNCTIONAL-REQ-C0133]() |
+| [Feature 5](pohjat/pohja-ominaisuus.md) | P4 | Esim [FUNCTIONAL-REQ-C0231]() |
+| [Feature 6](pohjat/pohja-ominaisuus.md) | P5 | Esim [FUNCTIONAL-REQ-C0221]() |
+| [Feature 7](pohjat/pohja-ominaisuus.md) | P5 | Esim [FUNCTIONAL-REQ-C0021]() |
+| [Feature 8](pohjat/pohja-ominaisuus.md) | P5 | EEsim [FUNCTIONAL-REQ-C0301]() |
+| [Feature 9](pohjat/pohja-ominaisuus.md) | P5 | Esim [FUNCTIONAL-REQ-C0401]() |
+| [Feature 10](pohjat/pohja-ominaisuus.md) | P5 | Esim [FUNCTIONAL-REQ-C0401]() |
+
+
+### Palvelun toiminnalliset vaatimukset
>Mitä ovat toiminnalliset vaatimukset? Toiminnallisilla vaatimuksilla kuvataan ohjelmistolta/järjestelmältä vaadittua toimintaa
Toiminnalliset vaatimukset ovat helpoimmin tunnistettavia. Vältä useamman vaatimuksen kirjaamista samaan lauseeseen! Jokainen vaatimus erikseen..
Voit esittää ne taulukossa tai viitata [yhteen](pohjat/pohja-vaatimuslistalle.md) laajempaan kokonaisuuteen
+[](http://www.youtube.com/watch?v=qO2qEIEHy_A "")
+
| 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](ft1-ominaisuus.md) |
-| FUNCTIONAL-REQ-C0002 | Functional Requirement |||
+| FUNCTIONAL-REQ-C0001 | Functional Requirement | Käyttäjänä (Asiakas Profiilit 1-4) voin kirjautua käyttäen Facebook-tunnuksia | [Kirjautuminen ft1](pohjat/pohja-ominaisuus.md) |
+| 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) |
| FUNCTIONAL-REQ-C0003 | Functional Requirement |||
| FUNCTIONAL-REQ-C0004 | Functional Requirement |||
| FUNCTIONAL-REQ-C0005 | Functional Requirement |||
@@ -223,17 +476,18 @@ Voit esittää ne taulukossa tai viitata [yhteen](pohjat/pohja-vaatimuslistalle.
| FUNCTIONAL-REQ-C0009 | Functional Requirement |||
| FUNCTIONAL-REQ-C0010 | Functional Requirement |||
-## Palveluun liittyvät tärkeimmät ei-toiminnalliset vaatimukset (Non Functional Requirements)
+### Ohjelmiston/palveluun ei-toiminnallisia vaatimuksia
>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?
+[](http://www.youtube.com/watch?v=Tta7bAFlg54 "")
+
+
+>Millaisia vaatimuksia palveluun kohdistuu suorituskyvyn näkökulmasta?
| VaatimusID | Tyyppi | Kuvaus | Ominaisuus johon vaikuttaa |
|:-:|:-:|:-:|:-:|
@@ -244,11 +498,7 @@ Miten hyvin palvelu/komponentti tai muu osa-alue palvelusta suoriutuu kuormituks
| PERFORMANCE-REQ-0004 | Non-Functional Performance |||
| PERFORMANCE-REQ-0005 | Non-Functional Performance |||
-
-### Tietoturva?
-
->Voit esittää eri vaatimuksia erillisessä taulukossa tai viitata tässä [yhteen](pohjat/pohja-vaatimuslistalle.md) laajempaan taulukkoon..
-
+>Millaisia vaatimuksia palveluun kohdistuu tietoturvan näkökulmasta?
| VaatimusID | Tyyppi | Kuvaus | Ominaisuus johon vaikuttaa |
|:-:|:-:|:-:|:-:|
@@ -263,211 +513,168 @@ Miten hyvin palvelu/komponentti tai muu osa-alue palvelusta suoriutuu kuormituks
| SECURITY-REQ-0009 | Non-Functional Security |||
| SECURITY-REQ-0010 | Non-Functional Security |||
-### Käytettävyys
-
->Voit esittää eri vaatimuksia erillisessä taulukossa tai viitata tässä [yhteen](pohjat/pohja-vaatimuslistalle.md) laajempaan taulukkoon..
-[Käytettävyys](https://fi.wikipedia.org/wiki/K%C3%A4ytett%C3%A4vyys)
-
+>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) | |
-| USABILITY-REQ-0001 | Non-Functional Usability |||
-| USABILITY-REQ-0002 | Non-Functional Usability |||
-| USABILITY-REQ-0003 | Non-Functional Usability |||
-| USABILITY-REQ-0004 | Non-Functional Usability |||
-| USABILITY-REQ-0005 | Non-Functional Usability |||
-
-### Testattavuus/Ylläpidettävyys
+| USABILITY-REQ-0000 | Non-Functional Usability | | [Kirjautuminen ft1](ft1-ominaisuus.md) | |
+| USABILITY-REQ-0001 | Non-Functional Usability | | [Käytettävyys](https://fi.wikipedia.org/wiki/K%C3%A4ytett%C3%A4vyys) |
+| USABILITY-REQ-0002 | Non-Functional Usability | | [Käytettävyys](https://fi.wikipedia.org/wiki/K%C3%A4ytett%C3%A4vyys) |
+| USABILITY-REQ-0003 | Non-Functional Usability | | [Käytettävyys](https://fi.wikipedia.org/wiki/K%C3%A4ytett%C3%A4vyys)|
+| USABILITY-REQ-0004 | Non-Functional Usability | | |[Käytettävyys](https://fi.wikipedia.org/wiki/K%C3%A4ytett%C3%A4vyys)|
+| USABILITY-REQ-0005 | Non-Functional Usability | | [Käytettävyys](https://fi.wikipedia.org/wiki/K%C3%A4ytett%C3%A4vyys)|
->Voit esittää eri vaatimuksia erillisessä taulukossa tai viitata tässä [yhteen](pohjat/pohja-vaatimuslistalle.md) laajempaan taulukkoon..
-[Lisätietoa](https://fi.wikipedia.org/wiki/Ohjelmiston_laatu)
+>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) |
-| TESTABILITY-REQ-0001 | Non-Functional Testability |||
-| TESTABILITY-REQ-0002 | Non-Functional Testability |||
-| TESTABILITY-REQ-0003 | Non-Functional Testability |||
-| TESTABILITY-REQ-0004 | Non-Functional Testability |||
-| TESTABILITY-REQ-0005 | Non-Functional Testability |||
+| TESTABILITY-REQ-0001 | Non-Functional Testability ||[Lisätietoa](https://fi.wikipedia.org/wiki/Ohjelmiston_laatu)|
+| TESTABILITY-REQ-0002 | Non-Functional Testability ||[Lisätietoa](https://fi.wikipedia.org/wiki/Ohjelmiston_laatu)|
+| TESTABILITY-REQ-0003 | Non-Functional Testability ||[Lisätietoa](https://fi.wikipedia.org/wiki/Ohjelmiston_laatu)|
+| TESTABILITY-REQ-0004 | Non-Functional Testability ||[Lisätietoa](https://fi.wikipedia.org/wiki/Ohjelmiston_laatu)|
+| TESTABILITY-REQ-0005 | Non-Functional Testability ||[Lisätietoa](https://fi.wikipedia.org/wiki/Ohjelmiston_laatu)|
->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)
+### Palvelun sijoittelunäkymä (Deployment diagram )
-[](http://www.youtube.com/watch?v=eTeUxYSdCxA "")
+>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.
+[](http://www.youtube.com/watch?v=tLuiQ9p8RkU "")
-[](http://www.youtube.com/watch?v=pIDSK21PE9M "")
+### Tietokantakuvaus (Database ER-diagram)
-| Ominaisuus | Prioriteetti | Muuta |
-| :-: | :-: | :-: |
-| [Ominaisuus 1 - Feature 1](pohjat/pohja-ominaisuus.md) | Tärkeä | |
-| [Ominaisuus 2](pohjat/pohja-ominaisuus.md) | Tärkeä | |
-| [Ominaisuus 3](pohjat/pohja-ominaisuus.md) | Pakollinen | |
-| [Ominaisuus 4](pohjat/pohja-ominaisuus.md) | Nice to Have | |
-| [Ominaisuus 5](pohjat/pohja-ominaisuus.md) | | |
+>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.
-
+* [Integraatioista IteWIkissä](https://www.itewiki.fi/opas/integraatiot/)
+```plantuml
+node node1
+node node2
+node node3
+node node4
+node1 -0)- node2 : service X
+node1 -0)- node3 : service Y
+node1 -0)- node4 : service Z
+```
-## Hyväksyntätestit
+**Integraation kuvaaminen sekvenssikaaviona**
->Kiinnitetään alustavat hyväksyntätestit vaatimuksiin taulukon muodossa.
+> Järjestelmien välisiä tapahtumia voi kuvata tarvittaessa esim. sekvenssikaavion muodossa.
-[](http://www.youtube.com/watch?v=EYEc8C57lbo "")
-[](http://www.youtube.com/watch?v=F2M93uWWXk8 "")
+```plantuml
+node1 ->node2: Log Start Request
+node2 --> node1 : Logging started
+```
+
+## 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.
+[](http://www.youtube.com/watch?v=WfMrCdAr-GM "")
-| VaatimusID | Testitapaus | Kuvaus | |
+
+
+>Kiinnitetään alustavat hyväksyntätestit vaatimuksiin taulukon muodossa.
+
+| Lähde | Testitapaus Id | Kuvaus | Tyyppi |
|:-:|:-:|:-:|:-:|
-| USE-CASE-007,SYSTEM-REQ-0001,SYSTEM-REQ-0004, SYSTEM-REQ-0012 | [Test Case Id X](Linkki testiin) | Hyväksyntätesti |
-| USE-CASE-017,SYSTEM-REQ-0011,SYSTEM-REQ-0004, SYSTEM-REQ-0012 | [Test Case Id Y](Linkki testiin) | Hyväksyntätesti |
-| USE-CASE-011,USE-CASE-013,SYSTEM-REQ-0204, SYSTEM-REQ-0212 | [Test Case Id Z](Linkki testiin) | Hyväksyntätesti |
-| USE-CASE-002,SYSTEM-REQ-0301,SYSTEM-REQ-0304, SYSTEM-REQ-0312 | [Test Case Id O](Linkki testiin) | Hyväksyntätesti |
+| [Feature 1](pohjat/pohja-ominaisuus.md), [FUNCTIONAL-REQ-0001]() | [Testitapaus 1](pohjat/pohja-hyvaksyntatesti.md) | esim. Tarkista kirjautuminen palveluun uutena käyttäjänä | Hyväksyntätesti |
+| [Feature 2](pohjat/pohja-ominaisuus.md), [FUNCTIONAL-REQ-0201](), [USE-CASE-017](pohjat/pohja-hyvaksyntatesti.md) | [Testitapaus 2](pohjat/pohja-testitapaus.md) | esim. Tarkista kenkilökohtaisten tietojen poisto | Hyväksyntätesti |
+| [Feature 3](pohjat/pohja-ominaisuus.md), | [Testitapaus 101](pohjat/pohja-hyvaksyntatesti.md) | esim. Takista Kirjautuminen toimivalla salasanalla | Hyväksyntätesti |
-## Alustava julkaisusuunnitelma
+## Julkaisusuunnitelma
-[](http://www.youtube.com/watch?v=ggFEhR3OZsk "")
> Julkaisusuunnitelman visualisoidulla muodolla on helpompi esittää ominaisuuksien julkaisut kehityksen aikanan.
-Alla oleva kuva on luotu käyttäen PlantUML-työkalua. Sen avulla on luoto ns. Gantt-kaavio ominaisuuksien julkaisuajankohdista.
-
-**Huomio** Alla oleva julkaisusuunnitelman kuva ei näy oikein vaatimusmäärittelydokumentin verkkojulkaisu-sivulla
+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..
+> Oletamme, että tuotteessa on muutamia ominaisuuksia, joiden järjestys on mietitty ennakkoon..
```plantuml
Project starts the 2019-5-15
[Version v1.0 EarlyAdopter] Starts 2019-5-15 and ends 2019-7-30
[Design Phase] Starts 2019-5-15 and ends 2019-6-15
-[Feature 1 v 1.0] Starts 2019-5-25 and ends 2019-6-15
-[Feature 2 v 1.0] Starts 2019-5-25 and ends 2019-7-1
-[Feature 3 v 1.1] Starts 2019-6-15 and ends 2019-7-15
-[Feature 4 v 1.1] Starts 2019-6-25 and ends 2019-7-20
-[Feature 5 v 2.3] Starts 2019-6-1 and ends 2019-7-21
+[Feature 1 v 1.0] Starts 2019-5-25 and ends 2019-6-15
+[Feature 2 v 1.0] Starts 2019-5-25 and ends 2019-7-1
+[Feature 3 v 1.1] Starts 2019-6-15 and ends 2019-7-15
+[Feature 4 v 1.1] Starts 2019-6-25 and ends 2019-7-20
+[Feature 5 v 2.3] Starts 2019-6-1 and ends 2019-7-21
[Accceptance Testing ] Starts 2019-7-21 and ends 2019-7-23
```
-## Julkaistavat tuotekokonaisuudet (Konfiguraatio)
+[](http://www.youtube.com/watch?v=Z1cSK_IMqMs "")
->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.
-
-[](http://www.youtube.com/watch?v=tLuiQ9p8RkU "")
-
-### Tietokantakuvaus (Database ER-diagram)
-
->Tähän esim alustava ER-kaavio
-
-# Testauksen vaatimukset (Testing requirements)
-
-### Testattavuus
-
->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
-
-* Riski -> Testaustarve
-* Vaatimus -> Testaustarve
-
-**Työkalu esimerkki**
-
-* SWOT -analyysi?
-
-
-### Vaatimukset yhtenä listana
-
-[](http://www.youtube.com/watch?v=s6v0g1Ut-SY "")
-
->Tähän osaan voidaan linkittää vaatimuslista, josta kaikki tunnistetut vaatimukset löytyvät
-
-* [Linkki vaatimuslistaan](pohjat/vaatimuslista.md)
-
+| [Feature 1](pohjat/pohja-ominaisuus.md) | 1.0 | 15.6.2019 | V1.0 |
+| [Feature 2](pohjat/pohja-ominaisuus.md) | 1.0 | 1.7.2019 | V1.0 |
+| [Feature 3](pohjat/pohja-ominaisuus.md) | 1.1 | 15.7.2019 | V1.0 |
+| [Feature 4](pohjat/pohja-ominaisuus.md) | 1.1 | 20.7.2019 | V1.0 |
+| [Feature 5](pohjat/pohja-ominaisuus.md) | 2.3 | 23.7.2019 | V1.0 |
-### Dokumentit, standardit ja lähteet
+## Standardit ja lähteet
-**Lähteet/Standardit/Suositukset**
+> 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 | |
|:-:|:-:|:-:|
--
GitLab