6 kroků pro psaní dokumentu SRS, který funguje + šablona

6 kroků pro psaní dokumentu SRS, který funguje + šablona

dokumenty Specifikace softwaru jsou někdy považovány za artefakty, které mají smysl pouze pro vývojáře. Dokument SRS však může jít dále a stát se průvodcem pro marketingové specialisty, zúčastněné strany, designérské týmy a dokonce i uživatele.

tento článek vysvětlí, proč záleží na softwarové dokumentaci a jak napsat dokument SRS, aby byl praktickým průvodcem pro všechny týmové specialisty.

co je dokument SRS a proč na tom záleží?

dokument SRS (software requirement specification) je artefakt, který obsahuje požadavky, očekávání a standardy pro budoucí produkt. Může zahrnovat textové dokumenty, tabulky, schémata, precedenty a další prvky, které objasňují vizi produktu. Jinými slovy, dokument SRS poskytuje podrobný popis toho, jak by měl produkt fungovat a jak by jej měl vývojový tým implementovat.

Představte si to jako stavbu lodi. Máte vizi stožáru nebo plachty a dokonce si dokážete představit, jak se pohybuje vlnami. K tomu, abyste loď položili na vodu, však potřebujete přísnější detaily.

totéž platí pro vývoj produktu. Můžete mít jasnou vizi aplikace, kterou chcete vytvořit, se všemi funkcemi, designovými prvky a tlačítky. Slovní popis funkcí však vývojářům nestačí k implementaci myšlenky.

aby výsledek odpovídal obrázku ve vaší hlavě, musíte na papíře přesně vysvětlit, jak by funkce měla fungovat. Dokument SRS je vynikajícím nástrojem pro popis takových technických detailů.

kdo píše dokument SRS?

psaní dokumentu SRS znamená přenos obecných popisů funkcí, úkolů a cílů do podrobného plánu jejich technické implementace.

SRS dokumenty jsou obvykle psány produktovými a projektovými manažery nebo obchodními analytiky, kteří přímo komunikují s klienty nebo provádějí průzkum uživatelů(kteří také pracují na drátových modelech a vědí, jak by se měl produkt chovat) a shromažďují požadavky budoucích produktů.

mezitím tento dokument. Dobrý dokument SRS není pouze technický, protože zahrnuje také obchodní cíle,metriky, problémy uživatelů, personas uživatelů atd.

3 Důvody, proč je dokument SRS důležitý

celková hodnota dokumentu SRS je tedy jasná. Zde jsou důvody, proč jsou nezbytné dokumenty specifikace požadavků na software:

SRS je komunikační bod

jako živý dokument slouží dokument SRS jako komunikační platforma mezi všemi odborníky: vývojáři, marketingoví specialisté a spoluzakladatelé.

vysvětlením podrobností v dokumentu SRS, formálně nebo neformálně, manažeři souhlasí s klienty o očekáváních výsledků. Mezitím, pokud jsou změny provedeny v požadavcích, může klient a / nebo vlastník produktu zkontrolovat a ověřit je v dokumentu. A vývojáři jsou zodpovědní za splnění těchto očekávání.

konečný popis funkcí

SRS dokumentuje konečné verze softwaru, které vycházely z předpokladů diskutovaných s klienty dříve. Během schůzek a hovorů, uživatelských testů a rozhovorů se verze produktů mohou velmi často měnit. Někdy dokonce i produktoví manažeři mohou být ohromeni stávajícími iteracemi produktů. Soubor SRS pomáhá sjednotit všechny tyto požadavky do jednoho standardu a eliminovat jakékoli nejasnosti ohledně požadavků na produkt.

SRS je standardní průvodce pro vývojáře produktů

kromě popisu požadavků na produkt dokument SRS vede vývojový tým o krocích, které by měli dodržovat při vytváření produktu, který chce klient.

v závislosti na organizaci projektu mohou nebo nemohou být vývojáři zapojeni do analytické části projektu. V obou případech musí dospět k závěru, jak by měl systém fungovat, definovat požadavky a parametry kódu, aby mu vyhovovaly.

podobně musí profesionálové QA porozumět všem technickým aspektům, které stojí za konceptem produktu. Dokumentace SRS tedy slouží jako standard pro plánování a provádění testů QA.

nakonec návrháři získají informace o projektu prostřednictvím Dokumentů SRS, aby odpovídaly návrhu případu použití.

6 kroky k psaní dobrého dokumentu SRS

funkční a nefunkční požadavky zaujímají velkou část každého dokumentu SRS. Produktoví manažeři tyto požadavky jednoduše neberou odnikud. Jsou výsledkem přesné komunikace s klienty a hloubkového uživatelského a technického výzkumu. Zde jsou hlavní kroky psaní vynikající dokumentace SRS:

Krok 1. Komunikace se zúčastněnými stranami

odstraňujeme první vrstvu nejistoty dotazem zúčastněných stran na jejich očekávání od produktu. Tak určitě, takový rozhovor dává jen trochu pochopení požadavků. To je však stále skvělý výchozí bod pro výzkum.

v Uptech nejprve mluvíme s klientem při předprodeji a zahájení hovoru, když se snažíme zjistit, zda se navzájem hodíme. Snažíme se vykrystalizovat sebemenší detaily o klientovi, abychom pochopili jeho představu.

jednoduchá komunikace však neposkytuje dostatek informací o cílovém publiku produktu a jeho přáních a potřebách. Takže pokračujeme ve fázi objevování, abychom to objasnili.

Krok 2. Discovery Stage

Fáze Discovery je kritická v písemné dokumentaci SRS. V této fázi máme příležitost prozkoumat problém, který by měl produkt řešit, zájmy a potřeby. Naším cílem je identifikovat problémy uživatelů a definovat hypotézy možných řešení, jak je řešit. S takovým přístupem můžeme aplikaci učinit cennou pro uživatele.

případy použití vs příběhy uživatelů

všechna uživatelská data se stávají součástí dokumentu SRS jako případy použití a příběhy uživatelů. Rozdíl mezi těmito dvěma kategoriemi je široce diskutován mezi komunitou pro vývoj produktů.

jednoduše řečeno, uživatelské příběhy jsou více zaměřeny na výsledek a výhody, které uživatel získá při používání funkce. Zatímco případy použití více granulárně popisují samotnou funkci.

například po několika uživatelských rozhovorech v projektu Yaza jsme dospěli k závěru, že aplikace by měla mít chat. Příběh uživatele pro takový případ by tedy zněl takto: „jako uživatel chci chatovat s potenciálním majitelem domu.“

mezitím by případ použití tohoto příběhu popisoval každý krok uživatele k dosažení tohoto cíle – “ jako uživatel musím přidat kontakt do svého seznamu chatu a poslat mu zprávu, aby…“.

Krok 3. Vytvořte strukturu

jakmile je objev dokončen, pokračujeme v psaní dokumentace SRS. Nejprve potřebujeme stručnou strukturu dokumentu. Obsah dokumentu SRS se může výrazně lišit, ale typická struktura dokumentace SRS by vypadala takto:

1. Úvod

Úvod obsahuje shrnutí obsahu dokumentu. Má odpovědět na následující otázky:

• Stručný popis obsahu dokumentu;
• zamýšlené čtečky tohoto dokumentu;
• myšlenka vyvíjeného softwaru;
• zamýšlené čtečky.

1.1 obchodní cíle

Nastavte seznam cílů, kterých chcete v projektu dosáhnout, jako je vytvoření MVP, vytvoření multiplatformní mobilní aplikace nebo spuštění webové stránky.

kromě toho by tato část měla odrážet cíle a metriky úspěchu vašeho podnikání. Ačkoli někteří mohou tuto část z dokumentu vyloučit, je nezbytné tyto věci uvést, protože přímo ovlivňují výzkum a vývoj.

1.3 zamýšlené použití

jak si myslíte, že jednotlivec bude používat váš produkt? Jaké jsou funkce, které poskytujete pro tento typ použití? Popište všechny možné způsoby, jak může osoba používat váš produkt v jakékoli roli uživatele, kterou jedná.

1.4 Rozsah

tato část popisuje rozsah práce, kterou musíte provést, abyste svůj nápad uvedli do života.

1.5 definice a zkratky

Tento z nich stanoví definice pojmů, které používáte v dokumentu, aby bylo zajištěno úplné porozumění uživatelům.

‍

2. Celkový popis

zde je část, kde vysvětlíte nápad aplikace, odkud pochází a proč může být pro uživatele zajímavý.

2.1 uživatel potřebuje

kus softwaru, který je postaven pro každého, neslouží nikomu. Ale pokud přesně víte, kdo je vaše cílové publikum, kde pracují, a jejich bolesti, budete mít vyšší šance na doručení aplikace, která je široce přijímána uživateli.

‍

3. Systémové vlastnosti a požadavky

nyní je čas nastínit technické požadavky vašeho budoucího softwaru. Popište funkce, které váš produkt bude obsahovat, spolu s normami, které definují kvalitu těchto produktů.

3.1 funkční požadavky

funkční požadavky jsou specifikace systému, bez nichž software nebude správně fungovat. Definice, kterou dáte svým softwarovým funkcím, určí, jak budou dále implementovány.

3.2 nefunkční požadavky

zatímco funkční požadavky definují, jaká bude Funkce systému, nefunkční požadavky určují, jak bude systém tyto funkce implementovat, například rychlost dokončení.

3.3 Tech Stack

tech stack je soubor technických řešení používaných k vytváření a spouštění softwaru nebo projektu. Je důležité jej uvést v dokumentu SRS, protože definuje všechny ostatní technické podrobnosti.

Krok 4. Udělejte obecný popis

než se ponoříte do podrobností o produktu, poskytněte obecný přehled hlavních funkcí aplikace. Jednoduše vysvětlete účel aplikace, její funkce a způsob, jakým řeší problém uživatele.

Krok 5. Definujte funkční a nefunkční požadavky

jádro dokumentu SRS se obvykle skládá z funkčních a nefunkčních požadavků produktu. S takovými specifikacemi přidáte do obecného přehledu další podrobnosti, a tak vedete tým technickými specifikami vaší aplikace.

rozdíl mezi funkčními a nefunkčními požadavky je dalším problémem ve Společenství pro vývoj produktů. V tomto článku jsme sdíleli naše odborné znalosti k tomuto tématu.

Krok 6. Ujistěte se, že klient na stejné stránce

schválení je velmi očekávanou součástí vývoje. Úpravy klienta však někdy mohou negovat celé množství práce dokončené v určitém bodě projektu.

abychom se vyhnuli tlaku, doporučujeme souhlasit s malými částmi dokončené dokumentace SRS, spíše než předložit celý balíček dokumentů najednou. To pomáhá rychle vyřešit určité problémy a je méně problematické.

odborné tipy pro psaní skvělé dokumentace SRS

zdokonalení dovednosti psaní vynikající dokumentace SRS vyžaduje určitý čas. Z našich zkušeností jsme vytáhli seznam odborných tipů na psaní dokumentace SRS. Zde je několik poznatků, díky nimž bude vaše dokumentace SRS efektivní:

ať je to jednoduché

to je stěží tajemství, ale jednoduché věci vládnou světu. To jistě platí pro jakýkoli typ dokumentace, na které pracujete. Vaše SRS je jednotný popis budoucího produktu pro celý váš tým. To znamená, že jazyk, struktura a formulace vašeho dokumentu SRS by měly být co nejlakoničtější.

zahrnout obchodní cíle

ačkoli dokument SRS se primárně zaměřuje na technické vlastnosti, včetně obchodních cílů je dobrou praxí. Dokument SRS je instrukcí pro vývojový tým a souhrnem produktu pro netechnické specialisty související s produktem. Kromě toho, včetně obchodních požadavků, jako jsou metriky a účely, učiní váš SRS jednotným nástrojem pro celý tým.

přidat uživatelská Data

fáze zjišťování obvykle odhaluje nejcennější informace o uživateli. Přidání těchto informací do dokumentu SRS z něj učiní užitečný dokument pro návrhářský a vývojový tým.

považujte SRS za živý dokument

dokument SRS by neměl být statický, i když jste pro svůj projekt sestavili všechny potřebné balíčky. V agilních ekosystémech projekty obcházejí získávání nových funkcí s každou další iterací. Všechny tyto změny a úpravy by měly být uvedeny v dokumentu SRS a dohodnuty s klientem.

závěr

psaní dokumentů SRS vyžaduje hluboký výzkum, analýzu a úsilí. Komplexní dokument SRS, který pokrývá obchodní charakteristiky, technické detaily a uživatelská data, se však vyplatí s ohromujícím produktem, který splňuje očekávání klientů i uživatelů.

Uptech má pět let zkušeností s budováním produktů pro prosperující startupy. Víme, jak prozkoumat potřeby uživatele a učinit SRS document účinným nástrojem pro řízení projektů, spíše než hromádkou prachu pokrytých papírů.

F. A. Q.

co je SRS?

SRS je dokument obsahující podrobný popis technických specifikací a požadavků aplikace nebo softwaru. SRS také instruuje vývojáře, jak implementovat nápad produktu tak, aby odpovídal očekáváním klienta.

jaký je účel dokumentu SRS?

účelem dokumentu SRS je poskytnout technický popis vlastností produktu, poskytnout technické a netechnické požadavky a vést vývojový tým k implementaci.

kdo píše dokumenty SRS?

v závislosti na složení týmu jsou dokumenty SRS obvykle psány:

• produktový manažer;
• projektový manažer;
• obchodní analytik;
• technický inženýr.