Követelmény

A mérnöki tudományban a követelmény olyan szükséglet, amelyet egy adott elemnek ki kell elégítenie ahhoz, hogy elfogadható legyen.

A követelményeket számos mérnöki területen alkalmazzák, beleértve a mérnöki tervezést, a rendszertervezést, a szoftvertervezést, a vállalati tervezést, a termékfejlesztést és a folyamatoptimalizálást .

A követelmény egy viszonylag tág fogalom, amely leírhat bármilyen szükséges vagy kívánt funkciót, attribútumot, képességet, jellemzőt vagy minőséget egy rendszer esetében, hogy értéket és hasznosságot nyújtson egy ügyfél, szervezet, felhasználó vagy más érdekelt fél számára.

A specifikáció vagy "spec" egy követelményrendszer, amelyet jellemzően a fejlesztők használnak a termékfejlesztés tervezési szakaszában, valamint a tesztelők az ellenőrzési folyamat során.

Az iteratív és inkrementális fejlesztéseknél, mint például az agilis szoftverfejlesztés, a követelmények a tervezéssel és megvalósítással párhuzamosan alakulnak ki. A vízesés modellnél a követelmények a tervezés vagy a megvalósítás megkezdése előtt teljesülnek.

A kifejezés eredete

A követelmény kifejezést legalább az 1960-as évek óta használják a szoftvermérnöki közösségben. [1]

Az Útmutató a Business Analysis Body of Knowledge® 2. verziójához (BABOK) [2] szerint a követelmény a következő:

  1. Egy feltétel vagy képesség, amelyre egy érdekelt félnek szüksége van egy probléma megoldásához vagy egy cél eléréséhez.
  2. Egy feltétel vagy képesség, amelynek teljesülnie kell vagy amelyet birtokolnia kell egy megoldásnak vagy megoldáskomponensnek egy szerződés, szabvány, specifikáció vagy más formálisan előírt dokumentum kielégítése érdekében.
  3. Egy feltétel vagy képesség dokumentált ábrázolása az (1) vagy (2) pont szerint.

Ez a meghatározás az IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology szabványon alapul. [3]

Rendszer vs. folyamati követelmények

A követelmények két területre vonatkoznak:

  • A termékkövetelmények előírják egy rendszer vagy termék tulajdonságait..
  • A folyamatkövetelmények előírják azokat a tevékenységeket, amelyeket a fejlesztő szervezetnek végre kell hajtania. Például a folyamatkövetelmények meghatározhatják az alkalmazandó módszertanokat és azokat a korlátozásokat, amelyeket a szervezetnek be kell tartania.

A termék- és folyamatkövetelmények szorosan összefüggenek; a termékkövetelményről azt lehet mondani, hogy meghatározza a folyamatkövetelmény támogatásához szükséges automatizálást, míg a folyamatkövetelményről azt lehet mondani, hogy meghatározza a termékkövetelmény támogatásához szükséges tevékenységeket. Például egy maximális fejlesztési költségkövetelmény (folyamatkövetelmény) előírható a maximális eladási ár követelményének (termékkövetelmény) elérésének elősegítése érdekében; azt a követelményt, hogy a termék karbantartható legyen (termékkövetelmény), gyakran bizonyos fejlesztési stílusok (pl. objektumorientált programozás ), stílus-útmutatók vagy egy felülvizsgálati/ellenőrzési folyamat (folyamatkövetelmények) követésének előírásával oldják meg.

A követelmények típusai

A követelményeket általában a fejlesztési folyamat különböző szakaszaiban előállított típusokba sorolják, a taxonómia az alkalmazott általános modelltől függ. Például a következő sémát az International Institute of Business Analysis dolgozta ki a Business Analysis Body of Knowledge-ban [4] (lásd még a FURPS-t és a követelmények típusait ).

Építészeti követelmények
Az építészeti követelmények megmagyarázzák, hogy mit kell tenni a rendszerstruktúra és a rendszer viselkedésének szükséges integrációjának azonosításával, azaz egy rendszer rendszerarchitektúrájával .
A szoftverfejlesztésben ezeket architekturálisan jelentős követelményeknek nevezik, amelyek olyan követelmények, amelyek mérhető hatással vannak a szoftverrendszer architektúrájára . [5]
Üzleti követelmények
A szervezet céljainak, feladatainak vagy igényeinek magas szintű megfogalmazása. Általában olyan lehetőségeket írnak le, amelyeket egy szervezet meg akar valósítani, vagy problémákat, amelyeket meg akarnak oldani. Gyakran szerepel üzleti ügyekben .
Felhasználói (érintettek) követelmények
Középszintű nyilatkozatok egy adott érdekelt fél vagy érintett csoport szükségleteiről. Általában leírják, hogy valaki hogyan kíván kapcsolatba lépni a tervezett megoldással. Gyakran középpontként működik a magas szintű üzleti követelmények és a részletesebb megoldási követelmények között.
Funkcionális (megoldási) követelmények
Általában részletes nyilatkozatok a képességekről, viselkedésről és információkról, amelyekre a megoldásnak szüksége lesz. Ilyen például a szöveg formázása, egy szám kiszámítása, egy jel modulálása. Néha képességeknek is nevezik őket.
Szolgáltatásminőségi (nem funkcionális) követelmények
Általában részletes nyilatkozatok arról, hogy a megoldásnak milyen feltételek mellett kell hatékonynak maradnia, milyen tulajdonságokkal kell rendelkeznie a megoldásnak, vagy milyen korlátok között kell működnie. [6] Példák: megbízhatóság, tesztelhetőség, karbantarthatóság, rendelkezésre állás. Jellemzőknek, megszorításoknak vagy jogosítványoknak is nevezik őket .
Megvalósítási (átmeneti) követelmények
Általában a képességek vagy viselkedés részletes kimutatásai csak a vállalat jelenlegi állapotából a kívánt jövőbeli állapotba való átmenet lehetővé tételéhez szükségesek, de ezt követően már nem lesz szükség. Példák közé tartozik a toborzás, a szerepkörök változása, az oktatás, valamint az adatok egyik rendszerről a másikra történő migrálása.
Szabályozási követelmények
Törvényekben (szövetségi, állami, önkormányzati vagy regionális), szerződésekben (feltételek és feltételek) vagy szabályzatokban (vállalati, részleg- vagy projektszintű) meghatározott követelmények.

A jó követelmények jellemzői

A jó követelmények jellemzőit a különböző írók eltérően fogalmazzák meg, és általában minden író az általános vitához vagy az adott technológiai területhez leginkább megfelelő jellemzőket emeli ki. A következő jellemzők azonban általánosan elismertek. [7] [8]

Jellemző Magyarázat
Egységes (összefüggő) A követelmény egy és egyetlen dologra vonatkozik.
teljes A követelmény egy helyen teljes egészében meg van fogalmazva, hiányzó információk nélkül.
Következetes A követelmény nem mond ellent semmilyen más követelménynek, és teljes mértékben összhangban van minden hiteles külső dokumentációval.
Nem konjugált ( atomi ) A követelmény atomi, azaz nem tartalmaz kötőszót. Pl.: "Az irányítószám mezőben érvényesíteni kell az amerikai és a kanadai irányítószámokat" két külön követelményként kell írni: (1) "Az irányítószám mezőben érvényesíteni kell az amerikai irányítószámokat" és (2) "Az irányítószám mezőben érvényesíteni kell a kanadai irányítószámokat" kódok".
Nyomon követhető A követelmény teljes egészében vagy részben kielégíti az érdekelt felek által megfogalmazott és hitelesen dokumentált üzleti igényt.
Jelenlegi A követelmény az idő múlásával nem évült el.
Félreérthetetlen A követelmény tömören, szakzsargon, mozaikszavak (kivéve, ha a Követelmények dokumentumban máshol van meghatározva) vagy más ezoterikus szóhasználat nélkül fogalmazva. Objektív tényeket fejez ki, nem szubjektív véleményeket. Egy és egyetlen értelmezés tárgya. A homályos alanyok, melléknevek, elöljárószavak, igék és szubjektív kifejezések kerülendők. A negatív és összetett állítások kerülendők.
Fontosság meghatározása Számos követelmény olyan, az érintettek által meghatározott jellemzőt képvisel, amelynek hiánya jelentős vagy akár végzetes hiányossághoz vezet. Mások olyan funkciókat képviselnek, amelyek megvalósíthatók, ha az idő és a költségvetés lehetővé teszi. A követelménynek meg kell határoznia a fontossági szintet.
Igazolható A követelmény megvalósítása alapvető lehetséges módszerekkel határozható meg: ellenőrzés, demonstráció, teszt (műszeres) vagy elemzés (validált modellezés és szimuláció is).

Számos további tulajdonságot kell figyelembe venni, amelyek hozzájárulnak a követelmények minőségéhez. Ha a követelményekre az adatintegritás szabályai vonatkoznak (például), akkor a pontosság/helyesség és az érvényesség/jogosultság is méltó tulajdonságok. A nyomon követhetőség megerősíti, hogy a meghatározott követelmény kielégíti az igényt (nem több - és nem kevesebb, mint amennyi szükséges).

A fentiekhez néhányan hozzáteszik az Externally Observable (külsőleg megfigyelhető) tulajdonságot is, vagyis a követelmény olyan jellemzőt határoz meg, amely a termék külsőleg megfigyelhető vagy a felhasználó által tapasztalható tulajdonsága. Az ilyen jogvédők azzal érvelnek, hogy azok a követelmények, amelyek a belső architektúrát, tervezést, megvalósítást vagy tesztelési döntéseket határozzák meg, valószínűleg korlátozások, és egyértelműen a követelmények dokumentum korlátozások részében kell szerepelniük. Az ellentétes nézet az, hogy ez a perspektíva két ponton kudarcot vall. Először is, a perspektíva nem ismeri fel, hogy a felhasználói élményt a felhasználó által nem érzékelhető követelmények támogathatják. Például a geokódolt információk felhasználó számára történő bemutatására vonatkozó követelményt támogathatja egy külső, harmadik fél üzleti partnerrel való interfész követelménye. Az interfész a felhasználó számára észrevehetetlen lesz, bár az interfészen keresztül kapott információk bemutatása biztosan nem lesz az. Másodszor, egy korlátozás a tervezési alternatívákat korlátozza, míg egy követelmény a tervezési jellemzőket határozza meg. Például, egy webszolgáltatási interfész kiválasztását előíró követelmény különbözik egy olyan korlátozástól, amely a tervezési alternatívákat a Single Sign-On architektúrával kompatibilis módszerekre korlátozza.

Igazolás

Minden követelménynek ellenőrizhetőnek kell lennie. A leggyakoribb módszer a tesztelés. Ha ez nem lehetséges, akkor más ellenőrzési módszert kell alkalmazni (például elemzés, bemutató, ellenőrzés vagy a tervezés felülvizsgálata).

Bizonyos követelmények már szerkezetüknél fogva nem ellenőrizhetők. Ide tartoznak azok a követelmények, amelyek szerint a rendszer soha vagy mindig nem mutathat fel egy adott tulajdonságot. Ezeknek a követelményeknek a megfelelő tesztelése végtelen tesztelési ciklust igényelne. Az ilyen követelményeket át kell fogalmazni, hogy ellenőrizhetők legyenek. Amint fentebb említettük, minden követelménynek ellenőrizhetőnek kell lennie.

A nem funkcionális követelményeket, amelyek szoftverszinten nem ellenőrizhetők, továbbra is meg kell őrizni a vevői szándék dokumentációjaként. Azonban ezeket olyan folyamatkövetelményekhez lehet kapcsolni, amelyek gyakorlati módon biztosítják ezek teljesítését. Például a hátsó ajtóktól való mentességre vonatkozó nem funkcionális követelmény kielégíthető, ha lecseréljük a páros programozás használatára vonatkozó folyamatkövetelményre. Az egyéb nem funkcionális követelmények más rendszerelemekre vonatkoznak, és ezen a szinten ellenőrizhetők. Például a rendszer megbízhatóságát gyakran rendszerszintű elemzéssel igazolják. A bonyolult biztonsági követelményeivel rendelkező repüléselektronikai szoftvernek követnie kell a DO-178B fejlesztési folyamatát.

