Vaatimusten määrittely: täydellinen opas ja mallipohja
Vaatimusten kerääminen on prosessi, jonka avulla voit asettaa ja hallita sidosryhmien odotuksia, ehkäistä laajuuden hallitsematonta kasvua ja vähentää epäselvyyttä siitä, mitä projektisi todellisuudessa tuottaa.
Mitä enemmän vaatimusdokumentaatiota sinulla on, sitä vähemmän tilaa jää virheille ja oletuksille. Tarkistukset ja tasapainot hyödyttävät tiimisi yhteistä ymmärrystä projektista sekä asiakkaasi odotuksia lopputuotteesta.
Mitä vaatimusten kerääminen on projektinhallinnassa?
Vaatimusten kerääminen on prosessi, jossa määritetään, mitä projektin toimeksiantajat ja keskeiset sidosryhmät tarvitsevat projektilta. Projektipäälliköt pyrkivät selvittämään, mitä pyydetään ja mitä yksityiskohtia pyyntöön liittyy.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Näistä pyynnöistä muodostuu projektin vaatimusluettelo. Vaatimusten täyttyminen määrittää, pidetäänkö hanketta onnistuneena projektina.
Projektipäälliköt käyttävät vaatimusasiakirjoja ja vaatimustenhallintatyökaluja seuratakseen tämäntyyppisiä vaatimuksia koko projektin ajan:
- Toiminnalliset vaatimukset
- Tekniset vaatimukset
- Ei-toiminnalliset vaatimukset
- Järjestelmävaatimukset
Miksi vaatimusten kerääminen on tärkeää?
Vaatimusten kerääminen on tärkeää seuraavista syistä, kuten myös vaatimusten dokumentointi:
- Se toimii viitekohtana, johon dokumentoidaan projektin kehitys, sen eri osat ja toteutus
- Se toimii projektin sidosryhmille laadittuna suunnitelmana, jonka avulla he ymmärtävät paremmin, mitä projektilta voi odottaa (projektin mitä-, missä-, milloin- ja miksi-näkökohdat).
- Se vähentää virheiden ja epäselvyyksien mahdollisuutta, koska vaatimukset dokumentoidaan selkeästi ja niistä sovitaan ennen työn aloittamista.
- Se tarjoaa tarkistukset ja tasapainot koko projektin tuotannon ja laadunvarmistuksen ajan, jolloin projektipäälliköt ja tiimin jäsenet voivat palata siihen aina, kun on epäselvää, miten tulisi edetä.
Sen lisäksi, että tehokkaan vaatimustenhallinnan suunnittelun tulisi kuvata, mitä voidaan odottaa, sen tulisi myös määritellä, mitä ei pidä odottaa. ”Oletukset”- ja/tai ”Rajaukset”-osion lisääminen on järkevä tapa poistaa pelätyn asiakkaan mielikuvituksen riski.
Esimerkki ohjelmistovaatimusmäärittelystä
Tässä on esimerkki verkkokauppaprojektin vaatimusmäärittelystä:
- Mitä: PayPal-integraatio
- Missä: Kassalla
- Milloin: Kassaprosessin vaiheessa 3/4 (toimitusosoitteen verkkolomakkeen jälkeen, ennen vahvistusta)
- Miksi: Tässä tapauksessa valmis integraatio (esimerkiksi PayPal) on maksupalvelun vankkaa räätälöityä integraatiota parempi ratkaisu, koska se täyttää liiketoimintavaatimukset helposti.
- Oletukset
- Kiinteä maksu kaikista toimitus- ja käsittelykuluista
- Kaikki toimitukset tapahtuvat Yhdysvaltojen sisällä (Alaskaa ja Havaijia lukuun ottamatta)
- Veroja ei sovelleta
- Rajaukset
- Räätälöidyt toimitus- ja käsittelymaksujen laskelmat
- Toimitukset ulkomaille, Alaskaan tai Havaijille
- Verosäännöt
Muista: mitä pienempi ero asiakkaan odotusten ja hänen digitaalisen tuotteensa todellisuuden välillä on, sitä tyytyväisempi asiakas tulee olemaan lopputulokseen. Vaatimustenhallintasi laatu korreloi suoraan kykysi kanssa projektipäällikkönä vähentää harmaita alueita, kun kyse on asiakkaan odotuksista.
Useimmiten asiakas suhtautuu myönteisesti siihen, että rajoitat laajuuden hallitsematonta kasvua, jos se tarkoittaa hänen budjettinsa säilyttämistä; jos koulutat asiakasta riittävästi siitä, miksi jokin ominaisuus toteutetaan (tai jätetään toteuttamatta), ja sitten dokumentoit kyseisen lähestymistavan taustalla olevan logiikan vaatimuksiin, asiakas tekee paljon todennäköisemmin yhteistyötä.
Hän hyväksyy suunnitelman todennäköisemmin, ja myöhemmin, kun hän suorittaa käyttäjähyväksymistestausta (UAT), hän ymmärtää jo paremmin tiimisi ratkaisun taustalla olevan "miksi"-perustelun.
6-vaiheinen vaatimustenkeruuprosessi
Vaikka vaatimusten keräämisen tulisi alkaa heti toimeksiannon alkaessa ja jatkua koko projektin elinkaaren ajan, vaatimusten keräämisen ja dokumentoinnin aloittaminen ei ole koskaan liian aikaista. Aloita itse asiassa eilen.
Tässä ovat vaatimusten keräämisen vaiheet.
1. Tee muistiinpanoja
Jokaisessa kokouksessa, johon osallistut – olipa kyseessä sisäinen kokous projektitiimisi kanssa tai ulkoinen kokous asiakkaasi kanssa – tee aina muistiinpanoja. Älä koskaan oleta, että joku muu tekee niitä.
Tilanteessa voi olla helppoa olettaa, että kaikki keskusteltu muistetaan, mutta kolmen kuukauden ja 15 kokouksen jälkeen tiimisi ja asiakkaasi kiittävät sinua siitä, että sinulla on tallessa muistiinpanot, joihin keskusteluissa voidaan palata.
Tässä on joitakin suosittelemiani menettelytapoja vaatimuksia koskevien muistiinpanojen tekemiseen:
- Ennen kokousta valmistele muistiinpanodokumenttisi vastaamaan esityslistaasi, jotta toimenpiteiden ja kohtien järjestäminen on helpompaa. Näin muistat, mitä tarvitaan, ja samalla tallennat asiaan liittyvät tiedot järjestelmällisesti.
- Varaa jokaisen kokouksen jälkeen itsellesi 15–30 minuuttia aikaa muistiinpanojesi tarkistamiseen, keskustellun sisäistämiseen, toimenpiteiden priorisointiin sekä haasteiden/varoitusmerkkien tai selvennystä tai lisäkokouksia vaativien asioiden tunnistamiseen.
- Lähetä muistiinpanosi sisäiselle projektitiimillesi. Pyydä tiimiä tarkistamaan ja varmistamaan toimenpiteet, varoitusmerkit ja muut asiat, jotka olet tunnistanut.
- Kun tiimi on hyväksynyt muistiinpanosi, lähetä ne asiakkaallesi.
- Lopuksi hyödynnä muistiinpanojasi viitteenä, kun luot tehtäviä kustakin toimenpiteestä. Lisää kaikki uudet tiedot vaatimusten dokumentaatioon ja aikatauluta tarvittavat kokoukset lisäselvityksiä tai keskustelua varten.
2. Käy läpi luovat vaatimukset
Älä jätä suunnittelu- ja tyylipäätöksiä yksittäisten tiimin jäsenten vastuulle: määrittele luovat vaatimukset aina, kun se on mahdollista. Luovia ohjeita tarvitaan kipeästi kehittäjille. Varmista vähintään, että sinulla on tyyliopas käytettävissäsi – vaikka se sisältäisi vain fontin ja brändin värit.
Kerää kaikki luovat aineistot, kuten brändilogot tai brändifontit, ja lataa ne jaettuun tilaan (kuten digitaalisten aineistojen hallintaohjelmistoon), jotta koko tiimillä on pääsy niihin ja näkyvyys niihin.
3. Laadi vaatimusdokumentti
Kun perehdyt dokumentointiin, muista: ensimmäinen yrityksesi vaatimusten dokumentoinnissa on vaikein. Miksi? Koska sinulla ei ole aiempaa dokumenttia hyödynnettäväksi (eli KOPIOI–LIITÄ). Onneksesi tämä artikkeli sisältää vaatimusten dokumentointimallin, joka toimii sinulle perustana.
Kuten tässä mallissa näkyy, jaan vaatimusten dokumentaationi neljään osaan:
- Merkintä: Sisältää suunnittelemaasi malliin lisäämäsi numerot. Jos sivusi mallissa on 8 elementtiä, siinä on 8 merkintää ja merkintäsarakkeessa on 8 riviä
- Elementti: Sisältää elementtien otsikot niiden kuhunkin merkintään liittyen
- Toiminnallinen vaatimus: Sisältää kunkin elementin määritelmän eli vaatimukset kirjallisessa muodossa
- Ylläpitäjän/CMS:n toiminnallisuus: Määrittele kaikki hallinnolliset ja/tai CMS-toiminnot, jotka liittyvät vastaavaan elementtiin
4. Järjestä sisäinen katselmointi
Tässä vaatimusten keräämisprosessin vaiheessa järjestä toinen sisäinen kokous projektiryhmäsi kanssa vaatimusdokumentaation läpikäymistä varten. Tämä on lopullinen sisäinen tarkistus ja vastapaino, jolla varmistetaan toteutuksen ymmärtämisesi.
Jos mahdollista, pyydä tiimiä tutustumaan vaatimusdokumentaatioon ennen kokousta, jotta he voivat tulla paikalle valmiina kysymystensä ja/tai palautteensa kanssa. Käytä kokousta vaatimuksia koskevien kysymysten tai palautteen käsittelyyn.
Tee dokumentaatioon tarvittavat muutokset sisäisen keskustelun perusteella. Lähetä lopuksi muokattu vaatimusdokumentaatio uudelleen tiimille lopullista hyväksyntää varten. Kun sisäinen projektiryhmä on antanut lopullisen hyväksyntänsä vaatimusdokumentaatiolle, tallenna asiakirja PDF-muodossa varmistaaksesi, että se säilyy viimeistellyssä muodossaan seuraavaa vaihetta eli tehtävien määrittelyä varten.
5. Määrittele tehtävät
Toimita vaatimusdokumentaation PDF-versio kehitystiimillesi. Ihannetapauksessa kehittäjäsi tai kehitysvastaavasi määrittelee toteutuksen tehtävät.
Vaikka jotkin organisaatiot saattavat toimia prosessilla, jossa projektipäälliköt määrittelevät kaikki tehtävät, itse haluan kehittäjien määrittelevän omat tehtävänsä; heidän siihen käyttämänsä muutama tunti on sen arvoista.
Voit silti antaa tiimillesi hyödyllisiä ohjeita , kun he määrittelevät kehitystehtäviään ja tuotoksiaan. Tehtävien määrittelyn jälkeen voit saada lopullisen tuntiarvion.
Vertaa tätä arviota aiemmin asiakkaallesi ilmoitettuun projektin aikatauluun ja hallitse tilannetta tarvittaessa sen mukaisesti. Lisätietoja projektien kustannusarvioista saat tästä kattavasta projektien arviointioppaasta.
6. Järjestä ulkoinen katselmointi
On aika esitellä vaatimusdokumentaatio asiakkaallesi. Toimita se PDF-muodossa, jotta siihen ei tehdä muutoksia. Tämä (1) osoittaa panostuksesi sen varmistamiseen, että asiakas ymmärtää digitaalisen ratkaisun, ja (2) toimii turvanasi, jotta voit sanoa “minähän sanoin” (tosin paljon hienostuneemmin), kun projektin laajuuden hallitsematon kasvu väistämättä nostaa päätään.
Perehdytä asiakastasi. Käy hänen kanssaan läpi tämä arvokas dokumentaatio, jonka olet huolellisesti koonnut häntä varten. Muista: he ovat oman liiketoimintansa asiantuntijoita. Sinä olet heille tarjoamasi digitaalisen ratkaisun asiantuntija. He maksavat sinulle tästä ratkaisusta. Perehdytä ja osallista asiakastasi.
Kun asiakas on vahvistanut ymmärtävänsä vaatimusdokumentaation, on aika saada virallinen hyväksyntä. Lähetä allekirjoitettu ja hyväksytty vaatimusdokumentaatio tiimillesi ja tallenna se yhteiseen tilaan, jotta on virallisesti osoitettavissa, että kehitys voi alkaa.
Vaatimusten keräämisen tekniikat
Seuraavien tekniikoiden avulla voit varmistaa, että teet tärkeän vaatimusten keräämiseen liittyvän työn mahdollisimman hyvin:
1. Aloita heti
Vaatimusdokumentaation laatiminen tulisi aloittaa heti keskustelujen käynnistyttyä, ennen kuin tarkka projektisuunnitelma tai projektin tavoitteet on lyöty lukkoon. Kirjaa ylös kaikki mahdollinen ja karsi sitä sen jälkeen. Tässä on joitakin strategioita, joita voit kokeilla asiakkaasi kanssa:
- Lähetä heille kysely siitä, mitä he haluaisivat projektissa nähdä
- Järjestä aivoriihi
- Järjestä fokusryhmä
Sen sijaan että poistaisit tietoja asiakirjasta, luokittele ne mukaan otettaviin ja pois jätettäviin tietoihin — näin vältät asiakkaan myöhemmät oletukset.
Voit ottaa esiin WIP-vaatimusdokumentaatiosi (työn alla oleva dokumentaatio) ja osoittaa, missä kyseinen tieto on kirjattu, miksi sitä ei ehkä ole sisällytetty, mikä päätöksen taustalla oleva logiikka on ja milloin tieto kirjattiin, jolloin se on jäljitettävissä.
2. Hyödynnä malleja
Kun sinulla on muutama vaatimusdokumentti takanasi, ala hyödyntää niitä ja luoda niistä malleja tulevaa käyttöä varten muissa projekteissa. Erityisesti jos keskityt tietynlaisiin verkkokauppa- tai oppimissovellusprojekteihin, alat huomata toiminnallisuuksien toistuvia kaavoja. Tunnista, missä voit hyödyntää sisältöä uudelleen.
3. Yhteistyöllä unelmat toteutuvat
Jos projektissa on erityyppisiä tiimin jäseniä, kunkin osaamisalueen vaatimukset voivat olla kyseisten asiantuntijoiden laatimia.
Monissa tapauksissa vaatimuksia koskeva keskustelu muodostuu puheluista, useista erillisistä kokouksista ja keskusteluista ynnä muusta. Siksi on erittäin tärkeää osoittaa vaatimusdokumentointi asianomaisille tiimin jäsenille samalla, kun keräät ja kokoat vaatimuksia.
4. Älä vain kirjaa vaatimuksia – opi
Älä tyydy pelkkien muistiinpanojen tekemiseen. Älä odota, että asiantuntijat lähettävät sinulle valtavan tekstiseinän, joka sisältää heidän osuutensa vaatimuksista. Varaa aikaa istuaksesi kehittäjätiimisi kanssa ja perehtyäksesi ratkaisuihin, joita tiimi suunnittelee toteutettaviksi. Keskustele siitä, miksi ja miten. Esitä kysymyksiä.
Ennen kuin sanot: ”Mutta meillä on vain rajallisesti aikaa päivässä – entä budjetti?”, ymmärrä tämä: jos työstämäsi ratkaisu soveltuu useampaan kuin yhteen projektiin, tämän ymmärryksen hankkimiseen käytetyn lisäajan ei välttämättä tarvitse olla laskutettavaa. Kehität toimialaosaamistasi, joka parantaa suoraan päivittäistä työtäsi.
5. Pidä asiakkaasi ajan tasalla
Laadi sekä sisäinen vaatimusdokumentti että asiakkaalle suunnattu keskeneräisten vaatimusten dokumentti. Sisäisessä dokumentissa voit olla huolettomampi ja sisällyttää siihen avoimempia muistiinpanoja.
Jos et käsittele arkaluonteisia tietoja, voit luoda tämän jaetun tilan Google Docsiin ja antaa asiakkaalle oikeudet kommentoida. Jos käsittelet arkaluonteisia tietoja, jaa vaatimusdokumentin versio viikoittain, jotta asiakas saa katsauksen siihen, mitä on kirjattu.
6. Oleta, että asiakkaasi haluaa aina tietää enemmän
Sen sijaan että ottaisit riskin olettamalla asiakkaasi tietävän enemmän kuin hän tietää (ja joutuisit myöhemmin kärsimään siitä), oleta, että asiakkaasi haluaa aina tietää enemmän. Kysy jokaisen merkinnän kohdalla itseltäsi ”Miksi?” viisi kertaa varmistaaksesi jokaisen vaatimuksen perusteellisuuden.
Kysymällä itseltäsi ”Miksi?” viisi kertaa jokaisen vaatimuksen kohdalla haastat itsesi todella pohtimaan kunkin sivutyypin jokaisen elementin ja toiminnallisuuden taustalla olevaa logiikkaa. Saatat yllättyä siitä, kuinka paljon opit (tai huomaat tarvitsevasi oppia).
3 asiantuntijavinkkiä projektin vaatimusdokumentin kirjoittamiseen
1. Kirjoita yleisiä elementtejä koskevat vaatimukset erikseen
Vältä toistoa käsittelemällä kaikki yleiset elementit vaatimusdokumentaation ”Yleiset elementit” -osiossa. Tämä koskee esimerkiksi päävalikon kohtia, kaikkea yleisessä yläosassa olevaa sisältöä ja kaikkea alatunnisteessa olevaa sisältöä.
Kun olet kirjoittanut näitä yleisiä elementtejä koskevat vaatimukset, niitä ei tarvitse merkitä erikseen muille sivuille; merkitse vain kyseisille sivuille ominaiset elementit.
2. Kopioi ja liitä samanlainen toiminnallisuus johdonmukaisuuden varmistamiseksi
Tämä on yksinkertaisesti vinkki, joka kannattaa pitää mielessä oman ja asiakkaasi mielenterveyden vuoksi. Huomaat tätä eniten yleisissä sivuelementeissä, kuten pääkuvissa ja bannerikuvissa, yläosissa tai ”takaisin”-kuvakkeissa – toistuvaa toiminnallisuutta on paljon eri sivutyypeissä (näitä ei pidä sekoittaa yleisiin elementteihin).
3. Huomioi ylläpito ja CMS tai niiden puuttuminen
Kun keskitymme niin voimakkaasti kunkin sivuelementin toiminnallisuuteen, hallinnollinen ja/tai CMS-toiminnallisuus on helppo sivuuttaa. Jos toteutat ratkaisua, joka tarjoaa hallinnollisia ja/tai CMS-toimintoja, muista sisällyttää ne omana sarakkeenaan vaatimuksiin. Esimerkki alla:
Vaatimusdokumentin malli [Lataa]
Vaatimusten määrittelyn yksityiskohdat riippuvat suhteestasi asiakkaaseen, tiimisi kokemuksesta ja muista tekijöistä.
Tarvitset kuitenkin edelleen projektin vaatimusasiakirjan perusosat, joissa määritellään ominaisuuden toiminnallisuus, sijainti, ulkoasu ja muut vastaavat asiat. Tässä on vaatimusasiakirjamallimme (sinun on oltava jäsen käyttääksesi sitä):
Nopeuta työskentelyä yli 100 ensiluokkaisen mallin avulla
Liity DPM-jäseneksi saadaksesi käyttöösi loputtomasti asiantuntijoiden luomia malleja, joiden avulla työskentelet nopeammin ja tehokkaammin.
