Specifikace požadavků dle IEEE standardu

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: 30.1.2024

Úvod a motivace

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.

Osnova a příklad DSP

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
  1. Úvod
     1.1 Účel systému
     1.2 Rozsah systému
     1.3 Definice, zkratky a akronymy
     1.4 Reference
     1.5 Přehled dokumentu
  2. Všeobecný popis
     2.1 Kontext produktu [vztahy k ostatním částem systému]  
     2.2 Základní přehled funkcí
     2.3 Profil uživatele
     2.4 Přehled omezujících podmínek
     2.5 Předpoklady (assumptions) a závislosti
  3. Specifikace požadavků
     ... (viz separátní popis)
  4. Ověřovací kritéria
     4.1 Rozsah výkonnostních charakteristik
     4.2 Druhy testů
     4.3 Platné odezvy
     4.4 Specifické případy
  Přílohy
  Rejstřík

Oddíl 1 -- Úvod

Úč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.

Oddíl 2 -- Všeobecný popis

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.

Oddíl 3 -- Specifikace požadavků

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)

• požadavky na funkce
• požadavky na výkonnost
• požadavky na vlastnosti (atributy)
• vnější rozhraní

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.

Oddíl 4 -- Ověřovací kritéria

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.

Přílohy -- Doplňující informace

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.

Čeho se vyvarovat při psaní DSP

Vzhledem k tomu, co je předmětem DSP, by tento dokument neměl obsahovat:

• vágní formulace -- všechny požadavky musí být popsány jednoznačně a přesně; formulace typu "program by mohl být použit pro..." nebo "výstupem mohou být např. statistiky ..." jsou nepřípustné (odpovídající správné formulace: program bude použit, výstup bude obsahovat statistiky).
• design zakomponovaný do požadavků -- DSP specifikuje co má software dělat, nikoli jak toho dosáhnout: to není věc, do které by měl zákazník co mluvit (týká se např. rozdělení systému na moduly, specifikace datových struktur, toku řízení apod.).
• požadavky na proces -- DSP by se měl týkat softwarového produktu, nikoli procesu jeho vytváření. Požadavky na termíny dodání, zajištění kvality, procedury pro verifikaci, validaci, a předání produktu mají být specifikovány v jiných dokumentech kontraktu.

Vlastnosti dobrého DSP

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í doplň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).

Management projektů