Jaký by měl být a co by měl obsahovat dobrý dokument specifikace
požadavků (DSP) na software.
(Zdroj: [Pressman], Standard ANSI/IEEE číslo
830-1984 [IEEE Guide to Software Requirements Specifications, IEEE 1984,
in: [IEEE,1990])
Datum poslední modifikace: 14.2.2004
Konečným výsledkem analýzy je dokument specifikace požadavků na software (dále DSP). O jeho struktuře podrobněji pojednává tento text založený na standardu IEEE 830-1984.
Na obr.1 je uveden prototyp osnovy DSP. Skutečný dokument bude velmi pravděpodobně přizpůsoben konkrétním podmínkám a jeho části mohou mít jiná jména a pořadí, nicméně dobrý DSP by měl v nějaké formě obsahovat všechny části zde uvedené.
Obsah |
Účel říká, proč má být daná aplikace vytvořena a vymezuje zamýšlený okruh čtenářů dokumentu.
Rozsah systému udává seznam sw systémů, které mají být vytvořeny, co se od nich má (případně nemá) očekávat, a jak budou používány (vč. jaké to bude mít přínosy).
Definice, zkratky a akronymy poskytuje definice termínů používaných v DSP, aby jej mohl číst i neodborník.
Reference obsahuje úplný seznam všech dokumentů, na něž se daný DSP odkazuje (z nichž vychází), a odkud mohou být získány.
Přehled dokumentu říká, jak je zbytek DSP zorganizován a co obsahuje.
Kontext produktu udává jeho vztahy k ostatním produktům, s nimiž má spolupracovat v rámci většího systému (v takovém případě jsou zde popsány jednotlivé systémové komponenty a jejich rozhraní) a také jeho postavení v organizačním kontextu uživatele.
Přehled funkcí uvádí shrnutí fcí poskytovaných sw bez uvedení detailů; je zaměřený především na vrcholový management zákazníka a příležitostné čtenáře.
Profil uživatele uvádí všeobecné charakteristiky budoucích uživatelů softwaru ('obyčejných' i administrátorů), a jaký vliv to má na specifikaci požadavků.
Přehled omezujících podmínek popisuje okolnosti omezující volby vývojářů při designu softwaru (dostupný hw pro vývoj a provoz, časové či jiné limity, nutnost dodržet rozhraní ke stávajícímu sw, použité protokoly, bezpečnost, apod.), tj. to co vás při vývoji bude brzdit od volného rozletu. ! Odlišné od obsahu následujícího odstavce Předpoklady a závislosti.
Předpoklady a závislosti uvádí vąechny faktory od nichž jsou odvozeny nebo na nichž závisí požadavky specifikované dále v dokumentu, kromě již uvedených omezení. Např. se zde uvede, co musí být organizačně a technicky připraveno na místě zákazníka, než bude možné systém nainstalovat a provozovat.
Obsahuje detailní informace potřebné pro vytvoření návrhu (designu) produktu. Tyto detaily by měly být specifikované po jednotlivých funkcích systému, splňovat vlastnosti uvedené dále v kvalitativních charakteristikách DSP a doplněné křížovými referencemi k příslušným částem Úvodu a Všeobecného popisu dle potřeby.
Požadavky je možné klasifikovat např. do kategorií (pododdílů kapitoly)
Je také potřeba popsat strukturu informací (dat), které systém udržuje/zpřístupňuje, ve formě např. výčtu položek nebo odkazem do datového slovníku.
Protože tento oddíl je obvykle nejrozsáhlejší a vyžaduje podrobný popis, je diskuse o něm uvedena v samostatném dokumentu.
Z jistého pohledu nejdůležitější část DSP. Definuje, jak bude možné poznat dobrou implementaci systému pomocí jeho výkonnostních charakteristik (doby odezvy, velikosti dat, ...), jaké druhy testů bude třeba vykonat pro ověření funkcionality a výkonnosti vč. specifikace reakcí, které má sw poskytnout. Podobně jako u popisu vlastností je nezbytné specifikovat tato kritéria číselně , aby bylo možno při ověřování změřit skutečné charakteristiky implementace a porovnat je se zde uvedenými požadavky.
Patří sem zejména obsah a rejstřík, které jsou velmi důležité pro rozsáhlé dokumenty. Dále je možno doplnit text přílohami, v tomto případě je dobré explicitně uvést zda se tyto mají považovat za součást požadavků.
Přílohy obsahují např. velké DFD a ERA diagramy, podrobné popisy v/v formátů, pomocné informace pro snažší porozumění DSP (výklad terminologie, vysvětlení grafických notací, ...); dále také např. historii a podporované operační charakteristiky klientské organizace, křížové reference na dosud nespecifikované požadavky [viz Vlastnosti dobrého DSP], instrukce pro balení dodávaného sw vzhledem k bezpečnosti a exportním požadavkům, atd.
Vzhledem k tomu, co je předmětem DSP, by tento dokument neměl obsahovat:
jednoznačnost -- jeden každý požadavek má právě jednu interpretaci (pozor na to, že přirozený jazyk je od principu nejednoznačný).
úplnost -- obsahuje všechny důležité požadavky (na funkce, vlastnosti, omezení, ...), definuje odezvy na všechny realizovatelné kombinace vstupních dat (platných i neplatných), splňuje případné příslušné normy, všechny diagramy apod. mají řádné titulky, neobsahuje odkazy typu "bude stanoveno později" (pokud je tyto odkazy nutno zahrnout, musí dokument popsat jejich důvod a způsob+termín odstranění).
verifikovatelnost -- jeden každý požadavek je verifikovatelný, tj. "existuje cenově efektivní proces, pomocí něhož je možno ručně nebo strojově ověřit, že software odpovídá tomuto požadavku" (s důrazem na kvantifikovatelnost => měřitelnost požadavků).
konzistence -- neobsahuje navzájem konfliktní množinu požadavků (ten může nastat při použití různých termínů pro stejný objekt, při konfliktních požadavcích na takový objekt, nebo při časově resp. logicky konfliktních specifikacích dvou akcí).
modifikovatelnost -- jeho struktura a styl dovoluje snadné, úplné a konzistentní dpolňování případných změn (dokument proto by měl být psaný konzistentním stylem bez redundancí a obsahovat seznamy pro křížové reference jako obsah a index).
trasovatelnost -- je zřejmé, odkud vzešly jednotlivé požadavky, a na každý požadavek je možné se explicitně odkazovat v další dokumentaci (zpětná trasovatelnost = u kažého požadavku jsou uvedeny jeho zdroje v předchozí dokumentaci, dopředná trasovatelnost= každý požadavek má jednoznačnou identifikaci, např. číselnou, důležité při údržbě a dohadech).