Rendszerelemzés az IT-ban

From Systems analysis Wiki
Jump to navigation Jump to search

Rendszerelemzés az IT-ban (Systems Analysis and Design) — az információs rendszerek tervezésének és fejlesztésének megközelítése az ötlettől az üzemeltetésig, amely magában foglalja az igények feltárását, a követelmények formalizálását, a szakterület és a folyamatok modellezését, valamint az alternatívák és kockázatok értékelését. Más szóval, az IT-beli rendszerelemzés az a fejlesztési szakasz, amelynek során a szakemberek megvizsgálják a feladatot, meghatározzák, hogy mit kell a rendszernek elvégeznie, és kidolgozzák a megvalósítás megoldásait.

A klasszikus rendszerelemzés alkalmazási területek széles spektrumát fedi le, nemcsak a szoftverfejlesztést, hanem a szervezeti változásokat, stratégiákat és egyéb aspektusokat is.[1] [2]

Rendszerelemzés tárgya és feladatai az IT-ban

A rendszerelemzés tárgya az IT-ban az információs rendszer (szoftvertermék és/vagy szolgáltatás) a teljes életciklusa során — az ötlettől és az indoklástól a megvalósításig és az üzemeltetésig.

A rendszerelemzés feladata — az üzleti igények átalakítása összehangolt és ellenőrizhető követelmények és architekturális döntések halmazává: az érdekeltek céljainak és korlátainak feltárása és dokumentálása, a követelmények formalizálása, a szakterület és a folyamatok modellezése, az alternatívák megvalósíthatóságának és kockázatainak értékelése, valamint a kiválasztott architektúra indoklása. Ennek eredményeképpen összehangolt dokumentumok jönnek létre, és nyomon követhető kapcsolatok jönnek létre a követelmények, a tervezési döntések és a tesztek között. Ez biztosítja a fejlesztési folyamat irányíthatóságát és kontrollját.

