Analýza požadavků na software s příkladem

Softwarový požadavek je funkční nebo nefunkční potřeba, která musí být v systému implementována. Funkční znamená poskytování konkrétní služby uživateli.

Například v kontextu bankovní aplikace je funkčním požadavkem, aby si zákazník po výběru možnosti „Zobrazit zůstatek“ mohl zobrazit aktuální zůstatek na svém účtu.

Softwarový požadavek může být také nefunkční, například požadavek na výkon. Například nefunkční požadavek může stanovit, že každá stránka systému by se měla uživatelům načíst do 5 sekund.

Takže softwarový požadavek je a

• Funkční nebo
• Nefunkční

potřeba které je třeba implementovat do systému. Požadavky na software jsou obvykle vyjádřeny jako prohlášení.

Typy požadavků

Obchodní požadavkyToto jsou požadavky na vysoké úrovni převzaté z obchodního případu projektu. Například systém mobilního bankovnictví poskytuje bankovní služby jihovýchodní Asii. Obchodním požadavkem stanoveným pro Indii je souhrn účtu a převod finančních prostředků, zatímco pro Čínu je to souhrn účtu a platba faktur.

Země	Společnost poskytující bankovní funkce nebo služby
Indie	Přehled účtu a převod prostředků
Čína	Přehled účtu a Bill Platba

Architechnické a designové požadavkyTyto požadavky jsou podrobnější než obchodní požadavky a řídí architekturu řešení. Určují celkový návrh potřebný k implementaci obchodního požadavku. Pro vzdělávací organizaci zahrnují typické architektonické a designové případy použití přihlášení, podrobnosti o kurzu a zápis. Požadavek by byl uveden níže.

Případ použití bankovnictví

Požadavek

Bill Platba

Tento případ použití popisuje, jak se může zákazník přihlásit do internetového bankovnictví a používat Bill Platební nástroj. Zákazník si může prohlédnout přehled neuhrazených faktur registrovaných fakturantů. Zákazník může přidávat, upravovat a mazat údaje o fakturantovi. Zákazník si může nakonfigurovat SMS a e-mailová upozornění pro různé fakturační akce. Zákazník si může prohlédnout historii dříve zaplacených faktur. Aktéry, kteří tento případ užití zahajují, jsou bankovní zákazníci nebo podpůrný personál.

Systémové a integrační požadavkyNa nejnižší úrovni máme systémové a integrační požadavky. Ta poskytuje podrobný popis každého požadavku. Lze jej zachytit jako uživatelské příběhy psané v běžném obchodním jazyce. Požadavky obsahují spoustu detailů, aby vývojáři mohli začít s kódováním. Bill Níže uvedený příklad platebního modulu ukazuje požadavek na přidání fakturanta.

Bill Platba	požadavky
přidat BilleRS	Název poskytovatele energií, číslo zákazníka, automatické platby – Ano/Ne, platba v plné výši Bill – Ano/Ne, Limit automatických plateb – Neplaťte, pokud Bill je nad stanovenou částku

Někdy se může stát, že pro daný projekt neobdržíte žádné požadavky ani dokumenty, se kterými byste mohli pracovat. I v tomto případě existují další zdroje informací o požadavcích, na které se můžete spolehnout při tvorbě softwaru nebo návrhu testů. Další zdroje požadavků, na které se můžete spolehnout, jsou uvedeny níže.

Jiné zdroje požadavků

• Přenos znalostí od kolegů nebo zaměstnanců, kteří již na daném projektu pracují
• Prodiskutujte projekt s obchodním analytikem, produktovým manažerem, vedoucím projektu a vývojáři.
• Analyzujte předchozí verzi systému, která již byla implementována
• Analyzujte starší dokumenty s požadavky z projektu
• Revzobrazit starší hlášení chyb; některá hlášení chyb jsou převedena na požadavky na vylepšení, která mohou být implementována v aktuální verzi
• Zkontrolujte instalační příručku, pokud je k dispozici, abyste zjistili, jaké instalace jsou nutné.
• Analyzujte znalosti z oblasti nebo odvětví, které se tým snaží implementovat

Ať už používáte jakýkoli zdroj požadavků, zdokumentujte je ve sdíleném formátu a nechte je zkontrolovat zkušenými členy týmu.

Jak analyzovat požadavky

Vezměme si příklad vzdělávacího softwarového systému, kde se student může registrovat na různé kurzy.

Pojďme se podívat na to, jak analyzovat požadavky. Každý požadavek musí splňovat sadu standardních atributů kvality, mezi které patří:

• Atomic
• Jednoznačně identifikované
• Kompletní
• Konzistentní a jednoznačné
• Tracmožné
• Upřednostněný
• Testovatelné

Následující tabulka ilustruje každý atribut pomocí tří sloupců:

1. První sloupec označuje – „požadovaná kvalita“
2. Druhý sloupec označuje – „špatný požadavek s nějakým problémem“
3. Třetí sloupec ukazuje stejný požadavek „převedený na dobrý požadavek“.

Požadavek Kvalita	Příklad špatného požadavku	Příklad dobrého požadavku
Atomic	Studenti se budou moci zapsat do pregraduálních a postgraduálních kurzů	Studenti se budou moci zapsat do bakalářských kurzů. Studenti se budou moci zapsat do postgraduálních kurzů.
Jednoznačně identifikované	1- Studenti se budou moci zapsat do bakalářských kurzů. 1- Studenti se budou moci zapsat do postgraduálních kurzů.	Zápis do kurzů. Studenti se budou moci zapsat do bakalářských kurzů. Studenti se budou moci zapsat do postgraduálních kurzů.
Kompletní	Uživatel profesor se přihlásí do systému zadáním svého uživatelského jména, hesla a dalších relevantních informací	Uživatel profesor se přihlásí do systému zadáním svého uživatelského jména, hesla a kódu katedry
Konzistentní a jednoznačné	Student bude mít buď vysokoškolské kurzy, nebo postgraduální kurzy, ale ne obojí. Některé kurzy budou otevřeny jak pro pregraduální, tak pro postgraduální studium	Student bude mít buď pregraduální nebo postgraduální studium, ale ne obojí
Tracmožné	Udržovat informace o studentech mapované podle BRD req.ID?	Udržovat informace o studentech – mapováno podle BRD req ID 4.1
Upřednostněný	Registrovaný student – ​​Priorita 1. Správa uživatelských informací – Priorita 1. Zápis kurzů – Priorita 1. Zobrazení vysvědčení – Priorita 1	Registrace studenta - Priorita 1. Správa uživatelských informací - Priorita 2. Zápis kurzů - Priorita 1. Zobrazení vysvědčení - Priorita 3
Testovatelné	Každá stránka systému se načte v přijatelném časovém rámci	Registrovat studenta a stránky kurzů systému se načtou do 5 sekund

Pojďme si každou z těchto vlastností podrobněji vysvětlit, počínaje Atomic.

Atomic

Každý požadavek by měl být atomický, což znamená, že musí být na nejnižší úrovni detailů a nelze jej dále rozdělit na komponenty. Následující příklady porovnávají atomické a neatomické požadavky.

Pokračování s příkladem vzdělávacího systému: Zde je špatný požadavek „Studenti se budou moci zapsat do bakalářských a postgraduálních kurzů“. Jedná se o špatný požadavek, protože není atomický – kombinuje dvě různé entity, bakalářské a postgraduální kurzy. Odpovídající dobrý požadavek jej rozděluje na dva požadavky. Jeden požadavek se týká zápisu do bakalářských kurzů a druhý zápisu do postgraduálních kurzů.

Jedinečně identifikováno

Dalším atributem kvality je jedinečná identifikace. Ve špatném příkladu dva samostatné požadavky sdílejí stejné ID#1. Pokud tým odkazuje na požadavek pomocí jeho ID, není jasné, které z těchto dvou identifikátorů je míněno. Dobrý požadavek je přeskupuje do Sekce 1 – Zápis do kurzů s dílčími požadavky 1.1 (zápis do bakalářských kurzů) a 1.2 (zápis do postgraduálních kurzů).

Kompletní

Každý požadavek by měl být kompletní. Například zde chybný požadavek říká, že „uživatel s rolí profesora se přihlásí do systému zadáním svého uživatelského jména, hesla a dalších relevantních informací“. Výraz „Další relevantní informace“ je vágní. Úplný požadavek uvádí přesná pole, například kód katedry, která musí profesor poskytnout.

Konzistentní a jednoznačné

Každý požadavek by měl být konzistentní a jednoznačný. V negativním příkladu jeden požadavek uvádí: „Student bude mít buď bakalářské, nebo postgraduální kurzy, ale ne obojí“, zatímco jiný uvádí: „Některé kurzy budou otevřeny jak bakalářským, tak postgraduálním studentům“.

První požadavek implikuje rozdělení kurzů do dvou samostatných kategorií, ale druhý požadavek je v rozporu s ním tím, že některé kurzy otevírá oběma skupinám.

Dobrý požadavek řeší konflikt jasným stanovením, že každý kurz je označen buď jako bakalářský, nebo magisterský a student se může zapsat pouze do kurzů jedné kategorie.

Tracmožné

Každý požadavek musí být tracmožné, protože požadavky existují na více úrovních: obchodní, architektonické a designové a systémové a integrační.

Když převedete obchodní požadavek na architektonické a designové požadavky nebo architektonické a designové požadavky na systémové a integrační požadavky, tracJe nutné zachovat funkčnost. Každý obchodní požadavek by měl být mapován na jeden nebo více architektonických a designových požadavků. V nevhodném příkladu „Udržovat informace o studentech – mapováno na ID požadavku BRD?“ chybí ID požadavku.

Požadavek na zboží zaznamenává stejné prohlášení, ale explicitně se mapuje na požadavek BRD s ID 4.1. Každý požadavek musí nést tracmapa snadnostipingSystémové a integrační požadavky by se měly také mapovat na kód, který je implementuje, a na testovací případy, které je ověřují.

TracEability proto probíhá od začátku do konce napříč celým projektem.

Upřednostněný

Každý požadavek musí mít stanovenou prioritu, aby tým věděl, co implementovat jako první a co může počkat. Ve špatném příkladu jsou Registrace studenta, Správa informací o uživateli, Zápis kurzů a Zobrazení vysvědčení nastaveny na Prioritu 1. Vše nemůže mít Prioritu 1, proto musí být požadavky seřazeny realisticky. Dobrý příklad dává Registraci studenta a Zápisu kurzů nejvyšší Prioritu 1, Správu informací o uživateli Prioritu 2 a Zobrazení vysvědčení Prioritu 3.

Testovatelné

Každý požadavek by měl být testovatelný. Špatný příklad „každá stránka systému se načte v přijatelném časovém rámci“ není testovatelný ze dvou důvodů. Zaprvé, „každá stránka“ může znamenat desítky stránek, což prodlužuje testovací úsilí. Zadruhé, „přijatelný časový rámec“ není definován – je přijatelný pro koho a vzhledem k jakému benchmarku? Dobrý požadavek řeší oba problémy pojmenováním konkrétních stránek („stránky pro registraci studentů a zápis kurzů“) a stanovením měřitelného cíle 5 sekund.

Nejčastější dotazy