Olyan tevékenységek, amelyek a rendszer- vagy szoftverkövetelmények levezetéséhez vezetnek. A követelménytervezés magában foglalhatja a projekt megvalósíthatósági tanulmányát vagy koncepcionális elemzési szakaszát, valamint a követelmények feltárását (az érdekelt felek igényeinek összegyűjtése, megértése, áttekintése és megfogalmazása), valamint követelményelemzést, [9] elemzést (konzisztencia és teljesség ellenőrzése), specifikációt. (a követelmények dokumentálása) és az érvényesítés (a meghatározott követelmények helyességének ellenőrzése). [10] [11]

A követelmények hajlamosak a kétértelműségre, hiányosságra és következetlenségre. Az olyan technikák, mint a szigorú ellenőrzés, bizonyítottan segítenek kezelni ezeket a problémákat. A követelmények szakaszában feloldható kétértelműségek, hiányosságok és következetlenségek általában nagyságrendekkel kevesebbe kerül kijavítása, mintha ugyanezeket a problémákat a termékfejlesztés későbbi szakaszaiban találnák. A követelményelemzés ezen problémák megoldására törekszik.

A mérnöki tervezés során figyelembe kell venni azt a kompromisszumot, amely a túl homályos követelmények és azok között van, amelyek annyira részletesek, hogy

  1. sok időt vesz igénybe a gyártás – néha egészen addig, hogy a befejezés után elavulttá váljon
  2. korlátozza a rendelkezésre álló megvalósítási lehetőségeket
  3. előállítása költséges

Az agilis megközelítések ezeknek a problémáknak a leküzdésének módjaként fejlődtek ki, a követelmények magas szintű alapozásával és a részletek kidolgozásával a just-in-time vagy az utolsó felelős pillanatban .

Dokumentációs követelmények

A követelményeket általában a különböző érintettek közötti kommunikáció eszközeként írják le. Ez azt jelenti, hogy a követelményeknek könnyen érthetőnek kell lenniük mind a hétköznapi felhasználók, mind a fejlesztők számára. A követelmény dokumentálásának egyik gyakori módja annak meghatározása, hogy mit kell tennie a rendszernek. Példa: "A vállalkozónak legkésőbb xyz dátumig kell leszállítania a terméket." Az egyéb módszerek közé tartoznak a használati esetek és a felhasználói történetek .

Változások a követelményekben

A követelmények általában idővel változnak. A meghatározás és jóváhagyás után a követelményeknek a változásvezérlés alá kell tartozniuk. Sok projekt esetében a követelmények a rendszer elkészülte előtt módosulnak. Ennek oka részben a számítógépes szoftverek összetettsége és az a tény, hogy a felhasználók nem tudják, mit akarnak, mielőtt látnák. A követelményeknek ez a jellemzője követelménykezelési tanulmányokhoz és gyakorlatokhoz vezetett.

Problémák

Versengő szabványok

Számos versengő nézet létezik arra vonatkozóan, hogy mik is a követelmények, és hogyan kell őket kezelni és használni. Az iparágban két vezető szervezet az IEEE és az IIBA. Mindkét csoportnak eltérő, de hasonló meghatározása van arra, hogy mi is az a követelmény.

A szoftverkövetelmények szükségességével és hatásaival kapcsolatos viták

Sok projekt úgy sikerült, hogy a követelményeket illetően alig vagy egyáltalán nem volt egyetértés. [12] Egyes bizonyítékok azt mutatják továbbá, hogy a követelmények meghatározása csökkentheti a kreativitást és a tervezési teljesítményt [13] A követelmények hátráltatják a kreativitást és a tervezést, mivel a tervezőket túlságosan lefoglalják a megadott információk. [14] [15] [16] Általánosabban fogalmazva, egyes kutatások azt sugallják, hogy a szoftverkövetelmények olyan illúziók, amelyeket a tervezési döntések követelményként való téves ábrázolása hozott létre olyan helyzetekben, ahol nincsenek nyilvánvaló követelmények. [17]

Eközben a legtöbb agilis szoftverfejlesztési módszer megkérdőjelezi a szoftverkövetelmények szigorú előzetes leírásának szükségességét, amit mozgó célpontnak tekintenek. Ehelyett az extrém programozás például informálisan írja le a követelményeket felhasználói történetek segítségével (rövid összefoglalók, amelyek egy indexkártyára illeszkednek, és elmagyarázzák, hogy mit kell tennie a rendszernek), és a fejlesztő kötelességének tekinti, hogy közvetlenül kérjen magyarázatot az ügyféltől. Az agilis módszertanok automatizált elfogadási tesztek sorozatával próbálják rögzíteni a követelményeket.

A követelmények kúszása

Hatókör csúszás léphet fel az idő múlásával változó követelmények miatt. A Követelménykezelésben a követelmények módosítása megengedett, de ha nem követik megfelelően nyomon, vagy a megelőző lépéseket (üzleti célok, majd felhasználói követelmények) nem korlátozza további felügyelet, vagy nem kezeli költségként és potenciális programhibaként, akkor a követelmények módosítása könnyű és valószínű, hogy megtörténik. Könnyen előfordulhat, hogy a követelményváltozások gyorsabban mennek végbe, mint ahogy a fejlesztők képesek lennének munkát végezni, és ennek eredményeként a visszafelé mutató erőfeszítés.

Több követelmény szerinti taxonómia

A követelményekre vonatkozóan többféle besorolási rendszer létezik attól függően, hogy melyik keretrendszeren belül működik valaki. (Például az IEEE meghatározott szabványai, szemben az IIBA vagy az Egyesült Államok Védelmi Minisztériumának (U.S. DoD) megközelítéseivel). Különböző nyelvek és folyamatok különböző helyszíneken vagy a hétköznapi beszédben zavart és eltérést okozhatnak a kívánt folyamattól.

Folyamatkorrupciók

Az emberek által irányított folyamat ki van téve a kormányzás emberi hibáinak, ahol a kényelem, a vágyak vagy a politika kivételekhez vagy a folyamat egyenes felforgatásához vezethetnek, és eltérhetnek a tankönyv szerint a folyamattól. Példák erre:

  • A szigorúság nélküli folyamat nem kap tiszteletet - Ha a kivételek vagy változtatások gyakoriak, például az azt működtető szervezet kevés függetlenséggel vagy hatalommal rendelkezik, vagy nem megbízható és átlátható a nyilvántartásban, az ahhoz vezethet, hogy az egész folyamatot figyelmen kívül hagyják.
  • Új szereplők, akik át akarnak tenni – pl. az új emberek természetes tendenciája, hogy meg akarják változtatni elődjük munkáját, hogy demonstrálják hatalmukat vagy értékigényeiket, például egy új vezérigazgató, aki meg akarja változtatni az előző vezérigazgató tervezését, beleértve az üzleti célokat is. valami (például egy szoftvermegoldás) már fejlesztés alatt áll, vagy egy újonnan létrehozott irodai objektumok egy projekt jelenlegi fejlesztéséhez kapcsolódnak, mert még nem léteztek a felhasználói követelmények kialakításakor, ezért erőfeszítéseket tesznek a projekt visszalépésére és alapozására.
  • A vonalakon kívüli színezés – például a nagyobb ellenőrzést igénylő felhasználók nem csak olyan dolgokat írnak be, amelyek megfelelnek a "felhasználói követelmény" vagy a prioritási szint követelménykezelési definíciójának, hanem beszúrnak tervezési részleteket vagy előnyben részesített szállítói jellemzőket felhasználói követelményként, vagy mindent, amit az irodájuk mond a legmagasabb értéknek. lehetséges prioritás.
  • Késői megjelenés – pl. kevés erőfeszítést tesz, vagy egyáltalán nem tesz erőfeszítést a követelmények feltárása terén a fejlesztés előtt. Ennek oka lehet az, hogy azt gondolják, hogy az egyéni részvételtől függetlenül ugyanazt az előnyt fogják kapni, vagy hogy nincs értelme, ha csak a tesztelési szakaszban és a következő pörgetésben beilleszthetik a követelményeket, vagy az a preferencia, hogy mindig igazuk legyen az utómunkára várva. kritika.
  • a Pentagon Warsban bemutatott alkalmi követelmények mozgalmának M-2 Bradley kérdései;
  • a Fighter maffia könnyűsúlyú vadászgép-koncepciójából az F-16-os növekedés, amelyet az F-15 programnak tulajdonítanak, amely megpróbálta szabotálni a versenyt, vagy az egyes irodákat, amelyek helyi vágyakat támasztanak alá, és aláássák a könnyű súly és az alacsony költség fogalmát.
  • lelkesedés kb. 1998-ban a „Net-Ready” a Net-Ready iroda kulcsfontosságú teljesítményparaméterként való megbízatásához vezetett, az irodán kívül, amely meghatározza a követelményeket, és nincs összhangban az adott iroda korábban meghatározott folyamatával, annak meghatározásával, hogy mi volt a KPP, vagy hogy bizonyos erőfeszítések lehet, hogy nem megfelelő vagy nem képes meghatározni, hogy mi minősül „Net-Ready”-nek.

