Analyza po?adavk? v systemovem a softwarovem in?enyrstvi , pojima ty ukoly, ktere vstupuji do rozhodovani o pot?ebach a podminkach, ktere jsou kladeny na novy, nebo zm?n?ny produkt. Take musi brat v uvahu r?zne protich?dne po?adavky u?astnicich se stran tzv. stakeholder? .

Systematicka analyza po?adavk? je n?kdy ozna?ovana jako requirements engineering . ^[2] nebo je take (?patn?) pojmenovana jako sb?r po?adavk?, nebo specifikace po?adavk?. Analyza po?adavk? m??e byt analyzou v pravem slova smyslu (jako opak ke sb?ru nebo dokumentaci po?adavk?).

Kvalitni analyza po?adavk? je podminkou usp??neho dokon?eni projektu vyvoje. ^[3] Po?adavek musi byt proveditelny, m??itelny, testovatelny, musi se vztahovat ke konkretnimu byznys po?adavku, nebo p?ile?itosti a take musi byt definovany dostate?ne detailn? pro u?ely navrhu systemu.

Requirements engineering [ editovat | editovat zdroj ]

Sprava po?adavk? obecn? m??e byt zast?e?ujici pojem pro r?zne aktivity:

• Sb?r po?adavk? : komunikace se zakazniky a u?ivateli za u?elem ziskani jejich po?adavk? na system.
• Vlastni analyza: identifikovani nejasnych, nekompletnich, nesmyslnych, nesplnitelnych nebo protich?dnych po?adavk? a nasledne ?e?eni t?chto nesrovnalosti.
• Zaznamenani po?adavk?: dokumentovani po?adavk? v r?znych formach, p?ipady u?iti (use case) , nebo specifikace proces?.
• ?izeni ?ivotniho cyklu po?adavk? (zm?ny, slu?ovani, zanik)

Podle ISO/IEC 24766:2009, ^[4] podporuji nastroje pro praci s po?adavky ?est hlavnich ?innosti:

• Zji??ovani po?adavk?
• Analyza po?adavk?
• Specifikace po?adavk?
• Ov??eni a validace po?adavk?
• Sprava po?adavk?
• Dal?i schopnosti.

Analytici mohou vyu?it vice postup? k ziskani po?adavk? od zakaznika. Historicky, to bylo interview , nebo vedeni rozhovoru s vybranou skupinou (focus group) (p?ihodn?j?i pojmenovani v tomto kontextu je 'po?adavkovy workshop') a vytva?eni seznam? po?adavk?. Mezi modern?j?i techniky pat?i prototypovani , a tvorba p?ipad? u?iti . Pokud to bude nutne, analytici pou?iji kombinaci metod ke ziskani p?esnych po?adavk? od zu?astn?nych stran, aby vyvijeny system co nejlepe odpovidal byznys pot?ebam zadavatele.

Analyza po?adavk? [ editovat | editovat zdroj ]

Identifikace zu?astn?nych stran ("Stakeholder?") [ editovat | editovat zdroj ]

V devadesatych letech hlavni roli hrala identifikace zu?astn?nych stran ( stakeholder? ) . Ma se za to, ?e zu?astn?ne strany se neomezuji pouze na organizaci, ktera zam?stnava analytika. Dal?imi zu?astn?nymi stranami mohou byt:

• ty organizace, ktere se integruji (nebo by m?ly byt za?len?ny) horizontaln? s organizaci, pro kterou analytik system navrhuje
• jakekoli tzv. back office systemy nebo organizace
• vrcholovy management.

Interview se zu?astn?nymi stranami ("Stakeholdery") [ editovat | editovat zdroj ]

Rozhovory se Stakeholdery jsou b??ne metody pou?ivane v analyze po?adavk?. Tyto rozhovory mohou odhalit po?adavky, ktere nebyly p?vodn? zamy?lene jako je?t? v ramci rozsahu tohoto projektu a mohou odhalit po?adavky, ktere jsou protich?dne. Nicmen?, ka?dy se zu?astn?nymi stranami bude mit p?edstavu o jejich o?ekavanich, nebo budou muset sve po?adavky objasnit.

"Contract-style" seznam po?adavk? [ editovat | editovat zdroj ]

Jednim z tradi?niho zp?sobu dokumentovani po?adavk? byl seznam po?adavk? a jeho struktura ( WBS ). Ve slo?item systemu mohou takoveto seznamy mit a? stovky stranek.

M??itelne cile [ editovat | editovat zdroj ]

Osv?d?enym postupem je brat seznam po?adavk? pouze jako voditko a opakovan? se klast otazku: ?Pro??“ a? se odhali skute?ne obchodni u?ely. Zainteresovane strany a take vyvoja?i pak mohou navrhnout testy tak, aby bylo mo?ne zjistit, nakolik bylo zatim dosa?eno cile. Tyto cile se m?ni mnohem pomaleji ne? dlouhy seznam konkretnich, ale nem??itelnych po?adavk?. Jakmile je stanoven maly soubor kritickych a m??itelnych cil?, m??e navazat softwarove prototypovani a kratke iterativni vyvojove faze, ktere mohou poskytnout zu?astn?nym stranam skute?nou hodnotu je?t? p?edtim, ne? bude projekt v polovin?.

Prototypy [ editovat | editovat zdroj ]

Prototypovani bylo v polovin? 80. let vnimano jako ?e?eni problemu analyzy po?adavk?. Prototypy jsou realne modely (makety) aplikaci umo??ujici u?ivatel?m vizualizovat aplikace, d?ive ne? jsou vyrobeny. Tim pomahaji u?ivatel?m ziskat p?edstavu, jak bude system vypadat, aby si mohli zvolit vzhled/rozlo?eni, ani? by ?ekali na system, ktery ma byt teprve vytvo?en. Pou?iti prototyp? vyznamn? zlep?ilo komunikaci mezi u?ivateli a vyvoja?i.

Vytvo?eni prototypove aplikace vedlo k men?im naslednym zm?nam v aplikaci, a tedy ni??im celkovym naklad?m. Nicmen? se v nasledujicich deseti letech i p?es u?ite?nost prototypovani nepoda?ilo vy?e?it souvisejici problemy:

• Jakmile mana?e?i vidi prototyp, mohou jen t??ko pochopit, ?e kone?ny vysledek nebude vyroben ve stejnem ?ase.
• Designe?i jsou ?asto nuceni pou?it prototyp kodu v realnem systemu, proto?e necht?ji ztracet ?as znovuvytva?enim ji? hotoveho kodu.
• Prototypy jsou napomocne hlavn? p?i navrhu u?ivatelskych rozhrani a navrhu obrazovek. Nicmen?, nemohou nic ?ict o tom, jaky byl p?vodni po?adavek.
• Designe?i a koncovi u?ivatele se soust?edi p?ili? na u?ivatelske rozhrani a p?ili? malo na system, ktery slou?i k podpo?e obchodnich proces?.
• Prototypy funguji velmi dob?e pro u?ivatelske rozhrani, rozvr?eni obrazovky a tok obrazovek, ale nejsou tak u?ite?ne pro davkove nebo asynchronni procesy, ktere mohou obsahovat komplexni aktualizace databaze nebo kalkulace.

Prototypy mohou byt 'flat diagrams' (dale jen 'wireframes') nebo funk?ni aplikace vyu?ivajici syntetizovanych funk?nosti. Wireframes jsou vyrab?ny v r?znych grafickych designech a ?asto bez jakychkoli barev v softwarovem designu (tj. pou?ivat paletu barev ?ede). Finalni software bude mit graficky design obdobneho charakteru. To pomaha zabranit nejasnostem ohledn? kone?ne vizualniho vzhledu aplikace.

Use cases [ editovat | editovat zdroj ]

Use case ( p?ipady (po)u?iti ) modelovani je technika pro nalezeni a zdokumentovani ve?kerych pou?iti (funkcionalit) systemu. Vyu?iva se jak pro systemy zcela nove, tak p?i zm?nach system? provozovanych. Ka?dy use case poskytuje jeden nebo vice scena?? , ktere zaznamenavaji, jak by system m?l interagovat s koncovym u?ivatelem, p?ipadn? i jinym systemem (obecn? je system nebo u?ivatel ozna?ovan terminem akter), k dosa?eni konkretnich cil? ( u?itek plynouci z pou?iti systemu). Use case modely zpravidla vytva?i business analytik ve spolupraci se zadavatelem, resp. kli?ovymi u?ivateli systemu.

Pro vytvo?eni Use case modelu posta?i i jednoduche nastroje (textovy editor) na popsani chovani softwaru nebo systemu. Use case modely obsahuji ve form? scena?? u?iti textovy popis v?ech mo?ny zp?sob?, jak u?ivatel (akter) m??e pracovat se softwarem nebo systemem. Tyto scena?e bli?e rozvad?ji jednotlive kroky akter? a reakce modelovaneho systemu. M??e jit o scena?e jednoduche i slo?it?ji v?tvene, nebo alternativni. V?dy by v?ak m?ly byt stru?n? psane, jasne a m?ly by poskytovat p?esnou informaci o popisovane akci. P?i psani scena?? se u?iti obvykle nepou?iva technicky jazyk, ale je preferovan jazyk koncoveho u?ivatele nebo domenoveho experta .

Softwarova specifikace po?adavk? [ editovat | editovat zdroj ]

Softwarova specifikace po?adavk? (SRS) je uplny popis chovani systemu, ktery ma byt vyvinut. Obsahuje soubor use cases, ktere popisuji v?echny interakce u?ivatele se softwarem. Use case je obvykle rozvedenim funk?nich po?adavk?. Krom? use cases, RS obsahuje take nefunk?ni (nebo dopl?kove) po?adavky. Nefunk?ni po?adavky softwarove architektury jsou po?adavky, ktere kladou omezeni na navrh a provedeni (nap?iklad po?adavky na vykonnost, standardy kvality, nebo designove omezeni).

Doporu?ene postupy pro specifikaci po?adavk? na software, jsou popsany v ISO/IEC/IEEE 29148:2018 ^[5] . Tato norma popisuje mo?nou strukturu, ?adouci obsah a kvalitu softwarove specifikace po?adavk?.

Typy po?adavk? [ editovat | editovat zdroj ]

Po?adavky jsou kategorizovane n?kolika zp?soby. Nasledujici kategorizace po?adavk? je z technickeho pohledu (technical managment): ^[1] ;Po?adavky zakaznik? : Specifikace po?adavk? a p?edpoklad?, ktere ur?uji o?ekavani od systemu vzhledem na sledovane cile, prost?edi, omezeni a metriky efektivnosti a vhodnosti (MOE / MOS). Zakaznici jsou ti, kte?i vykonavaji osm primarnich funkci systemoveho in?enyrstvi, se zvla?tnim d?razem na operatora jako na kli?oveho zakaznika. Provozni po?adavky budou definovat zakladni pot?eby a minimaln? odpov?di na otazky polo?ene v nasledujicim vy?tu: ^[1]

* Operativni distribuce nebo nasazeni : Kde bude system pou?ivan?

* Profil mise nebo scena? : Jak bude system splnit sve poslani nebo cil?

* Vykon a souvisejici parametry : Jake jsou kli?ove parametry systemu pro spln?ni cile?

* Vyu?iti prost?edi: Jak jsou jednotlive komponenty systemu pou?ity?

* Po?adavky na efektivitu: Jak u?inny nebo efektivni system musi byt p?i pln?ni sveho poslani?

* Provozni ?ivotny cyklus : Jak dlouho bude system pou?ivan u?ivatelem?

* Prost?edi: V jakem p?edpokladanem prost?edi bude system pracovat?

Funk?ni po?adavky

Funk?ni po?adavky objas?ujici co se musi ud?lat a identifikuje nutne ukony, aktivity a akce, ktere musi byt vykonany. Analyza funk?nich po?adavk? bude pou?ita jako zaklad takzvane toplevel funkce systemu pro funk?ni analyzu. ^[1]

Vykonnostni po?adavky

Kriterium stanovujici do kdy nebo jak musi byt funkce nebo ?innost vykonana; obvykle metrika ve vztahu pokud jde o mno?stvi, jakosti, pokryti, aktualnosti nebo pohotovosti. B?hem analyzy po?adavk?, celkova kvalita a vykonnost (performance ? jak dob?e se to muset byt u?in?no), budou na zaklad? po?adavk? interaktivn? vyvinute v ramci v?ech identifikovanych funkci vzhledem na system ?ivotniho cyklu faktor?. ^[1]

Designove po?adavky

Po?adavky na procesy vyjad?ena v technickych datovych bali?cich a technickych p?iru?kach. ^[1]

Odvozene po?adavky

Po?adavky, ktere jsou transformovany z po?adavk? vy??i urovn?. Nap?iklad, po?adavky na dlouhy dojezd nebo vysokou rychlost vozidla vytva?i po?adavek na jeho nizkou hmotnost. ^[1]

Alokovane po?adavky

Po?adavky, ktere vznikly rozd?lenim nebo alokovanim tzv. high-level po?adavku. ^[1]

Jine ?len?ni nap?. metoda FURPS

Analyza po?adavku problemy/dotazy [ editovat | editovat zdroj ]

Stakeholder problemy/dotazy [ editovat | editovat zdroj ]

Steve McConnell ve sve knize Rapid Development , popisuje ?adu zp?sob?, jak mohou u?ivatele brzdit spravu po?adavk?:

• U?ivatele nerozum?ji tomu, co cht?ji, nebo nemaji jasnou p?edstavu o svych po?adavcich
• U?ivatele neschvali seznam sepsanych po?adavku jako finalni
• U?ivatele trvaji na novych po?adavcich i po zafixovani naklad? a ?asoveho harmonogramu
• Komunikace s u?ivateli je pomala
• U?ivatele se nepodileji na kontrolach, nebo jsou neschopni je ud?lat
• U?ivatele jsou technicky nevzd?lani
• U?ivatele nerozum?ji procesu vyvoje
• U?ivatele nev?di o sou?asne technologii

To m??e vest k situaci, kdy u?ivatele pr?b??n? p?idavaji a m?ni sve po?adavky, i kdy? vyvoj systemu nebo produktu ji? byl zahajen.

In?enyr/vyvoja? ? problemy/dotazy [ editovat | editovat zdroj ]

Mo?ne problemy zp?sobene in?eny?i a vyvoja?i za b?hu analyzy po?adavk? jsou:

• Technicky personal a koncovi u?ivatele mohou pou?ivat odli?ny odborny jazyk. V d?sledku toho se mohou v?ichni myln? domnivat, ?e jsou v perfektni shod?, dokud neni hotovy produkt dodan.
• Tym technik? a vyvoja?? p?izp?sobi po?adavek tak, aby odpovidal stavajicimu systemu, misto aby vytvo?ili system vhodny pro specificke pot?eby klienta.
• Analyza m??e byt provad?na in?enyry nebo programatory a ne lidmi, kte?i maji znalosti a nadani spravn? porozum?t pot?ebam klienta.

Mo?ne ?e?eni [ editovat | editovat zdroj ]

Jeden pokus o ?e?eni problem? komunikace by mohlo byt zam?stnavat specialisty v byznysu nebo systemove analyze.

Techniky, ktere p?inesl rok 1990 jako Unified Modeling Language (UML), use case , Agilni softwarove metody vyvoje jsou ur?eny take jako ?e?eni problem?, s nimi? se potkali u p?edchozi metody. Take nove t?idy simulace aplikaci , nebo pou?iti nastroje pro definici aplikaci, ktere vstoupilo na trh. Tyto nastroje jsou navr?eny tak, aby p?eklenuly propast mezi byznys u?ivateli a IT organizaci ? a take, aby aplikace, mohly byt otestovany na trhu (test marketed) p?edtim ne? je v?bec n?jaky kod vytvo?en. Nejlep?i z t?chto nastroj? nabizi:

• Elektronicka tabule pro na?rt pou?iti tok? a test alternativ
• Schopnost zachytit byznys logiku a datove pot?eby
• Schopnost generovat High Fidelity prototypy, ktere v?rn? imituji finalni aplikaci
• Interaktivita
• Schopnost p?idat jine kontextove po?adavky a p?ipominky
• Schopnost pro vzdalene a distribuovane u?ivatele spou?t?t a pracovat se simulacemi

