Update vaatimusmaarittely.md

dokumentit/02-vaatimusmaarittely/vaatimusmaarittely.md

@@ -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 |