Tiivistetty vaatimusmäärittely

• [SIJOITA TOIMEKSIANNON NIMI TÄHÄN]
• Projektimäärittely/vaatimusmäärittelyn tiivistetty versio v 0.3 4.1.2021 (NarsuMan)

Ohjeita ennen aloitusta :)

Olet editoimassa tiivistettyä vaatimusmäärittelyä, joka on normaalia OPF:n laajempaa vaatimusmäärittelyä rajatumpi. Kannattaa tutustua ehdottomasti laajempaan vaatimusmäärittelyyn, koska se sisältää ohjeistuksen lisäksi videomateriaalia.

Johdanto

Tämä on vaatimusmäärittelydokumentti, jossa määritellään Wimma Lab -verkkosivustolle toteutettavaan keskustelufoorumiin liittyvät vaatimukset, ominaisuudet ja muut ratkaisut. Foorumin tilaaja eli toimeksiantaja on asiakkaamme Teemu K. Projektissa tuoteomistajana/tuotepäällikkönä toimii Marko Rintamäki. Toteutuksesta huolehtii tiimi nimeltä Lutakon Velhot.

Projektin tuloksena toteutetaan keskustelufoorumi käyttäen pohjana Conduit-ohjelmistoa. Conduitissa on jo tällä hetkellä valmiina foorumiin tarvittavat perustoiminnot eli sivustolle rekisteröityminen ja kirjautuminen sekä viestien lähettämiseen, kommentointiin ja seuraamiseen liittyvät toiminnot. Conduit ei kuitenkaan sellaisenaan istu tilaajan tarpeisiin, vaan meidän tehtävämme on muokata se ulkoasultaan ja toiminnoiltaan yhtenäiseksi Wimma Lab-sivuston kanssa.

Tavoitteet

Mitä ratkaisun avulla voidaan tehdä? Mihin pyritään? Tämä osuus voidaan käsitellä myös projektisuunnitelmassa, mutta vaatimusmäärittelyssä voidaan avata tarkemmin tavoiteltua ratkaisua.

Wimma Lab -sivustolla ei tähän asti ole ollut käytössä foorumia, joten nyt sellainen halutaan perustaa sivuston käyttäjien kommunikointia helpottamaan. Wimma Labin tavoitteena on esimerkiksi yhdistää oppimista, verkostoitumista, työkokemuksen kartuttamista ja samalla tuottaa ratkaisuja yrityksille. Foorumin tarkoitus on omalta osaltaan helpottaa näiden tavoitteiden toteutumista. Tärkeä osa projektin onnistumista on, että Conduit saadaan räätälöityä niin, että Wimma Lab -sivuston käyttäjä kokee siihen integroidun foorumin kuuluvan saumattomasti alkuperäiseen sivustoon niin ulkoasunsa kuin toimintojensakin puolesta.

Kohderyhmä

Millaisia ovat sen käyttäjät? Mikä tuotoksen tavoite on eri sidosryhmien kannalta? Kannattaa nostaa esiin lyhyesti mahdolliset loppukäyttäjä ja oleellisiin palvelusta hyötyviin sidosryhmät

Wimma Labin verkostoon ja kohderyhmään kuuluu monenlaisia toimijoita. Wimma Labin sisäiset sidosryhmät ovat Jamkin opiskelijoita, jotka toimivat projekteissa työntekijöinä. Lisäksi sisäisiin sidosryhmiin kuuluu Jamkin opettajia ja opiskelijoita, jotka toimivat projekteissa ohjaajina ja valmentajina. Ulkoisiin sidosryhmiin kuuluvat kaikki toiminnasta kiinnostuneet, mutta suurimpia sidosryhmiä ovat esimerkiksi projektien toimeksiantajat, yritykset, muut oppilaitokset, toimintaa auttavat opiskelijat ja toiminnasta kiinnostuneet vierailijat.

Sidosryhmäkartta

Mietitään tarkemmin millaisia käyttäjä/sidosryhmiä liittyy suunniteltuun ratkaisuun/ohjelmistoon/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.

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

Tarkennettut sidosryhmäprofiilit

Kuvataan tarkemmin sidosryhmäkartasssa esiteltyhä sidosryhmiä/profiileja. Tarvittaessa kuvataan tarkemmin valitut sidosryhmät ja tarkennetaan niitä, jos toimeksianto sitä edellyttää. Tähän sovelletaan alisivuja, joita tarpeen mukaan kopioidaan "pohjat"-kansiosta Katso esim. Asiakas B

