vaatimukset asiakirja esimerkkejä Inspiroidaksesi

kun on kyse toiminnallisia vaatimuksia koskevan asiakirjan kehittämisestä, tärkeintä on välittää selkeästi ja kattavasti projektin vaatimukset ja muut asiaankuuluvat tiedot kehitystiimille. Itse asiassa top requirements-dokumenteilla on kaikilla jotain yhteistä, eli ne kaikki tarjoavat projektipäälliköille riittävästi tilaa viestiä liiketoiminnan tarpeista ja projektin laajuudesta.

tästä huolimatta voi olla vaikea määrittää, miltä tällainen määrittelyasiakirja näyttää ja pystytkö todella luomaan vaatimukset-dokumenttimallin, joka toimii yhtä hyvin sinulle.

tässä artikkelissa annan joitakin parhaita tuotevaatimuksia koskevan asiakirjan esimerkkejä vuodelle 2020 sekä oppaan siitä, miten voit luoda sellaisen tuotteellesi.

aloitetaan.

mikä on Tuotevaatimusasiakirja

Tuotevaatimusasiakirja on yhteenveto tärkeimmistä vaatimuksista, joita yrityksellä on tuotteeltaan.

tuotepäälliköiden laatima asiakirja kehittäjien ja sidosryhmien kanssa käytyjen laajojen keskustelujen ja yksityiskohtaisen asiakasanalyysin jälkeen.

PRD eroaa Business Requirements Documentista (BRD), Functional Requirements Document (FRD) ja Software Requirements Specification (SRS) siinä, että se keskittyy enemmän tuotteen erityisvaatimuksiin sen sijaan, miksi yritys haluaa tuotteen olevan olemassa ja miltä lopputuotteen pitäisi näyttää.

tyypillinen PRD sisältää ohjelmistotuotteen perustarkoituksen, tuotteen ehdotetut ominaisuudet, julkaisuvalmiuskriteerit, aiotun käyttäjävirran ja käyttöliittymän suunnittelun sekä mahdolliset johtopäätökset, oletukset, riippuvuudet ja tulevat työt.

yrityksen koosta ja päällekkäisten tuotteiden määrästä riippuen PRD: n koko voi vaihdella yhden sivun asiakirjasta useasta sivusta koostuvaan asiakirjaan, joka sisältää interaktiivisia elementtejä.

5 Top Requirements Documents Examples

olitpa sitten luomassa dokumenttia ohjelmistokehityksen ohjenuoraksi tai vain välittämään tuotteen teknisiä vaatimuksia, nämä esimerkit auttavat sinua saamaan tiedot perille.

tässä ovat x parhaat PRD-esimerkit, jotka olen löytänyt vuonna 2020.

1. Atlassian

Atlassian product document template tarjoaa vakaan ja ketterän alustan kaikille lanseerausta edeltäville tuotevalmisteluillesi sekä käyttöönoton jälkeisille käytettävyysmittarianalyyseille.

se on yksinkertainen malli, jossa on vielä kaikki tarvittavat osiot kaikkien suoritteiden perusteelliseen kuvaukseen sekä tilaa loppukäyttäjälähtöisille tuoteoletuksille.

parasta Atlassian-mallissa on se, että se noudattaa ketterää metodologiaa ja tarjoaa silti tukea perinteisille ympäristöille. Tämän lisäksi projektipäälliköt voivat toimia siltana sidosryhmien ja kehittäjien välillä koko tuotteen elinkaaren ajan.

Atlassianin PRD-mallin etuja ovat:

• ohjeet ja esimerkit jokaiselle osiolle, joiden avulla esimiehet voivat lisätä oikeat tiedot
• puhdas, tavallinen asiakirja, jossa on vähän häiriötekijöitä
• Interaktiiviset työpisteet, grafiikat, vuokaaviot ja tietolomakkeet
• saumaton linkitys Jiran tehtäviin/kysymyksiin, Google-dokumentteihin ja erilaisiin liitännäisiin

lisäksi Atlassian tarjoaa koko joukon lisäarvoa tuottavia toimintoja tuotepäälliköille.

ladata mallin käy Atlassian.

1. Slite

Slite tarjoaa puhtaan ja tiiviin tuotevaatimusmallin, jossa on tilaa kaikille tarvittaville tiedoille, mutta joka on riittävän suora, jotta se ei ole pitkäveteinen.

malli on suunniteltu keskittymään käyttäjien tarinoihin toiminnallisten ja ei-toiminnallisten vaatimusten sijaan, ja se sopii ketterille tiimeille, joilla on virtaviivaiset liiketoimintaprosessit.

