jos aloitat uuden projektin keräämättä projektin vaatimuksia sponsoreilta ja loppukäyttäjiltä, asetat itsesi epäonnistumaan. Hankkeet onnistuvat, kun ne tuottavat myönteisiä tuloksia ja täyttävät sidosryhmien odotukset. Jos projektisi ei täytä projektin ja käyttäjien odotuksia, se on epäonnistunut riippumatta siitä, kuinka nopeasti valmistuit tai pidit sen budjetissa.

kerro esimerkiksi, että johdat projektia uuden mobiilisovelluksen luomiseksi. Keräät projektivaatimukset ja kokoat kehittäjistä, tuotepäälliköistä ja luojista koostuvan tiimin. Julkaisun jälkeen käyttäjät kuitenkin valittavat sovelluksen käyttöliittymästä. He eivät pysty navigoimaan sovellusta saadakseen mitään aikaan.

kävi ilmi, että tiimisi oli niin keskittynyt täyttämään kaikki projektin sponsoreilta kerätyt projektivaatimukset, että he jättivät huomiotta yhden ohjelmistoprojekteille tärkeän käyttäjävaatimuksen: keep it simple!

tiimisi toimitti toimivan sovelluksen, mutta ei vastannut käyttäjien odotuksia. Onneksi voit välttää tällaiset tulokset tunnistamalla, analysoimalla ja validoimalla sidosryhmien vaatimukset ennen uusien projektien aloittamista. Tässä tulee vaatimusanalyysi.

mikä on vaatimusanalyysi?

Vaatimusanalyysissä määritellään, analysoidaan, validoidaan ja yhdenmukaistetaan sidosryhmien odotuksia uusille hankkeille samalla kun otetaan huomioon kaikki mahdolliset ristiriidat.

se on prosessi, jossa tunnistetaan, analysoidaan ja hallitaan projektin vaatimuksia, jotta voidaan määrittää, mitä projektin pitäisi saavuttaa ja poistaa mahdolliset epäselvyydet tai ristiriitaiset vaatimukset projektisuunnitelmastasi.

kun suoritat vaatimusten analysointiprosessia, muista, että hyväksyttyjen vaatimusten tulee olla:

• dokumentoitu
• toimintakelpoinen
• mitattavissa oleva
• testattavissa oleva
• jäljitettävissä oleva
• määritelty riittävin yksityiskohtin
• liittyvät liiketoiminnan kokonaistarpeisiin

milloin tehdään tarveanalyysi?

yleensä suoritat vaatimusanalyysiprosessin ennen projektisuunnittelun aloittamista. Lisäksi projektinhallinnassa suoritat vaatimusten analysointia, kun:

• kehittämiskustannusten laskeminen
• hankkeen painopisteiden asettaminen
• työnjakorakenteen luominen
• mukaan lukien projektiasiantuntijat meneillään olevassa hankkeessa

kuka suorittaa tarveanalyysin?

projektipäälliköt tekevät projektivaatimusanalyysin ennen uusien projektien aloittamista. Vaatimusanalyysidokumentti kerää, järjestää ja seuraa projektin vaatimuksia keskeisiltä sidosryhmiltä. Se ohjaa projektisuunnittelua ja varmistaa, että saat projektisi päätökseen sidosryhmien ja liiketoiminnan tavoitteiden mukaisesti.

vaatimusanalyysi ohjelmistotekniikassa

vaikka vaatimusanalyysi on hyödyllinen mille tahansa projektille, se on yleisin ohjelmistotekniikassa. Ohjelmistotekniikassa vaatimusanalyysi eli requirement engineering määrittelee odotukset uuden ohjelmiston rakentamiselle tai muokkaamiselle.

ohjelmistotekniikan Vaatimusanalyysi antaa projektipäälliköille ja johtajille valmiudet pitää selkeä suunta, pitää käyttäjien tarpeet edessä ja keskellä ja kehittää kokonaisvaltaista dokumentaatiota kehitysprosessista. Ohjelmistotekniikan vaatimusanalyysi on yleensä iteratiivinen, jatkuva prosessi koko projektin keston ajan, ei yksittäinen ja tehty tehtävä.

miten selvität projektin vaatimukset?