A rendszerelemzés feladatai a következők:

  • Az érdekeltek igényeinek és céljainak feltárása. Az elemző összegyűjti és pontosítja a megrendelők, felhasználók és egyéb érdekelt felek elvárásait; interjúkat, kérdőíveket, megfigyelést és a jelenlegi folyamatok elemzését alkalmazzák. A kimenetben elkészül az elsődleges követelmény-specifikáció, funkcionális („mit kell a rendszernek tennie") és nemfunkcionális (megbízhatóság, teljesítmény, biztonság stb.) követelményekre bontva.[1][2]
  • A követelmények formalizálása és dokumentálása. Az igényeket ellenőrizhető követelményekké alakítják át. Egy jól megfogalmazott követelménynek világosnak és egyértelműnek, teljesnek, következetesnek, ellenőrizhetőnek és a magasabb szintű célokhoz visszavezethetőnek kell lennie; a követelmények halmaza — összehangoltnak és egységesnek.[3][4] A gyakorlatban szabványosított dokumentumokat alkalmaznak: SRS (Software Requirements Specification) az ISO/IEC/IEEE 29148 szerint, valamint egyes ágazatokban URS (User Requirements Specification) és funkcionális specifikációkat.[5][6][7]
  • A rendszer elemzése és modellezése. Annak megértéséhez, hogy hogyan fog működni a rendszer és hogyan lép kapcsolatba a külvilággal, modelleket építenek: Use Case-diagramokat a használati forgatókönyvekhez, DFD-ket az adatáramlásokhoz és üzleti folyamatokhoz, osztály-/komponensdiagramokat stb. A modellek alapul szolgálnak az alternatív megoldások és architektúrák összehasonlításához.[8][9][10]
  • Megvalósíthatóság értékelése és megoldásválasztás. Feasibility study (technikai, szervezeti, gazdasági, ütemezési megvalósíthatóság) és architekturális alternatívák összehasonlítása (trade-off) zajlik. Az architektúra minőségi attribútumok (pl. teljesítmény, skálázhatóság, módosíthatóság) szerinti értékeléséhez olyan módszereket alkalmaznak, mint az ATAM (Architecture Tradeoff Analysis Method).[11][12] A monolitikus és mikroszolgáltatás-alapú architektúra közötti választás [3] explicit kompromisszumokon alapul (üzemeltetési komplexitás vs. független skálázhatóság és szállítási sebesség) az ipari útmutatók ajánlásai szerint.[13][14]
  • Tervezési artefaktumok előkészítése. Az elemzés eredményeképpen elkészül:
    • a jóváhagyott követelmény-specifikáció (a követelmények fontosságának megjelölésével),
    • a rendszer fogalmi modellje (diagramok/leírások),
    • architekturális és tervezési döntések (adatsémák, külső rendszerek interfészei),
    • megvalósítási terv (szakaszok/modulok).
    • Kritikus a követelmények nyomon követhetőségének (bidirectional traceability) biztosítása a tervezési elemekhez és a tesztekhez.[15][4]

Az IT-projekt sikerének nagy része az érett követelmény- és architektúra-kezelési gyakorlatokon múlik. A McKinsey és az Oxford által végzett kutatás kimutatta, hogy a nagy IT-projektek gyakran túllépik a költségvetést és a határidőket. Ez a kutatás azt is hangsúlyozta, milyen fontos a stratégia megfelelő kezelése, az érdekelt felekkel való együttműködés és a követelmények gondos összegyűjtése. Mindez erősen befolyásolhatja a projekt sikerét vagy bukását.[16]

Megközelítések és módszertanok az IT rendszerelemzésben

A rendszerelemzés az IT-ban a rendszergondolkodás elvein és a szoftverfejlesztésre adaptált módszertanokon alapul. A gyakorlatban kombinálják a „kemény" és „lágy" megközelítéseket, a strukturális módszertanokat, az objektumorientált notációkat, valamint a folyamat- és követelmény-modellező nyelveket.

  • Kemény és lágy megközelítések. Az IT-projektekben a kemény megközelítés (hard systems) előzetesen formalizálható célokat és követelményeket feltételez, dekomponál és „felülről lefelé" tervez. A lágy megközelítést (soft systems) homályos célok és többféle nézőpont esetén alkalmazzák: a Soft Systems Methodology (SSM) elemeit használják (pl. rich picture, gyökérdefiníciók, CATWOE) a problémamegértés és a kívánt változások összehangolásához; majd az eredményeket formális követelményekre fordítják le.[17][18]
  • SSM (Soft Systems Methodology) módszertan. Eredetileg Peter Checkland által szervezeti változásokra kidolgozott SSM hasznos az IT előprojekt szakaszaiban: a problémás helyzet feltárásától és a gyökérdefiníciók megfogalmazásától (beleértve a CATWOE-t is) a fogalmi modellek valósággal való szembesítéséig és az érdekeltek közötti közeledés eléréséig.[19][20]
  • Strukturált módszertanok: SADT/IDEF0. A SADT a rendszert funkciók hierarchiájaként modellezi; az IDEF0 (IEEE 1320.1) szabványos notáció rögzíti a funkciókat és azok I-C-O-M-interfészeit (Inputs, Controls, Outputs, Mechanisms). A módszer alkalmas funkcionális dekompozícióra és a rendszer határainak összehangolására az algoritmusoktól függetlenül.[21][22]
  • Objektumorientált elemzés: UML és SysML (MBSE). Az UML alapvető nyelvvé vált a követelmények és a tervezés számára (Use Case-, osztály-, szekvenciadiagramok stb.), és megkönnyíti a forgatókönyvek validálását a felhasználókkal; a SysML kiterjeszti az UML-t a rendszertervezés számára (követelmény-diagramok, parametrikus diagramok), és az MBSE megközelítésre épül, ahol a modell a követelményektől a tesztekig minden szakaszon átívelő központi artefaktum.[23][24][25]
  • Üzleti folyamatok modellezése: BPMN. A BPMN szabványt a folyamatok grafikus leírásához használják (poolok, munkafolyamatok, események, átjárók), beleértve az as-is/to-be összehasonlítást a követelménymeghatározásokban és az integrációban.[26][27]
  • Kapcsolat a követelménytervezéssel. A folyamat magában foglalja az elicitation–analysis–specification–validation–change management szakaszokat; a „jó követelmény" kritériumait és az SRS struktúráját az ISO/IEC/IEEE 29148 szabályozza. A priorizáláshoz MoSCoW (Must/Should/Could/Won't) technikákat és többkritériumos kiválasztási módszereket alkalmaznak, például AHP-t. Az agilis folyamatokban a rendszerelemzési tevékenység a backlog refinement és a követelmények nyomon követhetőségében jelenik meg.[28][29][30][31]
  • Kapcsolat a rendszertervezéssel. Összetett (kiberfizikai) rendszerek esetén a V-modellt alkalmazzák: a „bal" ágon — rendszerelemzés és architektúra, a „jobb" ágon — integráció, verifikáció és validáció a bal ág artefaktumaihoz kötve. A minőségi attribútumok szerinti architektúraértékelési módszerek közé tartozik az ATAM (trade-off elemzés).[32][33]

Az IT rendszerelemzése bevált megközelítéseket kombinál — a látásmód összehangolásának lágy módszereitől a formális notációkig és szabványokig. Az eszközök megválasztását a feladat meghatározottságának foka határozza meg: nagy bizonytalanság esetén az SSM és a facilitáció szerepe erősödik, egyértelmű határok esetén — a formális modellek (UML/SysML, IDEF0, BPMN) és a szabályozások.

Kapcsolat az IT-architektúrával és a vállalati architektúrával

Az IT-projektekben végzett rendszerelemzés szorosan kapcsolódik az architekturális tervezéshez. Az elemző és az architekt szerepe átfed: az elemző megfogalmazza a követelményeket és a logikai modellt, az architekt meghatározza a megoldás célszerkezetét és a technikai kompromisszumokat; a munka közösen zajlik.

  • IT-rendszerek architektúrája. Szűk értelemben a szoftverarchitektúra a komponensek szervezete, kapcsolataik és a megoldás tervezésekor irányadó elvek. Az elemzőnek fontos figyelembe venni az architekturális stílusokat (réteges, kliens–szerver, mikroszolgáltatás-alapú, eseményvezérelt stb.), mivel a nemfunkcionális követelmények (megbízhatóság, skálázhatóság, módosíthatóság) gyakran meghatározzák az architekturális döntéseket és azok kompromisszumait.[34][35] Az elemzés korai szakaszában kialakítják az architekturális látásmódot (high-level vision) és kidolgozzák a megoldás vázlatos körvonalát a követelmények életképességének ellenőrzéséhez (az iterációk hossza és a részletezettség a módszertantól függ).[36]
  • Sablonok és előzetes megoldások. A nemfunkcionális követelmények kielégítéséhez architekturális mintákat (architectural patterns) alkalmaznak. Például aszinkron kommunikációhoz és laza kapcsoláshoz — publish–subscribe üzenetközvetítőn keresztül az eseményvezérelt architektúrában.[37]
  • TOGAF (The Open Group Architecture Framework). Az egyik legelterjedtebb vállalati architektúra keretrendszer; tartalmazza az ADM módszert (Architecture Development Method) és az architektúra-kezelés artefaktumait (repozitórium, katalógusok/mátrixok, elvek). A TOGAF-ban a követelmény-kezelés az ADM összes fázisába integrált átfogó folyamat.[36] A követelmények és a nyomon követhetőség támogatásához katalógusokat és mátrixokat használnak (pl. követelmények ↔ szolgáltatások, funkciók ↔ komponensek), és megkülönböztetik az Architecture Building Blocks és a Solution Building Blocks fogalmát.[38][39] A vállalati elveket és szabványokat a megfelelő katalógusokban rögzítik, és ezek a projektcsapatok számára külső nemfunkcionális követelményekként szolgálnak.[40] A megoldások célarchitektúrának való megfelelőségét az architekturális compliance eljárással (Architecture Compliance Review) erősítik meg.[41] A TOGAF megközelítés előzetes Architecture Vision és azt követő részletezést (adat/alkalmazás/technológia) feltételez, migrációs tervvel és a követelmény-változások kezelésével.[42][43]
  • Zachman Framework. A vállalati architektúra artefaktumainak korai és befolyásos ontológiája, 6×6-os mátrixként ábrázolva (perspektívák × „mit/hogyan/hol/ki/mikor/miért" szempontok). A „tervező" sor a rendszerelemzéssel és -tervezéssel áll összefüggésben; az oszlopok meghatározzák az adatok, funkciók/folyamatok, szerepek, helyszínek és motiváció vizsgálatának teljességét. A keretrendszer osztályozásként (nem módszertanként) szolgál, és segít biztosítani a megoldás leírásának teljességét a vállalati környezetben.[44]
  • Kapcsolat a vállalati architektúrával (Enterprise Architecture, EA). A rendszerelemző az EA kontextusában dolgozik: az új követelmények az üzleti képességekhez és az operatív modellhez vezethetők vissza; a vállalat szabványait és elvi korlátait alkalmazzák (biztonság, kompatibilitás stb.).[45][36] Az inicializálás szakaszában kialakítják az Architecture Visiont (célok/korlátok, általános követelmények), majd az elemző részletezi, megőrizve a nyomon követhetőséget a látásmódhoz és a vállalati szabványokhoz; a szabványok be nem tartását az architekturális felülvizsgálatokon tárják fel, ami a megoldás módosításához vezethet.[36][46]

Összefoglalva: a rendszerelemzés és az architekturális tervezés alkotja a „követelmények → architekturális döntések → minőségi attribútumokon alapuló kompromisszumok" kapcsolatot. A módszerek megválasztását (stílusok/minták, TOGAF artefaktumok, Zachman-osztályozás) a projekt jellege és a vállalati architektúra kerete határozza meg.

Folyamatok és gyakorlatok

A rendszerelemzés a szoftver teljes fejlesztési és üzemeltetési életciklusába integrálódik, összekapcsolva az üzleti célokat, az architektúrát és a szállítást. Magában foglalja az előprojektes kutatást, a megközelítés megválasztását, ellenőrizhető artefaktumok kialakítását, valamint a megbízhatóságra, teljesítményre, biztonságra és karbantarthatóságra vonatkozó követelményeket. A vízesés modellben az elemzés a tervezés és megvalósítás előtt zajlik, az agilis módszerekben — folyamatosan, iterációkon keresztül, a DevOps-ban — az üzemeltetési célokra helyezve a hangsúlyt. A megközelítéstől függetlenül az elemzés biztosítja a nyomon követhetőséget, a változás- és kockázatkezelést, az architekturális kompromisszumok dokumentálását és a szabályozási korlátok betartását, így a fejlesztés kiszámíthatóvá és irányíthatóvá válik.

  • Klasszikus SDLC (Waterfall). A System Analysis & Requirements Definition szakasz megelőzi a tervezést és a megvalósítást; a követelményeket részletes SRS-ben rögzítik a tervezés és a szerződések alapjaként. Stabil és szabályozott szakterületeken hatékony; a követelmények „befagyasztásának" kockázatait SRR/felülvizsgálatok és változáskezelés csökkenti CCB-n keresztül.[47][48][49]
  • Agilis módszertanok (Agile). Az elemzés folyamatos: a végső SRS helyett elfogadási kritériumokkal rendelkező user story-kból álló termék-backlogot vezetnek, amelyet backlog refinement során pontosítanak; BDD-t (Given–When–Then) alkalmaznak; az egységes architektúra elvesztésének kockázatát korai architekturális kidolgozással és átlátható követelmény- ↔ megvalósítás/tesztek nyomon követhetőséggel kompenzálják.[50][51][52]
  • DevOps és SRE. A gyakori kiadások alapértelmezett üzemeltetési követelményeket igényelnek: automatizálás, megfigyelhetőség, visszaállítás. A nemfunkcionális követelményeket SLO/SLI-ként fogalmazzák meg, error budget-et kezelnek; a backlogba naplók/metrikák/trace-ek/riasztások feladatait adják hozzá; a kiesés nélküli kiadáshoz — blue/green és egyéb minták.[53][54][55]
  • Követelmény- és kockázatkezelés. Az ALM-ben a követelményeknek állapotaik és kapcsolataik vannak feladatokkal/kiadásokkal/hibákkal; kötelező a version control, a change impact analysis és a rendszeres repriorizálás.[56][57]
  • Minőségbiztosítás (QA). A minőséget a követelmények szakaszán fektetik le: felülvizsgálat, „Three Amigos", Acceptance Test Plan, elfogadási kritériumok automatizált tesztjei (BDD/ATDD).[58][59]
  • Megfigyelhetőség és megbízhatóság. A követelmények tartalmazzák az SLA/SLO-t, MTTR-t és MTBF-et mérhető célokkal és ellenőrzési módszerekkel; a paraméterek az üzlettől/üzemeltetéstől érkeznek, és beépülnek az architektúrába és a megbízhatósági tesztekbe.[60][61]

Metrikák és artefaktum-minőség

A rendszerelemző munkájának és eredményei minőségének értékeléséhez általánosan elfogadott kritériumokat alkalmaznak. A minőségi követelmények és modellek — a sikeres projekt alapjai, ezért az egész életciklus alatt kezelik őket (elicitation → specification → verification/validation → change management). A követelmények minőségi alapattribútumait az ISO/IEC/IEEE 29148 és (történetileg) az IEEE 830 szabványok rögzítik.[3][62][1]

  • Helyesség (Correctness) — a követelmény a tényleges igényt tükrözi, és egyeztetett a szakterület szakértőivel; validálással erősítik meg (review/inspection, prototípusok, forgatókönyvek).[1][4]
  • Teljesség (Completeness) — figyelembe veszik az lényeges szempontokat és feltételeket.
    • Egyedi követelmény teljessége: a szükséges részletek megadottak (pl. „a jelzőlámpa piros állapotba vált hiba esetén", nem csak „pirossá válik").
    • Specifikáció teljessége: lefedik a forgatókönyveket/szerepeket, meghatározzák az NFR-eket; ellenőrzőlistákkal és üzleti célokhoz való nyomon követhetőséggel érhető el; hasznos a teljesség független auditja (QA/review).[3][63]
  • Egyértelműség (Unambiguity) — a megfogalmazások egyetlen módon értelmezhetők; segít a szószedet, a „a rendszer A-t kell tennie, ha B, amennyiben C"-szerű sablonok, példák; a diagramokat jelmagyarázat kíséri. Ellenőrzés — a „négy szem" elve.[3][1]
  • Konzisztencia (Consistency) — a követelmények nem mondanak ellent egymásnak és a külső korlátoknak; strukturálást, összesített attribútumtáblázatokat, csapatfelülvizsgálatokat alkalmaznak; ellenőrzik a szabályozásokat/szabványokat.[3][63]
  • Ellenőrizhetőség/tesztelhetőség (Verifiability) — a teljesítés teszttel/demonstrációval/elemzéssel igazolható; az ellenőrizhetetlen megfogalmazásokat mérhető kritériumokra cserélik; NFR-ekhez metrikákat adnak meg, és előre rögzítik az elfogadási kritériumokat.[3][63]
  • Módosíthatóság és nyomon követhetőség (Modifiability & Traceability) — egyedi azonosítók, logikus szerkezet („egy gondolat — egy bekezdés"), duplikátumok hiánya; a „követelmény ↔ forrás/cél/tervezés/teszt" kapcsolatokat fenntartják, nyomon követhetőségi mátrixot (RTM) vezetnek.[64][3]
  • Rangsorolás és priorizálás — a követelmények halmazának minősége; MoSCoW és MCDM technikákat alkalmaznak (pl. AHP); a priorizálás az üzlettel együtt befolyásolja a tervezést és a kockázatokat.[65][66]

A követelmények minőségének mérőszámai (példák):[63][1]

  • követelmény-hibák sűrűsége (megjegyzések száma 100 követelményre);
  • az alap rögzítése utáni változások száma;
  • lefedettségi metrikák: tesztekkel rendelkező követelmények aránya; üzleti célokhoz nyomon követhető követelmények aránya;
  • követelmény-stabilitás (hozzáadott/eltávolított követelmények aránya az összes követelményhez egy adott időszakban);
  • a specifikáció mérete/összetettsége (átlagos követelményszám egy use case-ben, a dekompozíció mélysége);
  • az érdekeltek elégedettsége (felmérés).

Érett folyamatokban (pl. CMMI 3+ szint) követelmény-minőségi szabályozások érvényesek: formális ellenőrzések, sablonmegfelelési auditok, metrikák gyűjtése/elemzése.[67] Kritikus szakterületeken (avionika, űrtechnika stb.) formális módszereket alkalmaznak a megbízhatóság növelésére.[68]

Tipikus hibák

Az IT-projektekben gyakran fordulnak elő rendszerelemzési hibák: hiányos és kétértelmű követelmények, ellentmondások, elmosódott határok, a nemfunkcionális szempontok figyelmen kívül hagyása, hiányzó integráció és elkésett biztonság. Ez átdolgozáshoz, késedelemhez, megnövekedett költségekhez és hibákhoz vezet.

Tipikus problémák, következményeik és megelőzési módjaik.

  • Hiányos és elmulasztott követelmények. Kimaradnak a különleges jogosultságú szerepek, határesetek és NFR-ek. Következmények: architekturális átdolgozás és az indítás elhalasztása. Hogyan kerüljük el: ellenőrzőlisták, „mi van, ha…" ötletbörze, korai tesztelők bevonása, üzleti célokhoz való nyomon követhetőség.[1][69]
  • Homályos, kétértelmű megfogalmazások. Következmények: a fejlesztők „mást" valósítanak meg, a megrendelő elégedetlen. Hogyan kerüljük el: mérhető kritériumok, szószedet, „A, ha B, amennyiben C" sablonok, peer‑review.[3][69]
  • Ellentmondó követelmények. Következmények: késedelmek a pontosításokban, átdolgozások az integráció során. Hogyan kerüljük el: strukturálás, üzleti szabályok/szabályozások összevetése, konfliktusmegoldó foglalkozások, konzisztencia-ellenőrzés a felülvizsgálaton.[3][1]
  • „Arany bevonat" szindróma (gold‑plating). Következmények: a terjedelem növekedése, bonyolódás, új meghibásodási pontok. Hogyan kerüljük el: minden követelményt célhoz/metrikához kötni; Agile-ban — ne adjunk feleslegeset a backloghoz; rögzítsük a hatókört; lásd YAGNI.
  • Szükségtelen helyen alkalmazott túlzott részletezés. Hogyan kerüljük el: a mit/miért (követelmények) elkülönítése a hogyan-tól (tervezés/megvalósítás); design‑free requirements alkalmazása ott, ahol indokolt.[3]
  • A követelmény-kezelhetőség megsértése. Következmények: verzióközeli zavar, „nem a megfelelő" megvalósítása. Hogyan kerüljük el: egységes igazságforrás az ALM-ben, előzmények és állapotok, RTM és change impact analysis; változáskezelés CCB-n keresztül.[64][1]
  • A felhasználók részvételének hiánya. Hogyan kerüljük el: interjúk, megfigyelés, prototípusok, rendszeres bemutatók; explicit validálás az érdekeltekkel.[3][1]
  • Túl hosszú „elemzési bénultság". Hogyan kerüljük el: elégségességi zóna, iterativitás és timeboxing; MVP/inkrementumok elindítása és visszajelzések alapján való korrekció.[1]
  • Nemfunkcionális követelmények figyelmen kívül hagyása. Hogyan kerüljük el: NFR-ek kiemelése (pl. FURPS+), mérhető kritériumok meghatározása, beépítésük a tesztelési tervbe és az architekturális döntésekbe.[1][3]
  • Kommunikációs hibák és „emberi tényező". Hogyan kezeljük: az interjúkészítés és a facilitáció fejlesztése, semlegesség megőrzése, döntések és követelményforrások rögzítése (nyomon követhetőség a célokhoz).[1]

A legtöbb probléma a megfogalmazások minőségére, a követelmények teljességére és kezelhetőségére vezethető vissza; az ISO/IEC/IEEE 29148 szabványok és a SWEBOK gyakorlatok (validálhatóság, nyomon követhetőség, iterativitás) alkalmazása jelentősen csökkenti a határidő-csúszások és az átdolgozások kockázatát.[3][1]

Korlátok

Annak ellenére, hogy hatékony a bizonytalanság csökkentésében, a rendszerelemzésnek megvannak a maga korlátai:

  • A valóság változékony és összetett. Nem lehet minden tényezőt figyelembe venni, különösen hosszú távú projektek esetén. Egyes követelmények elkerülhetetlenül csak a rendszer indítása után derülnek ki. Fontos törekedni a meglepetések minimalizálására, de fel kell készülni a változásokra.
  • A követelmények emberektől függenek. Az üzleti prioritások, a törvények és a piac változhatnak. A rendszerelemzés rögzíti a jelenlegi állapotot, és nem képes megjósolni az összes külső változást. Az alkalmazkodáshoz rendszeresen frissíteni kell a követelményeket és iteratívan kell dolgozni.
  • A felhasználók nem mindig tudják, mit akarnak, amíg nem látják. Ez ismert korlát. A prototípusok és az agilis módszertanok, mint például az Agile, segítenek leküzdeni ezt a problémát. A papíralapú elemzésnek megvannak a határai, és a pontos adatokhoz szükség van a megvalósítások visszajelzéseire.
  • Egyensúly az idő és a minőség között. A túlzottan részletes elemzés elavulhat. Az innovatív területeken jobb gyorsan létrehozni egy minimálisan életképes terméket (MVP) és valós adatokat szerezni. A rendszerelemzés stabil területeken hatékony, de kutatási projektekben (R&D) szerepe korlátozott.
  • Emberi tényező. Még a legjobb módszertanok sem kompenzálják az elemző inkompetenciáját vagy a megrendelő elérhetetlenségét. Fontos, hogy a folyamat összes résztvevője bevont és motivált legyen.

A modern technológiák hatása az IT rendszerelemzésére

Az IT rendszerelemzése folyamatosan fejlődik a technológiai innovációk hatására. A XXI. századi elemző az adatok robbanásszerű növekedésének, az AI mindenütt való elterjedésének, a gyors fejlesztési ciklusnak és a fokozott biztonsági figyelemnek a körülményei között dolgozik. A sikeres rendszerelemzési gyakorlat új ismeretek (Data Science, kiberbiztonság, felhőtechnológiák) elsajátítását és rugalmasságot igényel a módszerek alkalmazásában.

  • Adatok és AI/ML: mi adódik az elemzéshez. AI-val rendelkező rendszerek esetén már az elején rögzítik az alkalmazás céljait és kontextusát, az adatforrások és az adatminőség követelményeit, valamint a modell döntéseibe vetett bizalom mérőszámait (megbízhatóság, biztonság, magyarázhatóság, adatvédelem, méltányosság). Tervezik a TEVV (testing, evaluation, verification, validation) ellenőrzéseket, az üzemeltetési monitoringot és a modell biztonságos leállítását/kivonását. Ezek a lépések megfelelnek az AI kockázatkezelés NIST-keretrendszerének GOVERN–MAP–MEASURE–MANAGE funkcióinak; ezeket az SRS-ben, az architektúrában és a verifikációs/üzemeltetési tervekben tükrözik.[70]
  • DevSecOps: biztonság „balra tolva" és alapértelmezés szerint. A biztonság beépítése a CI/CD minden szakaszába normává válik: automatikus ellenőrzések (SAST/DAST), függőségek és konténerek szkennelése, telepítési politikák, alapszintű megfigyelhetőség. Megbízható artefaktum-nyilvántartásokat és szabványosított „hardened" képeket használnak; zero trust elveket alkalmaznak. A rendszerelemzésben előre leírják a folyamat ellenőrzőpontjait (szakaszátengedési feltételek), a követelmények és a biztonsági vezérlők kapcsolatát, és a környezetek közötti átmenet szabályait (dev/test/stage/prod).[71]
  • Mi változik a dokumentumokban (artefaktumokban). Mely rész jelenik meg vagy pontosodik a kulcsdokumentumokban Big Data és AI/ML esetén, illetve DevSecOps szerint végzett munka esetén:
    • SRS / Követelmény-specifikáció: az AI alkalmazásának céljai és kontextusa; az adatok követelményei (eredet, minőség, etikai és jogi korlátok); modell-metrikák (pontosság, megbízhatóság, válaszidő); TEVV terv (testing, evaluation, verification, validation); átláthatóság/magyarázhatóság és adatvédelmi követelmények; a modell leállítási/kivonási kritériumai.[70]
    • Architektúra és döntések (Architecture, ADR): a fenyegetésmodellezés eredményei; „alapértelmezett biztonság" intézkedések (titkosítás, hozzáférés-vezérlés, titkosság-kezelés, legkisebb jogosultság elve); adat/modellhasználati korlátok; ADR-bejegyzések kockázatértékeléssel és kompromisszumokkal.[71][70]
    • Verifikációs és validációs terv (V&V / TEVV): modellek és adatok tesztelési forgatókönyvei; minőségi metrikák elfogadási küszöbei; adat-/modelleltolódás monitoringja; időszakos újraértékelési és újravalidálási eljárások.[70]
    • CI/CD politikák és folyamat „kapuk": automatikus SAST/DAST, SCA (függőségek), konténer-szkennelési ellenőrzések; artefaktumok aláírása és megbízható nyilvántartásokban való tárolása; a környezetek közötti előléptetési szabályok (dev/test/stage/prod) és az ellenőrzési kudarcok esetén a build blokkolásának feltételei; alapértelmezett megfigyelhetőségi követelmények.[71]
    • Adat- és modellkezelési terv: forráskatológus és lineage; az adatok minőségi és rendelkezésre állási kritériumai; adatkészletek/modellek verziói; (újra)tanítási ütemezés és bias-ellenőrzés; hozzáférési és tárolási politika; a modell biztonságos deaktiválásának és az adatok törlésének terve, ha szükséges.[70]
    • Üzemeltetés és megfigyelhetőség (Ops/Runbook): AI megbízhatóság-metrikák és SLO-k; audit és naplózás; degradációs/anomália-riasztások; incidenskezelési terv; fallback/kill‑switch az AI-komponensekhez; jelentéstételi és utólagos incidenselemzési követelmények.[70][71]
    • Nyomon követhetőség (end‑to‑end): explicit kapcsolatok „követelmény ↔ vezérlő/ellenőrzés a folyamatban\" és „követelmény ↔ teszt/monitoring az üzemeltetésben\" között, hogy a biztonság és a minőség az egész életcikluson át bizonyíthatóan ellenőrizhető legyen.[71][70]
  • A rendszerelemző szerepe.
    • kezeli az AI kontextusát és kockázatait (szereplők, alkalmazási forgatókönyvek, adatok feltételezései és korlátai);
    • biztosítja a „követelmény ↔ biztonsági vezérlő a folyamatban\" nyomon követhetőséget;
    • ellenőrizhető nemfunkcionális követelményeket fogalmaz meg (biztonság, átláthatóság, megfigyelhetőség) a rendszer teljes életciklusán át.[70][71]

Különbségek a klasszikus rendszerelemzéstől

A „rendszerelemzés" kifejezés történetileg tágabb a szoftverfejlesztésnél. A klasszikus rendszerelemzés — összetett interdiszciplináris feladatok (társadalmi, gazdasági, irányítási) megoldásának megközelítése, amely rendszerszemléleten és kvantitatív módszereken alapul, általában a vezetői döntések támogatására. Az IT-ban a rendszerelemzés alatt a szoftverfejlesztés mérnöki területén belüli alkalmazott diszciplínát értik, amely az információs rendszerek létrehozására irányul.

Alább a főbb különbségek.

  • Az elemzés céljai és tárgya. A klasszikus elemzés rosszul strukturált, „elmosódott" problémákat old meg, és már meglévő szociotechnikai rendszereket fejleszt (városi közlekedési hálózat, vállalati stratégia, környezetpolitika). A tárgy — a valós rendszer; a feladat — segíteni a döntéshozónak a cselekvési irány megválasztásában. Az IT rendszerelemzés célja — egy új információs rendszer vagy szoftvertermék tervezése és létrehozása, amely megfelel a követelményeknek. A tárgy — a tervezett rendszer; a fókusz — a felhasználók által szükséges viselkedés és jellemzők.
  • Módszertani alapok. A klasszikus iskolák rendszerszemléleten és gyakran matematikán alapulnak. A kemény megközelítés (hard systems) — a probléma formalizálása, kvantitatív kritériumok, optimalizálás (mint az operations research-ben). A lágy módszertanok (soft systems) elismerik a nézőpontok sokféleségét; példa — a Soft Systems Methodology (SSM), ahol megbeszéléseken és fogalmi modelleken keresztül összehangolják a kívánt változásokat. Az IT-ban az alap — a mérnöki diszciplínák: követelménytervezés, szoftvertervezés, architekturális keretrendszerek. Szabványosított folyamatokat (ISO/IEC/IEEE 15288, 12207, 29148), UML/SysML notációkat és változáskezelési gyakorlatokat alkalmaznak.
  • Szerepek és artefaktumok. A klasszikus elemzésben a „rendszerelemző" szerepe gyakran informális; az eredmények — elemzési jelentés, ajánlások, matematikai modellek, „mi-ha" forgatókönyvek. Az IT-ban az elemző (vagy üzleti elemző) szerepe formalizált; követelmény-specifikációkat, rendszermodelleket (UML, ER), interfész-specifikációkat, user story-kat és backlogot adnak ki — olyan artefaktumokat, amelyeket közvetlenül a fejlesztők és tesztelők használnak.
  • Életciklus és folyamat. A klasszikus elemzésnek nincs egységes sablonja: a lépések a problémától függenek (SSM-ben — a helyzet vizsgálatától a változások bevezetéséig). Az IT-ban szabványos SDLC ciklusokat alkalmaznak: a vízesés modellben külön követelmény-elemzési fázis van; iteratív és agilis megközelítésekben az elemzés minden sprint állandó tevékenysége. A modern gyakorlatok (DevOps, CI/CD) kiterjesztik az elemzés kereteit az üzemeltetésre: figyelembe veszik a karbantarthatóság, a megfigyelhetőség és a frissíthetőség követelményeit. Más szóval, az IT rendszerelemzése be van ágyazva a fejlesztési életciklusba, míg a klasszikus elemzést gyakran projektjellegű/tanácsadói tevékenységként végzik.

Rendszerelemző

A rendszerelemző az IT-ban — olyan szakember, aki felelős a rendszerszemléletért az információs rendszerek tervezésében és fejlesztésében: a követelmények kialakításában és validálásában, a modellezésben (UML/BPMN), az architekturális döntések összehangolásában és az integráció biztosításában. A szerepet és a képesítési követelményeket az Orosz Föderációban a szakmai szabvány és a szövetségi állami oktatási szabvány rögzíti.

A szakmai tevékenység fő célja: Annak biztosítása, hogy az IT-szolgáltatás, az automatizált rendszer, az automatizált információs rendszer, az automatizált irányítási rendszer, a szoftver-, információs termék vagy eszköz (a továbbiakban: Rendszer) megfeleljen a környezetnek, a kiindulási követelményeknek és korlátoknak, az automatizálás és az automatizált tevékenység céljainak, minőségi és összehangolt tervezési döntések kidolgozása és átadása révén az érdekelt feleknek, az egyes végrehajtók munkájának elindítása és koordinálása során a Rendszer teljes életciklusán át („Rendszerelemző" szakmai szabvány (az Orosz Föderáció Munkaügyi Minisztériumának 2023.04.27-i, 367н számú rendelete).[72]

A kulcsfogalmak szótára

Alapfogalmak és résztvevők

  • Rendszerelemzés az IT-ban — olyan diszciplína, amelynek tárgya az információs rendszer a teljes életciklusán át, az ötlettől az üzemeltetésig.
  • Érdekeltek (Stakeholderek) — személyek vagy csoportok, akik érdekeltek a projektben vagy érintve vannak általa (megrendelők, felhasználók, menedzserek).
  • Tervezési artefaktumok — a projekt során létrehozott dokumentumok és eredmények, mint például specifikációk, modellek, tervek és döntések.

Követelmények: típusok és dokumentáció

  • Funkcionális követelmények — leírják, mit kell a rendszernek tennie; annak funkcióit és viselkedését.
  • Nemfunkcionális követelmények — leírják a rendszer minőségi attribútumait (megbízhatóság, teljesítmény, biztonság, használhatóság, skálázhatóság stb.).
  • Követelmény-specifikáció (elsődleges) — a projekt kezdeti szakaszaiban összegyűjtött kiindulási követelményeket tartalmazó dokumentum.
  • SRS (Software Requirements Specification) — szabványosított dokumentum, amely részletesen leírja a szoftverkövetelményeket a nemzetközi szabványok szerint (pl. ISO/IEC/IEEE 29148).
  • URS (User Requirements Specification) — dokumentum, amely leírja a felhasználó rendszerrel szemben támasztott követelményeit az üzleti folyamatok és a végfelhasználói elvárások szempontjából.
  • Architekturálisan jelentős követelmények (ASR) — olyan követelmények, amelyek lényegesen befolyásolják az architekturális döntéseket és kompromisszumokat.
  • Keresztfunkcionális követelmények (CFR) — a nemfunkcionális követelmények szinonimája, hangsúlyozva azok átfogó jellegét.
  • Elfogadási kritériumok (Acceptance Criteria) — ellenőrizhető feltételek, amelyek teljesülése esetén a követelményre vonatkozó munka elfogadottnak tekinthető.
  • Definition of Ready (DoR) — megállapodás a backlog-elem fejlesztésre való készségéről (egyértelműség, becslés, kritériumok).
  • Definition of Done (DoD) — megállapodás a munka „befejezettségéről" (kód, tesztek, dokumentáció, telepítés).
  • Korlát (Constraint) — kemény feltétel, amely korlátozza a megoldásokat (határidők, platformok, szabványok, licencek).
  • Feltételezés (Assumption) — bizonyítás nélkül elfogadott feltevés, amely utólagos validálást igényel.
  • Követelmények minősége — az ISO 29148 szerinti tulajdonságok: egyértelműség, teljesség, konzisztencia, ellenőrizhetőség, atomicitás.

Követelmények formalizálása, nyomon követhetősége és priorizálása

  • Követelmények formalizálása — az informális igények egyértelmű, ellenőrizhető és egyértelmű követelményekké alakításának folyamata.
  • Követelmények nyomon követhetősége — a követelmény életciklusának nyomon követési lehetősége a forrástól a megvalósításig, a tesztelésen és a telepítésen át.
  • Kétirányú nyomon követhetőség (Bidirectional traceability) — a követelmények, a tervezési elemek és a tesztelési forgatókönyvek közötti kapcsolatok előre- és visszairányban történő nyomon követésének képessége.
  • MoSCoW — a követelmények priorizálási technikája, amely Must-have (kell lennie), Should-have (kellene lennie), Could-have (lehetne) és Won't-have (nem lesz) kategóriákba sorolja azokat.
  • BDD (Behavior-Driven Development) — fejlesztési módszertan, amelyben a teszteket természetes nyelven írják, a rendszer felhasználói szempontú viselkedésére összpontosítva (Given–When–Then formátum).

Notációk és modellezés

  • UML (Unified Modeling Language) — szabványosított grafikus modellező nyelv szoftverrendszerek komponenseinek specifikálásához, vizualizálásához, felépítéséhez és dokumentálásához.
  • SysML (Systems Modeling Language) — az UML kiterjesztése a rendszertervezés számára, amely támogatja az összetett rendszerek különböző aspektusainak modellezését, beleértve a követelményeket, a viselkedést, a struktúrát és a paramétereket.
  • BPMN (Business Process Model and Notation) — grafikus notáció szabványa az üzleti folyamatok leírásához, amely lehetővé teszi a munkafolyamatok, események, átjárók és poolok vizualizálását.
  • MBSE (Model-Based Systems Engineering) — rendszertervezési megközelítés, amelyben a modell a rendszer életciklusának minden szakaszán átívelő központi artefaktum, a követelményektől a tesztelésig.
  • ArchiMate — vállalati architektúra notáció (üzlet, alkalmazások, technológiák) és azok kapcsolatai.
  • DMN (Decision Model and Notation) — üzleti döntések és szabálytáblázatok modellezése.
  • DFD (Data Flow Diagram) — adatáramlási diagramok (kontextus, dekompozíciós szintek).
  • ERD (Entity-Relationship Diagram) — a szakterület modellje entitásokkal, kapcsolatokkal és attribútumokkal.
  • CRUD-mátrix — a Create/Read/Update/Delete műveletek hozzárendelése az entitásokhoz és szerepekhez/funkciókhoz.

Architekturális stílusok és megoldásértékelés

  • Monolitikus architektúra — architekturális megközelítés, amelynek során az egész rendszert egyetlen, oszthatatlan modulként fejlesztik.
  • Mikroszolgáltatás-alapú architektúra — architekturális megközelítés, amelynek során a rendszer kis, egymástól függetlenül telepíthető és skálázható szolgáltatások halmazaként épül fel.
  • Trade-off (kompromisszum) — kölcsönösen kizáró vagy egymásnak ellentmondó jellemzők vagy megoldások közötti választás, ahol az egyik jellemző javítása a másik rovására megy.
  • ATAM (Architecture Tradeoff Analysis Method) — szoftverarchitektúra értékelési módszer, amelyet a minőségi attribútumok (pl. teljesítmény, skálázhatóság) közötti kompromisszumok elemzéséhez használnak.

Vállalati architektúra és keretrendszerek

  • TOGAF (The Open Group Architecture Framework) — az egyik legelterjedtebb vállalati architektúra keretrendszer, amely tartalmazza az ADM módszert (Architecture Development Method) az architektúra fejlesztéséhez és kezeléséhez.
  • Zachman Framework — a vállalati architektúra artefaktumainak ontológiája, 6×6-os mátrixként ábrázolva, amely az architektúra különböző szempontjait különböző perspektívákból osztályozza.

Elemzési megközelítések és fejlesztési folyamatok

  • Kemény megközelítés (Hard Systems) — rendszerelemzési módszertan, amely előzetesen formalizálható célokat és követelményeket feltételez, dekomponál és „felülről lefelé" tervez, hatékony egyértelműen meghatározott feladatoknál.
  • Lágy megközelítés (Soft Systems) — rendszerelemzési módszertan, amelyet homályos célok és az érdekeltek többféle nézőpontja esetén alkalmaznak, a problémamegértés és a kívánt változások összehangolására irányul.
  • SSM (Soft Systems Methodology) — Peter Checkland által kidolgozott konkrét lágy rendszerszemléletű módszertan, amely olyan eszközöket használ, mint a rich picture, a gyökérdefiníciók és a CATWOE.
  • Waterfall (vízesés modell) — klasszikus szoftverfejlesztési módszertan, amelynek során a szakaszok (elemzés, tervezés, megvalósítás, tesztelés, bevezetés) egymás után zajlanak, az előző szakasz teljes befejezése után kezdődik a következő.
  • Agile — rugalmas szoftverfejlesztési módszertanok csoportja, amely az iteratív fejlesztésre, a változásokhoz való alkalmazkodásra, a megrendelővel való együttműködésre és az érték folyamatos szállítására összpontosít.

Kiválasztási módszerek és tipikus hibák

  • AHP (Analytic Hierarchy Process) — többkritériumos kiválasztási módszer, amely lehetővé teszi az összetett problémák strukturálását és az alternatívák értékelését kritériumok hierarchiája alapján.
  • Gold-plating („arany bevonat" szindróma) — rendszerelemzési hiba, amelynek lényege az érdekeltek által nem igényelt funkcionalitás hozzáadása, ami a projekt terjedelmének és komplexitásának növekedéséhez vezet.

Hivatkozások

  • ISO/IEC/IEEE 15288:2023 — System life cycle processes
  • ISO/IEC/IEEE 12207:2017 — Software life cycle processes
  • ISO/IEC/IEEE 29148:2018 — Requirements engineering
  • ISO/IEC/IEEE 42010:2022 — Architecture description
  • ISO/IEC 25010:2023 — Product quality model (SQuaRE)
  • ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288
  • ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation)
  • ISO/IEC/IEEE 42020:2019 — Architecture processes
  • ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts
  • IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation
  • UML 2.5.1 — OMG Specification
  • BPMN 2.0.2 — OMG Specification
  • SysML v1.7 — OMG Specification
  • TOGAF Standard, 10th Edition — The Open Group
  • ArchiMate 3.2 — The Open Group
  • SEI ATAM — Architecture Tradeoff Analysis Method
  • NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF)
  • SWEBOK Guide v4.0a — IEEE Computer Society (PDF)
  • Guide to the Systems Engineering Body of Knowledge (SEBoK)
  • BABOK Guide v3 — IIBA
  • Google SRE Books — Official site
  • Microsoft Azure Well-Architected Framework — Official docs
  • Rendszerelemzés egyszerű szavakkal. YouTube
  • Rendszerelemzés az IT-ban egyszerű szavakkal. YouTube

Irodalom

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5. kiadás.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. Hivatalos ingyenes verzió.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. Hivatalos ingyenes letöltés (licenc alapján).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4. kiadás.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3. kiadás.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2. kiadás.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5. kiadás.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3. kiadás.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4. kiadás.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11. kiadás.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8. kiadás.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7. kiadás.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3. kiadás.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2. kiadás.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4. kiadás.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, 4. kiadás.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2. kiadás.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Megjegyzések

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4.0 4.1 4.2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. Определение «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (упоминает URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — требования к описанию архитектуры и точкам зрения. https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (обзор). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36.0 36.1 36.2 36.3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (спецификация). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (определение EA как «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. Репринт (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (исторический стандарт). Учебная копия (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63.0 63.1 63.2 63.3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64.0 64.1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69.0 69.1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (о типичных проблемах требований/трассируемости). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70.0 70.1 70.2 70.3 70.4 70.5 70.6 70.7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71.0 71.1 71.2 71.3 71.4 71.5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н).
Retrieved from "https://systems-analysis.info/int/index.php?title=Rendszerelemzés_az_IT-ban&oldid=6330"