Slite-mallin erottaa muusta se, että keskitytään ketterään työnkulkuun ja pyritään siirtymään pois tarpeettomista yksityiskohdista, joilla ei olisi lopputuotteen kannalta juuri mitään merkitystä. Koska ketterät ympäristöt keskittyvät enemmän käyttötapauksiin ja käyttäjätarinoihin, ne tarvitsevat dokumentteja, jotka heijastavat heidän tiimirakennettaan.

tässä on joitakin Slite PRD-mallin etuja:

• kyky rajata PRD yhdelle sivulle, tarvittaessa
• tilaa kuvata tuotteen tausta ja miksi omistajan mielestä tuotteen pitäisi olla olemassa
• virtuaalinen tiekartta, jota kehitystiimi voi käyttää kehitysoppaana
• tilaa runsaasti tarkistuksia, muutoksia ja uutta tietoa (laajenevilla vaatimuksilla

näiden lisäksi Slite product requirements document template muistuttaa wireframe-dokumenttia, jossa on tilaa kaikille tarvittaville tiedoille ihanteellisessa järjestyksessä.

ladataksesi Slite-mallin, käy Slite-sivustolla.

1. Aha!

Aha PRD-malli on yksi suorimmista ja ytimekkäimmistä asiakirjapohjista, joita voit löytää tuotteen tarpeisiin.

tämä johtuu siitä, että on keskitytty tarjoamaan vaihtoehto tuote-/projektinhallintaohjelmistoille, joita useimmat ketterät yritykset käyttävät nyt keskustellakseen tuotteiden vaatimuksista reaaliaikaisesti asiakirjojen korvaajana.

AHA-mallin parasta antia on se, että jos olet uusi tuotepäällikkö tai jos tämä on yrityksesi ensimmäinen tuote ja tarvitset ohjeita siitä, miten tällaista dokumenttia käytetään, sivustolta löytyy täydelliset ohjeet sen tehokkaaseen käyttöön.

joitakin AHA PRD-mallin etuja ovat:

• keskittyminen dokumentointiprosessin virtaviivaistamiseen ensikertalaisille
• tilaa koota kaikki tarvittavat tiedot (ja vain tarvittavat tiedot) yhteen paikkaan
• Mallirakenne, joka sopii yhteistyöhön ilman tuotehallintaohjelmistoa
• Useita asiakirjamuotoja (MSWord ja PDF))

on tärkeää huomata, että jotkut tuoteosastot eivät välttämättä löydä AHA-mallia tarpeeksi kattavaksi tuotteidensa tarpeisiin, koska se on suunniteltu enemmän ennalta ketterille yrityksille.

jos haluat ladata AHA PRD-mallin, käy osoitteessa Aha.

1. Product First

Product First requirements-malli on suunniteltu joustavasti, sillä sen avulla minkä kokoiset ja laajuiset yritykset voivat ilmoittaa vaatimuksistaan kehittäjille.

saatavana sekä tavallisena että “Lite” – versiona, tuotteen ensimmäinen malli antaa sinun käyttää siinä annettuja osioita, poistaa ne, jotka eivät kelpaa tuotteellesi tai lisätä omia mukautettuja osioita tuotteen tarpeiden mukaan.

parasta tuotteen ensimmäisessä PRD-mallissa on selkeät käyttöohjeet sekä verkkosivustolla että itse mallissa. Jos olet uusi tuotehallinta, se on ihanteellinen lähtökohta. Lisäksi, se toimii loistava luuranko asiakirja luoda oman PRD malli.

tuotteen ensimmäiset PRD-mallit ovat:

• joustava asiakirjaliittymä, jonka osiot voidaan lisätä tai poistaa tuotetarpeiden mukaan
• tuotepäällikön suunnittelema, tuotepäälliköille
• ihanteellinen monenlaisille ohjelmistotuotteille
• riippumaton osio ulkoisille resursseille ja linkit tyylioppaisiin, kehittäjien kieliversioon, API-riippuvuuksiin, vastaaviin tuotekampanjoihin jne.

Google Doc-linkin avulla useat ihmiset voivat tehdä dokumenttia reaaliajassa. Tämä on erittäin hyödyllinen ominaisuus, Jos sinulla on jo useita Google-laajennuksia tai Google-pohjainen asiakirjanhallintakangas.

mallin lataamiseksi käy ensin tuotteessa.

1. ShipIt

ShipIt PRD-malli on suunniteltu Google-pohjaista yhteistyötä silmällä pitäen. Koko asiakirja on saatavilla virtuaalisesti Google Docs ja voidaan muokata reaaliajassa useita ihmisiä.