ID	Tyyppi	Nimi	Piirteet	Motivaatio
SR-001	Sidosryhmä/Profiili	Asiakas A	Nuori 16-22V	Selkeä tarve palvelulle ja tarvitsee palvelua usein
SR-002	Sidosryhmä/Profiili	Asiakas B - Profiili 1	"Aikuinen" 22-45V	Tarve satunnainen, mutta yleisin asiakas
SR-003	Sidosryhmä/Profiili	Rahoittaja	Pääomasijoittaja	Palvelun tuottamat tuotot
SR-004	Sidosryhmä/Profiili	Verottaja	Nuori karhu	Kerätä verotuloja

Palveluun liittyviä asiakaspolkuja

Mieti toimeksiantoa ja pohdi onko siitä tunnistettavissa ns. palvelupolkuja? 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..

asiakaspolku PlantUML-esimerkki tilakoneena

Kokeillaan luonnostella asiakaspolkua PlantUML-työkalun avulla. Kannattaa kokeilla ehdottomasti myös muita tapoja! Sovella esim. PlantUML SDL/Swimlane kuvausta?

Käyttöliittymänäkymä/mockup

Conduit mockup

Tärkeimmät toiminnallisuudet/ominaisuudet

Hahmotellaan tähän kohtaan ominaisuudet pelkästään ranskalaisilla viivoilla ja MindMap-kuvauksen avulla. Eli mitä tavoitellulla ratkaisulla/palvelulla mielestäsi on mahdollista tehdä? Mieti tilannetta, kun joku kysyy sinulta mitä palvelulla voi tehdä? Saat aikaa vastata 15 sekuntia. Mitä vastaat ja mitkä toiminnot nostatat esiin ehdottomasti valtteina verrattuna muihin vastaaviin ratkaisuihin/palveluihin? Tässä kohtaa kannattaa tarkistaa mitä olivat asiakkaan esittämät toiveet palvelusta? Niistä voisi löytyä ehkä joitain tässä vaiheessa?

• Oleelliset toiminnot (Esimerkkejä)
  • Artikkelin kirjoittaminen
  • Artikkelin kommentoiminen
  • Artikkeleiden tykkääminen

Alustavat käyttäjätarinat

Ketterän kehityksen myötä on yleistynyt tapa kuvata asiakkaan tarpeita ns. käyttötarinoiden (User Story) muodossa. Kirjataan tähän ennalta tunnistetut käyttötarinat.

ID	Tyyppi	Kuvaus	Linkki
US-001	Käyttäjätarina	Esim. Käyttäjänä haluan, että voin luoda raportin tekemistäni ostoista viimeisen kuukauden ajalta, koska se helpottaa oman talouteni hallintaa	#1
US-002	Käyttäjätarina	Esim. Käyttäjänä haluan, että voin poistaa historian tekemistäni ostoista viimeisen kuukauden ajalta, koska en halua muistella menneitä	#2

Yleiset tekniset vaatimukset

Teknisiä ratkaisuja määriteltäessa on hyvä tunnistaa tarvittavat teknologiat, laitteistot tai muut tarvittavat fyysiset ratkaisut. Ohjelmiostoratkaisuja määriteltäessä kannattaa erottaa puhtaasti tekniset/tuotannolliset vaatimukset ja kirjata ne vaatimusmäärittelyyn esimerkiksi teknisinä vaatimuksina.

ID	Tyyppi	Kuvaus
HWREQ-0002	Tekniset vaatimukset	Palvelun tärkeimpien palvelujen on oltava vähintään kahdennettu N+1
HWREQ-0003	Tekniset vaatimukset	Palvelimen muistikapasiteeti >32GB
HWREQ-0005	Tekniset vaatimukset	Palvelimen fyysinen sijainti on oltava EU-aluella
HWREQ-0005	...	...

Toiminnalliset vaatimukset (Functional Requirements)

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.

ID	Tyyppi	Kuvaus	Toiminnallisuus johon vaatimus vaikuttaa
FUNCREQ-C0001	Toiminnallinen vaatimus	Krjautumiseen voi käyttää Facebook-tunnuksia	Toiminnallisuus X
FUNCREQ-C0002	Toiminnallinen vaatimus	Käyttöliittymää voidaan ohjata äänikomennoilla	Toiminnallisuus Y
FUNCREQ-C0003	Toiminnallinen vaatimus	...	...

