Raportointi >> Perusraportti Palautepyyntö: ICT palvelujen kehittäminen: Vaatimusmäärittely

Transkriptio

1 76c39 (Valtiovarainministeriö), olet kirjautuneena sisään.. toukokuuta 9 :9:46 Your boss is {} Kirjaudu ulos Etusivu Kyselyt Raportointi Asetukset Käyttäjätiedot Ota yhteyttä Oppaat Help Päällä P Raportointi >> Perusraportti Palautepyyntö: ICT palvelujen kehittäminen: Vaatimusmäärittely Vastaajien listaus Kopio e raporttiin Vie tulokset Exceliin Luo suodatus Kyselyn nimi Palautepyyntö:ICT palvelujen kehittäminen: Vaatimusmäärittely Kyselyn tekijä 76c39 Kysely luotu ::37 Vastausajankohta :54:5 Vastaajien kokonaismäärä 6 Ordered by answers. Organisaatio. Rautatievirasto ( ). Väestörekisterikeskus (688693) 3. Puolustusvoimat ( ) 4. Valtioneuvoston kanslia (7593) 5. Helsingin kaupunki (7657) 6. KELA (74798). Yleiskommentit. Suositus on erittäin hyvä, johdonmukainen ja helppolukuinen (688693). Puolustusvoimat on tutustunut asiakirjoihin ja toteaa ne erittäin hyvin valmistelluiksi ja eri vaihtoehdot (kehitetty vain omaan tarpeeseen, sovellusvuokraus, avoin lähdekoodi jne.) hyvin huomioon ottaviksi. Yleisesti kaikissa kolmessa dokumentissa tulisi paremmin käydä ilmi mitkä dokumentit on vähintään tehtävä ja mitkä ovat tarpeellisia mutta eivät välttämättömiä. Tämä edistäisi mm. pienten projektien läpimenoa ja isojen ohjelmistojen pienten osien parannusta. ( ) 3. Vaatimusten määrittely on osa vaatimusten hallintaa, joka jatkuu tietojärjestelmän koko elinkaaren ajan ja on hyvä, että tästä osaalueesta on suosituksessa oma lukunsa. Esiselvityssuosituksessa oli otettu esiin tarve ottaa kantaa tapaan, jolla vaatimusmäärittely tulisi laatia kilpailutusta varten, jotta esim. vertailuja ei riitautettaisi. Tähän seikkaan toivoisimme otettavan kantaa myös vaatimusmäärittelysuosituksessa, jossa voitaisiin tarkentaa erilaisten vaatimustyyppien käyttöä tarjouksen vertailussa. (7593) 4. Hyvä dokumentti myös päivitettynä. (7657) 3. Anna arviosi seuraavista suositusluonnokseen liittyvistä väitteistä asteikolla 5 (5 = samaa mieltä, = eri mieltä) Kysymykseen vastanneet: Suositus on tarpeellinen (ka: 4,833; yht: 6) 83,3% 5 6,7% Suositus on otettavissa käyttöön ilman tukea ja koulutusta (ka: 3,667; yht: 6) 6,7% 6,7% Suosituksen luettavuus ja ymmärrettävyys ovat hyvällä tasolla (ka: 4; yht: 6) ka: 4,67; yht: 8 5 9,% 4,% 4 5,6%

2 4. Suositusluonnoksen hyväksyminen Kysymykseen vastanneet: 6 (ka:,7) (4.) Hyväksytään ilman muutosehdotuksia (4.) Hyväksytään, oheisilla muutosehdotuksilla 66,7% 4 (4.3) Ei kantaa (4.4) Vastustetaan (perusteltava) 5. Vastustusperusteet 6. Yleiset muutosehdotukset. Olemme itse juuri keskelle ohjelmistoprojektia. Olemme talla hetkelle toteutus vaiheessa: maarittelyt on osaksi tehty. Testauksesta olisi voitu puhua enemmän. Näihin kysymyksiin haluaisin vastauksia:. Mitä asioita ohjelmiston ostaja tulee ottaa huomioon ohjelman integraatio ja hyäksymistestauksessa?. Miten lähdetään käyttötapauksista määrittelemään testaustapauksia? ( ). Arkkitehtuuri ja käytettävyysvaatimukset olisi hyvä nostaa omiksi pääotsikoikseen samoin järjestelmän konfikuraatiovaatimuksia olisi hyvä käsitellä erikseen. Mm. mitä sovelluksen toiminnallisuuksia halutaan ohjata esim. WebConfigin tms. kautta (688693) 3. Vaatimusmäärittelyosuudessa kuva, Vaatimusten hallinta tietojärjestelmien hankinnan eri vaiheissa, on epäselvä. Kuvaa olisi tarpeen selkiyttää esittämällä tilaaja ja toimittaja eri sarakkeissa tai eri väreillä. ( ) 4. Muutamia tarkennusehdotuksia, ei erityisiä virheitä. Arkkitehtuurista ja sen kuvauksista ei mainita tässä päivitetyssä versiossa juurikaan, vaikka ict palvelujen kehitys on arkkitehtuurivetoista suositussarjan muissa osissa. (7657) 5. Vaatimusmäärittelyn paikka "ICT palvelujen kehittämisen vaiheet" prosessissa on mielenkiintoinen, kun sitä vertaa vaiheiden sisältöön. Vaiheessa "Esiselvitys" pohditaan ja kiinnitetään toteutustapa (ASP, SaaS, oma toteutus jne), ja vaiheessa vaatimusmäärittely kerätään korkean tason vaatimukset. Tämä tuntuu takaperoiselta, koska usein korkeankin tason tärkeät vaatimukset vaikuttavat ratkaisevasti toteutustapaan ja erityisesti toteutustekniikkaan. Jos aiemmin on jo päätetty että järjestelmä hankitaan ASPina, mutta yksikään järjestelmä ei täytä kriittistä vaatimusta, niin joudutaanko palaamaan takaisin esiselvitysvaiheeseen? Toisaalta, monesti vasta yksityiskohtaisessa vaatimusmäärittelyvaiheessa tulee esiin asioita, jotka merkittävästi vaikuttavat valintoihin. Toisin sanoen, miten voidaan päättää "miten" tehdään, kun ei vielä ole selvitetty "mitä" tarkkaanottaen ollaan tekemässä? (74798) 7. Muutosehdotukset kappaleeseen. Johdanto 8. Muutosehdotukset kappaleeseen. Soveltamisala 9. Muutosehdotukset kappaleeseen 3. Termit ja määritelmät. Sanastossa on "arkkitehtuurimalli", jota ei käytetä dokumentissa lainkaan. (7657)

3 . Muutosehdotukset kappaleeseen 4.Prosessikuvaukset. Muutosehdotukset kappaleeseen 5. Vaatimusten hallinta. Kuva ei vastaa ICT palveluiden kehittämisen uusia suosituksia; kuvassa näkyvä "Hankintatarpeen kartoitus ja hankinnan suunnittelu" on vaiheena esiselvityksen ja vaatimusmäärittelyn tilalla. Yhtenäiset vaiheistukset auttavat lukijaa ymmärtämään helpommin sisältöä. Vaatimukset on jaettu kolmeen ryhmään; kattaako jokin näistä ns. ei toiminnalliset/tekniset/laadulliset vaatimukset, joita esitelty mm. kohdissa.3 4 ja.? Lisäksi vaatimusten jäljitettävyyden parantamiseksi voisi luoda hierarkkian vaatimuksille siten, että toimintavaatimuksiin (business requirements) johdetaan (toiminnalliset ja ei toiminnalliset) käyttäjävaatimukset ja niihin vastaavasti (toiminnalliset ja ei toiminnalliset) järjestelmävaatimukset. Eli jos joku vaatimus päätetään poistaa, niin nähdään vaikutukset ylemmän/alemman tason vaatimuksiin. (7657). Muutosehdotukset kappaleseen 6. Vaatimusten määrittelyn vaiheet 3. Muutosehdotukset kappaleseen 6. Valmistautuminen vaatimusten määrittelyyn 4. Muutosehdotukset kappaleseen 6. Vaatimusten määrittelyn tuottaminen. Kohdassa voisi mainita, että tietosisällön käsitemalli ja järjestelmän liittymäkuvaukset pitäisivät tulla vaiheesta "kehittämiskohteiden tunnistaminen" ja vaatimusmäärittelyvaiheessa tarkennetaan tarpeen mukaan näitä arkkitehtuurikuvauksia. (7657) 5. Muutosehdotukset kappaleseen 6.3 Vaatimusten määrittelyn hyväksyminen 6. Muutosehdotukset kappaleeseen 7. Vaatimusten määrittelyn roolit 7. Muutosehdotukset kappaleeseen 7. Tietojärjestelmän omistaja

4 8. Muutosehdotukset kappaleeseen 7. Projektipäällikkö/Vaatimusten määrittelyvastaava 9. Muutosehdotukset kappaleeseen 7.3 Vaatimusten esittäjät ja kirjoittajat. Muutosehdotukset kappaleeseen 7.4 Muut asiantuntijat. Muutosehdotukset kappaleeseen 8. Vaatimusten määrittelyn ositus ja käytännön työskentely. Muutosehdotukset kappaleeseen 9. Vaatimusten hankintamenetelmiä 3. Muutosehdotukset kappaleeseen 9. Dokumenttien tutkiminen 4. Muutosehdotukset kappaleeseen 9. Kyselylomakkeet 5. Muutosehdotukset kappaleeseen 9.3 Suullinen kysely 6. Muutosehdotukset kappaleeseen 9.4 Suullinen strukturoitu haastattelu. Kirjoitusvirhe on tainnut eksyä sanaan semi strukturoitu. (7657)

5 7. Muutosehdotukset kappaleeseen 9.5 Suullinen strukturoimaton haastattelu 8. Muutosehdotukset kappaleeseen 9.6 Ryhmäpohjaiset tapaamiset 9. Muutosehdotukset kappaleeseen. Hyvän vaatimusilmaisun kriteerit. Hyvän vaatimuksen tunnusmerkkeihin voisi laittaa lisäksi "toteutettavuus", eli vaatimus on projektin resursseilla tai muilla rajoitteilla ylipäätään mahdollinen toteuttaa. Lisäksi listaan voisi laittaa "mitattavuus", jolloin vaatimuksen toteutuminen voidaan jälkikäteen todentaa jollain tavalla (tämä siis sama kuin "todennettavissa oleva"). (7657) 3. Muutosehdotukset kappaleeseen. Vaatimusmäärittelyssä tuotettava dokumentaatio 3. Muutosehdotukset kappaleeseen. Vaatimusluettelo ja tunnistetiedot. Kappale..5 Toimittajan kommentit sisältää mielenkiintoisen merkinnän järjestelmän soveltuvuudesta vaatimuksiin. Soveltumattomalle ehdotetaan annettavaksi ja soveltuvalle. Eikö olisi loogisempaa, että soveltumattomalle annetaan ja soveltuvalle nollaa suurempi koodi? Tämä tukisi suoraan tarjousten arviointia ja vähentää virhemahdollisuuksia kuvattuun käänteiseen merkintään verrattuna. (74798) 3. Muutosehdotukset kappaleeseen. Vanhan järjestelmän tietojen konversiot 33. Muutosehdotukset kappaleeseen.3 Järjestelmän tietoturvavaatimukset 34. Muutosehdotukset kappaleeseen.4 Järjestelmän tekniset reunaehdot

6 35. Muutosehdotukset kappaleeseen.5 Sanasto 36. Muutosehdotukset kappaleeseen.6 Liittymät muihin järjestelmiin. Kohdassa voisi mainita, että liittymäkuvaukset tulevat kehittämiskohteiden tunnistamisessa tehdyistä arkkitehtuurikuvauksista ja niitä tarkennetaan tarvittavalle tarkkuustasolle tässä vaiheessa. (7657) 37. Muutosehdotukset kappaleeseen.7 Käyttäjäroolien kuvaaminen 38. Muutosehdotukset kappaleeseen.8 Käyttötapausmalli. Käyttötapauksien kuvaustarkkuudesta voisi mainita mahd. eroja esim. valmisohjelman tai räätälöidyn järjestelmän osalta onko esim. tarkat käyttötapauskuvaukset esiehtoineen ja virhetilanteineen välttämättömiä, jos lähtökohtana on valmisohjelmiston hankkiminen? (7657) 39. Muutosehdotukset kappaleeseen.9 Raportit ja tulosteet 4. Muutosehdotukset kappaleeseen. Järjestelmän ei toiminnalliset laatuvaatimukset 4. Muutosehdotukset liitteeseen Vaatimusluettelo 4. Muutosehdotukset liitteeseen Käyttötapauskuvaus pohja