sisäänrakennettu yksinkertainen Google Doc-muoto, mallissa on erilliset tilat yrityksen liiketoimintamallille ja yksittäisille käyttäjäpersoonille.

parasta ShipIt-mallissa on sen keskittyminen täydelliseen tuotehallintaan. Yhtiö tarjoaa täyden valikoiman palveluja yrityksille, jotka haluavat päivittää yksittäinen malli Täydellinen luettelo tuotehallintaominaisuuksia, ja että liian edulliseen hintaan. Lisäarvotyökalut hyödyntävät samaa mallia.

ShipIt-mallin käytön tärkeimmät edut ovat:

• erittäin yksinkertainen dokumenttiformaatti, joka sopii henkilölle, joka on uusi yksityiskohtaisessa dokumentaatiossa
• tilaa toiminnallisille ja ei-toiminnallisille sekä markkinointivaatimuksille
• ilmainen ja helppokäyttöinen malli kaiken kaikkiaan.
• laaja palveluvalikoima on demand, 4 viikon ilmainen kokeiluversio

edellä mainittujen lisäksi ShipIt-malli tarjoaa selvät ääriviivat Google-dokumentin kyljessä. Tuotepäälliköt voivat käyttää tätä osioiden lisäämiseen tai poistamiseen tai jopa käyttää mallirakennetta Oman dokumenttinsa luomiseen.

mallin voi ladata shipitistä.

vahvan Vaatimusdokumentin kirjoittaminen vuonna 2020

käytätpä valmista mallia tai luot tuotteellesi Oman, dokumenttisi tärkeintä on sisältö ja se, miten tiedotat vaatimuksista.

Kaikki tämän artikkelin mallit tarjoavat jonkintasoisia ohjeita siitä, miten asiakirja täytetään vaadituilla tiedoilla.

vahvan PRD: n luomiseksi vuonna 2020 sinun on kuitenkin tiedettävä liiketoimintasi tavoitteet keskipitkällä ja pitkällä aikavälillä sekä se vaikutus, jonka haluat tuotteella olevan toimialallaan.

tässä Vinkkejä yksityiskohtaisen ja tehokkaan tuotevaatimusdokumentin kirjoittamiseen vuonna 2020.

Suorita laaja Asiakasanalyysi

loppukäyttäjä on tärkein tekijä kaikissa ohjelmistokehityksen puitteissa. Tämä johtuu niiden tärkeydestä yhtiölle tulonlähteenä sekä hyvien ja huonojen tuotteiden erottavasta tekijästä.

loppukäyttäjien tarpeiden ja toiveiden analysointi johtaa myös siihen, että yritykset valmistavat tuotteita, jotka suoraan ratkaisevat käyttäjien ongelmia sen sijaan, että ne toimisivat yksinkertaisina tulonrakentajina. Käyttäjien kipupisteisiin puuttuminen on myös paras tapa herättää luottamusta tuotteeseesi ja tehdä käyttäjistä brändisi elinikäisiä seuraajia.

voit käyttää monia työkaluja ja tekniikoita kerätäksesi tarvittavat tiedot loppukäyttäjiltäsi. Näitä ovat kyselylomakkeet, prototyyppien, kilpailijoiden tuotteiden käyttötapaukset, historialliset käyttötapaukset ja käyttäjien tarinat.

Määrittele selkeästi tuotteen käyttötarkoitus

tuotteen käyttötarkoitus ei välttämättä tunnu kehittäjille vaaditulta tietojoukolta. Se on kuitenkin yksi koko prosessin tärkeimmistä osa-alueista, koska se auttaa suuntaamaan koko kehitys -, toiminta-ja hallintarakenteen yhteen visioon.

on suositeltavaa, että jo ennen kuin aloitat kirjoittamisen, varmista selvästi, miksi loppukäyttäjät tarvitsevat tuotetta. Tämä auttaa vakuuttamaan sidosryhmät siitä, että tuote on hyvä investointi.

lisäksi se auttaa kehittäjiä ymmärtämään tuotteen käyttöön liittyviä vaatimuksia ilmoittamalla heille tyypilliset käyttäjän kipupisteet samankaltaisten tuotteiden kanssa.

tavoitteen määrittelyn yhteydessä on varmistettava, että kaikki asianomaiset sidosryhmät ovat siitä yhtä mieltä. Voit jakaa alustavan asiakirjan sidosryhmien kesken vahvistaaksesi tämän.

Käännä tuotteen käyttötarkoitus ominaisuuksiksi