Laadulliset eli ei-toiminnalliset vaatimukset

Mitä olivat ei-toiminnalliset vaatimukset? Voit esittää eri vaatimuksia erillisessä taulukossa tai viitata tässä yhteen laajempaan taulukkoon. Ei-toiminnalliset vaatimukset sisältää laajan joukko eri näkökulmia sähköiseen palveluun liittyen. Tärkeimmät kirjoittajan näkökulmasta ovat seuraavat: Suorituskyky, tietoturva ja saavutettavuus

• Suorituskyky
• Tietoturva
• Saavutettavuus

Suorituskykyyn liittyvät vaatimukset

Millaisia vaatimuksia palveluun kohdistuu suorituskyvyn näkökulmasta?

ID	Tyyppi	Kuvaus
PERFREQ-0000	Suorituskyky	Kirjautuminen on mahdollista yhtäaikaa 100 käyttäjällä (100 request/s)
PERFREQ-0001	Suorituskyky	Palvelun maksimi käyttäjä määrä on ?
PERFREQ-0002	Suorituskyky	...

Tietoturvan vaatimukset

Millaisia vaatimuksia palveluun kohdistuu tietoturvan näkökulmasta?

ID	Tyyppi	Kuvaus	Miten testataan?
SECURITY-REQ-0001	Salasanassa on käytettävä vähintään MD5-tason salausta, koska CONSTRAIN-000 sitä edellyttää	Testitapaus X
SECURITY-REQ-0002	Jokainen tapahtuma palvelussa on kirjattava käyttölogiin, että niitä voidaan tarkastella myöhemmin	Testitapaus Y
SECURITY-REQ-0003	...	...

Saavutettavuuden vaatimukset

Mitä tarkoitetaan saavutettavuudella? Millaisia asioita/ohjeistuksia on otettava huomioon palvelua toteutettaessa? Tutustu saavutettavuusdirektiiviin ja kirjaa

ID	Luokka	Kuvaus	Miten testataan?
AVAILREQ-0000	Saavutettavuus		Testit
AVAILREQ-0001	Saavutettavuus		Testit
AVAILREQ-0002	Saavutettavuus	...	...

Toimeksiannon kannalta tärkeät oleelliset rajaukset

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. Kannattaa tutkia esimerkiksi https://www.sfs.fi/aihealueet/terveydenhuolto/laakinnalliset_laitteet tai http://docs.jhs-suositukset.fi/jhs-suositukset/JHS190/JHS190.html

ID	Tyyppi	kategoria	Vastuullinen
CONSTRAIN-000	Rajaus	Palvelun kirjautumisprosessin on noudatettava JUHTA-hyväksyttyjä käytänteitä	Kirjautuminen ft1
CONSTRAIN-001	Rajaus	On huomioitava Standardi ZZZ osana palvelun tapahtuma login talletusta	Log-palvelin
CONSTRAIN-002	Rajaus	...	...

Palvelun tuotantoympäristö

Vaatimusmäärittelyn tukena sovelletaan erilaisia kuvauksia, joista esimerkkinä UML-kuvauskieleen liittyvä sijoittelu näkymä, eli "Deployment Diagram", kuvauksen avulla voi esittää miten palvelu on tarkoitus toteuttaa käytännössä. Missä sijaitsevat eri osat palvelusta ja miten eri osat on kytketty toisiinsa.

Palveluun liittyvät muut järjestelmät

Alla olevat kuvaukset ovat esimerkkejä UML-kuvauksen mahdollisuuksista, kannattaa tutustua tarkemmin laajempaan vaatimusmäärittely pohjaan, koska siitä löytyy esimerkkejä.

Järjestelmien välisiä yhteyksiä voidaan kuvata tarvittaessa esim. UML-kuvauksiin liittyvän sekvenssikaavion muodossa (Sequence Diagram).

Standardit ja lähteet

Vaatimusmäärittelyyn kannattaa liittää mukaan kaikki 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 tukevat esitettyjä vaatimuksia.

ID	Nimi	Linkki	Kuvaus
REF1	JHS 165 ICT	JHS Suositukset - vaatimusmäärittelylle	Vaatimusmäärittelyn suositus
REF2	ISO 9241-11	Käytettävyys	Usability
REF3	EN 301 549	Saavutettavuus	Availability
REF4	GDPR	GDPR Asetus	General_Data_Protection_Regulation