---
title: "Systémová analýza v IT"
source: "https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT"
wiki: "systems-analysis.info/int"
article: "Systémová_analýza_v_IT"
language: "cs"
categories:
  - "Category:Czech"
  - "Category:Systems analysis"
revision_id: 7768
wiki_created_at: 2026-09-07T01:06:45Z
wiki_modified_at: 2026-09-07T01:06:45Z
downloaded_at: 2026-09-07T23:20:39Z
---

# Systémová analýza v IT

**Systémová analýza v IT** (*Systems Analysis and Design*) — přístup k navrhování a rozvoji informačních systémů od záměru až po provoz, zahrnující zjišťování potřeb, formalizaci požadavků, modelování předmětné oblasti a procesů, jakož i hodnocení alternativ a rizik. Jinými slovy, systémová analýza v IT je etapou vývoje, při níž specialisté studují úlohu, určují, co má systém dělat, a navrhují řešení pro jeho vytvoření.

**Klasická systémová analýza** zahrnuje široké spektrum oblastí použití*,* nejen vývoj softwaru, ale i organizační změny, strategie a další aspekty.<a href="https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7" class="external autonumber" rel="nofollow">[1]</a> <a href="https://systems-analysis.ru/systems_analysis.html" class="external autonumber" rel="nofollow">[2]</a>

## Předmět a úkoly systémové analýzy v IT

**Předmětem** **systémové analýzy v IT** je informační systém (softwarový produkt a/nebo služba) po celém životním cyklu — od záměru a zdůvodnění až po realizaci a provoz.

**Úkolem systémové analýzy** je přeměnit obchodní potřeby v konzistentní a ověřitelnou sadu požadavků a architektonických rozhodnutí: zjistit a zdokumentovat cíle a omezení stakeholderů, formalizovat požadavky, modelovat předmětnou oblast a procesy, posoudit proveditelnost a rizika alternativ a zdůvodnit zvolenou architekturu. Výsledkem jsou konzistentní dokumenty a jsou vytvořeny sledovatelné vazby mezi požadavky, projektovými rozhodnutími a testy. To zajišťuje řiditelnost a kontrolu nad procesem vývoje.

Úkoly systémové analýzy zahrnují:

- **Zjišťování potřeb a cílů stakeholderů**. Analytik shromažďuje a upřesňuje očekávání zákazníků, uživatelů a dalších zainteresovaných stran; používají se rozhovory, dotazníky, pozorování a analýza stávajících procesů. Na výstupu se formuje primární **specifikace požadavků** s rozdělením na funkční („co má systém dělat") a nefunkční (spolehlivost, výkon, bezpečnost atd.).<sup>[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)[\[2\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-Zowghi-2)</sup>

<!-- -->

- **Formalizace a dokumentování požadavků**. Požadavky jsou převáděny do ověřitelné podoby. Dobře formulovaný požadavek musí být jasný a jednoznačný, úplný, nerozporný, ověřitelný a sledovatelný k cílům vyšší úrovně; sada požadavků — konzistentní a celistvá.<sup>[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)[\[4\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NASA7123-4)</sup> V praxi se používají standardizované dokumenty: SRS (*Software Requirements Specification*) podle ISO/IEC/IEEE 29148, a také v některých odvětvích URS (*User Requirements Specification*) a funkční specifikace.<sup>[\[5\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-5)[\[6\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-6)[\[7\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-7)</sup>

<!-- -->

- **Analýza a modelování systému**. Pro pochopení toho, *jak* bude systém fungovat a interagovat s vnějším světem, se vytvářejí modely: diagramy případů užití (Use Case) pro scénáře použití, DFD pro toky dat a obchodní procesy, diagramy tříd/komponent aj. Modely slouží jako základ pro porovnávání alternativních řešení a architektur.<sup>[\[8\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-8)[\[9\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-9)[\[10\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO42010-10)</sup>

<!-- -->

- **Hodnocení proveditelnosti a výběr řešení**. Provádí se *feasibility study* (technická, organizační, ekonomická, časová proveditelnost) a porovnání architektonických alternativ (*trade-off*). Pro hodnocení kvality architektury podle atributů (např. výkon, škálovatelnost, modifikovatelnost) se používají metody jako ATAM (*Architecture Tradeoff Analysis Method*).<sup>[\[11\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-11)[\[12\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ATAM-12)</sup> Volba mezi například monolitickou a mikroservisní architekturou <a href="https://aws.amazon.com/ru/compare/the-difference-between-monolithic-and-microservices-architecture/" class="external autonumber" rel="nofollow">[3]</a> se opírá o explicitní kompromisy (složitost provozu vs. nezávislá škálovatelnost a rychlost dodávky) podle doporučení průmyslových příruček.<sup>[\[13\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-13)[\[14\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-14)</sup>

<!-- -->

- **Příprava projektových artefaktů**. Na základě výsledků analýzy se vytvářejí:
  - schválená specifikace požadavků (s uvedením jejich důležitosti),
  - konceptuální model systému (diagramy/popisy),
  - architektonická a projektová rozhodnutí (schémata dat, rozhraní externích systémů),
  - plán realizace (etapy/moduly).
  - Klíčové je zajistit *sledovatelnost* (bidirectional traceability) požadavků k prvkům návrhu a testům.<sup>[\[15\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-15)[\[4\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NASA7123-4)</sup>

Úspěch IT projektu do značné míry závisí na vyspělých postupech práce s požadavky a architekturou. Výzkum provedený McKinsey a Oxford ukázal, že velké IT projekty často překračují rozpočet a termíny. Tento výzkum také zdůraznil, jak důležité je správně řídit strategii, komunikovat se zainteresovanými stranami a odborně shromažďovat požadavky. To vše může výrazně ovlivnit úspěch nebo neúspěch projektu.<sup>[\[16\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-16)</sup>

## Přístupy a metodologie v systémové analýze IT

**Systémová analýza v IT** se opírá o principy systémového myšlení a metodiky přizpůsobené vývoji softwaru. V praxi se kombinují „tvrdé" a „měkké" přístupy, strukturální metodologie, objektově orientované notace a také jazyky modelování procesů a požadavků.

- **Tvrdý a měkký přístup**. V IT projektech tvrdý přístup (hard systems) předpokládá předem formalizovatelné cíle a požadavky, dekompozici a navrhování „shora dolů". Měkký přístup (soft systems) se uplatňuje při nejasných cílech a mnohočetných pohledech: používají se prvky Soft Systems Methodology (SSM) (např. *rich picture*, kořenové definice, CATWOE) pro sladění chápání problému a požadovaných změn; výsledky jsou pak převáděny do formálních požadavků.<sup>[\[17\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-17)[\[18\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-18)</sup>

<!-- -->

- **Metodologie SSM (Soft Systems Methodology)**. Původně vyvinutá *Peterem Checklandem* pro organizační změny, SSM je užitečná v předprojektových etapách IT: od průzkumu problémové situace a formulování kořenových definic (vč. CATWOE) až po porovnání konceptuálních modelů s realitou a dosažení akomodace mezi stakeholdery.<sup>[\[19\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-19)[\[20\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-20)</sup>

<!-- -->

- **Strukturované metodologie: SADT/IDEF0**. SADT modeluje systém jako hierarchii funkcí; standardní notace IDEF0 (IEEE 1320.1) zachycuje funkce a jejich I-C-O-M rozhraní (Inputs, Controls, Outputs, Mechanisms). Metoda je vhodná pro funkční dekompozici a sladění hranic systému nezávisle na algoritmech.<sup>[\[21\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-21)[\[22\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-22)</sup>

<!-- -->

- **Objektově orientovaná analýza:** UML a SysML (MBSE). UML se stal základním jazykem pro požadavky a návrh (diagramy případů užití, tříd, sekvencí aj.) a usnadňuje validaci scénářů s uživateli; SysML rozšiřuje UML pro systémové inženýrství (diagramy požadavků, parametrické diagramy) a opírá se o přístup MBSE, kde model je centrálním artefaktem napříč etapami od požadavků po testy.<sup>[\[23\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-23)[\[24\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-24)[\[25\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-25)</sup>

<!-- -->

- **Modelování obchodních procesů:** BPMN. Standard BPMN se používá pro grafický popis procesů (bazény, toky prací, události, brány), včetně porovnání *as-is/to-be* ve specifikacích požadavků a integraci.<sup>[\[26\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-26)[\[27\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-27)</sup>

<!-- -->

- **Vazba na inženýrství požadavků**. Proces zahrnuje etapy elicitation–analysis–specification–validation–change management; kritéria „dobrého požadavku" a struktura SRS jsou upraveny normou ISO/IEC/IEEE 29148. Pro prioritizaci se používají techniky **MoSCoW** (Must/Should/Could/Won't) a metody vícekriteriálního výběru, například AHP. V agilních procesech se činnost systémové analýzy odráží ve zpřesnění backlogu a sledovatelnosti požadavků.<sup>[\[28\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-28)[\[29\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-29)[\[30\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-30)[\[31\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-31)</sup>

<!-- -->

- **Vazba na systémové inženýrství**. Pro komplexní (kyberfyzické) systémy se používá V-model: na „levé" větvi — systémová analýza a architektura, na „pravé" — integrace, verifikace a validace s vazbou na artefakty levé větve. Metody hodnocení architektury podle kvalitativních atributů zahrnují ATAM (trade-off analýza).<sup>[\[32\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-32)[\[33\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-33)</sup>

Systémová analýza v IT kombinuje osvědčené přístupy — od měkkých metodik slaďování vize až po formální notace a standardy. Volba nástrojů je určena mírou určitosti úlohy: při vysoké nejistotě roste role SSM a facilitace, při jasně definovaných hranicích — formální modely (UML/SysML, IDEF0, BPMN) a předpisy.

## Vazba na IT architekturu a architekturu podniku

Systémová analýza v IT projektech úzce souvisí s architektonickým navrhováním. Role analytika a architekta se překrývají: analytik formuluje požadavky a logický model, architekt určuje cílovou strukturu řešení a technické kompromisy; práce probíhá společně.

- **Architektura IT systémů**. V užším smyslu je softwarová architektura organizace komponent, jejich vztahy a principy, kterými se řídí při navrhování řešení. Pro analytika je důležité zohledňovat architektonické styly (vrstvená, klient–server, mikroservisní, událostmi řízená aj.), protože nefunkční požadavky (spolehlivost, škálovatelnost, modifikovatelnost) často určují architektonická rozhodnutí a jejich kompromisy.<sup>[\[34\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-AzureStyles-34)[\[35\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SEI_ATAM-35)</sup> V rané fázi analýzy se formuje **architektonická vize** (high-level vision) a zpracovává se hrubý obrys řešení pro ověření životaschopnosti požadavků (délka iterací a míra detailizace závisí na metodologii).<sup>[\[36\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-TOGAFIntro-36)</sup>

<!-- -->

- **Šablony a předběžná řešení**. Pro splnění nefunkčních požadavků se používají architektonické šablony (architectural patterns). Například pro asynchronní komunikaci a volné vazby — publish–subscribe prostřednictvím brokeru zpráv v architektuře řízené událostmi.<sup>[\[37\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-AzureEvent-37)</sup>

<!-- -->

- **TOGAF (The Open Group Architecture Framework)**. Jeden z nejrozšířenějších rámců podnikové architektury; zahrnuje metodu ADM (Architecture Development Method) a artefakty řízení architektury (repozitář, katalogy/matice, principy). V TOGAF je řízení požadavků průřezovým procesem integrovaným do všech fází ADM.<sup>[\[36\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-TOGAFIntro-36)</sup> Pro podporu požadavků a sledovatelnosti se používají katalogy a matice (např. požadavky ↔ služby, funkce ↔ komponenty) a rozlišují se ***Architecture Building Blocks*** a ***Solution Building Blocks***.<sup>[\[38\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-38)[\[39\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-39)</sup> Principy a standardy podniku jsou zachyceny v příslušných katalozích a vystupují jako externí nefunkční **požadavky** pro projektové týmy.<sup>[\[40\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-40)</sup> Soulad řešení s cílovou architekturou je potvrzen postupem architektonického souladu (Architecture Compliance Review).<sup>[\[41\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-41)</sup> Přístup TOGAF předpokládá předběžnou **Architecture Vision** a následnou detailizaci (data/aplikace/technologie) s plánem migrace a řízením změn požadavků.<sup>[\[42\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-42)[\[43\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-43)</sup>

<!-- -->

- **Zachman Framework**. Raná a vlivná ontologie artefaktů podnikové architektury, představená jako matice 6×6 (perspektivy × aspekty „co/jak/kde/kdo/kdy/proč"). Řádek „návrhář" odpovídá systémové analýze a navrhování; sloupce určují úplnost zohlednění dat, funkcí/procesů, rolí, umístění a motivace. Rámec slouží jako klasifikace (nikoli metodologie) a pomáhá zajistit úplnost popisu řešení v kontextu podniku.<sup>[\[44\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-Zachman1987-44)</sup>

<!-- -->

- **Vazba na podnikovou architekturu (Enterprise Architecture, EA)**. Systémový analytik pracuje v kontextu EA: nové požadavky jsou sledovány k obchodním schopnostem a provoznímu modelu; uplatňují se standardy a zásadní omezení podniku (bezpečnost, kompatibilita atd.).<sup>[\[45\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-45)[\[36\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-TOGAFIntro-36)</sup> V etapě iniciace se formuje ***Architecture Vision*** (cíle/omezení, souhrnné požadavky), poté analytik detailizuje se zachováním sledovatelnosti k vizi a podnikovým standardům; nesplnění standardů se zjišťuje na architektonických přezkumech a může vést k úpravám řešení.<sup>[\[36\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-TOGAFIntro-36)[\[46\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-46)</sup>

Celkově: systémová analýza a architektonické navrhování tvoří vazbu „požadavky → architektonická rozhodnutí → kompromisy podle atributů kvality". Volba metod (stylů/šablon, artefaktů TOGAF, klasifikace Zachman) je určena charakterem projektu a rámcem podnikové architektury.

## Procesy a postupy

Systémová analýza se integruje do celého životního cyklu vývoje a provozu softwaru, propojující obchodní cíle, architekturu a dodávku. Zahrnuje předprojektový průzkum, volbu přístupu, tvorbu ověřitelných artefaktů a požadavky na spolehlivost, výkon, bezpečnost a udržovatelnost. V kaskádním modelu se analýza provádí před navrhováním a realizací, v agilních metodách — průběžně prostřednictvím iterací, a v DevOps — s důrazem na provozní cíle. Bez ohledu na přístup zajišťuje analýza sledovatelnost, řízení změn a rizik, dokumentování architektonických kompromisů a dodržování normativních omezení, čímž činí vývoj předvídatelným a řiditelným.

- **Klasický SDLC (Waterfall)**. Etapa System Analysis & Requirements Definition předchází navrhování a realizaci; požadavky jsou zachyceny v podrobné **SRS** jako základ plánování a smluv. Efektivní ve stabilních a regulovaných oblastech; rizika „zamrazení" požadavků snižují SRR/přezkumy a řízení změn prostřednictvím **CCB**.<sup>[\[47\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-Royce-47)[\[48\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-DAU_SRR-48)[\[49\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NASA_CCB-49)</sup>

<!-- -->

- **Agilní metodologie (Agile)**. Analýza je průběžná: místo finální SRS se vede produktový backlog z user stories s akceptačními kritérii, zpřesňovaný při backlog refinement; používá se **BDD** (Given–When–Then); riziko ztráty celistvé architektury se kompenzuje ranou architektonickou přípravou a transparentní sledovatelností požadavků ↔ realizaci/testům.<sup>[\[50\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-MS_Agile-50)[\[51\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-MS_BDD-51)[\[52\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-MS_Trace-52)</sup>

<!-- -->

- **DevOps a SRE**. Časté vydávání verzí vyžaduje provozní požadavky „ve výchozím nastavení": automatizaci, pozorovatelnost, rollback. Nefunkční požadavky se formulují jako SLO/SLI, spravuje se error budget; do backlogu se přidávají úkoly na logy/metriky/traces/alerty; pro vydání bez výpadku — vzory **blue/green** aj.<sup>[\[53\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SRE_SLO-53)[\[54\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-AzureMon-54)[\[55\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-AWS_BlueGreen-55)</sup>

<!-- -->

- **Řízení požadavků a rizik**. Požadavky v ALM mají stavy a vazby na úkoly/vydání/defekty; povinné jsou version control, change impact analysis a pravidelná reprioritizace.<sup>[\[56\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-Azure_Workflow-56)[\[57\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-Azure_Backlog-57)</sup>

<!-- -->

- **Zajištění kvality (QA)**. Kvalita se zabudovává v etapě požadavků: přezkumy, „Three Amigos", plán *Acceptance Test Plan*, automatizované testy akceptačních kritérií (BDD/ATDD).<sup>[\[58\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-MS_Test-58)[\[59\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-MS_SpecFlow-59)</sup>

<!-- -->

- **Pozorovatelnost a spolehlivost**. Do požadavků se zahrnují SLA/SLO, MTTR a MTBF s měřitelnými cíli a metodami kontroly; parametry přicházejí od businessu/provozu a jsou zabudovány do architektury a testů spolehlivosti.<sup>[\[60\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-IBM_MTTR-60)[\[61\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-GCloud_Obs-61)</sup>

## Metriky a kvalita artefaktů

Pro hodnocení práce systémového analytika a kvality jeho výsledků se používají obecně uznávaná kritéria. **Kvalitní požadavky a modely** — základ úspěšného projektu, proto jsou spravovány po celý životní cyklus (elicitation → specification → verification/validation → change management). Základní atributy kvality požadavků jsou zakotveny ve standardech ISO/IEC/IEEE 29148 a (historicky) IEEE 830.<sup>[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)[\[62\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-IEEE830-62)[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)</sup>

- **Správnost (Correctness)** — požadavek odráží skutečnou potřebu a je odsouhlaseno s experty v dané oblasti; potvrzuje se validací (review/inspection, prototypy, scénáře).<sup>[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)[\[4\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NASA7123-4)</sup>

<!-- -->

- **Úplnost (Completeness)** — jsou zohledněny podstatné aspekty a podmínky.
  - *Úplnost jednotlivého požadavku*: jsou uvedeny potřebné detaily (např. „indikátor přechází do stavu **červený při selhání**", nikoli jen „zčervená").
  - *Úplnost specifikace*: jsou pokryty scénáře/role, jsou stanoveny NFR; dosahuje se kontrolními seznamy a sledovatelností k obchodním cílům; užitečný je nezávislý audit úplnosti (QA/review).<sup>[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Jednoznačnost (Unambiguity)** — formulace jsou interpretovány jediným způsobem; pomáhá glosář, šablony ve tvaru „systém **musí dělat A, když B, pokud C**", příklady; diagramy jsou doplněny legendou. Kontrola — princip **„čtyř očí"**.<sup>[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Konzistentnost (Consistency)** — požadavky si navzájem neodporují a neodporují ani externím omezením; používá se strukturování, souhrnné tabulky atributů, týmové přezkumy; ověřují se předpisy/standardy.<sup>[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Ověřitelnost/testovatelnost (Verifiability)** — splnění se potvrzuje testem/demonstrací/analýzou; neověřitelné formulace se nahrazují měřitelnými kritérii; pro NFR se stanovují metriky a akceptační kritéria se fixují předem.<sup>[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Modifikovatelnost a sledovatelnost (Modifiability & Traceability)** — unikátní ID, logická struktura („jedna myšlenka — jeden odstavec"), absence duplicit; udržují se vazby „požadavek ↔ zdroj/cíl/návrh/test", vede se matice **sledovatelnosti (RTM)**.<sup>[\[64\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NASA_RM-64)[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Třídění a prioritizace** — kvalita sady požadavků; používají se techniky **MoSCoW** a MCDM (např. **AHP**); prioritizace společně s businessem ovlivňuje plánování a rizika.<sup>[\[65\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-MoSCoW-65)[\[66\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-Saaty-66)</sup>

**Metriky kvality požadavků** (příklady):<sup>[\[63\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NASA_SEH-63)[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)</sup>

- hustota defektů požadavků (připomínek na 100 požadavků);
- počet změn po základním zakotvení;
- metriky pokrytí: podíl požadavků s testy; podíl požadavků sledovatelných k obchodním cílům;
- stabilita požadavků (poměr přidaných/odstraněných k celkovému počtu za období);
- velikost/složitost specifikace (průměrný počet požadavků v případu užití, hloubka dekompozice);
- spokojenost stakeholderů (průzkum).

Ve vyspělých procesech (např. **CMMI** úroveň 3+) platí předpisy kvality požadavků: formální kontroly, audity shody se šablonami, sběr/analýza metrik.<sup>[\[67\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SEI_CMMI-67)</sup> V kritických oblastech (avionika, kosmonautika aj.) se používají **formální metody** pro zvýšení spolehlivosti.<sup>[\[68\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NASA_FM-68)</sup>

## Typické chyby

V IT projektech se často vyskytují chyby systémové analýzy: neúplnost a nejednoznačnost požadavků, rozpory, rozostřené hranice, ignorování nefunkčních aspektů, opomenutá integrace a opožděná bezpečnost. To vede k přepracování, zpožděním, nárůstu nákladů a defektům.

Typické problémy, jejich důsledky a způsoby prevence.

- **Neúplnost a chybějící požadavky**. Jsou přehlédnuty role se speciálními oprávněními, hraničními případy a NFR. *Důsledky:* přepracování architektury a odložení spuštění. Jak předejít: kontrolní seznamy, brainstormingy „co kdyby…", raná účast testerů, sledovatelnost k obchodním cílům.<sup>[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)[\[69\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **Nejasné, dvojznačné formulace**. *Důsledky:* vývojáři implementují „něco jiného", zákazník je nespokojený. Jak předejít: měřitelná kritéria, glosář, šablony „A, když B, pokud C", peer‑review.<sup>[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)[\[69\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **Rozporuplné požadavky**. *Důsledky:* zpoždění kvůli upřesňování, přepracování při integraci. Jak předejít: strukturování, srovnání obchodních pravidel/předpisů, sezení pro řešení konfliktů, kontrola konzistentnosti při přezkumech.<sup>[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Syndrom „zlatého pozlátka" (gold‑plating)**. *Důsledky:* nárůst rozsahu, komplikování, nové body selhání. Jak předejít: propojení každého požadavku s cílem/metrikou; v Agile — nevkládat nadbytečné do backlogu; fixovat scope; viz YAGNI.

<!-- -->

- **Nadměrná detailizace tam, kde není potřeba.** Jak předejít: oddělovat *co/proč* (požadavky) od *jak* (návrh/realizace); používat *design‑free requirements* tam, kde je to vhodné.<sup>[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Narušení řiditelnosti požadavků**. *Důsledky:* zmatení verzí, realizace „špatné věci". Jak předejít: jediný zdroj pravdy v ALM, historizace a stavy, RTM a change impact analysis; řízení změn prostřednictvím CCB.<sup>[\[64\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NASA_RM-64)[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Absence zapojení uživatelů**. Jak předejít: rozhovory, pozorování, prototypy, pravidelné ukázky; explicitní validace se stakeholdery.<sup>[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Příliš dlouhá „analytická paralýza"**. Jak předejít: zóna dostatečnosti, iterativnost a timeboxing; spuštění MVP/inkrementů a korekce na základě zpětné vazby.<sup>[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Ignorování nefunkčních požadavků**. Jak předejít: vymezit NFR (např. FURPS+), stanovit měřitelná kritéria, zahrnout je do plánu testování a architektonických rozhodnutí.<sup>[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Komunikační chyby a „lidský faktor"**. Jak řešit: rozvíjet techniky rozhovorů a facilitace, zachovávat neutralitu, zaznamenávat rozhodnutí a zdroje požadavků (sledovatelnost k cílům).<sup>[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)</sup>

Většina problémů se týká kvality formulací, úplnosti a řiditelnosti požadavků; používání standardů ISO/IEC/IEEE 29148 a postupů SWEBOK (validovatelnost, sledovatelnost, iterativnost) výrazně snižuje riziko zpoždění a přepracování.<sup>[\[3\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-SWEBOK-1)</sup>

## Omezení

Přes svou účinnost při snižování nejistoty má systémová analýza svá omezení:

- **Realita je proměnlivá a složitá.** Nelze zohlednit všechny faktory, zvláště v dlouhodobých projektech. Některé požadavky se nevyhnutelně projeví až po spuštění systému. Je důležité usilovat o minimalizaci překvapení, ale je třeba být připraven na změny.
- **Požadavky závisí na lidech.** Priority businessu, zákony a trh se mohou měnit. Systémová analýza zachycuje aktuální stav a nemůže předpovědět všechny externí změny. Aby bylo možné se přizpůsobit, je nutné pravidelně aktualizovat požadavky a pracovat iterativně.
- **Uživatelé ne vždy vědí, co chtějí, dokud to neuvidí.** Toto je known omezení. Prototypování a agilní metodologie, jako je Agile, pomáhají tento problém překonat. Analýza na papíře má své meze a pro získání přesných dat je potřebná zpětná vazba z realizací.
- **Rovnováha mezi časem a kvalitou.** Příliš detailní analýza může zastaraet. V inovativních oblastech je lepší rychle vytvořit minimálně životaschopný produkt (MVP) a získat reálná data. Systémová analýza je efektivní ve stabilních oblastech, ale ve výzkumných projektech (R&D) je její role omezena.
- **Lidský faktor.** Ani ty nejlepší metodologie nekompenzují nekompetentnost analytika nebo nedostupnost zákazníka. Je důležité, aby všichni účastníci procesu byli zapojeni a motivováni.

## Vliv moderních technologií na systémovou analýzu v IT

Systémová analýza v IT se neustále vyvíjí pod vlivem technologických inovací. Analytik 21. století pracuje v podmínkách explozivního růstu dat, všudypřítomného zavádění AI, rychlého vývojového cyklu a zvýšeného důrazu na bezpečnost. Úspěšná praxe systémové analýzy vyžaduje osvojení nových znalostí (Data Science, kybernetická bezpečnost, cloudové technologie) a flexibilitu při uplatňování metod.

- **Data a AI/ML: co se přidává do analýzy**. Pro systémy s AI se již na začátku fixují cíle a kontext použití, požadavky na zdroje a kvalitu dat a také metriky důvěry v rozhodnutí modelu (spolehlivost, bezpečnost, vysvětlitelnost, soukromí, spravedlivost). Plánují se kontroly **TEVV** (testing, evaluation, verification, validation), monitoring v provozu a bezpečné odstavení/vyřazení modelu. Tyto kroky odpovídají funkcím **GOVERN–MAP–MEASURE–MANAGE** z rámce NIST pro řízení rizik AI; jsou zohledněny v SRS, architektuře a plánech verifikace/provozu.<sup>[\[70\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NIST_AI_RMF-70)</sup>

<!-- -->

- **DevSecOps: bezpečnost „vlevo" a ve výchozím nastavení**. Zabudování bezpečnosti do každé etapy **CI/CD** se stává normou: automatické kontroly (SAST/DAST), skenování závislostí a kontejnerů, zásady nasazení, základní pozorovatelnost. Používají se důvěryhodné registry artefaktů a standardizované „hardened" obrazy; uplatňují se principy nulové důvěry. V systémové analýze jsou předem popsány **kontrolní body procesu** (podmínky průchodu etapami), vazba požadavků na bezpečnostní kontroly a pravidla přechodu mezi prostředími (dev/test/stage/prod).<sup>[\[71\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-DoD_DevSecOps-71)</sup>

<!-- -->

- **Co se mění v dokumentech (artefaktech)**. Jaká sekce se objevuje nebo upřesňuje v klíčových dokumentech při práci s Big Data a AI/ML a při práci podle DevSecOps:
  - **SRS / Specifikace požadavků**: cíle a kontext použití AI; požadavky na data (původ, kvalita, etická a právní omezení); metriky modelu (přesnost, spolehlivost, doba odezvy); plán TEVV (testing, evaluation, verification, validation); požadavky na transparentnost/vysvětlitelnost a soukromí; kritéria odstavení/vyřazení modelu z provozu.<sup>[\[70\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Architektura a rozhodnutí (Architecture, ADR)**: výsledky modelování hrozeb; opatření „bezpečnost ve výchozím nastavení" (šifrování, řízení přístupu, správa tajemství, princip nejnižšího oprávnění); omezení pro použití dat/modelů; záznamy ADR s hodnocením rizik a kompromisů.<sup>[\[71\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Plán verifikace a validace (V&V / TEVV)**: scénáře testování modelů a dat; prahové hodnoty přijetí pro metriky kvality; monitoring driftu dat/modelu; postupy periodického přehodnocení a opakované validace.<sup>[\[70\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Zásady CI/CD a „brány" procesu**: automatické kontroly SAST/DAST, SCA (závislosti), skenování kontejnerů; podpis a ukládání artefaktů v důvěryhodných registrech; pravidla postupu mezi prostředími (dev/test/stage/prod) a podmínky blokování sestavení při selhání kontrol; požadavky na pozorovatelnost ve výchozím nastavení.<sup>[\[71\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **Plán řízení dat a modelů**: katalog zdrojů a lineage; kritéria kvality a dostupnosti dat; verze datasetů/modelů; harmonogram (do)učení a kontrola bias; zásady přístupu a uchovávání; plán bezpečné deaktivace modelu a smazání dat, je-li to požadováno.<sup>[\[70\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Provoz a pozorovatelnost (Ops/Runbook)**: metriky důvěry v AI a SLO; audit a protokolování; alerty na degradaci/anomálie; plán reakce na incidenty; fallback/kill‑switch pro AI komponenty; požadavky na reporting a analýzu po incidentech.<sup>[\[70\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **Sledovatelnost** (end‑to‑end): explicitní vazby „**požadavek ↔ kontrola/ověření v procesu**\\ a „**požadavek ↔ test/monitoring v provozu**", aby bylo možné prokazatelně ověřovat bezpečnost a kvalitu po celý životní cyklus.<sup>[\[71\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NIST_AI_RMF-70)</sup>
- **Role systémového analytika**.
  - řídí kontext a rizika AI (aktéři, scénáře použití, předpoklady a omezení dat);
  - zajišťuje sledovatelnost „**požadavek ↔ bezpečnostní kontrola v procesu**";
  - formuluje ověřitelné nefunkční požadavky (bezpečnost, transparentnost, pozorovatelnost) po celý životní cyklus systému.<sup>[\[70\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-DoD_DevSecOps-71)</sup>

## Rozdíly od klasické systémové analýzy

Termín „systémová analýza" je historicky širší než vývoj softwaru. Klasická systémová analýza je přístupem k řešení složitých interdisciplinárních úloh (sociálních, ekonomických, manažerských), založený na systémovém myšlení a kvantitativních metodách, obvykle pro podporu manažerských rozhodnutí. V IT se systémovou analýzou rozumí aplikovaná disciplína v oblasti softwarového inženýrství zaměřená na tvorbu informačních systémů.

Níže jsou klíčové rozdíly.

- **Cíle a objekt analýzy**. Klasická analýza řeší špatně strukturované, „rozmazané" problémy a zlepšuje již existující sociotechnické systémy (městská dopravní síť, strategie společnosti, ekologická politika). Objektem je reálný systém; úkolem je pomoci rozhodovateli zvolit postup. Pro systémovou analýzu v IT je cílem navrhnout a vytvořit nový informační systém nebo softwarový produkt odpovídající požadavkům. Objektem je navrhovaný systém; fokus je na chování a vlastnostech potřebných uživatelům.

<!-- -->

- **Metodologické základy**. Klasické školy se opírají o systémové myšlení a často o matematiku. Tvrdý přístup (hard systems) — formalizace problému, kvantitativní kritéria, optimalizace (jako v *operations research*). Měkké metodologie (soft systems) uznávají mnohočetnost pohledů; příkladem je *Soft Systems Methodology (SSM)*, kde prostřednictvím diskusí a konceptuálních modelů se slaďují požadované změny. V IT je základem inženýrské disciplíny: inženýrství požadavků, navrhování softwaru, architektonické rámce. Používají se standardizované procesy (ISO/IEC/IEEE 15288, 12207, 29148), notace UML/SysML a postupy řízení změn.

<!-- -->

- **Role a artefakty**. V klasické analýze je role „systémového analytika" často neformální; výsledky jsou analytická zpráva, doporučení, matematické modely, scénáře „co kdyby". V IT je role analytika (nebo obchodního analytika) formalizována; vydávají se specifikace požadavků, modely systému (UML, ER), specifikace rozhraní, user stories a backlog — artefakty přímo používané vývojáři a testery.

<!-- -->

- **Životní cyklus a proces**. Klasická analýza nemá jednotnou šablonu: kroky závisí na problému (v SSM — od zkoumání situace po zavádění změn). V IT jsou přijaty standardní cykly SDLC: v kaskádním modelu existuje samostatná fáze analýzy požadavků; v iterativních a agilních přístupech je analýza trvalou činností každého sprintu. Moderní postupy (DevOps, CI/CD) rozšiřují rámec analýzy na provoz: zohledňují se požadavky na udržovatelnost, pozorovatelnost a aktualizovatelnost. Jinými slovy, systémová analýza v IT je zabudována do životního cyklu vývoje, zatímco klasická se provádí spíše jako projektová/konzultační činnost.

## Systémový analytik

**Systémový analytik v IT** — specialista odpovídající za systémové myšlení při navrhování a rozvoji informačních systémů: formování a validaci požadavků, modelování (UML/BPMN), slaďování architektonických rozhodnutí a zajišťování integrace. Role a kvalifikační požadavky v RF jsou zakotveny v profesním standardu a FGOS.

**Hlavní cíl druhu profesní činnosti:** Zajištění souladu IT služby, automatizovaného systému, automatizovaného informačního systému, automatizovaného řídicího systému, softwarového, informačního produktu nebo prostředku (dále - Systém) s okolím, výchozími požadavky a omezeními, cíli automatizace a automatizované činnosti prostřednictvím vývoje a předávání kvalitních a vzájemně provázaných projektových rozhodnutí zainteresovaným stranám při spouštění a koordinaci práce jednotlivých realizátorů po celý životní cyklus Systému (*Profesní standard „Systémový analytik" (příkaz Ministerstva práce RF ze dne 27.04.2023 č. 367n*).<sup>[\[72\]](https://systems-analysis.info/int/Syst%C3%A9mov%C3%A1_anal%C3%BDza_v_IT#cite_note-72)</sup>

## Glosář klíčových pojmů

### Základní pojmy a účastníci

- Systémová analýza v IT — disciplína, jejímž předmětem je informační systém po celém svém životním cyklu, od záměru po provoz.
- Stakeholdeři — osoby nebo skupiny zainteresované na projektu nebo jím dotčené (zákazníci, uživatelé, manažeři).
- Projektové artefakty — dokumenty a výsledky vytvářené v průběhu projektu, jako jsou specifikace, modely, plány a rozhodnutí.

### Požadavky: druhy a dokumentace

- Funkční požadavky — popisují, co má systém dělat; jeho funkce a chování.
- Nefunkční požadavky — popisují atributy kvality systému (spolehlivost, výkon, bezpečnost, použitelnost, škálovatelnost atd.).
- Specifikace požadavků (primární) — dokument obsahující výchozí sadu požadavků shromážděných v počátečních etapách projektu.
- SRS (Software Requirements Specification) — standardizovaný dokument podrobně popisující požadavky na software podle mezinárodních standardů (např. ISO/IEC/IEEE 29148).
- URS (User Requirements Specification) — dokument popisující požadavky uživatele na systém z pohledu obchodních procesů a očekávání koncového uživatele.

<!-- -->

- Architektonicky významné požadavky (ASR) — požadavky podstatně ovlivňující architektonická rozhodnutí a kompromisy.
- Průřezové funkční požadavky (CFR) — synonymum nefunkčních požadavků zdůrazňující jejich průřezový charakter.
- Akceptační kritéria (Acceptance Criteria) — ověřitelné podmínky, při jejichž splnění je práce na požadavku považována za přijatou.
- Definition of Ready (DoR) — dohoda o připravenosti položky backlogu k vývoji (srozumitelnost, odhad, kritéria).
- Definition of Done (DoD) — dohoda o „dokončenosti" práce (kód, testy, dokumentace, nasazení).
- Omezení (Constraint) — pevná podmínka omezující řešení (termíny, platformy, standardy, licence).
- Předpoklad (Assumption) — tvrzení přijímané bez důkazu, vyžadující následnou validaci.
- Kvalita požadavků — vlastnosti dle ISO 29148: jednoznačnost, úplnost, nerozpornost, ověřitelnost, atomárnost.

### Formalizace, sledovatelnost a prioritizace požadavků

- Formalizace požadavků — proces přeměny neformálních žádostí v jasné, ověřitelné a jednoznačné požadavky.
- Sledovatelnost požadavků — možnost sledovat životní cyklus požadavku od jeho zdroje po realizaci, testování a nasazení.
- Bidirectional traceability (obousměrná sledovatelnost) — schopnost sledovat vazby mezi požadavky, prvky návrhu a testovacími scénáři v přímém i zpětném směru.
- MoSCoW — technika prioritizace požadavků, klasifikující je jako Must-have (musí být), Should-have (mělo by být), Could-have (mohlo by být) a Won't-have (nebude).
- BDD (Behavior-Driven Development) — metodologie vývoje, při níž jsou testy psány v přirozeném jazyce orientovaném na chování systému z pohledu uživatele (formát Given–When–Then).

### Notace a modelování

- UML (Unified Modeling Language) — standardizovaný jazyk grafického modelování pro specifikaci, vizualizaci, konstruování a dokumentování komponent softwarových systémů.
- SysML (Systems Modeling Language) — rozšíření UML pro systémové inženýrství, podporující modelování různých aspektů složitých systémů, včetně požadavků, chování, struktury a parametrů.
- BPMN (Business Process Model and Notation) — standard grafické notace pro popis obchodních procesů, umožňující vizualizaci toků prací, událostí, bran a bazénů.
- MBSE (Model-Based Systems Engineering) — přístup k systémovému inženýrství, kde model je centrálním artefaktem ve všech etapách životního cyklu systému, od požadavků po testování.
- ArchiMate — notace podnikové architektury (business, aplikace, technologie) a jejich vazby.
- DMN (Decision Model and Notation) — modelování obchodních rozhodnutí a tabulek pravidel.
- DFD (Data Flow Diagram) — diagramy toků dat (kontext, úrovně dekompozice).
- ERD (Entity-Relationship Diagram) — model předmětné oblasti s entitami, vazbami a atributy.
- CRUD-matice — korespondence operací Create/Read/Update/Delete s entitami a rolemi/funkcemi.

### Architektonické styly a hodnocení řešení

- Monolitická architektura — architektonický přístup, při němž je celý systém vyvíjen jako jediný, nedělitelný modul.
- Mikroservisní architektura — architektonický přístup, při němž je systém budován jako sada malých, nezávisle nasaditelných a škálovatelných služeb.
- Trade-off (kompromis) — volba mezi vzájemně se vylučujícími nebo protichůdnými vlastnostmi či řešeními, kde zlepšení jedné vlastnosti nastává na úkor zhoršení druhé.
- ATAM (Architecture Tradeoff Analysis Method) — metoda hodnocení softwarové architektury, používaná k analýze kompromisů mezi kvalitativními atributy (např. výkonem, škálovatelností).

### Podniková architektura a rámce

- TOGAF (The Open Group Architecture Framework) — jeden z nejrozšířenějších rámců podnikové architektury, zahrnující metodu ADM (Architecture Development Method) pro vývoj a řízení architektury.
- Zachman Framework — ontologie artefaktů podnikové architektury, představená jako matice 6×6, klasifikující různé aspekty architektury z různých perspektiv.

### Přístupy k analýze a procesům vývoje

- Tvrdý přístup (Hard Systems) — metodologie systémové analýzy předpokládající předem formalizovatelné cíle a požadavky, dekompozici a navrhování „shora dolů", efektivní pro jasně definované úlohy.
- Měkký přístup (Soft Systems) — metodologie systémové analýzy uplatňovaná při nejasných cílech a mnohočetných pohledech stakeholderů, zaměřená na sladění chápání problému a požadovaných změn.
- SSM (Soft Systems Methodology) — konkrétní metodologie měkkého systémového přístupu, vyvinutá Peterem Checklandem, využívající nástroje jako rich picture, kořenové definice a CATWOE.
- Waterfall (kaskádní model) — klasická metodologie vývoje softwaru, kde etapy (analýza, navrhování, realizace, testování, zavádění) jsou prováděny postupně, s úplným dokončením předchozí etapy před zahájením následující.
- Agile — skupina agilních metodologií vývoje softwaru orientovaných na iterativní vývoj, adaptaci na změny, spolupráci se zákazníkem a průběžné dodávání hodnoty.

### Metody výběru a typické chyby

- AHP (Analytic Hierarchy Process) — metoda vícekriteriálního výběru umožňující strukturovat složité problémy a hodnotit alternativy na základě hierarchie kritérií.
- Gold-plating (syndrom „zlatého pozlátka") — chyba v systémové analýze spočívající v přidávání funkcionality, kterou stakeholdeři nevyžadují, což vede k nárůstu rozsahu a složitosti projektu.

## Odkazy

- 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
- Systémová analýza jednoduše. YouTube
- Systémová analýza v IT jednoduše. YouTube

## Literatura

- ISO/IEC/IEEE (2023). *15288: System Life Cycle Processes*.
- INCOSE (2023). *INCOSE Systems Engineering Handbook*, 5. vyd.
- 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*. Oficiální bezplatná verze.
- 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*. Oficiální bezplatné stažení (na licenci).
- Bass, L.; Clements, P.; Kazman, R. (2021). *Software Architecture in Practice*, 4. vyd.
- Wiegers, K.; Beatty, J. (2013). *Software Requirements*, 3. vyd.
- Rozanski, N.; Woods, E. (2012). *Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives*, 2. vyd.
- 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. vyd.
- Robertson, J.; Robertson, S. (2012). *Mastering the Requirements Process: Getting Requirements Right*, 3. vyd.
- 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. vyd.
- Kendall, K. E.; Kendall, J. E. (2023). *Systems Analysis and Design*, 11. vyd.
- Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). *Systems Analysis and Design: An Object-Oriented Approach with UML*, 8. vyd.
- Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). *Systems Analysis and Design in a Changing World*, 7. vyd.
- Fowler, M. (2003). *UML Distilled: A Brief Guide to the Standard Object Modeling Language*, 3. vyd.
- Delligatti, L. (2013). *SysML Distilled: A Brief Guide to the Systems Modeling Language*.
- Silver, B. (2011). *BPMN Method and Style*, 2. vyd.
- Lankhorst, M. et al. (2017). *Enterprise Architecture at Work: Modelling, Communication and Analysis*, 4. vyd.
- 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. vyd.
- 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. vyd.
- Saaty, T. L. (1980). *The Analytic Hierarchy Process*; (1990) *Decision Making for Leaders*.

## Poznámky

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