Commit dcff0d5a authored by N0597's avatar N0597
Browse files

Update vaatimusmaarittely.md

parent 2a0d29c9
Pipeline #73807 passed with stages
in 14 seconds
......@@ -54,7 +54,6 @@ Kännykkä/tabletti/web-palvelu jonka avulla käyttäjä voi löytää mieleisi
## Yleinen sidosryhmäkuva (Stakeholder -Map)
>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
![](kuvat/sidosryhmakuva.png)
......@@ -98,40 +97,9 @@ Liisa on tapahtumassa ja haluaa lisätä Erkin kaverikseen. Liisa avaa palvelun
![](kuvat/customerPath2.PNG)
>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
[![](http://img.youtube.com/vi/O04EYNKmEXc/0.jpg)](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
[![](http://img.youtube.com/vi/TLFBPQQ95ZE/0.jpg)](http://www.youtube.com/watch?v=TLFBPQQ95ZE "")
>Palvelupolkujen kuvaukseen voidaan hyödyntää myös erillisiä työkaluja. Mieti onko mahdollista hyödynnetään jotain ulkopuolista palvelua kuvauksen apuna?
**Työkalu esimerkkejä**
* [Canvanizer](https://canvanizer.com)
## Tärkeimmät käyttötapaukset (General Use Cases)
>**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.
**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://img.youtube.com/vi/rADU4vWTfyY/0.jpg)](http://www.youtube.com/watch?v=rADU4vWTfyY "")
[![](http://img.youtube.com/vi/BjQAWfBMpcw/0.jpg)](http://www.youtube.com/watch?v=BjQAWfBMpcw "")
>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.
```plantuml
Erkki--(Tapahtumien etsiminen)
......@@ -155,11 +123,6 @@ Sen avulla kuvataan palveluun liittyvää toiminnallisuutta, joka halutaa siinä
## Ohjelmiston/palvelun tekniset vaatimukset
>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.
**Teknisiä järjestelmävaatimuksia**
| VaatimusID | Tyyppi | Kuvaus | Ominaisuus johon vaikuttaa |
......@@ -173,8 +136,6 @@ ja tarpeet saattavat muuttua. Kehityskäytössä näppärä ratkaisu voi osoitta
## 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 | |
......@@ -186,10 +147,6 @@ ja tarpeet saattavat muuttua. Kehityskäytössä näppärä ratkaisu voi osoitta
## Rajoitteet (Key Requirements and restrictions)
>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).
| Id | Vaatimuksen kuvaus | kategoria | Vastuullinen |
|:-:|:-:|:-:|:-:|
| CONSTRAINT-REQ-S00000 | Constrain | Palvelun kirjautumisprosessin on noudatettava AC5-2009-käytäntöä | [Kirjautuminen ft1](ft1-ominaisuus.md) |
......@@ -202,10 +159,6 @@ saataa olla varsin ratkaiseva pitemmällä tähtäimella. Esimerkkinä [EU GDPR-
## Toiminnalliset vaatimukset (Functional Requirements)
>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://img.youtube.com/vi/eTeUxYSdCxA/0.jpg)](http://www.youtube.com/watch?v=eTeUxYSdCxA "")
| VaatimusID | Tyyppi | Kuvaus | Ominaisuus johon vaikuttaa |
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment