Vaatimusmäärittely. Sisällys. Hyväksyntä

Transkriptio

1 Vaatimusmäärittely Versio Päiväys Muokkaaja Kuvaus Rönkkö Lisätty selitykset prioriteetteihin ja statuksiin Rönkkö Kuvattu muutosprosessi ja viimeistelty dokumenttia Rönkkö Lisätty puuttuva kuva ja siihen liittyvä teksti, oikoluettu Rönkkö Lisätty hyväksyntäkenttä asian tullessa pian ajankohtaiseksi ja lisätty muutostenhallinta kohta Rönkkö Kirjoitettu tekstiä ja lisätty kuvia eri kohtiin Rönkkö Siirretty erilaiset vaatimukset omille sivuille paremman hallinnoimisen edistämiseksi Rönkkö Siirrytty käyttämään palvelimesta nimitystä Valpas Rönkkö Lisätty alustavia vaatimuksia ja käyttötapauksia Rönkkö Lisätty muutoslogi Hyväksyntä Päiväys Henkilö Sisällys 1. Dokumentin tarkoitus Liiketoimintatavoitteet Sovellusalueen pääkäsitteet Systeemikuvaus Käyttäjäryhmät Toiminnalliset vaatimukset Ei-toiminnalliset vaatimukset Käyttötapaukset Rajoitukset Ratkaisuehdotukset Vaatimusten muutosprosessi Termit ja lyhenteet Referenssit...9 Liite 1: Toiminnalliset vaatimukset...a Liite 2: Ei-toiminnalliset vaatimukset...d Liite 3: Rajoitukset...F 1

2 2

3 1. Dokumentin tarkoitus Tämä dokumentin tarkoitus on kuvata Valpas-järjestelmään ja Valvotut liittymät -projektiin kohdistuvat vaatimukset. Tämän dokumentin kohderyhmät on kuvattu alla taulukossa 1. Taulukko 1: Lukijaryhmät Lukijaryhmä Lukemisen syy Käyttäjät ja asiakas Palautteen antaminen vaatimuksista Kehittäjät Järjestelmän toiminnallisuuksien ja ominaisuuksien ymmärtäminen Testaaja Järjestelmän testaaminen vaatimuksiaan vasten Käyttöoppaan kirjoittajat Materiaalin hankinta opasta varten Projektiryhmä Statusten seuranta Mentor Arvosanan määrittäminen 2. Liiketoimintatavoitteet Suomessa on Virve-niminen TETRA-verkko, jonka asiakaskunta on hyvin rajattu. Laissa määritellään keille kaikille Virven palveluita voidaan tarjota. Tästä syystä kasvumahdollisuudet tavanomaisilla keinoilla ovat hyvin rajalliset. Lisäpalveluiden kehittäminen olemassa olevaan verkkoon on ainoa mahdollisuus lisätulojen saamiseksi. Jotta lisäpalveluita voitaisiin kehittää, tulee niiden toimivuutta ensin testata. Jos tämän projektin tuotoksilla voidaan todentaa, että TETRA-verkko soveltuu erilaisten hälytinjärjestelmien ja hätäkeskuksien sekä huoltoyhtiöiden väliseen viestintään, voidaan olettaa noin 50% kasvu Virven liittymien määrään. Tällä hetkellä erilaisia hälyttimiä ja niiden toimintakuntoa tarkastellaan järjestelmillä ja yhteyksillä, jotka eivät täytä vakuutusyhtiöiden ja viranomaisten määräyksiä. TUKES on tiedottanut aiheesta ja peräänkuuluttanut kaikkia alalla toimivia tahoja tekemään voitavansa tilanteen korjaamiseksi. 3. Sovellusalueen pääkäsitteet Sovellusalueen tärkeimmät käsitteet ja niiden suhteet on esitetty alla olevassa kuvassa. Kuva 1: Sovellusalueen pääkäsitteet. 3

4 Kuvassa 1 esitetyt käsitteet on lisäksi selvennetty alla olevaan taulukkoon. Lisää termejä ja lyhenteitä on koottu kohtaan Termit ja lyhenteet. Taulukko 2: Sovellusalueen pääkäsitteet Käsite Kuvaus Anturi Erilaisia antureita, jotka mittaavat erilaisia tilanteita ja raportoivat tilanteista ilmoitinkeskukselle, Esimerkiksi. paloanturi Hätäkeskus Suomessa toimivat hätäkeskukset jotka ottavat vastaan esimerkiksi palovaroituksia Huoltoyhtiö Jokaisen anturin/sensorin ja ilmoitinkeskuksen toiminnasta vastaa ainakin yksi huoltoyhtiö, jonka tehtäviin kuuluu pitää sensorit ja ilmoitinkeskukset toimintakuntoisina Ilmoitinkeskus Yhdessä talossa kaikki erilaiset anturit/sensorit on yhdistetty ilmoitin keskukseen, joka kerää tiedot kootusti ja tarvittaessa lähettää hälytyksen hätäkeskukseen. Operaattori Ilmoitinkeskuksen ja hätäkeskuksen välisen yhteyden tarjoaa aina jokin operaattori. Projektin tapauksessa kyse on aina viranomaisverkon operaattorista, Suomessa Virve Yhteyslinja Linja/tie, jota pitkin tieto hälytyksistä kulkee ilmoitin keskuksen ja hätäkeskuksen väliä. Nykyisin kiinteä tietoliikenneyhteys, projektin tapauksessa TETRA-verkko. 4. Systeemikuvaus Järjestelmän toiminnallisuutta on kuvattu kuvassa 2. Kuvassa oleva punainen viiva erottaa toteuttavan järjestelmän sen ulkoisista liitännöistä, jotka eivät kuulu projektiin. Kuva 2: Projektissa vaikuttavat osaset 4

5 Valppaan tarkoitus on olla järjestelmä, joka on yhteydessä hätäkeskuksiin, huoltoyhtiöihin ja erilaisiin ilmoitinkeskuksiin. Valppaan tehtävänä on varmistaa määritellyin väliajoin ilmoitinkeskuksen ja itsensä välisen linjan toimivuus lähettämällä ilmoitin keskukselle viesti. EPA huolehtii viestien välityksestä ja kertoo Valppaalle viestien välitystiedot. Valppaan toimintaan liittyy myös hätä- ja huoltoviestien vastaanotto ilmoitinkeskuksilta ja näiden edelleen toimittaminen tarpeen mukaan joko hätäkeskukselle tai huoltoyhtiölle. Projektin tarkoituksena on tuottaa Valppaasta sellainen versio, jolla pystytään testaamaan ajatellun järjestelmän toiminnallisuutta ja TETRA-verkon soveltuvuutta varoittimien valvontaan. Kuvassa 3 on esitelty erilaiset yhteydet, jotka liittyvät projektin lopputulokseen. Keskeisimpiä tekijöitä projektin tavoitteiden saavuttamiseksi ovat linjan toiminnallisuuden seuraaminen simulaattorin ollessa erilaisissa paikoissa ja simuloitujen viestien vastaanotto ja käsittely Valppaalla. Valppaan velvollisuuksiin kuuluu perille menneiden viestien päättely EPAlta saatujen status tietojen pohjalta. Simulaattorin toiminnallisuuksiin kuuluu tallentaa tiedot sijainnistaan ja generoida erilaisia hätä- ja huoltoviestejä harvakseltaan. Kummankin osan tulee tallentaa tiedot viesteistä, että testien lopuksi kummankin lähettämää ja vastaanottamaa dataa voidaan verrata ja havaita EPAn ja/tai verkon tarjoama virheellinen informaatio ja toiminta. Kuva 3: Projektiin vaikuttavat tietoliikenneyhteydet Yhteys 1 EPAn ja Valppaan välinen yhteys toimii TCP/IP:n yli. Valpas huomaa ongelmat tällä linjalla. 5

6 Yhteys 2 Valppaan ja ylläpitäjän tai asiakkaan välillä on myös yhteys Internetin välityksellä. Valpas huomaa tämän yhteyden puuttumisen ja olemassa olon. Yhteys 3 Valppaan ja huoltoyhtiöiden välillä voi olla monenlaisia yhteyksiä. Yhteys voi olla esimerkiksi sähköpostin tai SMS-viestin varassa. Valppaan tehtävä on valvoa tätä yhteyttä kuittausviestien avulla. Yhteys 4 EPAn ja TETRA-verkon yhteys on EPAn valvoma. EPA huolehtii TCS-aseman vaihdosta, mikäli yhteys ei toimi. Yhteys 5 Yhteys TETRA-puhelimen ja -verkon välillä on radioyhteys. Tämän yhteyden ja yhteyden numero 4 toimivuutta Valppas valvoo pääasiallisena tehtävänään. Linjavika on tilanne, jossa viesti ei kulje näiden kahden yhteyden yli. Yhteys 6 TETRA-puhelimen ja ilmoitinkeskuksen välinen yhteys on sarjaliikenneyhteys. Valpas saa tietoa tästä pyytämällä puhelinta testaamaan ilmoitinkeskuksen toiminnan. Yhteys 7 Ilmoitinkeskuksen ja antureiden välinen yhteys on ilmoitinkeskuksen aika ajoin testaama. Valpas saa tiedon tästä yhteyden 6 testaamisen yhteydessä tai erillisenä viestinä, jonka ilmoitinkeskus lähettää. 5. Käyttäjäryhmät Projektin tuotoksen käyttäjinä toimii lähinnä vain verkon toimivuuden testaamisesta kiinnostuneet henkilöt. Tämä on hyvin rajallinen määrä ihmisiä. Lopputuotteessa olevia käyttäjäryhmiä onkin sitten huomattavasti enemmän. Molemmista tilanteista koottu käyttäjien ryhmittely on esitetty taulukossa 3. Taulukko 3: Käyttäjäryhmät Käyttäjäryhmä Kuvaus Käyttäjien määrä Testaaja TETRA-verkon soveltuvuuden testausta suorittavat henkilöt n. 5 Ylläpitäjä Eri hätäkeskuksissa toimivat järjestelmän ylläpitäjät ja heidän n. 30 varahenkilönsä, sekä operaattorin asettamat ylläpitäjät Asiakkaat Erilaiset isojen ja julkisten talojen omistajat tai hallinnoijat, joiden vastuulla satoja talojen paloilmoittimet ovat Huoltoyhtiön Saavat tietoa vikatilanteista, jotka heidän pitäisi korjata satoja työntekijät Hätäkeskuksen Ottavat vastaan hätäilmoituksia ja tietoja siitä, ettei laite-/linjavikoja ole 800 työntekijät Operaattorin työntekijät korjattu (kuitattu huoltoviestiä saaduksi) Nämä saavat tiedon linjavioista ja heidän tehtäviinsä kuuluu korjata verkossa olevat toimintavirheet 15 6

7 6. Toiminnalliset vaatimukset Tässä dokumentissa käytetyt prioriteetit on selvitetty seuraavassa taulukossa tärkeysjärjestyksessään. Taulukko 4: Projektissa käytetyt prioriteetit ja niiden selitykset Prioriteetti Kuvaus Pakollinen Järjestelmän käyttö ilman tällä prioriteetilla varustetun vaatimuksen täyttämistä ei ole mahdollista tarkoitukseen, johon järjestelmä on tilattu. Tarpeellinen Järjestelmän käytön kannalta ei ole aivan välttämätöntä, että tällä prioriteetilla varustettu vaatimus on toteutettu, mutta se lisää huomattavasti järjestelmän käytön mielekkyyttä. Hyödyllinen Nämä ovat hyviä ominaisuuksia, joista on apua tai hyötyä, mutta eivät ole millään tavalla tärkeitä järjestelmän käyttämisen tai käyttötarkoituksen kannalta. Vaatimusten yhteydessä olevat statukset on selvitetty seuraavassa taulukossa. Taulukko 5: Projektissa käytetyt statukset ja niiden selitykset Status Kuvaus Ehdotettu Vaatimus tällä statuksella on vain kirjattu ylös. Hyväksytty Tämän statuksen omaavat vaatimukset on hyväksytty toteutettavaksi kuluvassa iteraatiossa ja niiden toteuttamiseen on varattu resurssit. Toteutettu Tarkoittaa, että vaatimus on toteutettu, mutta sitä ei ole vielä testattu, jolloin sitä ei vielä voida mainostaa olevaksi. Varmistettu Tämän statuksen omaava vaatimus on läpäissyt testin hyväksytysti ja sen toimivuuteen voidaan siten luottaa. Hylätty Vaatimus on jostain syystä havaittu tarpeettomaksi, jolloin sitä ei aiota missään vaiheessa toteuttaa. Itse toiminnalliset vaatimukset on kuvattu liitteessä Ei-toiminnalliset vaatimukset Ei-toiminnalliset vaatimukset ovat liitteessä Käyttötapaukset Taulukko 6: Käyttötapaukset ID Nimi K01 Valvotun liittymän lisäys järjestelmään K02 Järjestelmässä olevan valvotun liittymän tietojen muokkaaminen K03 Valvotun liittymän poistaminen järjestelmästä K04 Simulaattori hakee saapuneet viestit puhelimelta K05 Simulaattori lähettää viestin Valppaalle K06 Vertaillaan simulaattorien ja Valppaan tallentamia tietoja K07 Valpas saa hälytysviestin valvotulta liittymältä K08 Valpas saa huoltoviestin valvotulta liittymältä K09 Valpas tarkastelee linjan toimivuutta K10 Järjestelmään lisätään asiakas K11 Järjestelmään tallennetun asiakkaan tietoja muokataan K12 Asiakas poistetaan järjestelmästä K13 Asiakas tarkastelee laitteidensa toimintatilannetta K14 Valpas tarkistaa laitteen toimintakunnon 9. Rajoitukset Asiakkaan esittämät rajoitukset projektin toteutukselle on esitelty liitteessä 3. 7

8 10. Ratkaisuehdotukset Alla on kuvattu vaatimusmäärittelyä tehdessä syntyneitä ideoita erilaisiin ongelmakohtiin. Taulukko 7: Tähän mennessä kertyneet ratkaisuehdotukset ID Versio Ehdotus Lähde Perustelu Prioriteetti Status Käyttötapauskuvaus I01 1 Laitetaan tiedot lähetetyistä ja vastaanotetuista viesteistä debugmoodissa Log4J:n logiin talteen Rönkkö Tällöin toiminnallisuutta ei tarvitse varsinaisessa versiossa poistaa ja se voidaan tarvittaessa saada uudestaan käyttöön. Ehdotettu K04, K05, K06, K07, K08, K09, K Vaatimusten muutosprosessi Koska tässä dokumentissa esiintyviin vaatimuksiin voi ilmaantua muutoksia, uusia vaatimuksia voi ilmestyä ja voidaan huomata, että jokin vaatimus on tarpeeton, tarvitaan säännöt, joilla muutoksia vaatimuksiin hallitaan. Tässä kappaleessa on kuvattu tavat, joilla muutoksia tehdään. Mikäli joku haluaa ehdottaa muutosta vaatimuksiin (niiden sisältöön), tulee hänen lähestyä aiheesta Rönkköä. n tehtävä on hankkia kaikki tarpeellinen tieto muutoksen liittyen. Tämän jälkeen projektin johtoryhmän seuraavassa kokouksessa käsitellään aihe ja päätetään muutoksen tekemisestä tai tekemättä jättämisestä. Tarvittaessa otetaan yhteyttä asiakkaan edustajaan ja tiedustellaan hänen mielipidettään. Mikäli muutos koskee vaatimuksen statusta aiheesta, tullaan neuvottelemaan aina myös asiakkaan kanssa. Asiakkaan kanssa yhteistyötä tehden päätetään jo toteutettavaksi suunniteltujen vaatimusten hyllyttämisestä ja uusien muutosten asettamisesta toteutettaviksi. Päätöksen teon jälkeen saman päivän aikana korjataan myös muutokset tähän dokumenttiin. 12. Termit ja lyhenteet Taulukko 8:lista tärkeistä termeistä ja lyhenteistä. Termi/Lyhenne Selitys EPA Edusta palvelin, Tetra-verkon reunalla oleva palvelin, joka tarjoaa Tetra-verkon palveluita helpommin käytettävällä tavalla sovelluksille. Downlink Se kanava, jota pitkin viesti kulkee Valppaalta puhelimelle. Ilmoitinkeskus Rakennuksessa oleva keskus, johon kaikki rakennuksessa olevat hälytin anturit/sensorit on kytketty. Linjavika Vika yhdeydessä Valppaan ja puhelimen välillä. MTT Indagon Oy:n kehittämä laite, joka osaa kertoa koordinaatit paikasta, jossa laite sijaitsee. Ryhmäosoite TETRA-verkon "puhelinnumero", jonka vastaanottajina on useampia tahoja samaan aikaan. SDS Tetra-verkon vastine SMS-viestille. SDS-viestejä on useampia tyyppejä, joista kolmella on kiinteä pituus ja neljäs on vaihelevan pituinen. Tetra Tetra-verkko on viranomaiskäyttöön tarkoitettu puhelinverkko. TMR880 Nokian puhelin malli TETRA-verkkoon. Uplink Se kanava, jota pitkin viesti kulkee puhelimelta Valppaalle. Valpas Toteuttettava järjestelmä (ValvontaPalvelinSysteemi) Virve Suomessa oleva Tetra-verkko. Yksilöosoite Vastaa TETRA-verkossa tavallista puhelinnumeroa. 8

9 13. Referenssit Alla olevassa taulukossa on lueteltu ne artikkelit ja raportit, joista on kerätty materiaalia tätä dokumenttia varten. Taulukko 9: Lista käytetyistä lähdemateriaaleista. Dokumentin nimi Indagon Valvottuliittymä tutkimussuunnitelma Indagon Oy:n TEKES hakemus toiselle TETRA-verkossa olevalle sovellukselle Tiehallinnon Liikenteen automaattisten mittapisteiden (LAM) tiedon siirtäminen TETRA tegnologian avulla EPA WSDL-rajapintakuvaus Kuvaus Kuvaus tutkimuskohteen tavoitteista ja toteutuksesta Kuvaa yritystä ja toiminta mallia TETRA-verkossa Kuvaa toisen mahdollisen TETRA-verkkoon liitettävän sovelluksen järkevyyttä, kustannuksia ja toiminta varmuutta Kertoo kuinka EPAn tarjoamaa palvelua voidaan käyttää ja mitä kaikkea sen avulla voidaan saavuttaa 9

10 Liite 1: Toiminnalliset vaatimukset Liite 1: Toiminnalliset vaatimukset ID Ver Ominaisuus Vaatimus Lähde Perustelu Prioriteetti Status Käyttötapauskuvaus T01 1 Liittymän valvonta Pakollinen Ehdotettu K01, K02 T02 1 T03 1 T04 1 Liittymän valvonta Laitteen toiminnan testaaminen Linjatoiminnan testaaminen Jokaiselle laitteelle tulee voida määritellä aikaväli 10 sekunnin ja vuoden väliltä, kuinka usein linjan toiminta Valppaan ja laitteen välillä tarkistetaan Eri laitetyypeille voidaan valita linjan toiminnan testaustapa. Yleisimmässä tapauksessa Valpas pollaa linjaa. Toisessa tapauksessa laite lähettäää säännöllisesti viestin Valppaalle Jokaiselle pollattavalle laitteelle tulee voida määritellä kuinka usein linjan testauksen yhteydessä tarkistetaan myös laitteen toiminta (puhelin kysyy laitteelta toimintatilaa). Vaihtoehdot ovat joka kerran ja joka kymmenennen kerran väliltä Jokaisen laitteen kohdalla tulee voida määritellä tarkastetaanko linjan toimivuus EPAn statusviestien pohjalta vai sillä, että laite lähettää paikkatietonsa Valppaalle T05 1 Verkon testaus Simulaattorin ja Valppaan tallentamista tiedoista pitää selvittää TETRA-verkon ja/tai EPAn aiheuttamien virheiden määrä T06 1 Verkon testaus Valppaan ja simulaattorin tulee kummankin tallentaa tiedot lähetetyistä ja vastaanotetuista viesteistä/tiedoista T07 1 Verkon testaus Kaikki viestit tulee varustaa aikaleimoin T08 1 Verkon testaus Simulaattorin tulee tallentaa tieto omasta paikastaan vähintään 10 sekunnin välein A Poijuissa ei ole varaa pitää akkuja koko ajan päällä, jolloin ei voida tietää koska ne ovat päällä. Tällöin laite itse huolehtii viestien lähettämisestä Markus Maanoja Pakollinen Ehdotettu K01, K02 Mikko Weckström Pakollinen Ehdotettu K14 Tarpeellinen Ehdotettu K09 Markus Maanoja Indagon Valvottuliittymä tutkimussuunnitelma Markus Maanoja Järjestelmän tarkoitus on myös testata olemassa olevan verkon luotettavuutta Tällöin voidaan verrata viestien perillemenoa Voidaan tutkia viestien välitysaikoja ja virheiden tapahtuma-aikoja Tällöin voidaan havaita miltä alueita viestit eivät kulje Pakollinen Ehdotettu K06 Pakollinen Ehdotettu K06 Pakollinen Ehdotettu K06 Tarpeellinen Ehdotettu K06

11 Liite 1: Toiminnalliset vaatimukset T09 1 T10 1 T11 1 T12 1 T13 1 T14 1 T15 1 T16 1 T17 1 T18 1 Vikatilanteen tunnistus Vikatilanteen tunnistus Valppaan tulee tunnistaa huolto- ja hätäviestit Valppaan tulee tunnistaa linjavikatilanne Hätäviesteille tulee voida määritellä maximissaan 5 eri vastaanottajaa Huoltoviesteille tulee voida määrittellä maximissaan 5 eri vastaanottajaa, joille ei välttämättä ole mitään tekemistä hätäviestien vastaanottajien kanssa Huoltoviesteille määritellyille vastaanottajille tulee voida määrittää järjestys, jossa heitä halutaan lähestyä Huoltoviesteille tulee voida määritellä kuittausaika Huoltoviesti lähetetään ensin järjestyksessä ensimmäiselle vastaanottajalle. Mikäli viestiä ei kuitata saaduksi määriteltynä kuittausaikana viesti lähetetään seuraavalle vaihtoehdolle ja odotus toistetaan Jos kukaan laitteen huoltoketjussa ei kuittaa huoltoviestiä annetussa ajassa, tulee tilanteesta lähettää tiedonanto taholle, joka on sama kuin linjavikaviestien vastaanottaja Linjavioille tulee voida määritellä kuittausaika Linjavika ilmoitetaan taholle, joka on kaikilla laitteilla sama (operaattori) Tulevassa järjestelmässä nämä tiedot käsitellään eri tavalla (ne mm. lähetetään eri paikkoihin) Pakollinen Ehdotettu K07, K08 Tämä on järjestelmän Pakollinen Ehdotettu K09 pääkäyttökohde. Lisäksi tämä tapaus käsitellään eri tavalla kuin huolto- ja hätäviestit, jotka tulevat valvotulta liittymältä Tarpeellinen Ehdotettu K01, K02 Tarpeellinen Ehdotettu K01, K02 Hyödyllinen Ehdotettu K01, K02 Hyödyllinen Ehdotettu K01, K02 Hyödyllinen Ehdotettu K08, K14 Hyödyllinen Ehdotettu K08, K14 Hyödyllinen Ehdotettu K01, K02 Hyödyllinen Ehdotettu K09 B

12 Liite 1: Toiminnalliset vaatimukset T19 1 T20 1 T21 1 T22 1 T23 1 edelleen lähetys edelleen lähetys Kaikista järjestelmässä ilmenevistä linjavioista lähetetään tieto myös samalle taholle, jolle laitteen hätäviestit menevät Jos linjavikaa ei kuitata määritellyssä ajassa, tulee tilanteesta lähettää tiedonanto taholle, joka on sama kuin laitteen hätäviestin vastaanottaja Standardien ilmoitusten (hätä/huolto) jälkeen laite voi lähettää laitekohtaista lisäinformaatiota, joka Valppaan tulee välittää edelleen samalle taholle kuin standardiviestikin Järjestelmään tulee voida liittää erilaisia tapoja viestien edelleen lähetys ja kuittaus tavoiksi (Esimerkiksi sähköposti ja SMSviestit) Jokaiselle vastaanottajalle tulee voida määrittää tapa, jolla hän haluaa ottaa viestit vastaan Valppaalta (katso myös vaatimus 21) T24 1 Turvallisuus WWW-pohjaiseen käyttöliittymään pääsee käsiksi vain oikealla käyttäjätunnus/salasana parilla T25 1 T26 1 T27 1 T28 1 Järjestelmään kirjautuminen Asetusten muokkaus Asetusten muokkaus Laitteen toiminnan tarkastelu WWW-käyttöliittymään tulee voida kirjautua sekä admin- että asiakasoikeuksilla Jokaisen laitteen tietoihin voidaan kirjata laitteeseen liittyvä asiakas Jokaisella järjestelmään kirjatulla asiakkaalle voidaan määritellä oletusarvot laitteiden hätäviestien vastaanottajaksi ja huoltoviestien vastaanottoketjuksi Järjestelmän tulee tarjota ulkoinen rajapinta, johon liittymällä asiakas pystyy seuraamaan laitteidensa tilaa Hyödyllinen Ehdotettu K09 Tarpeellinen Ehdotettu K09 Hyödyllinen Ehdotettu K07, K08 Markus Maanoja Hyödyllinen Ehdotettu Hyödyllinen Ehdotettu Viranomaisverkossa tietoturvaan pitää kiinnittää erityistä huomiota Tarpeellinen Ehdotettu K13 Hyödyllinen Ehdotettu K10, K11, K12, K13, K14 Hyödyllinen Ehdotettu K01, K02, K10, K11 Hyödyllinen Ehdotettu K01 Mikko Weckström Järjestelmän halutaan tulevaisuudessa toimivan yhteen esimerkiksi Leaderin kanssa Tarpeellinen Ehdotettu K13 C

13 Liite 2: Ei-toiminnalliset vaatimukset Liite 2: Ei-toiminnalliset vaatimukset ID Ver Vaatimus Lähde Perustelu Prioriteetti Status Käyttötapauskuvaus E01 1 Järjestelmän tulee toimia yhteen ainakin TMR880-puhelimen kanssa Markus Maanoja Tämä on yleisin tällä hetkellä käytössä oleva TETRA-puhelin Pakollinen Ehdotettu K04, K05 E02 1 E03 1 E04 1 E05 1 E06 1 E07 1 E08 1 E09 1 E10 1 Testijärjestelmän arkkitehtuurissa tulee mahdollisimman pitkälle huomioida tulevan tuotteen asettamat vaatimukset Lopullisen järjestelmän tulee pahimmassa tapauksessa pystyä valvomaan laitetta 100 sekunnin välein Valpas kuuntelee viestejä myös ryhmäosoitteisiin Valpas lähettää viestejä yksilöosoitteisiin WWW-tietoliikenne tulee suojata ainakin SSL-tason salauksella Ulkoinen rajapinta erilaisille sovelluksille on toteutettu XMLmuodossa Kaikki pollaus tapahtumat tallennetaan tietokantaa Laitteen paikkatiedon laskemiseen käytetään MTT100AS-laitetta Simulaatiossa Valppaan tulee varmistaa viestien perille meno vain ja ainoastaan EPAn tarjoaman viestistatuksen mukaan Markus Mikkolainen Voi olla jo tämän projektin tehtävä kehittää testiversiosta toimivaa järjestelmää Tarpeellinen Ehdotettu Markus Maanoja Tarpeellinen Ehdotettu K09 Indagon Valvottuliittymä tutkimussuunnitelma Indagon Valvottuliittymä tutkimussuunnitelma Indagon Valvottuliittymä tutkimussuunnitelma Tällöin tieto menee myös muille tahoille, jolloin Valpas ei ole ainoa joka saa tiedon, jos asiat eivät toimi Jos viesti lähetetään ryhmäosoitteeseen ei saada tietää minne kaikkialle viesti meni perille ja minne ei TETRA-verkossa tietosuoja on tärkeää Tällöin voidaan analysoida liittymän luotettavuutta Tarpeellinen Ehdotettu K07, K08 Tarpeellinen Ehdotettu K09, K14 Tarpeellinen Tarpeellinen Ehdotettu Ehdotettu K13 Tarpeellinen Ehdotettu K09, K14 Hyödyllinen Ehdotettu K04, K05 Hyödyllinen Ehdotettu K09 D

14 Liite 2: Ei-toiminnalliset vaatimukset E11 1 Kaikki säädöt järjestelmän toimintaa pitää pystyä suorittamaan wwwkäyttöliittymän kautta Markus Mikkolainen E12 1 Asetusten muokkaus Admin-oikeuksilla wwwkäyttöliittymään kirjautunut henkilön pitää voida nähdä ja saada muokata kaikkia järjestelmässä olevia tietoja E13 1 Laitteen toiminnan tarkastelu Asiakas-oikeuksilla wwwkäyttöliittymään kirjautunut henkilö saa nähdä ja muokata vain niitä tietoja, jotka liittyvät kyseiseen käyttäjään Käyttäjällä ei välttämättä oikeuksia palvelin koneeseen ja/tai teknistä ymmärtämystä initiedostoihin tms. Hyödyllinen Ehdotettu K01, K02, K03, K10, K11, K12, K13 Rönkkö Hyödyllinen Ehdotettu K01, K02, K03, K10, K11, K12, K13 Tarpeellinen Ehdotettu K01, K02, K03 E

15 Liite 3: Rajoitukset Liite 3: Rajoitukset ID Versio Rajoitus Lähde Perustelu Prioriteetti Status Käyttötapauskuvaus R01 1 Tietokantana käytetään PostgreSQL:ää Markus Mikkolainen Tämä on yrityksessä käytössä ja tuttu Pakollinen Ehdotettu K01, K02, K03, K10, K11, K12 R02 1 WWW-palvelimena käytetään Jettyä Markus Mikkolainen Tämä on yrityksessä käytössä ja tuttu Hyödyllinen Ehdotettu K01, K02, K03, K10, K11, K12, K13 R03 1 Ohjelman sisäisen tilan ja siellä tapahtuvien asioiden raportoimisen tulee tapahtua Log4J:llä Markus Mikkolainen Tämä on yrityksessä käytössä ja tuttu Pakollinen Ehdotettu K04, K05, K06, K07, K08, K09, K14 R04 1 Järjestelmän tulee toimia ainakin LINUX-koneilla Markus Tarpeellinen Ehdotettu Maanoja R05 1 Simulaattorin tulee pyöriä puhelimeen ja MTT:hen kiinnitetyllä kannettavalla tietokoneella, joka ei välttämättä ole yhteydessä verkkoon Rönkkö Asiakas halusi liikuteltavan järjestelmän, jolla voidaan testata myös verkon katvealueita Tarpeellinen Ehdotettu K04, K05 F