Inženýrské požadavky - Requirements engineering

Inženýrské požadavky (RE)[1] je proces definování, dokumentace a údržby požadavky[2] v proces konstrukčního návrhu. Je to běžná role v systémové inženýrství a softwarové inženýrství.

První použití výrazu požadavky inženýrství byl pravděpodobně v roce 1964 v konferenčním příspěvku „Údržba, udržovatelnost a inženýrství systémových požadavků“,[3] ale k obecnému použití došlo až koncem 90. let 20. století, kdy byla vydána publikace IEEE Computer Society tutorial[4] v březnu 1997 a ustavení série konferencí o inženýrství požadavků, která se vyvinula do Mezinárodní konference o technických požadavcích.

V model vodopádu,[5] inženýrství požadavků je prezentováno jako první fáze procesu vývoje. Pozdější vývojové metody, včetně Racionální jednotný proces (RUP) pro software předpokládejme, že vývoj požadavků pokračuje po celou dobu životnosti systému.

Správa požadavků, která je dílčí funkcí postupů systémového inženýrství, je také indexována v Mezinárodní rada pro systémové inženýrství Manuály (INCOSE).

Činnosti

Činnosti spojené s inženýrstvím požadavků se velmi liší, v závislosti na typu vyvíjeného systému a konkrétních postupech organizace.[6] Mohou zahrnovat:

  1. Vznik požadavků nebo vyvolání požadavků - Setkávají se vývojáři a zúčastněné strany; posledně jmenovaní jsou dotazováni ohledně jejich potřeb a přání týkajících se softwarového produktu.
  2. Analýza požadavků a vyjednávání - identifikují se požadavky (včetně nových, pokud je vývoj iterativní) a řeší se konflikty se zúčastněnými stranami. Jako pomůcka se úspěšně používají jak písemné, tak grafické nástroje (tyto nástroje se běžně používají ve fázi návrhu, ale některé je považují za užitečné i v této fázi). Příklady nástrojů pro písemnou analýzu: případy užití a uživatelské příběhy. Příklady grafických nástrojů: UML[7] a LML.
  3. Modelování systému - Některé technické obory (nebo konkrétní situace) vyžadují, aby byl produkt kompletně navržen a vymodelován před zahájením jeho konstrukce nebo výroby. Proto musí být fáze návrhu provedena předem. Před schválením a podepsáním jakékoli smlouvy musí být například vypracovány plány budovy. Mnoho polí může odvodit modely systému s Celoživotní modelovací jazyk, zatímco ostatní mohou použít UML. Poznámka: V mnoha oblastech, jako je softwarové inženýrství, je většina činností modelování klasifikována jako konstrukční činnosti, a nikoli jako činnosti vyžadující inženýrství.
  4. Specifikace požadavků - Požadavky jsou dokumentovány ve formálním artefaktu zvaném Specifikace požadavků (RS), který se stane oficiálním až po ověření. RS může v případě potřeby obsahovat písemné i grafické (modelové) informace. Příklad: Specifikace softwarových požadavků (SRS).
  5. Ověření požadavků - Ověření, že dokumentované požadavky a modely jsou konzistentní a splňují potřeby zúčastněné strany. Pouze pokud konečný návrh projde procesem validace, RS se stává oficiálním.
  6. Správa požadavků - Správa všech činností souvisejících s požadavky od samého počátku, dohled nad vývojem systému a dokonce až po jeho uvedení do provozu (např. Změny, rozšíření atd.)

Někdy jsou prezentovány jako chronologické etapy, i když v praxi existuje značné prokládání těchto aktivit.

Ukázalo se, že inženýrství požadavků jasně přispívá k úspěchům softwarových projektů. [8]

Problémy

Jedna omezená studie v Německu představila možné problémy při implementaci požadavků na inženýrství a zeptala se respondentů, zda souhlasí, že se skutečně jedná o problémy. Výsledky nebyly prezentovány jako zobecnitelné, ale naznačovaly, že hlavními vnímanými problémy byly neúplné požadavky, pohyblivé cíle a časový rámec, přičemž menšími problémy byly komunikační nedostatky, nedostatek sledovatelnosti, terminologické problémy a nejasné odpovědnosti.[9]

Kritika

Předpokládá se, že strukturování problémů, klíčový aspekt inženýrství požadavků, sníží výkon návrhu.[10] Některé výzkumy naznačují, že je možné, že pokud dojde k nedostatkům v procesu inženýrství požadavků, což povede k situaci, kdy požadavky neexistují, mohou být požadavky na software vytvořeny bez ohledu na to, iluze zkreslování rozhodnutí o návrhu jako požadavků [11]

Viz také

Reference

  1. ^ Nuseibeh, B .; Easterbrook, S. (2000). Inženýrství požadavků: cestovní mapa (PDF). ICSE '00. Sborník z konference o budoucnosti softwarového inženýrství. str. 35–46. CiteSeerX  10.1.1.131.3116. doi:10.1145/336512.336523. ISBN  1-58113-253-0.
  2. ^
  3. ^ Dresner, K.H. Borchers (1964). Údržba, udržovatelnost a technické požadavky na systém. Světový kongres a výstava SAE 1964. Technický papír SAE 640591. doi:10.4271/640591.
  4. ^ Thayer, Richard H .; Dorfman, Merlin, eds. (Březen 1997). Inženýrství softwarových požadavků (2. vyd.). IEEE Computer Society Press. ISBN  978-0-8186-7738-0.
  5. ^ Royce, W. W. (1970). Řízení vývoje velkých softwarových systémů: koncepty a techniky (PDF). ICSE '87. Sborník z 9. mezinárodní konference o softwarovém inženýrství. s. 1–9.
  6. ^ Sommerville, Iane (2009). Softwarové inženýrství (9. vydání). Addison-Wesley. ISBN  978-0-13-703515-1.
  7. ^ „Odhalení požadavků pomocí diagramů tříd UML, část 1“. tynerblain.com. 7. března 2008. Citováno 14. března 2018.
  8. ^ Hofmann, H.F .; Lehner, F. (2001). "Požadavkové inženýrství jako faktor úspěchu v softwarových projektech". Software IEEE. 18 (4): 58–66. doi:10.1109 / MS.2001.936219. ISSN  0740-7459.
  9. ^ Méndez Fernández, Daniel; Wagner, Stefan (2015). „Pojmenování bolesti v inženýrství požadavků: Návrh pro globální skupinu průzkumů a první výsledky z Německa“. Informační a softwarová technologie. 57: 616–643. arXiv:1611.04976. doi:10.1016 / j.infsof.2014.05.008. S2CID  1924926.
  10. ^ Ralph, Paul; Mohanani, Rahul (květen 2015). „Je inženýrství požadavků ve své podstatě kontraproduktivní?“. IEEE. doi:10.13140/2.1.3831.6321. Citovat deník vyžaduje | deník = (Pomoc)
  11. ^ Ralph, P. (září 2013). "Iluze požadavků na vývoj softwaru". Inženýrské požadavky. 18 (3): 293–296. arXiv:1304.0116. Bibcode:2013arXiv1304.0116R. doi:10.1007 / s00766-012-0161-4. S2CID  11499083.

externí odkazy