követelmények dokumentum példák inspirálni

amikor a fejlődő funkcionális követelmények dokumentum, a legfontosabb az, hogy világosan és átfogóan kommunikálni projekt követelmények és egyéb releváns információkat a fejlesztőcsapat. Valójában a legfontosabb követelménydokumentumok példáinak mindegyikében van valami közös, azaz mindegyik elegendő teret biztosít a projektmenedzsereknek az üzleti igények és a projekt hatókörének kommunikálásához.

ennek ellenére nehéz lehet meghatározni, hogy néz ki egy ilyen specifikációs dokumentum, és hogy valóban létrehozhat-e olyan követelménydokumentum-sablont, amely ugyanolyan jól működik az Ön számára.

ebben a cikkben bemutatom a 2020-ra vonatkozó legjobb termékkövetelmény-dokumentum-példákat, valamint egy útmutatót arról, hogyan hozhat létre egyet a termékéhez.

kezdjük.

mi a Termékkövetelmény-dokumentum

a Termékkövetelmény-dokumentum a vállalat termékével szemben támasztott legfontosabb követelmények vázlata.

a termékmenedzserek által a fejlesztőkkel és az érdekelt felekkel folytatott széles körű megbeszélések és a részletes ügyfélelemzés után létrehozott dokumentum.

a PRD különbözik a Business Requirements Document (BRD), a Functional Requirements Document (Frd) és a Software Requirements Specification (SRS) dokumentumoktól, mivel inkább a termék konkrét követelményeire összpontosít, nem pedig arra, hogy miért akarja a vállalkozás a terméket létezni, és hogyan kell kinéznie a végterméknek.

egy tipikus PRD tartalmazza a szoftvertermék alapvető célját, a termék javasolt funkcióit, a kiadási készségi kritériumokat, a tervezett felhasználói folyamatot és a felhasználói felület kialakítását, valamint minden záró betekintést, feltételezést, függőséget és jövőbeli munkát.

a vállalat méretétől és az átfedő termékek számától függően a PRD mérete változhat, az egyoldalas dokumentumtól a több oldalból álló, interaktív elemeket tartalmazó DOKUMENTUMIG.

5 legfontosabb követelmények dokumentumok példák

akár szoftverfejlesztési iránymutatásként szolgáló dokumentumot hoz létre, akár csak egy termék műszaki követelményeinek közlésére szolgál, ezek a példák segítenek a specifikációk áttekintésében.

itt vannak az X legjobb PRD példák, amelyeket 2020-ban találtam.

1. Atlassian

az Atlassian termékdokumentumsablon stabil és agilis platformot biztosít az összes bevezetés előtti termék előkészítéséhez, valamint az indítás utáni használhatósági mutatók elemzéséhez.

ez egy leegyszerűsített sablon, amely még mindig tartalmazza az összes szükséges részt az összes teljesítés alapos leírásához, valamint helyet biztosít a végfelhasználó alapú termékfeltevésekhez.

az Atlassian sablonban az a legjobb, hogy betartja az agilis módszertant, miközben továbbra is támogatja a hagyományos környezeteket. Ezen felül lehetővé teszi a projektmenedzsment vezetők számára, hogy hídként működjenek az érdekeltek és a fejlesztők között azáltal, hogy szakaszokkal rendelkeznek a termék teljes életciklusára vonatkozóan.

az Atlassian PRD sablon előnyei a következők:

• utasítások és példák az egyes szakaszokhoz, amelyek segítenek a vezetőknek a megfelelő információk beillesztésében
• tiszta, sallangmentes dokumentum minimális zavaró tényezőkkel
• interaktív munkafolyamatok, grafikák, folyamatábrák és adatlapok
• zökkenőmentes linkelés a Jira feladatokhoz/kiadásokhoz, a Google Dokumentumokhoz és a különféle bővítményekhez

az Atlassian emellett számos értéknövelt funkciót kínál a termékmenedzserek számára.

a sablon letöltéséhez látogasson el az Atlassian oldalra.

1. Slite

a Slite egy tiszta és tömör termékkövetelmény-sablont kínál, amely helyet biztosít az összes szükséges adat számára, de elég közvetlen ahhoz, hogy ne legyen hosszú.

úgy tervezték, hogy a funkcionális és nem funkcionális követelmények helyett a felhasználói történetekre összpontosítson, a sablon ideális az agilis csapatok számára, amelyek egyszerűsített üzleti folyamatokkal rendelkeznek.

ami elválasztja a Slite sablont a többitől, az az agilis munkafolyamatra való összpontosítás és a redundáns részletektől való elmozdulás kísérlete, amelyeknek a végtermék szempontjából alig vagy egyáltalán nem lenne jelentősége. Mivel az agilis környezetek inkább a használati esetekre és a felhasználói történetekre összpontosítanak, olyan dokumentumokra van szükségük, amelyek tükrözik a csapat szövetét.

a Slite PRD sablon néhány előnye:

• az a képesség, hogy korlátozza a PRD, hogy egy oldal, ha szükséges
• tér leírására termék hátterét, és miért a tulajdonosok úgy vélik, a termék létezik
• a virtuális útitervet, amely a fejlesztőcsapat használhatja, mint egy fejlesztési útmutató
• hely rengeteg felülvizsgálatok, módosítások, és az új adatok (bővülő követelmények

ezek mellett a Slite termékkövetelmények dokumentumsablon hasonlít egy drótvázas dokumentumra, amely ideális sorrendben helyet biztosít az összes szükséges adat számára.

a Slite sablon letöltéséhez látogasson el a Slite oldalra.

1. Aha!

az Aha PRD sablon az egyik legközvetlenebb és tömörebb dokumentumsablon, amelyet a termék igényeihez talál.

ez annak köszönhető, hogy a termék/projekt menedzsment szoftver alternatívájának biztosítására összpontosít, amelyet a legtöbb agilis vállalat jelenleg a termékkövetelmények valós idejű megvitatására használ, a dokumentumok helyettesítésére.

az Aha sablonban az a legjobb, hogy ha új termékmenedzser vagy, vagy ha ez a vállalat első terméke, és szüksége van néhány útmutatásra egy ilyen dokumentum használatához, a webhely teljes körű utasításokat tartalmaz arra vonatkozóan, hogyan kell ezt hatékonyan megtenni.

az Aha PRD sablon néhány előnye a következő:

• a hangsúly a dokumentációs folyamat egyszerűsítésére az első felhasználók számára
• hely az összes szükséges követelmény egységesítéséhez adatok (és csak a szükséges adatok) egy helyen
• Sablonszerkezet, amely ideális az együttműködéshez termékkezelő szoftver hiányában
• több dokumentumformátum (MSWord és PDF)

fontos megjegyezni, hogy egyes termékosztályok nem találják elég átfogónak az Aha sablont a termékigényeikhez, mivel inkább az agilis előtti vállalatok számára tervezték.

az Aha PRD sablon letöltéséhez látogasson el az Aha oldalra.

1. Product First

a Product First követelmények sablont a rugalmasság szem előtt tartásával tervezték, mivel lehetővé teszi bármilyen méretű és termékkörű vállalatok számára, hogy közöljék követelményeiket a fejlesztőkkel.

mind a rendszeres, mind a ‘Lite’ verzióban elérhető, a termék első sablonja lehetővé teszi, hogy kihasználja a benne szereplő szakaszokat, törölje azokat, amelyek nem érvényesek a termékére, vagy helyezze be saját egyéni szakaszait a termék igényeinek megfelelően.

a legjobb dolog a termék első PRD sablonjában az egyértelmű használati utasítás mind a weboldalon, mind maga a sablon. Ha új vagy a termékmenedzsmentben, ez az ideális kiindulási pont. Ezenkívül ragyogó csontváz dokumentumként fog szolgálni, amelyen saját PRD sablont hozhat létre.

a termék elsődleges előnyei az első PRD sablonok:

• rugalmas dokumentum interfész olyan szakaszokkal, amelyek hozzáadhatók vagy törölhetők a termékkövetelményeknek megfelelően
• termékmenedzserek számára
• ideális a legkülönbözőbb szoftvertermékekhez
• független szakasz külső erőforrásokhoz és stílus útmutatókhoz, fejlesztői nyelvi verzióhoz, API-függőségekhez, hasonló termékkampányokhoz stb.

a Google Doc link lehetővé teszi, hogy több ember valós időben működjön együtt a dokumentumon. Ez egy nagyon hasznos funkció, ha már rendelkezik több Google-bővítménnyel vagy Google-alapú dokumentumkezelő anyaggal.

a sablon letöltéséhez először keresse fel a terméket.

1. ShipIt

a ShipIt PRD sablon a Google-alapú együttműködést szem előtt tartva készült. A teljes dokumentum gyakorlatilag elérhető a Google Dokumentumokban, és valós időben több ember is módosíthatja.

beépített egyszerű Google Doc formátum, a sablon külön tereket tartalmaz a vállalat üzleti modelljéhez és az egyes felhasználói személyekhez.

a ShipIt sablonban az a legjobb, hogy a teljes termékkezelésre összpontosít. A vállalat teljes körű szolgáltatást kínál azoknak a vállalatoknak, amelyek egy egyedi sablonról a termékmenedzsment funkciók teljes listájára kívánnak frissíteni, megfizethető áron. Az értéknövelt eszközök ugyanazt a sablont használják.

a shipit sablon használatának fő előnyei a következők:

• rendkívül egyszerű dokumentumformátum, amely ideális azok számára, akik újak a részletes dokumentációban
• hely funkcionális és nem funkcionális, valamint marketing követelmények
• egy ingyenes és könnyen használható sablon összességében.
• széles körű szolgáltatások igény szerint, 4 hetes ingyenes próbaverzióval

a fentieken kívül a ShipIt sablon világos vázlatot kínál a Google Doc oldalán. A termékkezelők ezt használhatják szakaszok hozzáadásához vagy törléséhez, vagy akár a sablonszerkezetet is használhatják saját dokumentumuk létrehozásához.

a sablon letöltéséhez látogasson el a ShipIt oldalra.

strong Requirements dokumentum írása 2020-ban

akár kész sablont használ, akár saját terméket hoz létre a termékéhez, a dokumentum legfontosabb szempontja a tartalom és a követelmények kommunikálásának módja.

az ebben a cikkben szereplő sablonok bizonyos szintű útmutatást nyújtanak a dokumentum kitöltéséhez a szükséges adatokkal.

Ahhoz azonban, hogy 2020-ban erős PRD-t hozzon létre, tudnia kell, hogy mik az üzleti céljai közép-és hosszú távon, valamint azt, hogy milyen hatást kíván elérni a termék az iparban.

Íme néhány tipp a részletes és hatékony termékkövetelmény-dokumentum megírásához 2020-ban.

végezzen átfogó Ügyfélelemzést

a végfelhasználó a legfontosabb tényező bármely szoftverfejlesztési keretben. Ez azért van, mert fontosak a vállalat számára, mint bevételi forrás, és megkülönböztetik a jó és a rossz termékeket.

a végfelhasználók igényeinek és szükségleteinek elemzése arra készteti a vállalatokat, hogy olyan termékeket állítsanak elő, amelyek közvetlenül megoldják a felhasználók problémáit, ahelyett, hogy egyszerű bevételépítőként szolgálnának. A felhasználók fájdalompontjainak kezelése szintén a legjobb módja annak, hogy bizalmat keltsen a termékében, és a felhasználókat a márka egész életen át tartó követőivé tegye.

számos eszközt és technikát használhat a szükséges adatok összegyűjtésére a végfelhasználóktól. Ezek közé tartoznak a kérdőívek, a prototípusok, a versenytársak termékhasználati esetei, a történelmi használati esetek és a felhasználói történetek.

egyértelműen határozza meg a termék célját

a termék célja nem feltétlenül szükséges adatkészlet a fejlesztők számára. Ez azonban az egész folyamat egyik legfontosabb szempontja, mivel segít összehangolni a teljes fejlesztési, működési és irányítási szövetet egy vízióhoz.

javasoljuk, hogy még az írás megkezdése előtt győződjön meg róla, hogy világosan megérti, miért van szüksége a végfelhasználóknak a termékre. Ez segít meggyőzni az érdekelt feleket arról, hogy a termék jó befektetés.

ezenkívül segít a fejlesztőknek megérteni a termék használatával kapcsolatos követelményeket azáltal, hogy tájékoztatja őket a hasonló termékekkel kapcsolatos tipikus felhasználói fájdalompontokról.

a cél meghatározásakor győződjön meg arról, hogy az összes érintett fél egyetért abban. Az előzetes dokumentumot az érdekeltek között terjesztheti annak megerősítésére.

kapcsolja be a termék célját funkciókká

a termék céljának meghatározása után a következő lépés az, hogy ezt a célt aktív termékjellemzőkre bontja, amelyeket a végfelhasználók használni fognak.

ez egy nagyszerű módja annak, hogy összehangolja a termék célját a tényleges használhatósággal, és közvetlen megoldást nyújtson a felhasználóknak a problémáikra. Ezenkívül jó iránymutatás az egyes funkciók felépítésének módjáról, valamint azokról a kezdeményezésekről és témákról, amelyeken a funkcióknak alapulniuk kell.

a funkció témájára összpontosítva a fejlesztők a termék minden aspektusát az adott témához igazítják, ezáltal növelve a használhatóságot ezen a vonalon. Miután meghatározták, a témák segítenek zökkenőmentesen átalakítani célját funkciókká.

állítsa be a reális kiadási kritériumokat

az egyik legnagyobb hiba, amelyet a vállalatok elkövetnek, a termék kiadásának siettetése, anélkül, hogy figyelembe vennék a finomabb részleteket, mint például az ügyfelek igénye az adott időpontban, a termékkészség és az általános használhatóság valós időben.

függetlenül attól, hogy mennyire jó a termék, mindig győződjön meg róla, hogy redundanciákat ad hozzá a kiadási kritériumokhoz, és javítsa ki a lehető legtöbb hibát a használhatósági mátrixban.

ezt úgy teheti meg, hogy elemzi a versenytársak termékeinek felhasználási eseteit, és megtudja, hogyan teljesítettek termékeik az ideálisnál korábban, vagy elbocsátásokkal.

végül győződjön meg arról, hogy a kiadási céljai hosszú és rövid távon megvalósíthatók, elérhetők és mérhetők, ugyanakkor könnyen érthetőek mindenki számára, aki részt vesz a fejlesztésben.

reális megjelenési idő beállítása

a megjelenési dátum megadja a fejlesztőknek és a vezetőségnek a kitűzött célt. Bár ez nem létfontosságú tényező egy jó termékben, fontos megbizonyosodni arról, hogy senki sem veszíti el a hangsúlyt a végcélra, ami a termék célja.

a megjelenési dátumnak nem kell pontosnak lennie, és a fejlesztők által megadott fejlesztési idővonal alapján durva becslést adhat meg. Azonban, fontos, hogy reális legyen, még előzetes dátummal is.

Továbbá Ne feledje az előző pontot arról, hogy az idővonal beállításakor nem szabad siettetni a terméket.

érdekelt felek engedélyének megszerzése

az a termék, amely minden érintett érdekelt féltől engedélyt kap, azt jelenti, hogy az egész vállalat hisz benne és bízik a piaci siker szempontjából.

ez különösen fontos a vezető érdekeltek számára, akik esetleg finanszírozzák a terméket, vagy adják meg a végső jóváhagyási szót.

annak érdekében, hogy mindenki egyetértsen a termékkel, annak céljával, jellemzőivel és hosszú távú hatásával, széles körű megbeszéléseket és ötletbörzét tartson az összes érintett féllel. A felső vezetés esetében konferenciát tarthat, amelyben röviden ismerteti a terméket.

ez úgy tűnhet, mint egy extra lépés wince ha a PRD épül, ez automatikusan azt jelenti, hogy mindenki aláírta rajta. Ugyanakkor nem árt megszerezni az összes érdekelt fél bizalmát a jövőbeli vállalkozások iránt is.

záró Megjegyzés

mint korábban említettük, ez az agilis csapat kora, amely különféle együttműködési szoftvereket használ az ötleteik átadásához, részletes dokumentáció nélkül.

azonban nem minden vállalat rendelkezik stabil agilis architektúrával, és sokuknak be kell érnie a hagyományos vízesés környezettel, különösen a termékfejlesztési út korábbi szakaszaiban.

ha vállalata az utóbbiak közé tartozik, óriási hasznot húzhat ezeknek a dokumentumsablonoknak az egyikéből, miközben az együttműködés és a fejlesztés javításán dolgozik.

Meta Leírás: