Üzleti követelmény dokumentum (BRD)

Adj rövid és egyértelmű leírást egy adott üzleti követelmény vagy követelménycsoport számára. Ideális esetben egy üzleti követelményhez egy BRD tartozik az én irányításom alatt.

Ismertesd azokat a nem tulajdonosi jellegű konvenciókat, módszertanokat, technikákat, keretrendszereket, gyakorlatokat vagy egyéb know-how-kat, amelyeket érdemes megemlíteni. Az említés szükségességét a vezető dönti el, figyelembe véve a célközönség és a dokumentum tartalmának közötti felkészültségi és képességbeli különbségeket.

Sorolj fel minden fogalmat és azok definícióját, amelyek kifejezetten ehhez a BRD-hez kapcsolódnak. Tüntesd fel az esetlegesen használt külső fogalmakat és definíciókat is, hogy minden egyértelmű legyen.

Állíts össze egy listát linkekből, könyvekből, oktatási anyagokból és egyéb forrásokból, amelyeket ajánlott átnézni a BRD értelmezése előtt.

Mivel a BRD-t általában szélesebb közönség használja, mint a projektindító dokumentumot, adj tömör összefoglalót a projekt céljáról és hatóköréről. Ez lehetővé teszi a BRD további elemzéshez, tervezéshez vagy kivitelezéshez való megosztását, miközben védi az érzékenyebb információkat, amelyeket szándékosan kihagytunk a dokumentumból.

Ezt töltsd ki a 3. szakasz befejezése után. Foglald össze a termék főbb jellemzőit és az általa nyújtott vagy lehetővé tett főbb funkciókat. Maradj magas szinten—részletek a 3. szakaszban találhatók. Rendszerezd az anyagot, hogy bármely BRD-olvasó számára könnyen érthető legyen. Vizualizációk, például felső szintű adatfolyam-diagramok vagy osztálydiagramok segíthetnek bemutatni, hogyan kapcsolódnak a főbb követelményszerkezetek.

Sorold fel és írd le az összes szereplőt, akik relevánsak a jelenlegi üzleti követelményekhez.

Adj világos és részletes leírást arról a környezetről, ahol az ebben a dokumentumban meghatározott üzleti követelmények teljesülni fognak.

Ne felejtsd el lefedni azokat a környezeti tényezőket sem, amelyek befolyásolhatják vagy alakíthatják a megoldások teljesítményét.

Vázold fel azokat a korlátokat és megszorításokat, amelyek befolyásolják vagy korlátozzák a fejlesztők számára elérhető lehetőségeket. Ilyenek lehetnek:

• Szabályozási vagy vállalati előírások.
• Hardveres korlátok, mint például időzítés, teljesítmény vagy memóriahatárok.
• Más rendszerekkel vagy alkalmazásokkal való szükséges integrációk.
• Konkrét technológiák, eszközök vagy adatbázisok, amelyeket használni kell.
• Párhuzamosan futó műveletek.
• Nyelvi vagy lokalizációs követelmények.
• Betartandó kommunikációs protokollok.
• Biztonsági követelmények.
• Megállapított tervezési konvenciók vagy programozási szabványok, különösen, ha a megoldást az ügyfél szervezete fogja karbantartani.

Legyen pontos és cselekvésre alkalmas—itt határozod meg a projekt játékszabályait.

Sorold fel a szállítandó felhasználói dokumentációkat (pl. kézikönyvek, online súgók, oktatóanyagok). Ha ismert, tüntesd fel a szükséges formátumokat vagy szabványokat is.

Sorold fel azokat a tényezőket, amelyeket igaznak gondolnak, de nem megerősítettek, és amelyek hatással lehetnek a követelményekre. Példák: harmadik fél komponenseinek tervezett használata, várható fejlesztési környezetek vagy feltételezett korlátozások. Ha ezek hamisnak bizonyulnak vagy megváltoznak, az hatással lehet a projektre.

Határozd meg azokat a külső elemeket, amelyekre a projekt támaszkodik, például más projektekből származó újrafelhasználható szoftverkomponenseket vagy harmadik féltől származó szolgáltatásokat. Megjegyzés: Hagyd ki azokat a függőségeket, amelyek más projektanyagokban (pl. vízió dokumentum vagy projektterv) már dokumentálva vannak.

Emeld ki azokat a lehetséges problémákat, amelyek helytelen feltételezésekből vagy nem teljesített függőségekből adódnak. Határozd meg, hogy ezek a kockázatok hogyan befolyásolhatják a projektet és annak eredményeit.

Ez a szakasz bemutatja, hogyan kell strukturálni a termék funkcionális követelményeit, általában rendszerfunkciók szerint csoportosítva—a termék által nyújtott kulcsszolgáltatások. Alternatív megoldásként csoportosíthatók használati esetek, működési módok, felhasználói típusok, objektumkategóriák, funkcionális hierarchia vagy bármely logikus kombináció szerint. Válaszd azt a megközelítést, amely a legjobban illeszkedik a projekt igényeihez és a tisztaságához.

Adj világos, magas szintű összefoglalót erről a jellemzőről vagy komponensről. Magyarázd el a célját, a problémát, amit megold, és a szerepét az egész projektben vagy termékben.

Sorold fel a felhasználói műveleteket, triggermozzanatokat vagy működési bemeneteket és az ezekhez kapcsolódó válaszokat, viselkedéseket vagy kimeneteket, amelyeket a jellemzőtől elvárnak. Emeld ki azokat az interakciókat, amelyek meghatározzák, hogyan működik a jellemző a környezetében vagy rendszerében.

Határozd meg egyértelműen, mit kell elérnie ennek a jellemzőnek vagy komponensnek, különös tekintettel a mérhető és ellenőrizhető szállítandókra. Ide tartozhat:

• Konkrét képességek vagy műveletek, amelyeket a jellemzőnek támogatnia kell.
• Elvárt viselkedések szélsőséges esetekben vagy hibaszcenáriókban.
• Bármilyen feltétel vagy megszorítás (pl. „meg kell felelnie az [X] szabványnak”).

Minden követelményt egyedi címkével kell ellátni (pl. REQ-01, REQ-02).

Azok a tényezők, amelyek várhatóan állandók vagy igazak maradnak, hogy a jellemző megfelelően működjön.

Azok a feltételek, amelyeket teljesíteni kell, mielőtt a jellemző működőképes lesz.

A várt állapot vagy kimenetek, miután a jellemző folyamatai befejeződtek.

Határozd meg a megvalósításhoz szükséges külső vagy belső tényezőket (pl. rendszerek, eszközök, harmadik féltől származó komponensek).

Emeld ki a jellemzőhöz kapcsolódó kockázatokat és a lehetséges mérséklési stratégiákat.

A részletesség szintje a projekt és az üzleti követelmény összetettségétől függ. Gondoskodj arról, hogy a BRD-ben érintett felek számára ne legyenek meglepetések.

Csak a releváns elemeket tartalmazd, a többit hagyd ki. A részletesség szintje igazodjon az elköteleződés összetettségéhez és a szerződésben szükséges egyértelműséghez, hogy elkerüld az ügyfél-szállító fél félreértéseit.

Csak konkrét, számszerűsíthető vagy bizonyítható tulajdonságokat írj le. Ne használj "minél előbb" bullshit kifejezéseket, és kerüld az

Jogszabályi megfelelés, szabványok és egyéb releváns tényezők