Lásd még

Hivatkozások

  1. ↑ Boehm, Barry (2006). „A view of 20th and 21st century software engineering”.: 12–29, University of Southern California, University Park Campus, Los Angeles, CA: Association for Computing Machinery, ACM New York, NY, USA. 
  2. ↑ 1.3 Key Concepts - IIBA | International Institute of Business Analysis. www.iiba.org. (Hozzáférés: 2016. szeptember 25.)
  3. ↑ IEEE SA - 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology
  4. ↑ Iiba. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0 (2009). ISBN 978-0-9811292-1-1 
  5. ↑ Chen (2013). „Characterizing Architecturally Significant Requirements”. IEEE Software 30 (2), 38–45. o. DOI:10.1109/MS.2012.174.  
  6. ↑ Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136
  7. ↑ Davis, Alan M.. Software Requirements: Objects, Functions, and States, Second Edition. Prentice Hall (1993). ISBN 978-0-13-805763-3 
  8. ↑ IEEE Computer Society. IEEE Recommended Practice for Software Requirements Specifications. Institute of Electrical and Electronics Engineers, Inc (1998). ISBN 978-0-7381-0332-7 
  9. ↑ Stellman, Andrew. Applied Software Project Management [archivált változat]. O'Reilly Media, 98. o. (2005). ISBN 978-0-596-00948-9 [archiválás ideje: 2015. február 9.] 
  10. ↑ Wiegers, Karl E.. Software Requirements, Second Edition. Microsoft Press (2003). ISBN 978-0-7356-1879-4 
  11. ↑ Young, Ralph R.. Effective Requirements Practices. Addison-Wesley (2001). ISBN 978-0-201-70912-4 
  12. ↑ Checkland, Peter. System Thinking, System Practice. Chichester: Wiley (1999. június 5.) 
  13. ↑ (2015. május 1.) „Is Requirements Engineering Inherently Counterproductive?”., Florence, Italy: IEEE. 
  14. ↑ Jansson (1991. június 5.). „Design fixation”. Design Studies 12 (1), 3–11. o. DOI:10.1016/0142-694X(91)90003-F.  
  15. ↑ Purcell (1996. június 5.). „Design and other types of fixation”. Design Studies 17 (4), 363–383. o. DOI:10.1016/S0142-694X(96)00023-3.  
  16. ↑ (2014. május 1.) „Requirements Fixation”., Hyderabad, India: IEEE. 
  17. ↑ Ralph (2012). „The Illusion of Requirements in Software Development”. Requirements Engineering 18 (3), 293–296. o. DOI:10.1007/s00766-012-0161-4.  

Külső linkek

  • A rendszerkövetelmények feltárása