projektin vaatimusten esiin nostaminen on vaatimusanalyysin ydin. Se alkaa tärkeimpien sidosryhmien tunnistamisesta ja panoksen saamisesta. Kun nämä sidosryhmät on tunnistettu, kirjataan niiden hankkeen vaatimukset tutkimusta ja validointia varten ennen töiden aloittamista.

perusteellisen vaatimusanalyysin tekemisessä on kolme päävaihetta:

1. ensimmäinen askel on kerätä vaatimukset keräämällä liiketoimintaprosessien dokumentaatiota ja tekemällä haastatteluja sidosryhmien kanssa.
2. seuraavaksi analysoidaan ja validoidaan vaatimukset ja arvioidaan, ovatko ne selkeitä, täydellisiä, johdonmukaisia ja yksiselitteisiä.
3. lopuksi kirjataan vaatimukset ja seurataan niiden toteutumista koko hankkeen ajan.

tärkeitä sidosryhmiä, joita on kuultava vaatimusten analysointiprosessissa, ovat asiakkaat, loppukäyttäjät, tiimin jäsenet ja projektin sponsorit. Nämä ovat yleensä sidosryhmiä, joihin hanke vaikuttaa eniten, ja heidän tarpeensa yhdessä määrittelevät hankkeen ihanteellisen lopputuloksen.

Requirements analysis techniques you need to know

Requirements analysis techniques help you determine the stakeholder expectations that make it through requirements analysis. Niiden avulla voit myös selkeyttää sidosryhmien odotuksia yksinkertaisella, visuaalisella kielellä, jotta olet samalla sivulla. Kun olet kerännyt vaatimukset, kirjoita ne vaatimusanalyysiasiakirjaan ja jaa ne sidosryhmien hyväksyttäväksi.

jos teet muutoksia tähän vaatimusanalyysiasiakirjaan hankkeen aikana, tallenna se muutoksenhallintamenettelyllä ja lähetä se uudelleen asianomaisten sidosryhmien hyväksyttäväksi.

Requirements analysis techniques for discovering business needs

the following requirement analysis techniques help to discover business needs:

• Gap analysis: Gap analysis on prosessi, joka tutkii liiketoimintaa ja sen tavoitteita ja tarjoaa oivalluksia siitä, miten tämä aukko voidaan kuroa umpeen.
• Business motivation model (BMM): tämä analyysitekniikka perustuu OMG-mallinnusjärjestelmään, joka tukee maailmanlaajuisiin muutoksiin reagoivia liiketoimintapäätöksiä.
• Asiakasmatkan kartoitus: Tarinankerronnan ja visuaalisuuden avulla asiakkaiden matkakartat auttavat ymmärtämään asiakkaiden motivaatiota, pelkoja ja vastaväitteitä.

Vaatimusanalyysitekniikat ohjelmistovaatimusten tunnistamiseksi

seuraavat vaatimusanalyysitekniikat auttavat tunnistamaan ohjelmistovaatimustarpeet:

• Data flow program: data flow program (DFP) määrittelee projektin laajuuden syventymättä yksityiskohtiin.
• käyttötapaukset: käyttötapaukset voivat auttaa määrittelemään järjestelmän käyttäytymistä ja viestimään loppukäyttäjän näkökulmasta.
• User stories: User stories keskittyy käyttäjien tarpeisiin eikä ominaisuuksiin, joita järjestelmän tulisi tarjota.

mitä haasteita hankkeen vaatimusten määrittelyssä on?

hankkeen vaatimusten määrittelyssä on odotettavissa joitakin yhteisiä haasteita. Osa näistä on:

sidosryhmät eivät tiedä mitä haluavat

vaatimusanalyysin suurin haaste on se, että asiakkailla on usein epämääräinen käsitys siitä, mitä he haluavat. Jotkut asiakkaat voivat tietää, mutta kamppailevat kommunikoida sitä, joten se on jopa voit kysyä oikeita kysymyksiä kaapata heidän tarpeitaan.

vaatimukset ovat usein dynaamisia

toinen vaatimusanalyysin haaste on vaatimusten muuttuva luonne. Projektin alussa määritellyt odotukset voivat muuttua projektin edetessä. Liiketoimintasuuntaukset voivat vaikuttaa lähtötilanteisiin, mikä edellyttää kokonaan uutta ratkaisua. Varasuunnitelmat ja muutoksenhallintaprosessit käytössä odottamattomien muutosten torjumiseksi.

huono viestintä ryhmien välillä

johtuen teknisestä asiantuntemuksesta projektipäälliköiden, insinöörien ja Käyttäjien välillä, nämä sidosryhmät eivät välttämättä aina ole samaa mieltä. Sinun tehtäväsi projektipäällikkönä on toimia välittäjänä ja viestijänä kaikkien osapuolten välillä.

kehitystiimi on tietämätön organisaation politiikasta

kehitystiimit ovat usein tietämättömiä järjestöpolitiikasta, erityisesti suurissa yrityksissä, joissa on poikkitoimintaisia tiimejä. Jos tätä ei valvota, se voi aiheuttaa väärinymmärrystä, tavoitteiden asettamista väärin ja hankkeen epäonnistumista.

mikä on vaatimusten analysointiprosessi?

alla oleva viisivaiheinen prosessi on tärkeä hankkeen vaatimusten selvittämisessä.

tee sidosryhmäanalyysi

selvittääksesi hankkeen vaatimukset, luetteloidaksesi keskeiset sidosryhmät hankkeen rahoittajasta loppukäyttäjiin ja projektiryhmään.

selkeä kuva siitä, kenellä on sananvaltaa hankkeessa, asettaa sinut oikealle tielle kerätä ja järjestää heidän odotuksensa ennen varsinaista tarveanalyysiä. Kun olet tunnistanut keskeiset sidosryhmät, voit ryhmitellä ne sen mukaan, kuinka suuri vaikutusvalta ja kiinnostus heillä on projektisi onnistumiseen tai epäonnistumiseen.

• suurvalta, erittäin kiinnostunut: hallitsee tarkasti tämän tason sidosryhmien odotukset. Heidän vaatimuksensa pitäisi olla etusijalla. Asiakkaat, projektin sponsorit ja loppukäyttäjät kuuluvat tähän kategoriaan. Tarkkaile myös heidän lähimpiä vaikuttajiaan.
• suuritehoiset, vähemmän kiinnostuneet: näillä sidosryhmillä on merkittävä osuus projektissasi, mutta he eivät ole siitä innostuneita. Ponnistele kovasti pitääksesi heidät tyytyväisinä ja ylläpitääksesi heidän kiinnostustaan.
• low power, erittäin kiinnostunut: vaikka näillä sidosryhmillä ei ole merkittävää osuutta hankkeessasi, pidä heidät ajan tasalla ja kommunikoi säännöllisesti, jotta ongelmia ei synny.
• low power, less interested: näillä sidosryhmillä on vain vähän kiinnostusta ja panosta hankkeeseesi. Pidä heidät ajan tasalla ja pidä yllä suhdettasi heihin, mutta älä häiritse heitä liiallisella kommunikaatiolla.

pane merkille kunkin sidosryhmän vaatimukset

kun olet yksilöinyt ja luokitellut hankkeen sidosryhmät, kysy heiltä heidän odotuksiaan. Mitä he haluavat tästä tuotteesta? Mikä on niiden odotettu tulos?

sidosryhmien kanssa keskusteltaessa on säilytettävä avoimuus, selvennettävä hankkeen soveltamisalaa ja mahdollisia soveltamisalan aukkoja sekä kontekstualisoitava keskustelut. Jos et tee niin, sidosryhmät voivat asettaa epärealistisia projektivaatimuksia, mikä johtaa pettymykseen, jos et toteuta heidän toivomiaan toimintoja projektissa.

on tärkeää ymmärtää kunkin sidosryhmän oma näkökulma, jotta projektisi tavoitteista saadaan selkeämpi kuva. Tässä muutamia vaatimuksia analysointitekniikoita, jotka auttavat huomioimaan sidosryhmien vaatimukset:

• isännöi yksittäisiä haastatteluja: Keskustele kunkin sidosryhmän kanssa yksilöllisesti ymmärtääksesi heidän erityistarpeensa ja näkemyksensä.
• tee ryhmähaastatteluja: pidä haastattelutunteja, joissa on mukana erityisiä sidosryhmiä. Näiden istuntojen avulla voit muodostaa tiedon päällekkäisyyttä, joka yhdistää eri Ryhmän odotuksia.
• käytä käyttötapauksia: käyttötapaukset ovat skenaariopohjaisia tekniikoita, jotka opastavat sinua järjestelmän, ohjelmiston tai palvelun toiminnallisuuden läpi.
• Rakenna mallikuvia: prototyypit antavat käyttäjille käsityksen valmiista tuotteesta, mikä helpottaa tuoteaukkojen ja käyttäjien tyytymättömyyden havaitsemista ennen julkaisua.

Ryhmävaatimukset

vaatimusten yksilöimisen jälkeen ryhmitellään ne johonkin näistä neljästä ryhmästä:

• tekniset vaatimukset: tekniset ongelmat, jotka sinun on ratkaistava saadaksesi projektin onnistuneesti päätökseen
• operatiiviset vaatimukset: tarvittavat toiminnot, jotka pitävät projektin käynnissä tietyn ajan
• toiminnalliset vaatimukset: Toiminnalliset vaatimukset, joita projektillasi on oltava, jotta niitä voidaan pitää täydellisinä tai onnistuneina

selventää ja tallentaa vaatimukset

nyt on aika määrittää kunkin vaatimuksen toteutettavuus ja se, miten projekti voi toteuttaa ne. Tämän saavuttamiseksi sinun täytyy:

• Määrittele vaatimukset selkeästi, riittävän yksityiskohtaisesti ja asiaankuuluvasti.
• Sijoitusvaatimukset niiden merkityksen mukaan. Sinun täytyy priorisoida vaatimukset, koska budjetit ovat usein rajalliset. Listaa kriittisimmät tarpeet edellä ”nice-to-haves.”
• selvitä ristiriitaiset vaatimukset keskustelemalla niistä keskeisten sidosryhmien kanssa. Tämä on arvokkain askel vaatimusten analysoinnissa. Sen avulla osapuolet voivat tutkia useita mahdollisuuksia hankkeen lopputulokseen ja sopia parhaasta tavoiteltavasta.
• tutki toteutettavuutta. Suorita yksityiskohtainen analyysi uuden tuotteen tai järjestelmän mahdollisesta luotettavuudesta ja käytettävyydestä. Analyysissä tunnistetaan harmaita alueita ja mahdollisia ongelmia. Kirjaa Keskeiset havaintosi kirjalliseen asiakirjaan ja jaa ne sitten aiemmin tunnistetuille sidosryhmille.

Hanki allekirjoitettu sopimus

ei riitä, että vaatimuksista sovitaan suullisesti. Hanki ne kirjallisina ja hanki avainosapuolten allekirjoittama asiakirja, jossa vahvistetaan, että esitetyt vaatimukset vastaavat tarkasti niiden tarpeita. Tämä vaatimusanalyysiasiakirja, joka tunnetaan ohjelmistotekniikassa nimellä Software Requirements Specifications (SRS), estää scope creep-ongelmien todennäköisyyden.

Requirement analysis document example

your requirement analysis document (RAD) can include text and visual diagramms. Se voi toimia sopimuksena sinun ja asiakkaidesi välillä, ja se tulisi kirjoittaa kielellä, jota sidosryhmät voivat ymmärtää. Tärkeitä osia vaatimusanalyysiasiakirjasta ovat:

• tarkoitus
• yleisö
• toiminnalliset vaatimukset
• tekniset vaatimukset

tässä vaatimusanalyysi asiakirja esimerkki Florida State University inspire omasi.

Miksi käyttää Wrikeä vaatimusanalyysityökaluna?

onnistunut hanke täyttää kaikki sidosryhmien odotukset. Wriken kaltaiset tehokkaat projektinhallintatyökalut helpottavat vaatimusten keräämistä keskeisiltä sidosryhmiltä, tarjoavat näkyvyyttä vaatimusten analysointiin ja projektisuunnitteluun sekä analysoivat projektivaatimuksia keskitetyssä paikassa ja työtilassa.

Oletko valmis saavuttamaan hankkeen tavoitteet ajoissa ja budjetissa samalla kun täytät sidosryhmien odotukset? Aloita ilmainen kahden viikon kokeiluversio Wriken projektinhallintaohjelmistosta.