---
title: "Analiza systemowa w IT"
source: "https://systems-analysis.info/int/Analiza_systemowa_w_IT"
wiki: "systems-analysis.info/int"
article: "Analiza_systemowa_w_IT"
language: "pl"
categories:
  - "Category:Polish"
  - "Category:Systems analysis"
revision_id: 340
wiki_created_at: 2026-09-06T22:32:20Z
wiki_modified_at: 2026-09-06T22:32:20Z
downloaded_at: 2026-09-07T22:39:30Z
---

# Analiza systemowa w IT

**Analiza systemowa w IT** (*Systems Analysis and Design*) — podejście do projektowania i rozwijania systemów informacyjnych od koncepcji do eksploatacji, obejmujące identyfikację potrzeb, formalizację wymagań, modelowanie dziedziny i procesów, a także ocenę alternatyw i ryzyk. Innymi słowy, analiza systemowa w IT to etap wytwarzania, na którym specjaliści badają zadanie, określają, co system powinien robić, i opracowują rozwiązania służące jego stworzeniu.

**Klasyczna analiza systemowa** obejmuje szeroki zakres obszarów zastosowań*,* nie tylko wytwarzanie oprogramowania, ale również zmiany organizacyjne, strategie i inne 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>

## Przedmiot i zadania analizy systemowej w IT

**Przedmiotem** **analizy systemowej w IT** jest system informacyjny (produkt programowy i/lub usługa) na całym cyklu życia — od koncepcji i uzasadnienia do realizacji i eksploatacji.

**Zadaniem analizy systemowej** jest przekształcenie potrzeb biznesowych w uzgodniony i weryfikowalny zestaw wymagań i decyzji architektonicznych: identyfikacja i dokumentowanie celów oraz ograniczeń interesariuszy, formalizacja wymagań, modelowanie dziedziny i procesów, ocena wykonalności i ryzyk alternatyw oraz uzasadnienie wybranej architektury. W wyniku tego tworzone są uzgodnione dokumenty i ustanawiane są śledzalne powiązania między wymaganiami, decyzjami projektowymi i testami. Zapewnia to zarządzalność i kontrolę nad procesem wytwarzania.

Zadania analizy systemowej obejmują:

- **Identyfikacja potrzeb i celów interesariuszy**. Analityk zbiera i doprecyzowuje oczekiwania zamawiających, użytkowników i innych zainteresowanych stron; stosuje się wywiady, ankiety, obserwację i analizę bieżących procesów. Na wyjściu formowana jest wstępna **specyfikacja wymagań** z podziałem na funkcjonalne («co system powinien robić») i niefunkcjonalne (niezawodność, wydajność, bezpieczeństwo itp.).<sup>[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)[\[2\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-Zowghi-2)</sup>

<!-- -->

- **Formalizacja i dokumentowanie wymagań**. Żądania przekształcane są w weryfikowalne wymagania. Dobrze sformułowane wymaganie powinno być jasne i jednoznaczne, kompletne, niesprzeczne, weryfikowalne i śledzalne do celów wyższego poziomu; zestaw wymagań — uzgodniony i spójny.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)[\[4\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NASA7123-4)</sup> W praktyce stosuje się ustandaryzowane dokumenty: SRS (*Software Requirements Specification*) według ISO/IEC/IEEE 29148, a także, w niektórych branżach, URS (*User Requirements Specification*) i specyfikacje funkcjonalne.<sup>[\[5\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-5)[\[6\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-6)[\[7\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-7)</sup>

<!-- -->

- **Analiza i modelowanie systemu**. Aby zrozumieć, *jak* system będzie działać i współdziałać ze światem zewnętrznym, budowane są modele: diagramy przypadków użycia (Use Case) dla scenariuszy użycia, DFD dla przepływów danych i procesów biznesowych, diagramy klas/komponentów i inne. Modele służą jako podstawa do porównywania alternatywnych rozwiązań i architektur.<sup>[\[8\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-8)[\[9\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-9)[\[10\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO42010-10)</sup>

<!-- -->

- **Ocena wykonalności i wybór rozwiązania**. Przeprowadzane jest *feasibility study* (wykonalność techniczna, organizacyjna, ekonomiczna, harmonogramowa) oraz porównanie alternatyw architektonicznych (*trade-off*). Do oceny jakości architektury według atrybutów (np. wydajność, skalowalność, modyfikowalność) stosuje się metody takie jak ATAM (*Architecture Tradeoff Analysis Method*).<sup>[\[11\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-11)[\[12\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ATAM-12)</sup> Wybór między np. architekturą monolityczną a mikroserwisową <a href="https://aws.amazon.com/ru/compare/the-difference-between-monolithic-and-microservices-architecture/" class="external autonumber" rel="nofollow">[3]</a> opiera się na jawnych kompromisach (złożoność eksploatacji vs. niezależna skalowalność i szybkość dostarczania) zgodnie z zaleceniami branżowych przewodników.<sup>[\[13\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-13)[\[14\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-14)</sup>

<!-- -->

- **Przygotowanie artefaktów projektowych**. Po zakończeniu analizy tworzone są:
  - zatwierdzona specyfikacja wymagań (z określeniem ich ważności),
  - konceptualny model systemu (diagramy/opisy),
  - decyzje architektoniczne i projektowe (schematy danych, interfejsy systemów zewnętrznych),
  - plan realizacji (etapy/moduły).
  - Krytyczne jest zapewnienie *śledzalności* (bidirectional traceability) wymagań do elementów projektu i testów.<sup>[\[15\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-15)[\[4\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NASA7123-4)</sup>

Sukces projektu IT w znacznej mierze zależy od dojrzałych praktyk pracy z wymaganiami i architekturą. Badanie przeprowadzone przez McKinsey i Oxford wykazało, że duże projekty IT często przekraczają budżet i terminy. Badanie to podkreśliło również, jak ważne jest właściwe zarządzanie strategią, współdziałanie z interesariuszami i staranne zbieranie wymagań. Wszystko to może mieć ogromny wpływ na sukces lub porażkę projektu.<sup>[\[16\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-16)</sup>

## Podejścia i metodologie w analizie systemowej IT

**Analiza systemowa w IT** opiera się na zasadach myślenia systemowego i metodykach zaadaptowanych do wytwarzania oprogramowania. W praktyce łączy się podejścia «twarde» i «miękkie», metodologie strukturalne, notacje obiektowe oraz języki modelowania procesów i wymagań.

- **Podejście twarde i miękkie**. W projektach IT podejście twarde (hard systems) zakłada z góry formalizowalne cele i wymagania, dekompozycję i projektowanie «od góry do dołu». Podejście miękkie (soft systems) stosuje się przy niejasnych celach i wielości punktów widzenia: wykorzystuje się elementy Soft Systems Methodology (SSM) (np. *rich picture*, definicje korzeniowe, CATWOE) w celu uzgodnienia rozumienia problemu i pożądanych zmian; następnie wyniki przekształca się w formalne wymagania.<sup>[\[17\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-17)[\[18\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-18)</sup>

<!-- -->

- **Metodologia SSM (Soft Systems Methodology)**. Pierwotnie opracowana przez *Petera Checklanda* na potrzeby zmian organizacyjnych, SSM jest użyteczna na etapach przedprojektowych w IT: od badania sytuacji problemowej i formułowania definicji korzeniowych (m.in. przez CATWOE) do porównywania modeli konceptualnych z rzeczywistością i osiągania porozumienia między interesariuszami.<sup>[\[19\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-19)[\[20\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-20)</sup>

<!-- -->

- **Metodologie ustrukturyzowane: SADT/IDEF0**. SADT modeluje system jako hierarchię funkcji; standardowa notacja IDEF0 (IEEE 1320.1) utrwala funkcje i ich interfejsy I-C-O-M (Inputs, Controls, Outputs, Mechanisms). Metoda jest wygodna do funkcjonalnej dekompozycji i uzgadniania granic systemu niezależnie od algorytmów.<sup>[\[21\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-21)[\[22\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-22)</sup>

<!-- -->

- **Analiza obiektowa:** UML i SysML (MBSE). UML stał się podstawowym językiem dla wymagań i projektu (diagramy przypadków użycia, klas, sekwencji i inne) i ułatwia walidację scenariuszy z użytkownikami; SysML rozszerza UML na potrzeby inżynierii systemów (diagramy wymagań, diagramy parametryczne) i opiera się na podejściu MBSE, gdzie model jest centralnym artefaktem przez wszystkie etapy od wymagań do testów.<sup>[\[23\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-23)[\[24\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-24)[\[25\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-25)</sup>

<!-- -->

- **Modelowanie procesów biznesowych:** BPMN. Standard BPMN stosuje się do graficznego opisu procesów (pule, przepływy pracy, zdarzenia, bramki), w tym do porównania *as-is/to-be* w specyfikacjach wymagań i integracji.<sup>[\[26\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-26)[\[27\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-27)</sup>

<!-- -->

- **Powiązanie z inżynierią wymagań**. Proces obejmuje etapy elicitation–analysis–specification–validation–change management; kryteria «dobrego wymagania» i struktura SRS są uregulowane przez ISO/IEC/IEEE 29148. Do priorytetyzacji stosuje się techniki **MoSCoW** (Must/Should/Could/Won't) oraz metody wielokryterialnego wyboru, np. AHP. W procesach zwinnych działania analizy systemowej odzwierciedlone są w backlog refinement i śledzalności wymagań.<sup>[\[28\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-28)[\[29\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-29)[\[30\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-30)[\[31\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-31)</sup>

<!-- -->

- **Powiązanie z inżynierią systemów**. W przypadku złożonych systemów (cyberfizycznych) stosuje się model V: na «lewej» gałęzi — analiza systemowa i architektura, na «prawej» — integracja, weryfikacja i walidacja z powiązaniem do artefaktów lewej gałęzi. Metody oceny architektury według atrybutów jakości obejmują ATAM (analiza trade-off).<sup>[\[32\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-32)[\[33\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-33)</sup>

Analiza systemowa w IT łączy sprawdzone podejścia — od miękkich metod uzgadniania wizji do formalnych notacji i standardów. Wybór narzędzi zależy od stopnia określoności zadania: przy wysokiej niepewności wzrasta rola SSM i facylitacji, przy wyraźnych granicach — formalne modele (UML/SysML, IDEF0, BPMN) i regulaminy.

## Związek z architekturą IT i architekturą korporacyjną

Analiza systemowa w projektach IT jest ściśle związana z projektowaniem architektonicznym. Role analityka i architekta nakładają się: analityk formułuje wymagania i model logiczny, architekt określa docelową strukturę rozwiązania i kompromisy techniczne; praca prowadzona jest wspólnie.

- **Architektura systemów IT**. W wąskim sensie architektura oprogramowania to organizacja komponentów, ich relacje i zasady, którymi kieruje się podczas projektowania rozwiązania. Analityk powinien uwzględniać style architektoniczne (warstwowy, klient–serwer, mikroserwisowy, sterowany zdarzeniami i inne), ponieważ wymagania niefunkcjonalne (niezawodność, skalowalność, modyfikowalność) często wyznaczają decyzje architektoniczne i ich kompromisy.<sup>[\[34\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-AzureStyles-34)[\[35\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SEI_ATAM-35)</sup> Na wczesnym etapie analizy formuje się **wizję architektoniczną** (high-level vision) i opracowuje wstępny zarys rozwiązania w celu sprawdzenia wykonalności wymagań (długość iteracji i poziom szczegółowości zależą od metodologii).<sup>[\[36\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-TOGAFIntro-36)</sup>

<!-- -->

- **Szablony i wstępne rozwiązania**. W celu spełnienia wymagań niefunkcjonalnych stosuje się wzorce architektoniczne (architectural patterns). Na przykład, dla asynchronicznej komunikacji i słabego sprzężenia — publish–subscribe przez broker komunikatów w architekturze sterowanej zdarzeniami.<sup>[\[37\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-AzureEvent-37)</sup>

<!-- -->

- **TOGAF (The Open Group Architecture Framework)**. Jeden z najpowszechniejszych frameworków architektury korporacyjnej; obejmuje metodę ADM (Architecture Development Method) i artefakty zarządzania architekturą (repozytorium, katalogi/macierze, zasady). W TOGAF zarządzanie wymaganiami jest procesem przekrojowym, zintegrowanym ze wszystkimi fazami ADM.<sup>[\[36\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-TOGAFIntro-36)</sup> Do obsługi wymagań i śledzalności stosuje się katalogi i macierze (np. wymagania ↔ usługi, funkcje ↔ komponenty), a także rozróżnia się ***Architecture Building Blocks*** i ***Solution Building Blocks***.<sup>[\[38\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-38)[\[39\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-39)</sup> Zasady i standardy przedsiębiorstwa utrwalane są w odpowiednich katalogach i pełnią rolę zewnętrznych niefunkcjonalnych **wymagań** dla zespołów projektowych.<sup>[\[40\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-40)</sup> Zgodność rozwiązań z docelową architekturą jest potwierdzana przez procedurę przeglądu zgodności architektonicznej (Architecture Compliance Review).<sup>[\[41\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-41)</sup> Podejście TOGAF zakłada wstępne **Architecture Vision** oraz późniejsze uszczegółowienie (dane/aplikacje/technologie) z planem migracji i zarządzaniem zmianami wymagań.<sup>[\[42\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-42)[\[43\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-43)</sup>

<!-- -->

- **Zachman Framework**. Wczesna i wpływowa ontologia artefaktów architektury korporacyjnej, przedstawiona jako macierz 6×6 (perspektywy × aspekty «co/jak/gdzie/kto/kiedy/dlaczego»). Wiersz «projektant» odpowiada analizie systemowej i projektowaniu; kolumny wyznaczają kompletność rozpatrywania danych, funkcji/procesów, ról, lokalizacji i motywacji. Framework służy jako klasyfikacja (a nie metodologia) i pomaga zapewnić kompletność opisu rozwiązania w krajobrazie przedsiębiorstwa.<sup>[\[44\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-Zachman1987-44)</sup>

<!-- -->

- **Związek z architekturą korporacyjną (Enterprise Architecture, EA)**. Analityk systemowy pracuje w kontekście EA: nowe wymagania są śledzone do możliwości biznesowych i modelu operacyjnego; stosowane są standardy i zasadnicze ograniczenia przedsiębiorstwa (bezpieczeństwo, kompatybilność itp.).<sup>[\[45\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-45)[\[36\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-TOGAFIntro-36)</sup> Na etapie inicjacji tworzona jest ***Architecture Vision*** (cele/ograniczenia, zagregowane wymagania), następnie analityk uszczegółowia, zachowując śledzalność do wizji i standardów korporacyjnych; niespełnienie standardów ujawniane jest podczas przeglądów architektonicznych i może prowadzić do przeróbek rozwiązania.<sup>[\[36\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-TOGAFIntro-36)[\[46\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-46)</sup>

Podsumowując: analiza systemowa i projektowanie architektoniczne tworzą parę «wymagania → decyzje architektoniczne → kompromisy w zakresie atrybutów jakości». Wybór metod (stylów/wzorców, artefaktów TOGAF, klasyfikacji Zachman) zależy od charakteru projektu i ram architektury korporacyjnej.

## Procesy i praktyki

Analiza systemowa jest zintegrowana z całym cyklem życia wytwarzania i eksploatacji oprogramowania, łącząc cele biznesowe, architekturę i dostarczanie. Obejmuje badanie przedprojektowe, wybór podejścia, tworzenie weryfikowalnych artefaktów oraz wymagania dotyczące niezawodności, wydajności, bezpieczeństwa i utrzymania. W modelu kaskadowym analiza wykonywana jest przed projektowaniem i realizacją, w metodach zwinnych — ciągłe przez iteracje, a w DevOps — z naciskiem na cele eksploatacyjne. Niezależnie od podejścia, analiza zapewnia śledzalność, zarządzanie zmianami i ryzykami, dokumentowanie kompromisów architektonicznych oraz przestrzeganie ograniczeń normatywnych, czyniąc wytwarzanie przewidywalnym i zarządzalnym.

- **Klasyczny SDLC (Waterfall)**. Etap System Analysis & Requirements Definition poprzedza projektowanie i realizację; wymagania są utrwalane w szczegółowej **SRS** jako podstawa planowania i umów. Efektywny w stabilnych i regulowanych domenach; ryzyka «zamrożenia» wymagań zmniejszają SRR/przeglądy i zarządzanie zmianami przez **CCB**.<sup>[\[47\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-Royce-47)[\[48\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-DAU_SRR-48)[\[49\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NASA_CCB-49)</sup>

<!-- -->

- **Metodologie zwinne (Agile)**. Analiza jest ciągła: zamiast finalnej SRS prowadzony jest backlog produktu z user stories z kryteriami akceptacji, doprecyzowywany podczas backlog refinement; stosuje się **BDD** (Given–When–Then); ryzyko utraty spójnej architektury kompensuje wczesne opracowanie architektoniczne i przejrzysta śledzalność wymagań ↔ realizacji/testom.<sup>[\[50\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-MS_Agile-50)[\[51\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-MS_BDD-51)[\[52\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-MS_Trace-52)</sup>

<!-- -->

- **DevOps i SRE**. Częste wydania wymagają domyślnych wymagań operacyjnych: automatyzacji, obserwowalności, wycofania. Wymagania niefunkcjonalne formułuje się jako SLO/SLI, zarządza się error budget; do backlogu dodaje się zadania dotyczące logów/metryk/trace'ów/alertów; dla wydania bez przestoju — wzorce **blue/green** i inne.<sup>[\[53\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SRE_SLO-53)[\[54\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-AzureMon-54)[\[55\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-AWS_BlueGreen-55)</sup>

<!-- -->

- **Zarządzanie wymaganiami i ryzykami**. Wymagania w ALM mają statusy i powiązania z zadaniami/wydaniami/defektami; obowiązkowe są version control, change impact analysis i regularna repriorytyzacja.<sup>[\[56\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-Azure_Workflow-56)[\[57\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-Azure_Backlog-57)</sup>

<!-- -->

- **Zapewnienie jakości (QA)**. Jakość jest wbudowywana na etapie wymagań: przeglądy, «Three Amigos», plan *Acceptance Test Plan*, testy automatyczne kryteriów akceptacji (BDD/ATDD).<sup>[\[58\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-MS_Test-58)[\[59\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-MS_SpecFlow-59)</sup>

<!-- -->

- **Obserwowalność i niezawodność**. W wymagania włącza się SLA/SLO, MTTR i MTBF z mierzalnymi celami i metodami kontroli; parametry napływają od biznesu/eksploatacji i są wbudowywane w architekturę i testy niezawodności.<sup>[\[60\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-IBM_MTTR-60)[\[61\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-GCloud_Obs-61)</sup>

## Metryki i jakość artefaktów

Do oceny pracy analityka systemowego i jakości jego wyników stosuje się ogólnie przyjęte kryteria. **Wymagania i modele dobrej jakości** stanowią podstawę udanego projektu, dlatego zarządza się nimi przez cały cykl życia (elicitation → specification → verification/validation → change management). Podstawowe atrybuty jakości wymagań są ustalone w standardach ISO/IEC/IEEE 29148 i (historycznie) IEEE 830.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)[\[62\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-IEEE830-62)[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)</sup>

- **Poprawność (Correctness)** — wymaganie odzwierciedla rzeczywistą potrzebę i jest uzgodnione z ekspertami dziedzinowymi; potwierdzone walidacją (review/inspekcja, prototypy, scenariusze).<sup>[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)[\[4\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NASA7123-4)</sup>

<!-- -->

- **Kompletność (Completeness)** — uwzględniono istotne aspekty i warunki.
  - *Kompletność pojedynczego wymagania*: podane są niezbędne szczegóły (np. «wskaźnik przechodzi w status **czerwony przy awarii**», a nie po prostu «staje się czerwony»).
  - *Kompletność specyfikacji*: pokryte są scenariusze/role, określone NFR; osiągana przez listy kontrolne i śledzalność do celów biznesowych; przydatny jest niezależny audyt kompletności (QA/review).<sup>[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Jednoznaczność (Unambiguity)** — sformułowania interpretowane są w jeden jedyny sposób; pomaga słownik, szablony w rodzaju «system **musi robić A, gdy B, jeśli C**», przykłady; diagramy są opatrzone legendą. Weryfikacja — zasada **«czterech oczu»**.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Spójność (Consistency)** — wymagania nie są ze sobą sprzeczne ani z zewnętrznymi ograniczeniami; stosuje się strukturyzację, zbiorcze tabele atrybutów, przeglądy zespołowe; sprawdza się zgodność z regulacjami/standardami.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Weryfikowalność/testowalność (Verifiability)** — spełnienie potwierdzane jest testem/demonstracją/analizą; nieweryfikowalne sformułowania zastępuje się mierzalnymi kryteriami; dla NFR określa się metryki i z góry ustala kryteria akceptacji.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Modyfikowalność i śledzalność (Modifiability & Traceability)** — unikalne ID, logiczna struktura («jedna myśl — jeden akapit»), brak duplikatów; utrzymywane są powiązania «wymaganie ↔ źródło/cel/projekt/test», prowadzona jest macierz **śledzalności (RTM)**.<sup>[\[64\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NASA_RM-64)[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Rangowanie i priorytetyzacja** — jakość zestawu wymagań; stosuje się techniki **MoSCoW** i MCDM (np. **AHP**); priorytetyzacja wspólnie z biznesem wpływa na planowanie i ryzyka.<sup>[\[65\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-MoSCoW-65)[\[66\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-Saaty-66)</sup>

**Metryki jakości wymagań** (przykłady):<sup>[\[63\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NASA_SEH-63)[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)</sup>

- gęstość defektów wymagań (uwag na 100 wymagań);
- liczba zmian po bazowym utrwaleniu;
- metryki pokrycia: udział wymagań z testami; udział wymagań śledzowalnych do celów biznesowych;
- stabilność wymagań (stosunek dodanych/usuniętych do ogólnej liczby za okres);
- rozmiar/złożoność specyfikacji (średnia liczba wymagań w przypadku użycia, głębokość dekompozycji);
- satysfakcja interesariuszy (ankieta).

W dojrzałych procesach (np. **CMMI** poziom 3+) obowiązują regulaminy jakości wymagań: formalne przeglądy, audyty zgodności z szablonami, zbieranie/analiza metryk.<sup>[\[67\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SEI_CMMI-67)</sup> W krytycznych domenach (lotnictwo, kosmonautyka i inne) stosuje się **metody formalne** w celu zwiększenia niezawodności.<sup>[\[68\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NASA_FM-68)</sup>

## Typowe błędy

W projektach IT często spotykane są błędy analizy systemowej: niekompletność i niejednoznaczność wymagań, sprzeczności, rozmyte granice, ignorowanie aspektów niefunkcjonalnych, pominięta integracja i opóźnione bezpieczeństwo. Prowadzi to do przeróbek, opóźnień, wzrostu kosztów i defektów.

Typowe problemy, ich skutki i sposoby zapobiegania.

- **Niekompletność i pominięte wymagania**. Pomijane są role ze szczególnymi uprawnieniami, przypadki brzegowe i NFR. *Skutki:* przebudowa architektury i opóźnienie uruchomienia. Jak uniknąć: listy kontrolne, burze mózgów «co jeśli…», wczesne zaangażowanie testerów, śledzalność do celów biznesowych.<sup>[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)[\[69\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **Niejasne, wieloznaczne sformułowania**. *Skutki:* programiści realizują «nie to», zamawiający jest niezadowolony. Jak uniknąć: mierzalne kryteria, słownik, szablony «A, gdy B, jeśli C», peer‑review.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)[\[69\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **Sprzeczne wymagania**. *Skutki:* opóźnienia w wyjaśnieniach, przeróbki przy integracji. Jak uniknąć: strukturyzacja, weryfikacja reguł biznesowych/regulacji, sesje rozwiązywania konfliktów, sprawdzanie spójności podczas przeglądów.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Syndrom «złotej klamki» (gold‑plating)**. *Skutki:* wzrost zakresu, komplikacja, nowe punkty awarii. Jak uniknąć: powiązanie każdego wymagania z celem/metryką; w Agile — nie włączać zbędnych elementów do backlogu; utrwalać zakres; zob. YAGNI.

<!-- -->

- **Nadmierna szczegółowość tam, gdzie jest zbędna.** Jak uniknąć: oddzielać *co/po co* (wymagania) od *jak* (projekt/realizacja); stosować *design‑free requirements* tam, gdzie to właściwe.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Naruszenie zarządzalności wymaganiami**. *Skutki:* chaos wersji, realizacja «nie tego». Jak uniknąć: jedno źródło prawdy w ALM, historyzacja i statusy, RTM i change impact analysis; zarządzanie zmianami przez CCB.<sup>[\[64\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NASA_RM-64)[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Brak udziału użytkowników**. Jak uniknąć: wywiady, obserwacja, prototypy, regularne pokazy; jawna walidacja z interesariuszami.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Zbyt długi «paraliż analityczny»**. Jak uniknąć: strefa wystarczalności, iteracyjność i timeboxing; uruchomienie MVP/inkrementów i korygowanie na podstawie informacji zwrotnej.<sup>[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Ignorowanie wymagań niefunkcjonalnych**. Jak uniknąć: wyodrębniać NFR (np. FURPS+), określać mierzalne kryteria, włączać je do planu testowania i decyzji architektonicznych.<sup>[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Błędy komunikacyjne i «czynnik ludzki»**. Jak rozwiązać: rozwijać techniki wywiadów i facylitacji, zachowywać neutralność, utrwalać decyzje i źródła wymagań (śledzalność do celów).<sup>[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)</sup>

Większość problemów sprowadza się do jakości sformułowań, kompletności i zarządzalności wymaganiami; stosowanie standardów ISO/IEC/IEEE 29148 i praktyk SWEBOK (weryfikowalność, śledzalność, iteracyjność) znacznie zmniejsza ryzyko opóźnień i przeróbek.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-SWEBOK-1)</sup>

## Ograniczenia

Niemniej jednak, pomimo swojej skuteczności w redukcji niepewności, analiza systemowa ma swoje ograniczenia:

- **Rzeczywistość jest zmienna i złożona.** Nie można uwzględnić wszystkich czynników, szczególnie w projektach długoterminowych. Niektóre wymagania nieuchronnie ujawnią się dopiero po uruchomieniu systemu. Ważne jest dążenie do minimalizacji niespodzianek, ale trzeba być gotowym na zmiany.
- **Wymagania zależą od ludzi.** Priorytety biznesowe, przepisy prawa i rynek mogą się zmieniać. Analiza systemowa utrwala bieżący stan i nie może przewidzieć wszystkich zewnętrznych zmian. Aby się adaptować, konieczna jest regularna aktualizacja wymagań i praca iteracyjna.
- **Użytkownicy nie zawsze wiedzą, czego chcą, dopóki tego nie zobaczą.** To znane ograniczenie. Prototypowanie i metodologie zwinne, takie jak Agile, pomagają pokonać ten problem. Analiza na papierze ma swoje granice i aby uzyskać dokładne dane, potrzebna jest informacja zwrotna z realizacji.
- **Balans między czasem a jakością.** Nadmiernie szczegółowa analiza może się zdezaktualizować. W obszarach innowacyjnych lepiej jest szybko stworzyć minimalnie wartościowy produkt (MVP) i uzyskać rzeczywiste dane. Analiza systemowa jest efektywna w stabilnych obszarach, ale w projektach badawczych (R&D) jej rola jest ograniczona.
- **Czynnik ludzki.** Nawet najlepsze metodologie nie zrekompensują niekompetencji analityka lub niedostępności zamawiającego. Ważne jest, aby wszyscy uczestnicy procesu byli zaangażowani i zmotywowani.

## Wpływ nowoczesnych technologii na analizę systemową w IT

Analiza systemowa w IT stale ewoluuje pod wpływem innowacji technologicznych. Analityk XXI wieku pracuje w warunkach gwałtownego wzrostu danych, powszechnego wdrażania AI, szybkiego cyklu wytwarzania i wzmożonej uwagi na bezpieczeństwo. Skuteczna praktyka analizy systemowej wymaga przyswojenia nowej wiedzy (Data Science, cyberbezpieczeństwo, technologie chmurowe) i elastyczności w stosowaniu metod.

- **Dane i AI/ML: co dodaje się do analizy**. W przypadku systemów z AI już na starcie utrwala się cele i kontekst zastosowania, wymagania dotyczące źródeł i jakości danych, a także metryki zaufania do decyzji modelu (niezawodność, bezpieczeństwo, wyjaśnialność, prywatność, sprawiedliwość). Planuje się weryfikacje **TEVV** (testing, evaluation, verification, validation), monitorowanie podczas eksploatacji oraz bezpieczne wyłączenie/wycofanie modelu. Kroki te odpowiadają funkcjom **GOVERN–MAP–MEASURE–MANAGE** z ram NIST dotyczących zarządzania ryzykiem AI; odzwierciedlane są one w SRS, architekturze i planach weryfikacji/eksploatacji.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NIST_AI_RMF-70)</sup>

<!-- -->

- **DevSecOps: bezpieczeństwo «z lewej strony» i domyślne**. Wbudowywanie bezpieczeństwa w każdy etap **CI/CD** staje się normą: automatyczne sprawdzenia (SAST/DAST), skanowanie zależności i kontenerów, polityki wdrożenia, podstawowa obserwowalność. Stosuje się zaufane rejestry artefaktów i standaryzowane «zahartowane» obrazy; stosuje się zasady zerowego zaufania. W analizie systemowej z wyprzedzeniem opisuje się **punkty kontrolne potoku** (warunki przejścia przez etapy), powiązania wymagań z kontrolami bezpieczeństwa oraz reguły przejścia między środowiskami (dev/test/stage/prod).<sup>[\[71\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-DoD_DevSecOps-71)</sup>

<!-- -->

- **Co zmienia się w dokumentach (artefaktach)**. Jaka sekcja pojawia się lub jest doprecyzowywana w kluczowych dokumentach przy obecności Big Data i AI/ML oraz przy pracy w modelu DevSecOps:
  - **SRS / Specyfikacja wymagań**: cele i kontekst zastosowania AI; wymagania dotyczące danych (pochodzenie, jakość, ograniczenia etyczne i prawne); metryki modelu (dokładność, niezawodność, czas odpowiedzi); plan TEVV (testing, evaluation, verification, validation); wymagania dotyczące przejrzystości/wyjaśnialności i prywatności; kryteria wyłączenia/wycofania modelu z eksploatacji.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Architektura i decyzje (Architecture, ADR)**: wyniki modelowania zagrożeń; środki «bezpieczeństwo domyślnie» (szyfrowanie, kontrola dostępu, zarządzanie sekretami, zasada najmniejszych uprawnień); ograniczenia dotyczące korzystania z danych/modeli; wpisy ADR z oceną ryzyk i kompromisów.<sup>[\[71\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Plan weryfikacji i walidacji (V&V / TEVV)**: scenariusze testowania modeli i danych; progi akceptacji dla metryk jakości; monitorowanie dryfu danych/modelu; procedury okresowej ponownej oceny i ponownej walidacji.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Polityki CI/CD i «bramki» potoku**: automatyczne sprawdzenia SAST/DAST, SCA (zależności), skanowanie kontenerów; podpisywanie i przechowywanie artefaktów w zaufanych rejestrach; reguły awansu między środowiskami (dev/test/stage/prod) i warunki blokowania kompilacji przy niepowodzeniu sprawdzeń; wymagania dotyczące domyślnej obserwowalności.<sup>[\[71\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **Plan zarządzania danymi i modelami**: katalog źródeł i lineage; kryteria jakości i dostępności danych; wersje zbiorów danych/modeli; harmonogram (do)uczenia i kontrola bias; polityka dostępu i przechowywania; plan bezpiecznej deaktywacji modelu i usunięcia danych, jeśli wymagane.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Eksploatacja i obserwowalność (Ops/Runbook)**: metryki zaufania do AI i SLO; audyt i dziennikowanie; alerty na degradację/anomalie; plan reagowania na incydenty; fallback/kill‑switch dla komponentów AI; wymagania dotyczące raportowania i analizy poincydentalnej.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **Śledzalność** (end‑to‑end): jawne powiązania «**wymaganie ↔ kontrola/weryfikacja w potoku**» i «**wymaganie ↔ test/monitorowanie w eksploatacji**», aby można było dowodowo weryfikować bezpieczeństwo i jakość przez cały cykl życia.<sup>[\[71\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NIST_AI_RMF-70)</sup>
- **Rola analityka systemowego**.
  - zarządza kontekstem i ryzykami AI (aktorzy, scenariusze zastosowania, założenia i ograniczenia danych);
  - zapewnia śledzalność «**wymaganie ↔ kontrola bezpieczeństwa w potoku**»;
  - formułuje weryfikowalne wymagania niefunkcjonalne (bezpieczeństwo, przejrzystość, obserwowalność) przez cały cykl życia systemu.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-DoD_DevSecOps-71)</sup>

## Różnice w stosunku do klasycznej analizy systemowej

Termin «analiza systemowa» jest historycznie szerszy niż wytwarzanie oprogramowania. Klasyczna analiza systemowa to podejście do rozwiązywania złożonych, interdyscyplinarnych zadań (społecznych, ekonomicznych, zarządczych), oparte na myśleniu systemowym i metodach ilościowych, zazwyczaj służące wspieraniu decyzji kierowniczych. W IT przez analizę systemową rozumie się stosowaną dyscyplinę z dziedziny inżynierii oprogramowania, ukierunkowaną na tworzenie systemów informacyjnych.

Poniżej — kluczowe różnice.

- **Cele i obiekt analizy**. Klasyczna analiza rozwiązuje słabo ustrukturyzowane, «rozmyte» problemy i ulepsza już istniejące systemy socjotechniczne (miejska sieć transportowa, strategia firmy, polityka ekologiczna). Obiektem jest rzeczywisty system; zadaniem — pomóc osobie decyzyjnej w wyborze kierunku działania. Dla analizy systemowej w IT celem jest zaprojektowanie i stworzenie nowego systemu informacyjnego lub produktu programowego spełniającego wymagania. Obiekt — projektowany system; fokus — zachowanie i cechy potrzebne użytkownikom.

<!-- -->

- **Podstawy metodologiczne**. Klasyczne szkoły opierają się na myśleniu systemowym i często na matematyce. Podejście twarde (hard systems) — formalizacja problemu, ilościowe kryteria, optymalizacja (jak w *operations research*). Miękkie metodologie (soft systems) uznają wielość punktów widzenia; przykładem jest *Soft Systems Methodology (SSM)*, gdzie poprzez dyskusje i modele konceptualne uzgadnia się pożądane zmiany. W IT podstawą są dyscypliny inżynieryjne: inżynieria wymagań, projektowanie oprogramowania, frameworki architektoniczne. Stosowane są ustandaryzowane procesy (ISO/IEC/IEEE 15288, 12207, 29148), notacje UML/SysML oraz praktyki zarządzania zmianami.

<!-- -->

- **Role i artefakty**. W klasycznej analizie rola «analityka systemowego» jest często nieformalna; wynikami są raport analityczny, rekomendacje, modele matematyczne, scenariusze «co‑jeśli». W IT rola analityka (lub analityka biznesowego) jest sformalizowana; wydawane są specyfikacje wymagań, modele systemu (UML, ER), specyfikacje interfejsów, user stories i backlog — artefakty bezpośrednio używane przez programistów i testerów.

<!-- -->

- **Cykl życia i proces**. Klasyczna analiza nie ma jednolitego szablonu: kroki zależą od problemu (w SSM — od zbadania sytuacji do wdrożenia zmian). W IT przyjęte są standardowe cykle SDLC: w modelu kaskadowym istnieje oddzielna faza analizy wymagań; w podejściach iteracyjnych i zwinnych analiza jest stałą działalnością każdego sprintu. Nowoczesne praktyki (DevOps, CI/CD) rozszerzają ramy analizy na eksploatację: uwzględniane są wymagania dotyczące utrzymania, obserwowalności i aktualizowalności. Innymi słowy, analiza systemowa w IT jest wbudowana w cykl życia wytwarzania, podczas gdy klasyczna częściej realizowana jest jako działalność projektowa/doradcza.

## Analityk systemowy

**Analityk systemowy w IT** — specjalista odpowiedzialny za myślenie systemowe w projektowaniu i rozwijaniu systemów informacyjnych: tworzenie i walidację wymagań, modelowanie (UML/BPMN), uzgadnianie decyzji architektonicznych i zapewnianie integracji. Rola i wymagania kwalifikacyjne w RF są utrwalone w standardzie zawodowym i FGOS.

**Główny cel rodzaju działalności zawodowej:** Zapewnienie zgodności usługi IT, systemu zautomatyzowanego, zautomatyzowanego systemu informacyjnego, zautomatyzowanego systemu zarządzania, produktu lub środka programowego lub informacyjnego (dalej — System) z otoczeniem, wyjściowymi wymaganiami i ograniczeniami, celami automatyzacji i zautomatyzowanej działalności poprzez opracowanie i przekazanie jakościowych i wzajemnie powiązanych rozwiązań projektowych zainteresowanym stronom przy uruchamianiu i koordynowaniu pracy poszczególnych wykonawców na całym cyklu życia Systemu (*Standard zawodowy «Analityk systemowy» (zarządzenie Ministerstwa Pracy RF z dnia 27.04.2023 nr 367н*).<sup>[\[72\]](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_note-72)</sup>

## Słownik kluczowych terminów

### Podstawowe pojęcia i uczestnicy

- Analiza systemowa w IT — dyscyplina, której przedmiotem jest system informacyjny na całym jego cyklu życia, od koncepcji do eksploatacji.
- Interesariusze — osoby lub grupy zainteresowane projektem lub dotknięte przez niego (zamawiający, użytkownicy, menedżerowie).
- Artefakty projektowe — dokumenty i wyniki tworzone w procesie projektu, takie jak specyfikacje, modele, plany i decyzje.

### Wymagania: rodzaje i dokumentacja

- Wymagania funkcjonalne — opisują, co system powinien robić; jego funkcje i zachowanie.
- Wymagania niefunkcjonalne — opisują atrybuty jakości systemu (niezawodność, wydajność, bezpieczeństwo, łatwość użytkowania, skalowalność itp.).
- Specyfikacja wymagań (wstępna) — dokument zawierający wyjściowy zestaw wymagań zebranych na początkowych etapach projektu.
- SRS (Software Requirements Specification) — ustandaryzowany dokument szczegółowo opisujący wymagania dotyczące oprogramowania zgodnie z normami międzynarodowymi (np. ISO/IEC/IEEE 29148).
- URS (User Requirements Specification) — dokument opisujący wymagania użytkownika wobec systemu z punktu widzenia procesów biznesowych i oczekiwań użytkownika końcowego.

<!-- -->

- Wymagania architektonicznie istotne (ASR) — wymagania mające istotny wpływ na decyzje architektoniczne i kompromisy.
- Wymagania przekrojowe (CFR) — synonim wymagań niefunkcjonalnych, podkreślający ich przekrojowy charakter.
- Kryteria akceptacji (Acceptance Criteria) — weryfikowalne warunki, przy spełnieniu których praca nad wymaganiem jest uznawana za przyjętą.
- Definition of Ready (DoR) — umowa dotycząca gotowości elementu backlogu do wytwarzania (jasność, oszacowanie, kryteria).
- Definition of Done (DoD) — umowa dotycząca «ukończenia» pracy (kod, testy, dokumentacja, wdrożenie).
- Ograniczenie (Constraint) — twarde warunki ograniczające rozwiązania (terminy, platformy, standardy, licencje).
- Założenie (Assumption) — przypuszczenie przyjmowane bez dowodu, wymagające późniejszej walidacji.
- Jakość wymagań — właściwości według ISO 29148: jednoznaczność, kompletność, niesprzeczność, weryfikowalność, atomowość.

### Formalizacja, śledzalność i priorytetyzacja wymagań

- Formalizacja wymagań — proces przekształcania nieformalnych żądań w jasne, weryfikowalne i jednoznaczne wymagania.
- Śledzalność wymagań — możliwość śledzenia cyklu życia wymagania od jego źródła do realizacji, testowania i wdrożenia.
- Bidirectional traceability (dwukierunkowa śledzalność) — zdolność do śledzenia powiązań między wymaganiami, elementami projektu i scenariuszami testowymi zarówno w kierunku do przodu, jak i wstecz.
- MoSCoW — technika priorytetyzacji wymagań klasyfikująca je jako Must-have (musi być), Should-have (powinno być), Could-have (może być) i Won't-have (nie będzie).
- BDD (Behavior-Driven Development) — metodologia wytwarzania, w której testy pisane są w języku naturalnym zorientowanym na zachowanie systemu z punktu widzenia użytkownika (format Given–When–Then).

### Notacje i modelowanie

- UML (Unified Modeling Language) — ustandaryzowany język graficznego modelowania służący do specyfikacji, wizualizacji, konstruowania i dokumentowania komponentów systemów programowych.
- SysML (Systems Modeling Language) — rozszerzenie UML dla inżynierii systemów, obsługujące modelowanie różnych aspektów złożonych systemów, w tym wymagań, zachowania, struktury i parametrów.
- BPMN (Business Process Model and Notation) — standard notacji graficznej do opisu procesów biznesowych, umożliwiający wizualizację przepływów pracy, zdarzeń, bramek i pul.
- MBSE (Model-Based Systems Engineering) — podejście do inżynierii systemów, gdzie model jest centralnym artefaktem na wszystkich etapach cyklu życia systemu, od wymagań do testowania.
- ArchiMate — notacja architektury korporacyjnej (biznes, aplikacje, technologie) i ich powiązań.
- DMN (Decision Model and Notation) — modelowanie decyzji biznesowych i tabel reguł.
- DFD (Data Flow Diagram) — diagramy przepływu danych (kontekst, poziomy dekompozycji).
- ERD (Entity-Relationship Diagram) — model dziedziny z encjami, relacjami i atrybutami.
- Macierz CRUD — odwzorowanie operacji Create/Read/Update/Delete na encje i role/funkcje.

### Style architektoniczne i ocena rozwiązań

- Architektura monolityczna — podejście architektoniczne, w którym cały system jest wytwarzany jako jeden, niepodzielny moduł.
- Architektura mikroserwisowa — podejście architektoniczne, w którym system budowany jest jako zestaw małych, niezależnie wdrażanych i skalowalnych usług.
- Trade-off (kompromis) — wybór między wzajemnie wykluczającymi się lub sprzecznymi cechami lub rozwiązaniami, gdzie poprawa jednej cechy odbywa się kosztem pogorszenia innej.
- ATAM (Architecture Tradeoff Analysis Method) — metoda oceny architektury oprogramowania, stosowana do analizy kompromisów między atrybutami jakości (np. wydajnością, skalowalnością).

### Architektura korporacyjna i frameworki

- TOGAF (The Open Group Architecture Framework) — jeden z najpowszechniejszych frameworków architektury korporacyjnej, obejmujący metodę ADM (Architecture Development Method) do opracowywania i zarządzania architekturą.
- Zachman Framework — ontologia artefaktów architektury korporacyjnej, przedstawiona jako macierz 6×6, klasyfikująca różne aspekty architektury z różnych perspektyw.

### Podejścia do analizy i procesów wytwarzania

- Podejście twarde (Hard Systems) — metodologia analizy systemowej zakładająca z góry formalizowalne cele i wymagania, dekompozycję i projektowanie «od góry do dołu», efektywna dla wyraźnie zdefiniowanych zadań.
- Podejście miękkie (Soft Systems) — metodologia analizy systemowej stosowana przy niejasnych celach i wielości punktów widzenia interesariuszy, ukierunkowana na uzgadnianie rozumienia problemu i pożądanych zmian.
- SSM (Soft Systems Methodology) — konkretna metodologia miękkiego podejścia systemowego, opracowana przez Petera Checklanda, wykorzystująca narzędzia takie jak rich picture, definicje korzeniowe i CATWOE.
- Waterfall (model kaskadowy) — klasyczna metodologia wytwarzania oprogramowania, gdzie etapy (analiza, projektowanie, realizacja, testowanie, wdrożenie) wykonywane są sekwencyjnie, z pełnym zakończeniem poprzedniego etapu przed rozpoczęciem następnego.
- Agile — grupa zwinnych metodologii wytwarzania oprogramowania, zorientowanych na iteracyjne wytwarzanie, adaptację do zmian, współdziałanie z zamawiającym i ciągłe dostarczanie wartości.

### Metody wyboru i typowe błędy

- AHP (Analytic Hierarchy Process) — metoda wielokryterialnego wyboru, pozwalająca strukturyzować złożone problemy i oceniać alternatywy na podstawie hierarchii kryteriów.
- Gold-plating (syndrom «złotej klamki») — błąd w analizie systemowej polegający na dodawaniu funkcjonalności, która nie jest wymagana przez interesariuszy, co prowadzi do wzrostu zakresu i złożoności projektu.

## Odnośniki

- 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
- Analiza systemowa w prostych słowach. YouTube
- Analiza systemowa w IT w prostych słowach. YouTube

## Literatura

- ISO/IEC/IEEE (2023). *15288: System Life Cycle Processes*.
- INCOSE (2023). *INCOSE Systems Engineering Handbook*, wyd. 5.
- 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*. Oficjalna bezpłatna wersja.
- 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*. Oficjalne bezpłatne pobieranie (na licencji).
- Bass, L.; Clements, P.; Kazman, R. (2021). *Software Architecture in Practice*, wyd. 4.
- Wiegers, K.; Beatty, J. (2013). *Software Requirements*, wyd. 3.
- Rozanski, N.; Woods, E. (2012). *Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives*, wyd. 2.
- Meadows, D. (2008). *Thinking in Systems: A Primer*.
- Senge, P. M. (2006). *The Fifth Discipline: The Art & Practice of the Learning Organization* (wyd. zmienione).
- Blanchard, B. S.; Fabrycky, W. J. (2010). *Systems Engineering and Analysis*, wyd. 5.
- Robertson, J.; Robertson, S. (2012). *Mastering the Requirements Process: Getting Requirements Right*, wyd. 3.
- van Lamsweerde, A. (2009). *Requirements Engineering: From System Goals to UML Models to Software Specifications*.
- Hull, E.; Jackson, K.; Dick, J. (2017). *Requirements Engineering*, wyd. 4.
- Kendall, K. E.; Kendall, J. E. (2023). *Systems Analysis and Design*, wyd. 11.
- Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). *Systems Analysis and Design: An Object-Oriented Approach with UML*, wyd. 8.
- Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). *Systems Analysis and Design in a Changing World*, wyd. 7.
- Fowler, M. (2003). *UML Distilled: A Brief Guide to the Standard Object Modeling Language*, wyd. 3.
- Delligatti, L. (2013). *SysML Distilled: A Brief Guide to the Systems Modeling Language*.
- Silver, B. (2011). *BPMN Method and Style*, wyd. 2.
- Lankhorst, M. et al. (2017). *Enterprise Architecture at Work: Modelling, Communication and Analysis*, wyd. 4.
- 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*, wyd. 4.
- Silverston, L. (2008–2009). *The Data Model Resource Book*, Vols. 1–3 (wyd. zmienione).
- Keeney, R. L.; Raiffa, H. (1993). *Decisions with Multiple Objectives: Preferences and Value Trade-Offs*, wyd. 2.
- Saaty, T. L. (1980). *The Analytic Hierarchy Process*; (1990) *Decision Making for Leaders*.

## Przypisy

1.  <span id="cite_note-SWEBOK-1">↑ <sup>[1.00](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-0)</sup> <sup>[1.01](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-1)</sup> <sup>[1.02](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-2)</sup> <sup>[1.03](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-3)</sup> <sup>[1.04](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-4)</sup> <sup>[1.05](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-5)</sup> <sup>[1.06](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-6)</sup> <sup>[1.07](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-7)</sup> <sup>[1.08](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-8)</sup> <sup>[1.09](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-9)</sup> <sup>[1.10](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-10)</sup> <sup>[1.11](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-SWEBOK_1-11)</sup> <sup>[1.12](https://systems-analysis.info/int/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-0)</sup> <sup>[3.01](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-1)</sup> <sup>[3.02](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-2)</sup> <sup>[3.03](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-3)</sup> <sup>[3.04](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-4)</sup> <sup>[3.05](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-5)</sup> <sup>[3.06](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-6)</sup> <sup>[3.07](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-7)</sup> <sup>[3.08](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-8)</sup> <sup>[3.09](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-9)</sup> <sup>[3.10](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-10)</sup> <sup>[3.11](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-ISO29148_3-11)</sup> <sup>[3.12](https://systems-analysis.info/int/Analiza_systemowa_w_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/Analiza_systemowa_w_IT#cite_ref-NASA7123_4-0)</sup> <sup>[4.1](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-NASA7123_4-1)</sup> <sup>[4.2](https://systems-analysis.info/int/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_IT#cite_ref-TOGAFIntro_36-0)</sup> <sup>[36.1](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-TOGAFIntro_36-1)</sup> <sup>[36.2](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-TOGAFIntro_36-2)</sup> <sup>[36.3](https://systems-analysis.info/int/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_IT#cite_ref-NASA_SEH_63-0)</sup> <sup>[63.1](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-NASA_SEH_63-1)</sup> <sup>[63.2](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-NASA_SEH_63-2)</sup> <sup>[63.3](https://systems-analysis.info/int/Analiza_systemowa_w_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/Analiza_systemowa_w_IT#cite_ref-NASA_RM_64-0)</sup> <sup>[64.1](https://systems-analysis.info/int/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_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/Analiza_systemowa_w_IT#cite_ref-SEI_Pitfalls_69-0)</sup> <sup>[69.1](https://systems-analysis.info/int/Analiza_systemowa_w_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/Analiza_systemowa_w_IT#cite_ref-NIST_AI_RMF_70-0)</sup> <sup>[70.1](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-NIST_AI_RMF_70-1)</sup> <sup>[70.2](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-NIST_AI_RMF_70-2)</sup> <sup>[70.3](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-NIST_AI_RMF_70-3)</sup> <sup>[70.4](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-NIST_AI_RMF_70-4)</sup> <sup>[70.5](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-NIST_AI_RMF_70-5)</sup> <sup>[70.6](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-NIST_AI_RMF_70-6)</sup> <sup>[70.7](https://systems-analysis.info/int/Analiza_systemowa_w_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/Analiza_systemowa_w_IT#cite_ref-DoD_DevSecOps_71-0)</sup> <sup>[71.1](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-DoD_DevSecOps_71-1)</sup> <sup>[71.2](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-DoD_DevSecOps_71-2)</sup> <sup>[71.3](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-DoD_DevSecOps_71-3)</sup> <sup>[71.4](https://systems-analysis.info/int/Analiza_systemowa_w_IT#cite_ref-DoD_DevSecOps_71-4)</sup> <sup>[71.5](https://systems-analysis.info/int/Analiza_systemowa_w_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/Analiza_systemowa_w_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>