Systeemanalyse in IT

From Systems analysis Wiki
Jump to navigation Jump to search

Systeemanalyse in IT (Systems Analysis and Design) — een aanpak voor het ontwerpen en ontwikkelen van informatiesystemen van concept tot exploitatie, die het inventariseren van behoeften, het formaliseren van eisen, het modelleren van het probleemdomein en processen, alsmede het beoordelen van alternatieven en risico's omvat. Met andere woorden: systeemanalyse in IT is de ontwikkelfase waarin specialisten de taak bestuderen, bepalen wat het systeem moet doen, en oplossingen voor de realisatie ervan uitwerken.

Klassieke systeemanalyse bestrijkt een breed scala aan toepassingsgebieden, niet alleen softwareontwikkeling, maar ook organisatorische veranderingen, strategieën en andere aspecten.[1] [2]

Onderwerp en taken van systeemanalyse in IT

Het onderwerp van systeemanalyse in IT is het informatiesysteem (softwareproduct en/of dienst) gedurende de gehele levenscyclus — van concept en onderbouwing tot realisatie en exploitatie.

De taak van systeemanalyse — zakelijke behoeften omzetten in een coherente en toetsbare verzameling eisen en architectuurbeslissingen: doelen en beperkingen van stakeholders inventariseren en documenteren, eisen formaliseren, het probleemdomein en processen modelleren, haalbaarheid en risico's van alternatieven beoordelen, en de gekozen architectuur onderbouwen. Als resultaat worden afgestemde documenten opgesteld en worden traceerbare verbanden gelegd tussen eisen, ontwerpbeslissingen en tests. Dit zorgt voor beheersbaarheid en controle over het ontwikkelproces.

Taken van systeemanalyse omvatten:

  • Inventariseren van behoeften en doelen van stakeholders. De analist verzamelt en verduidelijkt verwachtingen van opdrachtgevers, gebruikers en andere belanghebbenden; hierbij worden interviews, enquêtes, observatie en analyse van lopende processen toegepast. Als resultaat wordt een eerste eisenspecificatie opgesteld met onderscheid tussen functionele («wat het systeem moet doen») en niet-functionele eisen (betrouwbaarheid, prestaties, beveiliging, enz.).[1][2]
  • Formaliseren en documenteren van eisen. Verzoeken worden omgezet in toetsbare eisen. Een goed geformuleerde eis moet helder en ondubbelzinnig, volledig, niet-tegenstrijdig, toetsbaar en traceerbaar naar hogere doelstellingen zijn; de verzameling eisen moet coherent en samenhangend zijn.[3][4] In de praktijk worden gestandaardiseerde documenten gebruikt: SRS (Software Requirements Specification) conform ISO/IEC/IEEE 29148, en in bepaalde sectoren ook URS (User Requirements Specification) en functionele specificaties.[5][6][7]
  • Analyse en modellering van het systeem. Om te begrijpen hoe het systeem zal werken en met de buitenwereld zal interageren, worden modellen gebouwd: use case-diagrammen voor gebruiksscenario's, DFD voor datastromen en bedrijfsprocessen, klasse- en componentdiagrammen e.a. Modellen dienen als basis voor het vergelijken van alternatieve oplossingen en architecturen.[8][9][10]
  • Haalbaarheidsanalyse en keuze van oplossing. Er wordt een feasibility study (technische, organisatorische, economische en planningshaalbaarheid) uitgevoerd en een vergelijking van architectuuralternatieven gemaakt (trade-off). Voor het beoordelen van de kwaliteit van de architectuur op basis van attributen (bijv. prestaties, schaalbaarheid, aanpasbaarheid) worden methoden zoals ATAM (Architecture Tradeoff Analysis Method) toegepast.[11][12] De keuze tussen bijvoorbeeld monolithische en microservicesarchitectuur [3] berust op expliciete afwegingen (complexiteit van exploitatie vs. onafhankelijke schaalbaarheid en leveringssnelheid) conform aanbevelingen uit industriegidsen.[13][14]
  • Voorbereiding van projectartefacten. Na de analyse worden opgesteld:
    • goedgekeurde eisenspecificatie (met aanduiding van hun prioriteit),
    • conceptueel model van het systeem (diagrammen/beschrijvingen),
    • architectuur- en ontwerpbeslissingen (gegevensschema's, interfaces van externe systemen),
    • implementatieplan (fasen/modules).
    • Het is cruciaal om traceerbaarheid (bidirectional traceability) van eisen naar ontwerpelementen en tests te waarborgen.[15][4]

Het succes van een IT-project hangt in belangrijke mate af van volwassen praktijken op het gebied van eisen en architectuur. Onderzoek uitgevoerd door McKinsey en Oxford toonde aan dat grote IT-projecten vaak boven budget en buiten planning uitlopen. Dit onderzoek benadrukte ook hoe belangrijk een correcte beheersing van de strategie, interactie met belanghebbenden en een degelijke eisenverzameling zijn. Dit alles kan het succes of mislukken van een project sterk beïnvloeden.[16]

Benaderingen en methodologieën in IT-systeemanalyse

Systeemanalyse in IT steunt op principes van systeemdenken en aan softwareontwikkeling aangepaste methoden. In de praktijk worden «harde» en «zachte» benaderingen gecombineerd, structurele methodologieën, objectgeoriënteerde notaties, alsmede talen voor het modelleren van processen en eisen.

  • Harde en zachte benaderingen. In IT-projecten veronderstelt de harde benadering (hard systems) vooraf formaliseerbare doelen en eisen, decompositie en ontwerp «van boven naar beneden». De zachte benadering (soft systems) wordt toegepast bij onduidelijke doelen en meervoudige gezichtspunten: elementen van de Soft Systems Methodology (SSM) worden gebruikt (bijv. rich picture, worteldefenities, CATWOE) om het begrip van het probleem en de gewenste veranderingen te coördineren; daarna worden de resultaten omgezet in formele eisen.[17][18]
  • Methodologie SSM (Soft Systems Methodology). Oorspronkelijk ontwikkeld door Peter Checkland voor organisatorische veranderingen, is SSM nuttig in de voorprojectfasen van IT: van het onderzoeken van de probleemситuatie en het formuleren van worteldefenities (o.a. via CATWOE) tot het vergelijken van conceptuele modellen met de werkelijkheid en het bereiken van accommodatie tussen stakeholders.[19][20]
  • Gestructureerde methodologieën: SADT/IDEF0. SADT modelleert het systeem als een hiërarchie van functies; de standaardnotatie IDEF0 (IEEE 1320.1) legt functies en hun I-C-O-M-interfaces vast (Inputs, Controls, Outputs, Mechanisms). De methode is geschikt voor functionele decompositie en het afstemmen van systeemgrenzen onafhankelijk van algoritmen.[21][22]
  • Objectgeoriënteerde analyse: UML en SysML (MBSE). UML is de basisnotatie geworden voor eisen en ontwerp (use case-, klasse-, sequentiediagrammen e.a.) en vergemakkelijkt de validatie van scenario's met gebruikers; SysML breidt UML uit voor systeemengineering (eisendiagrammen, parametrische diagrammen) en steunt op de MBSE-aanpak, waarbij het model het centrale artefact is doorheen alle fasen van eisen tot tests.[23][24][25]
  • Modellering van bedrijfsprocessen: BPMN. De BPMN-standaard wordt gebruikt voor de grafische beschrijving van processen (pools, werkstromen, gebeurtenissen, gateways), inclusief de vergelijking van as-is/to-be in eisenspecificaties en integratie.[26][27]
  • Verband met requirements engineering. Het proces omvat de fasen elicitation–analysis–specification–validation–change management; de criteria voor «goede eisen» en de structuur van de SRS zijn vastgelegd in ISO/IEC/IEEE 29148. Voor prioritering worden technieken als MoSCoW (Must/Should/Could/Won't) en methoden voor meervoudige criteria-analyse, zoals AHP, toegepast. In agile processen komt de activiteit van systeemanalyse tot uiting in backlog refinement en traceerbaarheid van eisen.[28][29][30][31]
  • Verband met systeemengineering. Voor complexe (cyberfysische) systemen wordt het V-model toegepast: op de «linker» tak bevinden zich systeemanalyse en architectuur, op de «rechter» tak integratie, verificatie en validatie gekoppeld aan de artefacten van de linker tak. Methoden voor beoordeling van architectuur op kwaliteitsattributen omvatten ATAM (trade-off analyse).[32][33]

Systeemanalyse in IT combineert beproefde benaderingen — van zachte methoden voor het afstemmen van visie tot formele notaties en standaarden. De keuze van instrumenten wordt bepaald door de mate van duidelijkheid van de taak: bij hoge onzekerheid neemt de rol van SSM en facilitering toe, bij duidelijke grenzen domineren formele modellen (UML/SysML, IDEF0, BPMN) en regelgeving.

Verband met IT-architectuur en enterprise-architectuur

Systeemanalyse in IT-projecten is nauw verbonden met architectuurontwerp. De rollen van analist en architect overlappen: de analist formuleert eisen en het logische model, de architect bepaalt de doelstructuur van de oplossing en technische afwegingen; het werk wordt gezamenlijk uitgevoerd.

  • Architectuur van IT-systemen. In enge zin is softwarearchitectuur de organisatie van componenten, hun relaties en de principes die leidend zijn bij het ontwerp van de oplossing. Het is belangrijk voor de analist om architectuurstijlen in beschouwing te nemen (gelaagd, client–server, microservices, event-driven e.a.), omdat niet-functionele eisen (betrouwbaarheid, schaalbaarheid, aanpasbaarheid) vaak architectuurbeslissingen en hun afwegingen bepalen.[34][35] In de vroege analysefase wordt een architectuurvisie (high-level vision) gevormd en wordt een ruwe contouren van de oplossing uitgewerkt om de haalbaarheid van de eisen te toetsen (de lengte van iteraties en de mate van detaillering hangen af van de methodologie).[36]
  • Sjablonen en voorlopige oplossingen. Om niet-functionele eisen te vervullen worden architectuurpatronen (architectural patterns) toegepast. Bijvoorbeeld voor asynchrone communicatie en losse koppeling — publish–subscribe via een berichtenbroker in een event-driven architectuur.[37]
  • TOGAF (The Open Group Architecture Framework). Een van de meest verspreide frameworks voor enterprise-architectuur; omvat de ADM-methode (Architecture Development Method) en artefacten voor architectuurbeheer (repository, catalogi/matrices, principes). In TOGAF is het beheer van eisen een doorlopend proces, geïntegreerd in alle ADM-fasen.[36] Voor de ondersteuning van eisen en traceerbaarheid worden catalogi en matrices gebruikt (bijv. eisen ↔ diensten, functies ↔ componenten), en er wordt onderscheid gemaakt tussen Architecture Building Blocks en Solution Building Blocks.[38][39] Principes en standaarden van de onderneming worden vastgelegd in de betreffende catalogi en fungeren als externe niet-functionele eisen voor projectteams.[40] De conformiteit van oplossingen met de doelarchitectuur wordt bevestigd door de procedure van Architecture Compliance Review.[41] De TOGAF-aanpak veronderstelt een voorafgaande Architecture Vision en daaropvolgende detaillering (data/applicaties/technologieën) met migratieplan en beheer van eisenwijzigingen.[42][43]
  • Zachman Framework. Een vroege en invloedrijke ontologie van enterprise-architectuurartefacten, weergegeven als een 6×6-matrix (perspectieven × aspecten «wat/hoe/waar/wie/wanneer/waarom»). De rij «ontwerper» correspondeert met systeemanalyse en -ontwerp; de kolommen bepalen de volledigheid van de beschouwing van gegevens, functies/processen, rollen, locatie en motivatie. Het framework dient als classificatie (niet als methodologie) en helpt de volledigheid van de beschrijving van de oplossing in het enterprise-landschap te waarborgen.[44]
  • Verband met enterprise-architectuur (Enterprise Architecture, EA). De systeemanalyist werkt in de context van EA: nieuwe eisen worden getraceerd naar bedrijfscapaciteiten en het operationeel model; standaarden en principiële beperkingen van de onderneming worden toegepast (beveiliging, compatibiliteit, enz.).[45][36] In de initiatiefase wordt een Architecture Vision gevormd (doelen/beperkingen, samengevatte eisen), waarna de analist detailleert met behoud van traceerbaarheid naar de visie en bedrijfsstandaarden; niet-conformiteit met standaarden wordt vastgesteld bij architectuurreviews en kan leiden tot aanpassingen van de oplossing.[36][46]

Samenvatting: systeemanalyse en architectuurontwerp vormen de koppeling «eisen → architectuurbeslissingen → afwegingen op kwaliteitsattributen». De keuze van methoden (stijlen/patronen, TOGAF-artefacten, Zachman-classificatie) wordt bepaald door de aard van het project en de kaders van de enterprise-architectuur.

Processen en praktijken

Systeemanalyse wordt geïntegreerd in de gehele levenscyclus van softwareontwikkeling en -exploitatie en verbindt bedrijfsdoelen, architectuur en oplevering. Het omvat vooronderzoek, keuze van aanpak, vorming van toetsbare artefacten en eisen aan betrouwbaarheid, prestaties, beveiliging en onderhoud. In het cascademodel wordt de analyse uitgevoerd vóór ontwerp en realisatie, in agile methoden voortdurend via iteraties, en in DevOps met de nadruk op exploitatiedoelen. Ongeacht de aanpak zorgt de analyse voor traceerbaarheid, beheer van wijzigingen en risico's, documentatie van architectuurafwegingen en naleving van regelgevingsbeperkingen, waardoor de ontwikkeling voorspelbaar en beheersbaar wordt.

  • Klassieke SDLC (Waterfall). De fase System Analysis & Requirements Definition gaat vooraf aan ontwerp en realisatie; eisen worden vastgelegd in een gedetailleerde SRS als basis voor planning en contracten. Effectief in stabiele en gereguleerde domeinen; risico's van «bevroren» eisen worden verminderd door SRR/reviews en wijzigingsbeheer via CCB.[47][48][49]
  • Agile methodologieën. Analyse is continu: in plaats van een definitieve SRS wordt een product backlog bijgehouden van user stories met acceptatiecriteria, verfijnd tijdens backlog refinement; BDD (Given–When–Then) wordt toegepast; het risico van verlies van een coherente architectuur wordt gecompenseerd door vroegtijdige architectuuruitwerking en transparante traceerbaarheid van eisen ↔ realisatie/tests.[50][51][52]
  • DevOps en SRE. Frequente releases vereisen operationele eisen «standaard»: automatisering, observeerbaarheid, terugrol. Niet-functionele eisen worden geformuleerd als SLO/SLI, error budget wordt beheerd; taken voor logs/metrics/traces/alerts worden aan de backlog toegevoegd; voor releases zonder uitval — patronen zoals blue/green e.a.[53][54][55]
  • Beheer van eisen en risico's. Eisen in ALM hebben statussen en koppelingen met taken/releases/defecten; version control, change impact analysis en regelmatige herprioritering zijn verplicht.[56][57]
  • Kwaliteitsborging (QA). Kwaliteit wordt ingebouwd in de eisenfase: reviews, «Three Amigos», Acceptance Test Plan, geautomatiseerde tests van acceptatiecriteria (BDD/ATDD).[58][59]
  • Observeerbaarheid en betrouwbaarheid. In de eisen worden SLA/SLO, MTTR en MTBF opgenomen met meetbare doelen en controlemethoden; parameters worden aangeleverd door bedrijf/exploitatie en ingebouwd in architectuur en betrouwbaarheidstests.[60][61]

Metrieken en kwaliteit van artefacten

Voor de beoordeling van het werk van de systeemanalyist en de kwaliteit van zijn resultaten worden algemeen erkende criteria toegepast. Kwalitatieve eisen en modellen — de basis voor een succesvol project — worden gedurende de gehele levenscyclus beheerd (elicitation → specification → verification/validation → change management). Basale kwaliteitsattributen van eisen zijn vastgelegd in de standaarden ISO/IEC/IEEE 29148 en (historisch) IEEE 830.[3][62][1]

  • Correctheid (Correctness) — de eis weerspiegelt de werkelijke behoefte en is afgestemd met domeinexperts; bevestigd door validatie (review/inspectie, prototypes, scenario's).[1][4]
  • Volledigheid (Completeness) — wezenlijke aspecten en condities zijn meegenomen.
    • Volledigheid van een afzonderlijke eis: de benodigde details zijn vermeld (bijv. «de indicator gaat over naar de status rood bij een fout», niet alleen «wordt rood»).
    • Volledigheid van de specificatie: scenario's/rollen zijn gedekt, NFR zijn gedefinieerd; bereikt via checklists en traceerbaarheid naar bedrijfsdoelen; een onafhankelijke volledigheidsaudit (QA/review) is nuttig.[3][63]
  • Ondubbelzinnigheid (Unambiguity) — formuleringen worden op slechts één manier geïnterpreteerd; een glossarium, sjablonen van de vorm «het systeem moet A doen, wanneer B, als C», en voorbeelden helpen hierbij; diagrammen worden voorzien van een legenda. Verificatie — het principe van de «vier ogen».[3][1]
  • Consistentie (Consistency) — eisen zijn niet in tegenspraak met elkaar en met externe beperkingen; structurering, samenvattende attribuuttabellen, teamreviews worden toegepast; regelgeving/standaarden worden gecontroleerd.[3][63]
  • Verifieerbaarheid/testbaarheid (Verifiability) — het bereiken wordt bevestigd door test/demonstratie/analyse; niet-verifieerbare formuleringen worden vervangen door meetbare criteria; voor NFR worden metrieken vastgesteld en acceptatiecriteria vooraf gedefinieerd.[3][63]
  • Wijzigbaarheid en traceerbaarheid (Modifiability & Traceability) — unieke ID's, logische structuur («één gedachte — één alinea»), geen duplicaten; koppelingen «eis ↔ bron/doel/ontwerp/test» worden bijgehouden, een traceerbaarheidsmatrix (RTM) wordt onderhouden.[64][3]
  • Rangschikking en prioritering — kwaliteit van de verzameling eisen; technieken als MoSCoW en MCDM (bijv. AHP) worden gebruikt; prioritering samen met het bedrijf beïnvloedt planning en risico's.[65][66]

Metrieken voor kwaliteit van eisen (voorbeelden):[63][1]

  • defectdichtheid van eisen (opmerkingen per 100 eisen);
  • aantal wijzigingen na de basisvaststelling;
  • coverage-metrieken: aandeel eisen met tests; aandeel eisen traceerbaar naar bedrijfsdoelen;
  • stabiliteit van eisen (verhouding van toegevoegde/verwijderde eisen ten opzichte van het totale aantal over een periode);
  • omvang/complexiteit van de specificatie (gemiddeld aantal eisen per use case, diepte van decompositie);
  • tevredenheid van stakeholders (enquête).

In volwassen processen (bijv. CMMI niveau 3+) gelden kwaliteitsregels voor eisen: formele controles, conformiteitsaudits op sjablonen, verzameling en analyse van metrieken.[67] In kritieke domeinen (luchtvaart, ruimtevaart e.a.) worden formele methoden toegepast om de betrouwbaarheid te verhogen.[68]

Typische fouten

In IT-projecten komen veelvoorkomende fouten in systeemanalyse voor: onvolledigheid en ambiguïteit van eisen, tegenstrijdigheden, vage grenzen, het negeren van niet-functionele aspecten, ontbrekende integratie en te laat aandacht voor beveiliging. Dit leidt tot herbewerking, vertragingen, hogere kosten en defecten.

Typische problemen, hun gevolgen en preventiemethoden.

  • Onvolledigheid en ontbrekende eisen. Rollen met bijzondere rechten, grensgevallen en NFR worden over het hoofd gezien. Gevolgen: herbewerking van de architectuur en uitstel van de lancering. Hoe te voorkomen: checklists, brainstormsessies «wat als…», vroege betrokkenheid van testers, traceerbaarheid naar bedrijfsdoelen.[1][69]
  • Onduidelijke, ambigue formuleringen. Gevolgen: ontwikkelaars realiseren «het verkeerde», de opdrachtgever is ontevreden. Hoe te voorkomen: meetbare criteria, glossarium, sjablonen «A, wanneer B, als C», peer-review.[3][69]
  • Tegenstrijdige eisen. Gevolgen: vertragingen door verduidelijkingen, herbewerking tijdens integratie. Hoe te voorkomen: structurering, controle van bedrijfsregels/regelgeving, conflictoplossingssessies, consistentiecontrole bij reviews.[3][1]
  • Syndroom van «gold‑plating». Gevolgen: toename van omvang, complexiteit, nieuwe faalpunten. Hoe te voorkomen: koppeling van elke eis aan een doel/metriek; in Agile — geen overbodige items in de backlog opnemen; scope vastleggen; zie YAGNI.
  • Overmatige detaillering waar niet nodig. Hoe te voorkomen: «wat/waarom» (eisen) scheiden van «hoe» (ontwerp/realisatie); design-free requirements toepassen waar passend.[3]
  • Schending van eisenbeheer. Gevolgen: verwarring over versies, realisatie van «het verkeerde». Hoe te voorkomen: één bron van waarheid in ALM, historisering en statussen, RTM en change impact analysis; wijzigingsbeheer via CCB.[64][1]
  • Afwezigheid van gebruikersparticipatie. Hoe te voorkomen: interviews, observatie, prototypes, regelmatige demonstraties; expliciete validatie met stakeholders.[3][1]
  • Te langdurige «analyseverlamming». Hoe te voorkomen: voldoendheidsnorm, iterativiteit en timeboxing; lancering van MVP/incrementen en bijsturing op basis van feedback.[1]
  • Negeren van niet-functionele eisen. Hoe te voorkomen: NFR expliciet benoemen (bijv. FURPS+), meetbare criteria definiëren, opnemen in het testplan en architectuurbeslissingen.[1][3]
  • Communicatiefouten en «menselijke factor». Hoe aan te pakken: interviewvaardigheden en facilitering ontwikkelen, neutraliteit bewaren, beslissingen en bronnen van eisen documenteren (traceerbaarheid naar doelen).[1]

De meeste problemen herleiden zich tot de kwaliteit van formuleringen, volledigheid en beheersbaarheid van eisen; toepassing van de standaarden ISO/IEC/IEEE 29148 en SWEBOK-praktijken (valideerbaarheid, traceerbaarheid, iterativiteit) vermindert het risico op planningsvertragingen en herbewerking aanzienlijk.[3][1]

Beperkingen

Ondanks zijn effectiviteit bij het reduceren van onzekerheid kent systeemanalyse zijn beperkingen:

  • De werkelijkheid is veranderlijk en complex. Het is onmogelijk alle factoren in aanmerking te nemen, vooral bij langdurige projecten. Sommige eisen zullen onvermijdelijk pas na de lancering van het systeem aan het licht komen. Het is belangrijk om verrassingen te minimaliseren, maar men moet voorbereid zijn op veranderingen.
  • Eisen zijn afhankelijk van mensen. Bedrijfsprioriteiten, wetgeving en de markt kunnen veranderen. Systeemanalyse legt de huidige toestand vast en kan niet alle externe wijzigingen voorspellen. Om zich aan te passen, is het noodzakelijk eisen regelmatig bij te werken en iteratief te werken.
  • Gebruikers weten niet altijd wat ze willen totdat ze het zien. Dit is een bekende beperking. Prototyping en agile methodologieën, zoals Agile, helpen dit probleem te overwinnen. Analyse op papier heeft zijn grenzen, en voor nauwkeurige gegevens is feedback uit realisaties nodig.
  • Balans tussen tijd en kwaliteit. Een al te gedetailleerde analyse kan verouderd raken. In innovatieve domeinen is het beter snel een minimaal levensvatbaar product (MVP) te bouwen en echte gegevens te verzamelen. Systeemanalyse is effectief in stabiele domeinen, maar in onderzoeksprojecten (R&D) is de rol ervan beperkt.
  • Menselijke factor. Zelfs de beste methodologieën compenseren geen incompetentie van de analist of onbeschikbaarheid van de opdrachtgever. Het is belangrijk dat alle procesdeelnemers betrokken en gemotiveerd zijn.

Invloed van moderne technologieën op systeemanalyse in IT

Systeemanalyse in IT evolueert voortdurend onder invloed van technologische innovaties. De analist van de 21e eeuw werkt in omstandigheden van explosieve gegevensgroei, alomtegenwoordige AI, snelle ontwikkelcycli en verhoogde aandacht voor beveiliging. Succesvolle praktijk van systeemanalyse vereist het verwerven van nieuwe kennis (Data Science, cybersecurity, cloud-technologieën) en flexibiliteit in de toepassing van methoden.

  • Gegevens en AI/ML: wat er aan de analyse wordt toegevoegd. Voor systemen met AI worden al bij de start de doelen en toepassingscontext vastgelegd, de eisen aan gegevensbronnen en -kwaliteit, alsmede vertrouwensmetrieken voor modelbesluiten (betrouwbaarheid, veiligheid, verklaarbaarheid, vertrouwelijkheid, eerlijkheid). TEVV-controles (testing, evaluation, verification, validation), monitoring in exploitatie en veilige deactivering/uitfasering van het model worden gepland. Deze stappen corresponderen met de functies GOVERN–MAP–MEASURE–MANAGE uit het NIST AI Risk Management Framework; ze worden weerspiegeld in de SRS, architectuur en verificatie-/exploitatieplannen.[70]
  • DevSecOps: beveiliging «links» en standaard. Het inbedden van beveiliging in elke fase van CI/CD wordt de norm: automatische controles (SAST/DAST), scannen van afhankelijkheden en containers, implementatiebeleid, basisobserveerbaarheid. Vertrouwde artefactregisters en gestandaardiseerde «geharde» images worden gebruikt; principes van zero trust worden toegepast. In systeemanalyse worden vooraf de controlepunten van de pipeline beschreven (doorlaatcondities voor fasen), de koppeling van eisen aan beveiligingscontroles en de overgangsregels tussen omgevingen (dev/test/stage/prod).[71]
  • Wat er verandert in documenten (artefacten). Welke sectie verschijnt of wordt verduidelijkt in de belangrijkste documenten bij aanwezigheid van Big Data en AI/ML en bij werken volgens DevSecOps:
    • SRS / Eisenspecificatie: doelen en toepassingscontext van AI; gegevensvereisten (herkomst, kwaliteit, ethische en juridische beperkingen); modelmetrieken (nauwkeurigheid, betrouwbaarheid, reactietijd); TEVV-plan (testing, evaluation, verification, validation); eisen inzake transparantie/verklaarbaarheid en privacy; criteria voor deactivering/uitfasering van het model.[70]
    • Architectuur en beslissingen (Architecture, ADR): resultaten van bedreigingsmodellering; maatregelen voor «beveiliging standaard» (versleuteling, toegangscontrole, secret management, principe van minimale rechten); beperkingen op het gebruik van gegevens/modellen; ADR-registraties met risicobeoordeling en afwegingen.[71][70]
    • Verificatie- en validatieplan (V&V / TEVV): testscenario's voor modellen en gegevens; acceptatiedrempels voor kwaliteitsmetrieken; monitoring van gegevens-/modeldrift; procedures voor periodieke herbeoordeling en hervalidatie.[70]
    • CI/CD-beleid en pipeline «gates»: automatische SAST/DAST-, SCA- (afhankelijkheden) en containerscans; ondertekening en opslag van artefacten in vertrouwde registers; regels voor doorstroming tussen omgevingen (dev/test/stage/prod) en blokkeervoorwaarden bij mislukken van controles; eisen aan standaard observeerbaarheid.[71]
    • Gegevens- en modelbeheerplan: broncatalogus en lineage; kwaliteits- en beschikbaarheidscriteria voor gegevens; versies van datasets/modellen; (bij)trainingsschema en biascontrole; toegangs- en opslagbeleid; plan voor veilige deactivering van het model en verwijdering van gegevens indien vereist.[70]
    • Exploitatie en observeerbaarheid (Ops/Runbook): vertrouwensmetrieken voor AI en SLO; audit en logging; meldingen bij degradatie/anomalieën; incidentresponsplan; fallback/kill-switch voor AI-componenten; eisen aan rapportage en post-incidentanalyse.[70][71]
    • Traceerbaarheid (end-to-end): expliciete koppelingen «eis ↔ controle/verificatie in de pipeline» en «eis ↔ test/monitoring in exploitatie», zodat beveiliging en kwaliteit aantoonbaar gecontroleerd kunnen worden gedurende de gehele levenscyclus.[71][70]
  • Rol van de systeemanalyist.
    • beheert de context en risico's van AI (actoren, toepassingsscenario's, aannames en gegevensbeperkingen);
    • zorgt voor traceerbaarheid «eis ↔ beveiligingscontrole in de pipeline»;
    • formuleert toetsbare niet-functionele eisen (beveiliging, transparantie, observeerbaarheid) gedurende de gehele levenscyclus van het systeem.[70][71]

Verschillen met klassieke systeemanalyse

De term «systeemanalyse» is historisch gezien breder dan softwareontwikkeling. Klassieke systeemanalyse is een aanpak voor het oplossen van complexe interdisciplinaire vraagstukken (sociaal, economisch, bestuurlijk), gebaseerd op systeemdenken en kwantitatieve methoden, doorgaans ter ondersteuning van managementbeslissingen. In IT verstaat men onder systeemanalyse een toegepaste discipline binnen software-engineering, gericht op de realisatie van informatiesystemen.

Hieronder staan de belangrijkste verschillen.

  • Doelen en object van analyse. Klassieke analyse lost slecht gestructureerde, «diffuse» problemen op en verbetert bestaande sociotechnische systemen (stedelijk transportnetwerk, bedrijfsstrategie, milieubeleid). Het object is een reëel systeem; de taak is de beslisser te helpen een handelwijze te kiezen. Voor systeemanalyse in IT is het doel een nieuw informatiesysteem of softwareproduct te ontwerpen en te bouwen dat voldoet aan de eisen. Het object is het te ontwerpen systeem; de focus ligt op gedrag en kenmerken die gebruikers nodig hebben.
  • Methodologische grondslagen. Klassieke scholen steunen op systeemdenken en vaak op wiskunde. De harde benadering (hard systems) — formalisering van het probleem, kwantitatieve criteria, optimalisatie (zoals in operations research). Zachte methodologieën (soft systems) erkennen de meervoudigheid van gezichtspunten; een voorbeeld is Soft Systems Methodology (SSM), waarbij via discussies en conceptuele modellen gewenste veranderingen worden afgestemd. In IT is de basis gevormd door ingenieursdisciplines: requirements engineering, software-ontwerp, architectuurframeworks. Gestandaardiseerde processen (ISO/IEC/IEEE 15288, 12207, 29148), notaties als UML/SysML en praktijken voor wijzigingsbeheer worden toegepast.
  • Rollen en artefacten. In de klassieke analyse is de rol van «systeemanalyist» vaak informeel; resultaten zijn analytische rapporten, aanbevelingen, wiskundige modellen, «wat-als»-scenario's. In IT is de rol van analist (of bedrijfsanalist) geformaliseerd; er worden eisenspecificaties, systeemmodellen (UML, ER), interfacespecificaties, user stories en backlog opgesteld — artefacten die rechtstreeks door ontwikkelaars en testers worden gebruikt.
  • Levenscyclus en proces. Klassieke analyse kent geen uniform sjabloon: de stappen hangen af van het probleem (in SSM — van het bestuderen van de situatie tot het implementeren van wijzigingen). In IT zijn standaard SDLC-cycli gangbaar: in het cascademodel bestaat er een aparte fase voor eisenanalyse; in iteratieve en agile benaderingen is analyse een voortdurende activiteit van elke sprint. Moderne praktijken (DevOps, CI/CD) breiden het analysekader uit tot de exploitatie: er wordt rekening gehouden met eisen aan onderhoud, observeerbaarheid en bijwerking. Met andere woorden: systeemanalyse in IT is ingebed in de ontwikkelingslevenscyclus, terwijl klassieke analyse vaker als project-/adviesactiviteit wordt uitgevoerd.

Systeemanalyist

De systeemanalyist in IT — een specialist verantwoordelijk voor systeemdenken bij het ontwerpen en ontwikkelen van informatiesystemen: het vormen en valideren van eisen, modellering (UML/BPMN), afstemming van architectuurbeslissingen en waarborging van integratie. De rol en kwalificatievereisten in de Russische Federatie zijn vastgelegd in de professionele standaard en het federale onderwijsstandaard.

Het hoofddoel van de beroepsactiviteit: Het waarborgen van de conformiteit van de IT-dienst, het geautomatiseerde systeem, het geautomatiseerde informatiesysteem, het geautomatiseerde besturingssysteem, het software- en informatieproduct of -middel (hierna — het Systeem) met zijn omgeving, de initiële eisen en beperkingen, de automatiseringsdoelen en de geautomatiseerde activiteit, door middel van het ontwikkelen en overdragen van kwalitatieve en onderling afgestemde projectbeslissingen aan belanghebbenden bij de lancering en coördinatie van de werkzaamheden van afzonderlijke uitvoerders gedurende de gehele levenscyclus van het Systeem (Professionele standaard «Systeemanalyist» (besluit van het Ministerie van Arbeid van de Russische Federatie van 27.04.2023 nr. 367n).[72]

Woordenlijst van sleuteltermen

Basisbegrippen en deelnemers

  • Systeemanalyse in IT — de discipline waarvan het onderwerp het informatiesysteem is gedurende zijn gehele levenscyclus, van concept tot exploitatie.
  • Stakeholders — personen of groepen die belang hebben bij of worden beïnvloed door het project (opdrachtgevers, gebruikers, managers).
  • Projectartefacten — documenten en resultaten die tijdens het project worden gecreëerd, zoals specificaties, modellen, plannen en beslissingen.

Eisen: soorten en documentatie

  • Functionele eisen — beschrijven wat het systeem moet doen; de functies en het gedrag ervan.
  • Niet-functionele eisen — beschrijven kwaliteitsattributen van het systeem (betrouwbaarheid, prestaties, beveiliging, gebruiksgemak, schaalbaarheid, enz.).
  • Eisenspecificatie (initieel) — document dat de initiële verzameling eisen bevat, verzameld in de vroege projectfasen.
  • SRS (Software Requirements Specification) — gestandaardiseerd document dat de eisen aan de software gedetailleerd beschrijft conform internationale standaarden (bijv. ISO/IEC/IEEE 29148).
  • URS (User Requirements Specification) — document dat de gebruikerseisen aan het systeem beschrijft vanuit het perspectief van bedrijfsprocessen en verwachtingen van de eindgebruiker.
  • Architectuurbepalende eisen (ASR) — eisen die een wezenlijke invloed hebben op architectuurbeslissingen en afwegingen.
  • Cross-functionele eisen (CFR) — synoniem voor niet-functionele eisen, dat hun doorsnijdend karakter benadrukt.
  • Acceptatiecriteria (Acceptance Criteria) — toetsbare voorwaarden waaraan moet worden voldaan opdat het werk aan een eis als geaccepteerd wordt beschouwd.
  • Definition of Ready (DoR) — afspraak over de gereedheid van een backlog-item voor ontwikkeling (duidelijkheid, schatting, criteria).
  • Definition of Done (DoD) — afspraak over de «afgerondheid» van het werk (code, tests, documentatie, implementatie).
  • Beperking (Constraint) — een harde voorwaarde die oplossingen beperkt (termijnen, platforms, standaarden, licenties).
  • Aanname (Assumption) — veronderstelling die zonder bewijs wordt aanvaard en nadere validatie vereist.
  • Kwaliteit van eisen — eigenschappen conform ISO 29148: ondubbelzinnigheid, volledigheid, consistentie, verifieerbaarheid, atomiciteit.

Formalisering, traceerbaarheid en prioritering van eisen

  • Formalisering van eisen — het proces van omzetting van informele verzoeken in heldere, toetsbare en ondubbelzinnige eisen.
  • Traceerbaarheid van eisen — de mogelijkheid om de levenscyclus van een eis te volgen van de bron tot realisatie, testen en implementatie.
  • Bidirectional traceability (tweerichtingstraceerbaarheid) — het vermogen om koppelingen tussen eisen, ontwerpelementen en testscenario's in beide richtingen te volgen.
  • MoSCoW — techniek voor de prioritering van eisen, die ze classificeert als Must-have (moet aanwezig zijn), Should-have (zou aanwezig moeten zijn), Could-have (kan aanwezig zijn) en Won't-have (zal niet aanwezig zijn).
  • BDD (Behavior-Driven Development) — ontwikkelingsmethodologie waarbij tests worden geschreven in een natuurlijke taal gericht op het gedrag van het systeem vanuit het perspectief van de gebruiker (formaat Given–When–Then).

Notaties en modellering

  • UML (Unified Modeling Language) — gestandaardiseerde grafische modelleertaal voor de specificatie, visualisatie, constructie en documentatie van componenten van softwaresystemen.
  • SysML (Systems Modeling Language) — uitbreiding van UML voor systeemengineering, die modellering van diverse aspecten van complexe systemen ondersteunt, waaronder eisen, gedrag, structuur en parameters.
  • BPMN (Business Process Model and Notation) — standaard voor grafische notatie voor de beschrijving van bedrijfsprocessen, waarmee werkstromen, gebeurtenissen, gateways en pools gevisualiseerd kunnen worden.
  • MBSE (Model-Based Systems Engineering) — aanpak voor systeemengineering waarbij het model het centrale artefact is in alle fasen van de levenscyclus van het systeem, van eisen tot testen.
  • ArchiMate — notatie voor enterprise-architectuur (bedrijf, applicaties, technologieën) en hun onderlinge verbanden.
  • DMN (Decision Model and Notation) — modellering van bedrijfsbeslissingen en regeltabellen.
  • DFD (Data Flow Diagram) — datastroomdiagrammen (context, decompositieniveaus).
  • ERD (Entity-Relationship Diagram) — domeinmodel met entiteiten, relaties en attributen.
  • CRUD-matrix — overeenkomst van de bewerkingen Create/Read/Update/Delete met entiteiten en rollen/functies.

Architectuurstijlen en beoordeling van oplossingen

  • Monolithische architectuur — architectuurstijl waarbij het gehele systeem wordt ontwikkeld als één ondeelbare module.
  • Microservicesarchitectuur — architectuurstijl waarbij het systeem wordt opgebouwd als een verzameling kleine, onafhankelijk implementeerbare en schaalbare diensten.
  • Trade-off (afweging) — keuze tussen onderling uitsluitende of tegenstrijdige kenmerken of oplossingen, waarbij verbetering van één kenmerk ten koste gaat van een ander.
  • ATAM (Architecture Tradeoff Analysis Method) — methode voor de beoordeling van softwarearchitectuur, gebruikt voor de analyse van afwegingen tussen kwaliteitsattributen (bijv. prestaties, schaalbaarheid).

Enterprise-architectuur en frameworks

  • TOGAF (The Open Group Architecture Framework) — een van de meest verspreide frameworks voor enterprise-architectuur, met de ADM-methode (Architecture Development Method) voor het ontwikkelen en beheren van architectuur.
  • Zachman Framework — ontologie van enterprise-architectuurartefacten, weergegeven als een 6×6-matrix, die diverse aspecten van de architectuur vanuit verschillende perspectieven classificeert.

Analysebenaderingen en ontwikkelprocessen

  • Harde benadering (Hard Systems) — methodologie van systeemanalyse die vooraf formaliseerbare doelen en eisen veronderstelt, decompositie en ontwerp «van boven naar beneden»; effectief voor duidelijk gedefinieerde taken.
  • Zachte benadering (Soft Systems) — methodologie van systeemanalyse die wordt toegepast bij onduidelijke doelen en meervoudige gezichtspunten van stakeholders, gericht op het afstemmen van het begrip van het probleem en de gewenste veranderingen.
  • SSM (Soft Systems Methodology) — specifieke methodologie van de zachte systeembenadering, ontwikkeld door Peter Checkland, die instrumenten gebruikt zoals rich picture, worteldefenities en CATWOE.
  • Waterfall (cascademodel) — klassieke softwareontwikkelingsmethodologie waarbij de fasen (analyse, ontwerp, realisatie, testen, implementatie) sequentieel worden uitgevoerd, met volledige afronding van de vorige fase vóór aanvang van de volgende.
  • Agile — groep flexibele softwareontwikkelingsmethodologieën gericht op iteratieve ontwikkeling, aanpassing aan veranderingen, interactie met de opdrachtgever en continue levering van waarde.

Selectiemethoden en typische fouten

  • AHP (Analytic Hierarchy Process) — methode voor meervoudige criteria-analyse waarmee complexe problemen gestructureerd en alternatieven beoordeeld kunnen worden op basis van een hiërarchie van criteria.
  • Gold-plating (syndroom van de «gouden plaat») — fout in systeemanalyse, bestaande uit het toevoegen van functionaliteit die niet door stakeholders wordt gevraagd, wat leidt tot toename van omvang en complexiteit van het project.

Verwijzingen

  • 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
  • Systeemanalyse in eenvoudige bewoordingen. YouTube
  • Systeemanalyse in IT in eenvoudige bewoordingen. YouTube

Literatuur

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5e druk.
  • 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. Officiële gratis versie.
  • 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. Officiële gratis download (onder licentie).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4e druk.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3e druk.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2e druk.
  • 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, 5e druk.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3e druk.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4e druk.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11e druk.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8e druk.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7e druk.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3e druk.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2e druk.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4e druk.
  • 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, 4e druk.
  • 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, 2e druk.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Noten

  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=Systeemanalyse_in_IT&oldid=7043"