Analýza požadavků na software s příkladem
Charles Moore
Například v souvislosti s bankovní aplikací bude funkční požadavek, když zákazník vybere „Zobrazit zůstatek“, musí mít možnost podívat se na svůj poslední zůstatek na účtu.
Softwarový požadavek může být také nefunkční, může to být požadavek na výkon. Například nefunkčním požadavkem je, že každá stránka systému by měla být pro uživatele viditelná do 5 sekund.
Takže softwarový požadavek je a
- Funkční popř
- Nefunkční
potřeba které je třeba implementovat do systému. Softwarové požadavky jsou obvykle vyjádřeny jako prohlášení.
Typy požadavků
- Obchodní požadavky: Jsou to požadavky na vysoké úrovni, které jsou převzaty z obchodního případu z projektů. Například systém mobilních bankovních služeb poskytuje bankovní služby pro jihovýchodní Asii. Obchodním požadavkem, o kterém se rozhoduje pro Indii, je souhrn účtu a převod prostředků, zatímco pro Čínu se souhrn účtu a platba faktury rozhoduje jako obchodní požadavek
| 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žadavky: Tyto požadavky jsou podrobnější než obchodní požadavky. Určuje celkový design potřebný k realizaci obchodního požadavku. Pro naši vzdělávací organizaci by architektonické a designové případy použití byly přihlášení, detail kurzu atd. Požadavek by byl takový, jak je uvedeno 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 uvidí řídicí panel neuhrazených účtů registrovaných fakturantů. Může přidat, upravit a odstranit detail fakturanta. Zákazník si může nakonfigurovat SMS, e-mailová upozornění pro různé fakturační akce. Může vidět historii minulých zaplacených účtů. Aktéři, kteří zahajují tento případ použití, jsou zákazníci banky nebo pracovníci podpory. |
- Systémové a integrační požadavky: Na nejnižší úrovni máme systémové a integrační požadavky. Je to podrobný popis každého požadavku. Může to být ve formě uživatelských příběhů, které skutečně popisují každodenní obchodní jazyk. Požadavky jsou v mnoha podrobnostech, takže vývojáři mohou začít kódovat. Zde je příklad Bill Platební modul, kde bude uveden požadavek na přidání a Biller
| Bill Platba | požadavky |
|---|---|
| přidat BilleRS |
|
Někdy u některých projektů nemusíte obdržet žádné požadavky nebo dokumenty, se kterými byste mohli pracovat. Stále však existují další zdroje požadavků, které můžete u požadavku nebo informací zvážit, abyste mohli svůj software nebo návrh testu založit na těchto požadavcích. Takže další zdroje požadavků, na které se můžete spolehnout, jsou
Jiné zdroje požadavků
- Přenos znalostí od kolegů nebo zaměstnanců, kteří již na daném projektu pracují
- Promluvte si o projektu s obchodním analytikem, produktovým manažerem, vedoucím projektu a vývojáři
- Analyzujte předchozí verzi systému, která je již v systému implementována
- Analyzujte starší dokument požadavků projektu
- Podívejte se na minulá hlášení o chybách, některá hlášení o chybách jsou změněna na požadavek na vylepšení, který lze implementovat do aktuální verze
- Podívejte se do instalační příručky, pokud je k dispozici, abyste viděli, co je instalace vyžadována
- Analyzujte znalosti domény nebo oboru, které se tým snaží implementovat
Ať už získáte jakýkoli zdroj požadavků, ujistěte se, že je nějakou formou zdokumentujete, nechte si je zkontrolovat od jiných zkušených a znalých členů 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 do různých kurzů.
Pojďme studovat, jak analyzovat požadavky. Požadavky musí zachovávat standardní kvalitu svého požadavku, včetně různých typů kvality požadavků
- Atomic
- Jednoznačně identifikované
- Kompletní
- Konzistentní a jednoznačné
- Sledovatelnost
- Upřednostněný
- Testovatelné
Pochopte to na příkladu, v tabulce jsou tři sloupce,
- První sloupec označuje – „požadovaná kvalita“
- Druhý sloupec označuje – „špatný požadavek s nějakým problémem“
- Třetí sloupec je stejný jako druhý, ale – „převedeno na dobrý požadavek“.
| Požadavek Kvalita | Příklad špatného požadavku | Příklad dobrého požadavku |
|---|---|---|
| Atomic |
|
|
| Jednoznačně identifikované | 1- Studenti se budou moci zapsat do pregraduálních kurzů 1- 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í |
| Sledovatelnost | 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 1Udržování informací o uživateli-Priorita 1Registrace kurzů-Priorita 1Zobrazení vysvědčení-Priorita 1 | Registrovat student-Priorita 1Udržovat informace o uživateli-Priorita 2Zapsat kurzy-Priorita 1Zobrazit vysvědčení-Priorita3 |
| 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 |
Nyní pochopme každý z těchto požadavků podrobně počínaje Atomic.
Atomic
Takže každý požadavek, který máte, by měl být atomický, což znamená, že by měl být na velmi nízké úrovni detailů a nemělo by být možné rozdělit na komponenty. Zde uvidíme dva příklady požadavků na adrese Atomic a jednoznačně identifikované úrovně požadavků.
Pokračujme tedy příkladem sestavení systému pro oblast vzdělávání. Zde je špatný požadavek „Studenti se budou moci zapsat do bakalářských a postgraduálních kurzů“. To je špatný požadavek, protože není atomický, protože hovoří o dvou různých entitách vysokoškolských a postgraduálních kurzů. Je zřejmé, že to není dobrý požadavek, ale špatný požadavek, takže korespondence dobrým požadavkem by bylo rozdělit jej na dva požadavky. Jeden tedy hovoří o zápisu do pregraduálních kurzů, zatímco druhý o zápisu do postgraduálních kurzů.
Jedinečně identifikováno
Podobně dalším požadavkem kvality je kontrola jednoznačně identifikovaných, zde máme dva samostatné požadavky, ale oba mají stejné ID #1. Pokud tedy odkazujeme na náš požadavek s odkazem na ID#, ale není jasné, který přesný požadavek máme na mysli dokument nebo jinou část systému, protože oba mají stejné ID#1. Takže pokud se oddělíte pomocí jedinečných id, dobrý požadavek se bude vracet jako sekce 1 – zápisy do kurzů, a má dva požadavky 1.1 id je zápis do vysokoškolských kurzů, zatímco 1.2 id je zápis do postgraduálních kurzů.
Kompletní
Také každý požadavek by měl být úplný. Například zde špatný požadavek říká, že „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í“. Zde nejsou další relevantní informace jasné, takže ostatní relevantní informace by měly být uvedeny v řádném požadavku, aby byl požadavek úplný.
Konzistentní a jednoznačné
Dále by měl být každý požadavek konzistentní a jednoznačný, takže zde máme například požadavky „Student bude mít buď vysokoškolské kurzy, nebo postgraduální kurzy, ale ne obojí“, je to jeden požadavek, existuje další požadavek, který říká „Některé kurzy budou mít být otevřen studentům pregraduálního i postgraduálního studia“.
Problémem tohoto požadavku je, že z prvního požadavku se zdá, že kurzy jsou rozděleny do dvou kategorií v rámci postgraduálních kurzů a postgraduálních kurzů a student si může vybrat jeden ze dvou, ale ne oba. Ale když si přečtete další požadavek, je to v rozporu s prvním požadavkem a říká, že některé kurzy budou otevřeny pro postgraduální i vysokoškoláky.
Je tedy zřejmé, že tento špatný požadavek převedeme na dobrý požadavek, kterým je „Student bude mít buď pregraduální kurzy, nebo postgraduální kurzy, ale ne obojí“. To znamená, že každý kurz bude označen buď jako pregraduální nebo postgraduální
Sledovatelnost
Každý požadavek by měl být dohledatelný, protože již existují různé úrovně požadavků, už jsme viděli, že na vrcholu máme obchodní požadavky, a pak máme architektonické a designové požadavky následované požadavky systémové integrace.
Když nyní převádíme obchodní požadavky na požadavky na architekturu a design nebo převádíme požadavky na architekturu a návrh na požadavky systémové integrace, musí být zajištěna sledovatelnost. Což znamená, že bychom měli být schopni vzít každý jeden obchodní požadavek a namapovat jej na odpovídající jeden nebo více požadavků na architekturu softwaru a návrh. Zde je příklad špatného požadavku, který říká: „Udržovat informace o studentech – mapované na BRD req ID?“ ID požadavku zde není uvedeno.
Takže když to převedete na dobrý požadavek, říká to totéž, ale je to mapováno s id požadavku 4.1. Mapování by tedy mělo existovat pro každý požadavek. Stejným způsobem máme požadavek na mapování na vysoké a nízké úrovni, mapování je také mezi požadavkem na systém a integraci do kódu, který tento požadavek implementuje, a také existuje mapování mezi požadavkem na systém a integraci na testovací případ, který testuje tento konkrétní požadavek. .
Tato sledovatelnost je tedy v celém projektu
Upřednostněný
| Upřednostněný | Registrovaný student – priorita 1 Udržujte informace o uživateli – priorita 1 Zápis do kurzů – priorita 1 Zobrazit hlášení s prioritou 1 |
Registrace Student-Priorita 1 Udržujte informace o uživateli – priorita 2 Zápis do kurzů – priorita 1 Zobrazit kartu zpráv-Priorita3 |
Pak musí být každý požadavek upřednostněn, takže tým má vodítko, který požadavek je možné implementovat jako první a který lze provést později. Zde můžete vidět špatnou prioritu má zaregistrovat student, udržovat informace o uživateli a každý požadavek má prioritu-1. Všechno nemůže mít stejnou prioritu, takže požadavek může být upřednostněn. Takže příkladem dobrého požadavku zde je registrace studenta a zapsání kurzů má nejvyšší prioritu 1, zatímco udržování informací o uživateli je pod prioritou 2 a pak máme zobrazit vysvědčení s prioritou 3
Testovatelné
| 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 |
Každý požadavek by měl být testovatelný, zde špatný požadavek je „každá stránka systému se načte v přijatelném časovém rámci“. Nyní existují dva problémy s tímto požadavkem, za prvé je to, že každá stránka znamená, že může být mnoho stránek, což zničí testovací úsilí. Dalším problémem je, že říká, že se stránka načte v přijatelném časovém rámci, jaký je nyní přijatelný časový rámec? Přijatelné pro koho. Musíme tedy převést netestovatelný argument na testovatelný argument, který konkrétně vypovídá o tom, na které stránce mluvíme o „stránkách registrace studenta a zápisu kurzů“ a je uveden i přijatelný časový rámec, který je 5 sekund.
Proč investovat do čističky vzduchu?
Takže takto se musíme dívat na každý požadavek na vhodné úrovni. Například pokud budeme stavět software s ohledem na systémové a integrační požadavky. Musíme se podívat na systémové a integrační požadavky uvedené ve specifikacích požadavků na software nebo uživatelských příbězích a aplikovat je na každý požadavek kvality. Poté zkontrolujte, zda je každý požadavek atomický, jednoznačně identifikovaný a úplný a tak dále.