Reference [ editovat | editovat zdroj ]

V tomto ?lanku byl pou?it p?eklad textu z ?lanku Requirements analysis na anglicke Wikipedii.

Literatura [ editovat | editovat zdroj ]

• MCCONNELL, Steve. Rapid Development: Taming Wild Software Schedules . 1st. vyd. Redmond, WA: Microsoft Press, 1996. Dostupne online . ISBN   1-55615-900-5 .  
• WIEGERS, Karl E. Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle . 2nd. vyd. Redmond: Microsoft Press, 2003. Dostupne online . ISBN   0-7356-1879-8 .  
• Andrew Stellman and Jennifer Greene. Applied Software Project Management . Cambridge, MA: O'Reilly Media, 2005. Dostupne online . ISBN   0-596-00948-8 .  

Externi odkazy [ editovat | editovat zdroj ]

• Obrazky, zvuky ?i videa k tematu analyza po?adavk? na Wikimedia Commons
• Requirements Engineering Process "Goodies"
• Requirements Engineering: A Roadmap (PDF) article by Bashar Nuseibeh and Steve; Easterbrook, 2000.
• Undreamt Requirements Analysis
• Getting Started With Use Cases
• 830-1984 ? IEEE Guide to Software Requirements Specifications . [s.l.]: [s.n.], 1984. ISBN   978-0-7381-4418-4 . DOI 10.1109/IEEESTD.1984.119205 .   Je zde pou?ita ?ablona {{ Cite book }} ozna?ena jako k ?pouze do?asnemu pou?iti“.
• 830-1993 ? IEEE Recommended Practice for Software Requirements Specifications . [s.l.]: [s.n.], 1994. ISBN   978-0-7381-4723-9 . DOI 10.1109/IEEESTD.1994.121431 .   Je zde pou?ita ?ablona {{ Cite book }} ozna?ena jako k ?pouze do?asnemu pou?iti“.
• 830-1998 ? IEEE Recommended Practice for Software Requirements Specifications . [s.l.]: [s.n.], 1998. ISBN   978-0-7381-0332-7 . DOI 10.1109/IEEESTD.1998.88286 .   Je zde pou?ita ?ablona {{ Cite book }} ozna?ena jako k ?pouze do?asnemu pou?iti“.
• 29148-2011 - Systems and software engineering ? Life cycle processes ? Requirements engineering . [s.l.]: [s.n.], 2011. Dostupne online . ISBN   978-0-7381-6591-2 . DOI 10.1109/IEEESTD.2011.6146379 . S. 1?94.   Je zde pou?ita ?ablona {{ Cite book }} ozna?ena jako k ?pouze do?asnemu pou?iti“. ("This standard replaces IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 ? http://standards.ieee.org/findstds/standard/29148-2011.html ")
• LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements: A Use Case Approach . 2nd. vyd. [s.l.]: Addison-Wesley, 2003. ISBN   978-0321122476 .   Je zde pou?ita ?ablona {{ Cite book }} ozna?ena jako k ?pouze do?asnemu pou?iti“.
• GOTTESDIENER, Ellen. The Software Requirements Memory Jogger: A Desktop Guide to Help Business and Technical Teams Develop and Manage Requirements . [s.l.]: Addison-Wesley, 2009. ISBN   978-1576811146 .   Je zde pou?ita ?ablona {{ Cite book }} ozna?ena jako k ?pouze do?asnemu pou?iti“.
• WIEGERS, Karl; BEATTY, Joy. Software Requirements, Third Edition . [s.l.]: Microsoft Press, 2013. ISBN   9780735679665 .   Je zde pou?ita ?ablona {{ Cite book }} ozna?ena jako k ?pouze do?asnemu pou?iti“.
• IEEE SRS Template - rick4470/IEEE-SRS-Tempate [online]. [cit. 2017-12-27]. Dostupne online .   Je zde pou?ita ?ablona {{ Cite web }} ozna?ena jako k ?pouze do?asnemu pou?iti“.
• TAAFFE, Ed. Mr [online]. [cit. 2019-02-02]. Dostupne online .   Je zde pou?ita ?ablona {{ Cite web }} ozna?ena jako k ?pouze do?asnemu pou?iti“.