heti seuraava vaihe tuotteen käyttötarkoituksen määrittelyn jälkeen on jakaa tämä Käyttötarkoitus aktiivisiksi tuoteominaisuuksiksi, joita loppukäyttäjät hyödyntävät.

tämä on erinomainen tapa sovittaa tuotteen käyttötarkoitus todelliseen käytettävyyteen ja antaa käyttäjille suora ratkaisu heidän ongelmiinsa. Lisäksi, se on myös hyvä ohje, miten kukin ominaisuus olisi rakennettava, sekä aloitteita ja teemoja ominaisuuksia olisi perustuttava.

johonkin ominaisuusteemaan keskittyminen kehottaa kehittäjiä sovittamaan kaikki tuotteen osa-alueet kyseisen teeman mukaisesti, mikä lisää käytettävyyttä kyseisellä linjalla. Kun teemat on määritelty, ne auttavat sinua muuttamaan tarkoituksesi saumattomasti ominaisuuksiksi.

aseta realistiset julkaisukriteerit

yksi suurimmista virheistä, joita yritykset tekevät, on kiirehtiä tuotteen julkaisua ottamatta huomioon yksityiskohtia, kuten asiakaskysyntää kyseisenä ajankohtana, tuotteen valmiutta ja käytettävyyttä reaaliajassa.

riippumatta siitä, kuinka hyvä tuotteesi on, Varmista aina, että julkaisukriteereihin lisätään irtisanomisia ja että käytettävyysmatriisissa on mahdollisimman paljon virheitä ennen julkaisua.

voit tehdä tämän analysoimalla kilpailevien tuotteiden käyttötapauksia ja selvittämällä, miten niiden tuotteet toimivat, kun ne julkaistaan joko ideaalia aikaisemmin tai irtisanomisilla.

varmista lopuksi, että julkaisutavoitteesi ovat toteutettavissa, saavutettavissa ja mitattavissa pitkällä ja lyhyellä aikavälillä, samalla kun ne ovat helposti ymmärrettävissä kaikille kehitystyössä mukana oleville.

Aseta realistinen julkaisuaikataulu

Julkaisupäivä antaa kehittäjille ja johtohenkilöille tavoitteen, johon pyrkiä. Vaikka se ei ole tärkeä tekijä hyvä tuote, on tärkeää varmistaa, että kukaan menettää keskittyä tavoite, joka on tuotteen tarkoitus.

julkaisupäivän ei tarvitse olla tarkka, ja voit asettaa karkean arvion kehittäjien antaman kehitysaikajanan perusteella. Kuitenkin, on tärkeää olla realistinen, vaikka alustava päivämäärä.

muista myös edellinen kohta siitä, ettei tuotteen julkaisua kiirehditä aikajanaa määritettäessä.

Hanki sidosryhmien hyväksyntä

tuote, joka saa hyväksynnän kaikilta sidosryhmiltä, merkitsee jotain, johon koko yhtiö uskoo ja johon se luottaa markkinamenestyksen kannalta.

tämä on erityisen tärkeää ylemmille sidosryhmille, jotka voivat rahoittaa tuotetta tai antaa lopullisen hyväksynnän.

varmista, että kaikki ovat samaa mieltä tuotteesta, sen tarkoituksesta, ominaisuuksista ja pitkäaikaisesta vaikutuksesta, käy laajoja keskusteluja ja aivoriihiä kaikkien osapuolten kanssa. Ylimmän johdon tapauksessa voit pitää konferenssin, jossa voit kertoa tuotteesta.

tämä voi tuntua ylimääräiseltä askelvoitolta, jos PRD: tä rakennetaan, se tarkoittaa automaattisesti, että kaikki ovat hyväksyneet sen. Kuitenkin, se ei haittaa saada luottamusta kaikkien sidosryhmien tuleviin hankkeisiin samoin.

Loppuhuomautus

kuten aiemmin mainittiin, tämä on ketterän tiimin aikakausi, joka käyttää erilaisia yhteistyöohjelmistoja saadakseen ideansa perille ilman yksityiskohtaista dokumentointia.

kaikilla yrityksillä ei kuitenkaan ole käytössään vakaata ketterää arkkitehtuuria, ja monet joutuvat tyytymään perinteiseen Vesiputousympäristöön etenkin tuotekehitysmatkansa varhaisemmissa vaiheissa.

jos yrityksesi on yksi näistä asiakirjapohjista, voit hyötyä valtavasti näistä asiakirjapohjista, samalla kun parannat yhteistyötapojasi ja kehität niitä.

Metakuvaus: