---
title: "Analiza sistemică în IT"
source: "https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT"
wiki: "systems-analysis.info/int"
article: "Analiza_sistemică_în_IT"
language: "ro"
categories:
  - "Category:Romanian"
  - "Category:Systems analysis"
revision_id: 337
wiki_created_at: 2026-09-06T22:32:17Z
wiki_modified_at: 2026-09-06T22:32:17Z
downloaded_at: 2026-09-07T22:39:28Z
---

# Analiza sistemică în IT

**Analiza sistemică în IT** (*Systems Analysis and Design*) — abordare pentru proiectarea și dezvoltarea sistemelor informaționale de la concept până la exploatare, care include identificarea necesităților, formalizarea cerințelor, modelarea domeniului de aplicare și a proceselor, precum și evaluarea alternativelor și riscurilor. Cu alte cuvinte, analiza sistemică în IT este etapa de dezvoltare în care specialiștii studiază sarcina, determină ce trebuie să facă sistemul și elaborează soluții pentru crearea acestuia.

**Analiza sistemică clasică** acoperă un spectru larg de domenii de aplicare*,* nu doar dezvoltarea software, ci și schimbările organizaționale, strategiile și alte aspecte.<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>

## Obiectul și sarcinile analizei sistemice în IT

**Obiectul** **analizei sistemice în IT** este sistemul informațional (produsul software și/sau serviciul) pe tot parcursul ciclului de viață — de la concept și justificare până la implementare și exploatare.

**Sarcina analizei sistemice** — transformarea necesităților de afaceri într-un set coerent și verificabil de cerințe și decizii arhitecturale: identificarea și documentarea obiectivelor și constrângerilor stakeholderilor, formalizarea cerințelor, modelarea domeniului de aplicare și a proceselor, evaluarea fezabilității și riscurilor alternativelor și justificarea arhitecturii alese. Ca rezultat, se creează documente coordonate și se stabilesc legături trasabile între cerințe, decizii de proiectare și teste. Aceasta asigură gestionabilitatea și controlul asupra procesului de dezvoltare.

Sarcinile analizei sistemice includ:

- **Identificarea necesităților și obiectivelor stakeholderilor**. Analistul colectează și clarifică așteptările clienților, utilizatorilor și altor părți interesate; se aplică interviuri, sondaje, observație și analiza proceselor curente. La ieșire se formează o **specificație primară a cerințelor** cu separarea în funcționale („ce trebuie să facă sistemul") și nefuncționale (fiabilitate, performanță, securitate etc.).<sup>[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)[\[2\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-Zowghi-2)</sup>

<!-- -->

- **Formalizarea și documentarea cerințelor**. Solicitările sunt transformate în cerințe verificabile. O cerință bine formulată trebuie să fie clară și lipsită de ambiguitate, completă, necontradictorie, verificabilă și trasabilă la obiective de nivel superior; setul de cerințe — coerent și integru.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)[\[4\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NASA7123-4)</sup> În practică se utilizează documente standardizate: SRS (*Software Requirements Specification*) conform ISO/IEC/IEEE 29148, precum și, în anumite industrii, URS (*User Requirements Specification*) și specificații funcționale.<sup>[\[5\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-5)[\[6\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-6)[\[7\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-7)</sup>

<!-- -->

- **Analiza și modelarea sistemului**. Pentru a înțelege *cum* va funcționa sistemul și va interacționa cu lumea externă, se construiesc modele: diagrame de cazuri de utilizare (Use Case) pentru scenarii de utilizare, DFD pentru fluxuri de date și procese de afaceri, diagrame de clase/componente etc. Modelele servesc drept bază pentru compararea soluțiilor și arhitecturilor alternative.<sup>[\[8\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-8)[\[9\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-9)[\[10\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO42010-10)</sup>

<!-- -->

- **Evaluarea fezabilității și alegerea soluției**. Se realizează *feasibility study* (fezabilitate tehnică, organizațională, economică, calendaristică) și compararea alternativelor arhitecturale (*trade-off*). Pentru evaluarea calității arhitecturii pe atribute (de ex., performanță, scalabilitate, modificabilitate) se aplică metode precum ATAM (*Architecture Tradeoff Analysis Method*).<sup>[\[11\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-11)[\[12\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ATAM-12)</sup> Alegerea între, de exemplu, arhitectura monolitică și cea de microservicii <a href="https://aws.amazon.com/ru/compare/the-difference-between-monolithic-and-microservices-architecture/" class="external autonumber" rel="nofollow">[3]</a> se bazează pe compromisuri explicite (complexitatea exploatării vs. scalabilitate independentă și viteza de livrare) conform recomandărilor ghidurilor industriale.<sup>[\[13\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-13)[\[14\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-14)</sup>

<!-- -->

- **Pregătirea artefactelor de proiect**. În urma analizei se formează:
  - specificația aprobată a cerințelor (cu indicarea importanței acestora),
  - modelul conceptual al sistemului (diagrame/descrieri),
  - decizii arhitecturale și de proiectare (scheme de date, interfețe ale sistemelor externe),
  - planul de implementare (etape/module).
  - Este esențial să se asigure *trasabilitatea* (bidirectional traceability) cerințelor față de elementele de design și teste.<sup>[\[15\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-15)[\[4\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NASA7123-4)</sup>

Succesul unui proiect IT depinde în mare măsură de practicile mature de lucru cu cerințele și arhitectura. Un studiu realizat de McKinsey și Oxford a arătat că proiectele IT mari depășesc adesea bugetul și termenele. Acest studiu a subliniat, de asemenea, cât de important este să gestionezi corect strategia, să interacționezi cu părțile interesate și să colectezi cu atenție cerințele. Toate acestea pot influența puternic succesul sau eșecul unui proiect.<sup>[\[16\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-16)</sup>

## Abordări și metodologii în analiza sistemică IT

**Analiza sistemică în IT** se bazează pe principiile gândirii sistemice și pe metodici adaptate pentru dezvoltarea software. În practică se combină abordări „rigide" și „flexibile", metodologii structurate, notații orientate pe obiecte, precum și limbaje de modelare a proceselor și cerințelor.

- **Abordările rigidă și flexibilă**. În proiectele IT abordarea rigidă (hard systems) presupune obiective și cerințe formalizabile în prealabil, descompunere și proiectare „de sus în jos". Abordarea flexibilă (soft systems) se aplică la obiective neclare și puncte de vedere multiple: se utilizează elemente din Soft Systems Methodology (SSM) (de ex., *rich picture*, definiții de bază, CATWOE) pentru alinierea înțelegerii problemei și a schimbărilor dorite; ulterior, rezultatele sunt transpuse în cerințe formale.<sup>[\[17\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-17)[\[18\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-18)</sup>

<!-- -->

- **Metodologia SSM (Soft Systems Methodology)**. Dezvoltată inițial de *Peter Checkland* pentru schimbări organizaționale, SSM este utilă în etapele pre-proiect IT: de la investigarea situației problematice și formularea definițiilor de bază (inclusiv prin CATWOE) până la compararea modelelor conceptuale cu realitatea și atingerea acomodării între stakeholderi.<sup>[\[19\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-19)[\[20\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-20)</sup>

<!-- -->

- **Metodologii structurate: SADT/IDEF0**. SADT modelează sistemul ca o ierarhie de funcții; notația standard IDEF0 (IEEE 1320.1) fixează funcțiile și interfețele lor I-C-O-M (Inputs, Controls, Outputs, Mechanisms). Metoda este convenabilă pentru descompunerea funcțională și alinierea granițelor sistemului independent de algoritmi.<sup>[\[21\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-21)[\[22\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-22)</sup>

<!-- -->

- **Analiza orientată pe obiecte:** UML și SysML (MBSE). UML a devenit limbajul de bază pentru cerințe și design (diagrame de cazuri de utilizare, clase, secvențe etc.) și facilitează validarea scenariilor cu utilizatorii; SysML extinde UML pentru ingineria sistemelor (diagrame de cerințe, diagrame parametrice) și se bazează pe abordarea MBSE, unde modelul este artefactul central pe toate etapele de la cerințe la teste.<sup>[\[23\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-23)[\[24\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-24)[\[25\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-25)</sup>

<!-- -->

- **Modelarea proceselor de afaceri:** BPMN. Standardul BPMN este utilizat pentru descrierea grafică a proceselor (pool-uri, fluxuri de lucru, evenimente, gateway-uri), inclusiv compararea *as-is/to-be* în specificațiile de cerințe și integrare.<sup>[\[26\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-26)[\[27\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-27)</sup>

<!-- -->

- **Legătura cu ingineria cerințelor**. Procesul include etapele elicitation–analysis–specification–validation–change management; criteriile „cerinței bune" și structura SRS sunt reglementate de ISO/IEC/IEEE 29148. Pentru prioritizare se aplică tehnicile **MoSCoW** (Must/Should/Could/Won't) și metode de selecție multicriterială, de exemplu AHP. În procesele flexibile, activitatea de analiză sistemică se reflectă în backlog refinement și trasabilitatea cerințelor.<sup>[\[28\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-28)[\[29\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-29)[\[30\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-30)[\[31\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-31)</sup>

<!-- -->

- **Legătura cu ingineria sistemelor**. Pentru sisteme complexe (ciberfizice) se aplică modelul V: pe ramura „stângă" — analiza sistemică și arhitectura, pe ramura „dreaptă" — integrarea, verificarea și validarea cu referire la artefactele ramurii stângi. Metodele de evaluare a arhitecturii pe atribute de calitate includ ATAM (analiza trade-off).<sup>[\[32\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-32)[\[33\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-33)</sup>

Analiza sistemică în IT combină abordări verificate — de la metodici flexibile de aliniere a viziunii până la notații formale și standarde. Alegerea instrumentelor este determinată de gradul de certitudine al sarcinii: la incertitudine ridicată crește rolul SSM și facilitării, la granițe clare — modelele formale (UML/SysML, IDEF0, BPMN) și reglementările.

## Legătura cu arhitectura IT și arhitectura întreprinderii

Analiza sistemică în proiectele IT este strâns legată de proiectarea arhitecturală. Rolurile analistului și arhitectului se suprapun: analistul formulează cerințele și modelul logic, arhitectul determină structura țintă a soluției și compromisurile tehnice; lucrul se desfășoară în comun.

- **Arhitectura sistemelor IT**. În sens restrâns, arhitectura software este organizarea componentelor, relațiile lor și principiile care ghidează proiectarea soluției. Analistului îi este important să țină cont de stilurile arhitecturale (stratificat, client–server, microservicii, orientat pe evenimente etc.), deoarece cerințele nefuncționale (fiabilitate, scalabilitate, modificabilitate) determină adesea deciziile arhitecturale și compromisurile acestora.<sup>[\[34\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-AzureStyles-34)[\[35\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SEI_ATAM-35)</sup> În etapa timpurie de analiză se formează **viziunea arhitecturală** (high-level vision) și se elaborează conturul preliminar al soluției pentru verificarea viabilității cerințelor (lungimea iterațiilor și nivelul de detaliere depind de metodologie).<sup>[\[36\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-TOGAFIntro-36)</sup>

<!-- -->

- **Șabloane și soluții preliminare**. Pentru satisfacerea cerințelor nefuncționale se aplică șabloane arhitecturale (architectural patterns). De exemplu, pentru interacțiunea asincronă și cuplarea slabă — publish–subscribe prin broker de mesaje în arhitectura orientată pe evenimente.<sup>[\[37\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-AzureEvent-37)</sup>

<!-- -->

- **TOGAF (The Open Group Architecture Framework)**. Unul dintre cele mai răspândite framework-uri de arhitectură corporativă; include metoda ADM (Architecture Development Method) și artefacte de management al arhitecturii (repository, cataloage/matrice, principii). În TOGAF managementul cerințelor este un proces transversal, integrat în toate fazele ADM.<sup>[\[36\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-TOGAFIntro-36)</sup> Pentru suportul cerințelor și trasabilității se utilizează cataloage și matrice (de ex., cerințe ↔ servicii, funcții ↔ componente), iar ***Architecture Building Blocks*** și ***Solution Building Blocks*** sunt distinse.<sup>[\[38\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-38)[\[39\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-39)</sup> Principiile și standardele întreprinderii sunt fixate în cataloagele corespunzătoare și reprezintă **cerințe** nefuncționale externe pentru echipele de proiect.<sup>[\[40\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-40)</sup> Conformitatea soluțiilor cu arhitectura țintă este confirmată prin procedura de conformitate arhitecturală (Architecture Compliance Review).<sup>[\[41\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-41)</sup> Abordarea TOGAF presupune o **Architecture Vision** preliminară și o detaliere ulterioară (date/aplicații/tehnologii) cu un plan de migrare și managementul schimbărilor cerințelor.<sup>[\[42\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-42)[\[43\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-43)</sup>

<!-- -->

- **Zachman Framework**. O ontologie timpurie și influentă a artefactelor arhitecturii întreprinderii, reprezentată ca o matrice 6×6 (perspective × aspecte „ce/cum/unde/cine/când/de ce"). Rândul „designer" corespunde analizei și proiectării sistemice; coloanele definesc completitudinea examinării datelor, funcțiilor/proceselor, rolurilor, locației și motivației. Framework-ul servește drept clasificare (nu metodologie) și ajută la asigurarea completitudinii descrierii soluției în peisajul întreprinderii.<sup>[\[44\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-Zachman1987-44)</sup>

<!-- -->

- **Legătura cu arhitectura întreprinderii (Enterprise Architecture, EA)**. Analistul de sistem lucrează în contextul EA: noile cerințe sunt trasate la capacitățile de afaceri și modelul operațional; se aplică standardele și constrângerile de principiu ale întreprinderii (securitate, compatibilitate etc.).<sup>[\[45\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-45)[\[36\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-TOGAFIntro-36)</sup> În etapa de inițiere se formează ***Architecture Vision*** (obiective/constrângeri, cerințe agregate), ulterior analistul detaliază, menținând trasabilitatea față de viziune și standardele corporative; nerespectarea standardelor este identificată în revizuirile arhitecturale și poate conduce la revizuiri ale soluției.<sup>[\[36\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-TOGAFIntro-36)[\[46\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-46)</sup>

În concluzie: analiza sistemică și proiectarea arhitecturală formează cuplul „cerințe → decizii arhitecturale → compromisuri pe atribute de calitate". Alegerea metodelor (stiluri/șabloane, artefacte TOGAF, clasificarea Zachman) este determinată de natura proiectului și de cadrul arhitecturii corporative.

## Procese și practici

Analiza sistemică se integrează în întregul ciclu de viață al dezvoltării și exploatării software, conectând obiectivele de afaceri, arhitectura și livrarea. Include cercetarea pre-proiect, alegerea abordării, formarea artefactelor verificabile și cerințele privind fiabilitatea, performanța, securitatea și mentenanța. În modelul cascadă, analiza se realizează înaintea proiectării și implementării, în metodele flexibile — continuu prin iterații, iar în DevOps — cu accent pe obiectivele operaționale. Indiferent de abordare, analiza asigură trasabilitatea, managementul schimbărilor și riscurilor, documentarea compromisurilor arhitecturale și respectarea constrângerilor normative, făcând dezvoltarea predictibilă și gestionabilă.

- **SDLC clasic (Waterfall)**. Etapa System Analysis & Requirements Definition precede proiectarea și implementarea; cerințele sunt fixate într-o **SRS** detaliată ca bază de planificare și contracte. Eficient în domenii stabile și reglementate; riscurile „înghețării" cerințelor sunt reduse prin SRR/revizuiri și managementul schimbărilor prin **CCB**.<sup>[\[47\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-Royce-47)[\[48\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-DAU_SRR-48)[\[49\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NASA_CCB-49)</sup>

<!-- -->

- **Metodologii flexibile (Agile)**. Analiza este continuă: în loc de SRS finală se menține un backlog de produs cu user stories și criterii de acceptare, rafinat în backlog refinement; se aplică **BDD** (Given–When–Then); riscul pierderii arhitecturii integrale este compensat prin elaborarea arhitecturală timpurie și trasabilitatea transparentă a cerințelor ↔ implementare/teste.<sup>[\[50\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-MS_Agile-50)[\[51\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-MS_BDD-51)[\[52\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-MS_Trace-52)</sup>

<!-- -->

- **DevOps și SRE**. Lansările frecvente necesită cerințe operaționale „implicite": automatizare, observabilitate, rollback. Cerințele nefuncționale sunt formulate ca SLO/SLI, se gestionează error budget; în backlog se adaugă sarcini pentru jurnalizare/metrici/trace-uri/alerte; pentru lansare fără întreruperi — pattern-uri **blue/green** etc.<sup>[\[53\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SRE_SLO-53)[\[54\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-AzureMon-54)[\[55\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-AWS_BlueGreen-55)</sup>

<!-- -->

- **Managementul cerințelor și riscurilor**. Cerințele din ALM au statusuri și legături cu sarcini/lansări/defecte; sunt obligatorii version control, change impact analysis și re-prioritizarea periodică.<sup>[\[56\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-Azure_Workflow-56)[\[57\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-Azure_Backlog-57)</sup>

<!-- -->

- **Asigurarea calității (QA)**. Calitatea se pune în etapa cerințelor: revizuiri, „Three Amigos", plan *Acceptance Test Plan*, teste automate ale criteriilor de acceptare (BDD/ATDD).<sup>[\[58\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-MS_Test-58)[\[59\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-MS_SpecFlow-59)</sup>

<!-- -->

- **Observabilitate și fiabilitate**. Cerințele includ SLA/SLO, MTTR și MTBF cu obiective măsurabile și metode de control; parametrii provin de la afaceri/exploatare și sunt încorporați în arhitectură și teste de fiabilitate.<sup>[\[60\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-IBM_MTTR-60)[\[61\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-GCloud_Obs-61)</sup>

## Metrici și calitatea artefactelor

Pentru evaluarea activității analistului de sistem și a calității rezultatelor sale se aplică criterii general acceptate. **Cerințele și modelele de calitate** — baza unui proiect de succes, de aceea sunt gestionate pe tot ciclul de viață (elicitation → specification → verification/validation → change management). Atributele de bază ale calității cerințelor sunt fixate în standardele ISO/IEC/IEEE 29148 și (istoric) IEEE 830.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)[\[62\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-IEEE830-62)[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)</sup>

- **Corectitudinea (Correctness)** — cerința reflectă necesitatea autentică și este convenită cu experții domeniului; se confirmă prin validare (review/inspection, prototipuri, scenarii).<sup>[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)[\[4\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NASA7123-4)</sup>

<!-- -->

- **Completitudinea (Completeness)** — sunt luate în considerare aspectele și condițiile esențiale.
  - *Completitudinea cerinței individuale*: sunt indicate detaliile necesare (de ex., „indicatorul trece în starea **roșu la defecțiune**", nu doar „devine roșu").
  - *Completitudinea specificației*: sunt acoperite scenariile/rolurile, sunt definite NFR; se atinge prin liste de verificare și trasabilitate la obiectivele de afaceri; un audit independent al completitudinii (QA/review) este util.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Univocitatea (Unambiguity)** — formulările sunt interpretate într-un singur mod; ajută glosarul, șabloanele de tipul „sistemul **trebuie să facă A, când B, dacă C**", exemplele; diagramele sunt însoțite de legendă. Verificare — principiul **„celor patru ochi"**.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Consecvența (Consistency)** — cerințele nu se contrazic reciproc și nu contrazic constrângerile externe; se aplică structurarea, tabelele rezumative ale atributelor, revizuirile de echipă; se verifică reglementările/standardele.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Verificabilitatea/testabilitatea (Verifiability)** — atingerea este confirmată prin test/demonstrație/analiză; formulările neverificabile sunt înlocuite cu criterii măsurabile; pentru NFR se definesc metrici și criterii de acceptare fixate în prealabil.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Modificabilitatea și trasabilitatea (Modifiability & Traceability)** — ID-uri unice, structură logică („un singur gând — un singur paragraf"), absența duplicatelor; sunt menținute legăturile „cerință ↔ sursă/țintă/design/test", se menține o matrice de **trasabilitate (RTM)**.<sup>[\[64\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NASA_RM-64)[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Ierarhizarea și prioritizarea** — calitatea setului de cerințe; se utilizează tehnicile **MoSCoW** și MCDM (de ex., **AHP**); prioritizarea împreună cu afacerea influențează planificarea și riscurile.<sup>[\[65\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-MoSCoW-65)[\[66\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-Saaty-66)</sup>

**Metrici ale calității cerințelor** (exemple):<sup>[\[63\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NASA_SEH-63)[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)</sup>

- densitatea defectelor cerințelor (observații la 100 de cerințe);
- numărul de modificări după fixarea de bază;
- metrici de acoperire: ponderea cerințelor cu teste; ponderea cerințelor trasate la obiectivele de afaceri;
- stabilitatea cerințelor (raportul cerințelor adăugate/eliminate față de numărul total pe perioadă);
- dimensiunea/complexitatea specificației (numărul mediu de cerințe în use case, adâncimea descompunerii);
- satisfacția stakeholderilor (sondaj).

În procesele mature (de ex., **CMMI** nivel 3+) există reglementări de calitate a cerințelor: verificări formale, audituri de conformitate cu șabloanele, colectarea/analiza metricilor.<sup>[\[67\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SEI_CMMI-67)</sup> În domeniile critice (avionică, spațiu etc.) se aplică **metode formale** pentru creșterea fiabilității.<sup>[\[68\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NASA_FM-68)</sup>

## Erori tipice

În proiectele IT se întâlnesc frecvent erori de analiză sistemică: incompletitudinea și ambiguitatea cerințelor, contradicțiile, granițele neclare, ignorarea aspectelor nefuncționale, integrarea omisă și securitatea tardivă. Acestea conduc la reluări de lucru, întârzieri, creșterea costurilor și defecte.

Probleme tipice, consecințele lor și modalitățile de prevenire.

- **Incompletitudinea și cerințele omise**. Se omit roluri cu drepturi speciale, cazuri limită și NFR. *Consecințe:* revizuiri ale arhitecturii și amânarea lansării. Cum se evită: liste de verificare, sesiuni de brainstorming „ce dacă…", implicarea timpurie a testerilor, trasabilitatea la obiectivele de afaceri.<sup>[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)[\[69\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **Formulări neclare, ambigue**. *Consecințe:* dezvoltatorii implementează „altceva", clientul este nemulțumit. Cum se evită: criterii măsurabile, glosar, șabloane „A, când B, dacă C", peer‑review.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)[\[69\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **Cerințe contradictorii**. *Consecințe:* întârzieri pentru clarificări, reluări la integrare. Cum se evită: structurare, verificarea regulilor de afaceri/reglementărilor, sesiuni de rezolvare a conflictelor, verificarea coerenței la revizuiri.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Sindromul „plăcuței de aur" (gold‑plating)**. *Consecințe:* creșterea volumului, complicarea, noi puncte de eșec. Cum se evită: legarea fiecărei cerințe de un obiectiv/metrică; în Agile — să nu se includă nimic suplimentar în backlog; fixarea scope-ului; vezi YAGNI.

<!-- -->

- **Detaliere excesivă acolo unde nu este necesară.** Cum se evită: separarea *ce/de ce* (cerințe) de *cum* (design/implementare); aplicarea *design‑free requirements* acolo unde este potrivit.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Încălcarea gestionabilității cerințelor**. *Consecințe:* confuzie de versiuni, implementarea „a altceva". Cum se evită: sursă unică de adevăr în ALM, istoricizare și statusuri, RTM și change impact analysis; managementul schimbărilor prin CCB.<sup>[\[64\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NASA_RM-64)[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Absența participării utilizatorilor**. Cum se evită: interviuri, observație, prototipuri, demonstrații periodice; validare explicită cu stakeholderii.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **„Paralizia analitică" prea îndelungată**. Cum se evită: zona de suficiență, iterativitate și timeboxing; lansarea MVP/incrementelor și corectarea pe baza feedback-ului.<sup>[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Ignorarea cerințelor nefuncționale**. Cum se evită: evidențierea NFR (de ex., FURPS+), definirea criteriilor măsurabile, includerea lor în planul de testare și deciziile arhitecturale.<sup>[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Erori de comunicare și „factorul uman"**. Cum se rezolvă: dezvoltarea intervievării și facilitării, menținerea neutralității, documentarea deciziilor și surselor cerințelor (trasabilitate la obiective).<sup>[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)</sup>

Majoritatea problemelor se reduc la calitatea formulărilor, completitudinea și gestionabilitatea cerințelor; aplicarea standardelor ISO/IEC/IEEE 29148 și a practicilor SWEBOK (validabilitate, trasabilitate, iterativitate) reduce semnificativ riscul depășirii termenelor și al reluărilor de lucru.<sup>[\[3\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-SWEBOK-1)</sup>

## Limitări

În ciuda eficacității sale în reducerea incertitudinii, analiza sistemică are propriile limitări:

- **Realitatea este schimbătoare și complexă.** Este imposibil să ții cont de toți factorii, mai ales în proiectele pe termen lung. Unele cerințe vor apărea inevitabil abia după lansarea sistemului. Este important să se urmărească minimizarea surprizelor, dar trebuie să fii pregătit pentru schimbări.
- **Cerințele depind de oameni.** Prioritățile de afaceri, legile și piața se pot schimba. Analiza sistemică fixează starea curentă și nu poate prezice toate schimbările externe. Pentru a se adapta, este necesară actualizarea periodică a cerințelor și lucrul iterativ.
- **Utilizatorii nu știu întotdeauna ce vor până nu văd.** Aceasta este o limitare binecunoscută. Prototiparea și metodologiile flexibile, precum Agile, ajută la depășirea acestei probleme. Analiza pe hârtie are limitele sale, iar pentru obținerea de date precise este necesară feedback-ul din implementări.
- **Echilibrul dintre timp și calitate.** O analiză excesiv de detaliată poate deveni depășită. În domeniile inovatoare este mai bine să creezi rapid un produs minim viabil (MVP) și să obții date reale. Analiza sistemică este eficientă în domenii stabile, dar în proiectele de cercetare (R&D) rolul său este limitat.
- **Factorul uman.** Chiar și cele mai bune metodologii nu compensează incompetența analistului sau indisponibilitatea clientului. Este important ca toți participanții la proces să fie implicați și motivați.

## Impactul tehnologiilor moderne asupra analizei sistemice în IT

Analiza sistemică în IT evoluează constant sub influența inovațiilor tehnologice. Analistul secolului XXI lucrează în condițiile creșterii explozive a datelor, implementării generalizate a AI, ciclului rapid de dezvoltare și atenției sporite față de securitate. Practica de succes a analizei sistemice necesită asimilarea de noi cunoștințe (Data Science, securitate cibernetică, tehnologii cloud) și flexibilitate în aplicarea metodelor.

- **Date și AI/ML: ce se adaugă în analiză**. Pentru sistemele cu AI, încă de la început se fixează obiectivele și contextul de aplicare, cerințele față de sursele și calitatea datelor, precum și metricile de încredere în deciziile modelului (fiabilitate, securitate, explicabilitate, confidențialitate, echitate). Se planifică verificările **TEVV** (testing, evaluation, verification, validation), monitorizarea în exploatare și dezactivarea/retragerea în siguranță a modelului. Acești pași corespund funcțiilor **GOVERN–MAP–MEASURE–MANAGE** din cadrul NIST de management al riscurilor AI; ele se reflectă în SRS, arhitectură și planurile de verificare/exploatare.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NIST_AI_RMF-70)</sup>

<!-- -->

- **DevSecOps: securitate „la stânga" și implicit**. Integrarea securității în fiecare etapă a **CI/CD** devine normă: verificări automate (SAST/DAST), scanarea dependențelor și containerelor, politici de deployment, observabilitate de bază. Se utilizează registre de artefacte de încredere și imagini standardizate „hardened"; se aplică principiile zero trust. În analiza sistemică sunt descrise în prealabil **punctele de control ale pipeline-ului** (condițiile de trecere a etapelor), legătura cerințelor cu controalele de securitate și regulile de tranziție între medii (dev/test/stage/prod).<sup>[\[71\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-DoD_DevSecOps-71)</sup>

<!-- -->

- **Ce se schimbă în documente (artefacte)**. Ce secțiune apare sau se precizează în documentele cheie în prezența Big Data și AI/ML și la lucrul conform DevSecOps:
  - **SRS / Specificația cerințelor**: obiectivele și contextul de aplicare AI; cerințele față de date (origine, calitate, constrângeri etice și juridice); metricile modelului (precizie, fiabilitate, timp de răspuns); planul TEVV (testing, evaluation, verification, validation); cerințe privind transparența/explicabilitatea și confidențialitatea; criterii de dezactivare/retragere a modelului din exploatare.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Arhitectura și deciziile (Architecture, ADR)**: rezultatele modelării amenințărilor; măsuri de „securitate implicit" (criptare, control acces, secret‑management, principiul privilegiului minim); constrângeri privind utilizarea datelor/modelelor; înregistrări ADR cu evaluarea riscurilor și compromisurilor.<sup>[\[71\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Planul de verificare și validare (V&V / TEVV)**: scenarii de testare a modelelor și datelor; praguri de acceptare pentru metricile de calitate; monitorizarea driftului datelor/modelului; proceduri de reevaluare periodică și revalidare.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Politicile CI/CD și „porțile" pipeline-ului**: verificări automate SAST/DAST, SCA (dependențe), scanarea containerelor; semnarea și stocarea artefactelor în registre de încredere; reguli de promovare între medii (dev/test/stage/prod) și condiții de blocare a build-ului la eșecul verificărilor; cerințe de observabilitate implicite.<sup>[\[71\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **Planul de management al datelor și modelelor**: catalogul surselor și lineage; criterii de calitate și disponibilitate a datelor; versiuni de dataset-uri/modele; programul de (re)antrenare și controlul bias; politica de acces și stocare; planul de dezactivare în siguranță a modelului și ștergerea datelor, dacă este necesar.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Exploatare și observabilitate (Ops/Runbook)**: metrici de încredere AI și SLO; audit și jurnalizare; alerte pentru degradare/anomalii; plan de răspuns la incidente; fallback/kill‑switch pentru componentele AI; cerințe de raportare și analiză post-incident.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **Trasabilitate** (end‑to‑end): legături explicite „**cerință ↔ control/verificare în pipeline**\\ și „**cerință ↔ test/monitorizare în exploatare**", pentru a putea verifica în mod demonstrabil securitatea și calitatea pe tot ciclul de viață.<sup>[\[71\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NIST_AI_RMF-70)</sup>
- **Rolul analistului de sistem**.
  - gestionează contextul și riscurile AI (actori, scenarii de aplicare, ipoteze și constrângeri ale datelor);
  - asigură trasabilitatea „**cerință ↔ control de securitate în pipeline**";
  - formulează cerințe nefuncționale verificabile (securitate, transparență, observabilitate) pe tot ciclul de viață al sistemului.<sup>[\[70\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-DoD_DevSecOps-71)</sup>

## Diferențe față de analiza sistemică clasică

Termenul „analiză sistemică" este istoric mai larg decât dezvoltarea software. Analiza sistemică clasică este o abordare pentru rezolvarea problemelor complexe interdisciplinare (sociale, economice, manageriale), bazată pe gândirea sistemică și metode cantitative, de obicei pentru sprijinirea deciziilor manageriale. În IT, prin analiză sistemică se înțelege o disciplină aplicată în domeniul ingineriei software, orientată spre crearea de sisteme informaționale.

Mai jos — diferențele cheie.

- **Obiective și obiectul analizei**. Analiza clasică rezolvă probleme slab structurate, „difuze" și îmbunătățește sistemele sociotehnice existente (rețeaua de transport urban, strategia companiei, politica de mediu). Obiectul — sistemul real; sarcina — ajutarea factorului de decizie să aleagă un curs de acțiune. Pentru analiza sistemică în IT, scopul este proiectarea și crearea unui nou sistem informațional sau produs software care să îndeplinească cerințele. Obiectul — sistemul proiectat; focusul — comportamentul și caracteristicile necesare utilizatorilor.

<!-- -->

- **Bazele metodologice**. Școlile clasice se bazează pe gândirea sistemică și adesea pe matematică. Abordarea rigidă (hard systems) — formalizarea problemei, criterii cantitative, optimizare (ca în *operations research*). Metodologiile flexibile (soft systems) recunosc multiplicitatea punctelor de vedere; un exemplu — *Soft Systems Methodology (SSM)*, unde prin discuții și modele conceptuale se aliniază schimbările dorite. În IT baza o constituie disciplinele inginerești: ingineria cerințelor, proiectarea software, framework-uri arhitecturale. Se aplică procese standardizate (ISO/IEC/IEEE 15288, 12207, 29148), notații UML/SysML și practici de management al schimbărilor.

<!-- -->

- **Roluri și artefacte**. În analiza clasică, rolul „analistului de sistem" este adesea informal; rezultatele sunt raportul analitic, recomandările, modelele matematice, scenariile „ce dacă". În IT rolul analistului (sau al business analistului) este formalizat; se produc specificații de cerințe, modele ale sistemului (UML, ER), specificații de interfețe, user stories și backlog — artefacte utilizate direct de dezvoltatori și testeri.

<!-- -->

- **Ciclul de viață și procesul**. Analiza clasică nu are un șablon unic: pașii depind de problemă (în SSM — de la studierea situației până la implementarea schimbărilor). În IT există cicluri SDLC standard: în modelul cascadă există o fază separată de analiză a cerințelor; în abordările iterative și flexibile, analiza este o activitate continuă a fiecărui sprint. Practicile moderne (DevOps, CI/CD) extind cadrul analizei la exploatare: sunt luate în considerare cerințele privind mentenanța, observabilitatea și actualizabilitatea. Cu alte cuvinte, analiza sistemică în IT este integrată în ciclul de viață al dezvoltării, în timp ce analiza clasică este mai frecvent realizată ca activitate de proiect/consultanță.

## Analistul de sistem

**Analistul de sistem în IT** — specialist responsabil pentru gândirea sistemică în proiectarea și dezvoltarea sistemelor informaționale: formarea și validarea cerințelor, modelarea (UML/BPMN), alinierea deciziilor arhitecturale și asigurarea integrării. Rolul și cerințele de calificare în Federația Rusă sunt fixate în standardul profesional și FGOS.

**Obiectivul principal al tipului de activitate profesională:** Asigurarea conformității serviciului IT, a sistemului automatizat, a sistemului informațional automatizat, a sistemului de management automatizat, a produsului sau mijlocului software, informațional (în continuare - Sistemul) cu mediul înconjurător, cerințele și constrângerile inițiale, obiectivele de automatizare și activitățile automatizate, prin elaborarea și transmiterea de decizii de proiect de calitate și intercorelate către părțile interesate, la lansarea și coordonarea lucrărilor executanților individuali pe tot ciclul de viață al Sistemului (*Standardul profesional „Analist de sistem" (ordinul Ministerului Muncii al Federației Ruse din 27.04.2023 nr. 367n*).<sup>[\[72\]](https://systems-analysis.info/int/Analiza_sistemic%C4%83_%C3%AEn_IT#cite_note-72)</sup>

## Glosar de termeni cheie

### Concepte de bază și participanți

- Analiza sistemică în IT — disciplină al cărei obiect este sistemul informațional pe tot ciclul său de viață, de la concept până la exploatare.
- Stakeholderi — persoane sau grupuri interesate de proiect sau afectate de acesta (clienți, utilizatori, manageri).
- Artefacte de proiect — documente și rezultate create în cursul proiectului, precum specificații, modele, planuri și decizii.

### Cerințe: tipuri și documentație

- Cerințe funcționale — descriu ce trebuie să facă sistemul; funcțiile și comportamentul acestuia.
- Cerințe nefuncționale — descriu atributele de calitate ale sistemului (fiabilitate, performanță, securitate, ușurință de utilizare, scalabilitate etc.).
- Specificație a cerințelor (primară) — document conținând setul inițial de cerințe colectate în etapele timpurii ale proiectului.
- SRS (Software Requirements Specification) — document standardizat care descrie în detaliu cerințele față de software conform standardelor internaționale (de ex., ISO/IEC/IEEE 29148).
- URS (User Requirements Specification) — document care descrie cerințele utilizatorului față de sistem din perspectiva proceselor de afaceri și așteptărilor utilizatorului final.

<!-- -->

- Cerințe semnificative arhitectural (ASR) — cerințe care influențează semnificativ deciziile și compromisurile arhitecturale.
- Cerințe cross-funcționale (CFR) — sinonim al cerințelor nefuncționale, subliniind caracterul lor transversal.
- Criterii de acceptare (Acceptance Criteria) — condiții verificabile la îndeplinirea cărora lucrul privind cerința este considerat acceptat.
- Definition of Ready (DoR) — acord privind pregătirea unui element de backlog pentru dezvoltare (claritate, estimare, criterii).
- Definition of Done (DoD) — acord privind „finalizarea" lucrului (cod, teste, documentație, deployment).
- Constrângere (Constraint) — condiție rigidă care limitează soluțiile (termene, platforme, standarde, licențe).
- Ipoteză (Assumption) — presupunere acceptată fără demonstrație, care necesită validare ulterioară.
- Calitatea cerințelor — proprietăți conform ISO 29148: univocitate, completitudine, necontradictorietate, verificabilitate, atomicitate.

### Formalizarea, trasabilitatea și prioritizarea cerințelor

- Formalizarea cerințelor — procesul de transformare a solicitărilor informale în cerințe clare, verificabile și univoce.
- Trasabilitatea cerințelor — posibilitatea de a urmări ciclul de viață al cerinței de la sursă până la implementare, testare și deployment.
- Bidirectional traceability (trasabilitate bidirecțională) — capacitatea de a urmări legăturile dintre cerințe, elementele de design și scenariile de test atât în direcție directă, cât și inversă.
- MoSCoW — tehnică de prioritizare a cerințelor, clasificându-le ca Must-have (trebuie să existe), Should-have (ar trebui să existe), Could-have (ar putea exista) și Won't-have (nu va exista).
- BDD (Behavior-Driven Development) — metodologie de dezvoltare în care testele sunt scrise în limbaj natural, orientat pe comportamentul sistemului din perspectiva utilizatorului (format Given–When–Then).

### Notații și modelare

- UML (Unified Modeling Language) — limbaj standardizat de modelare grafică pentru specificarea, vizualizarea, construirea și documentarea componentelor sistemelor software.
- SysML (Systems Modeling Language) — extensie a UML pentru ingineria sistemelor, suportând modelarea diferitelor aspecte ale sistemelor complexe, inclusiv cerințe, comportament, structură și parametri.
- BPMN (Business Process Model and Notation) — standard de notație grafică pentru descrierea proceselor de afaceri, permițând vizualizarea fluxurilor de lucru, evenimentelor, gateway-urilor și pool-urilor.
- MBSE (Model-Based Systems Engineering) — abordare în ingineria sistemelor unde modelul este artefactul central pe toate etapele ciclului de viață al sistemului, de la cerințe la testare.
- ArchiMate — notație de arhitectură corporativă (afaceri, aplicații, tehnologii) și relațiile dintre ele.
- DMN (Decision Model and Notation) — modelarea deciziilor de afaceri și a tabelelor de reguli.
- DFD (Data Flow Diagram) — diagrame ale fluxurilor de date (context, niveluri de descompunere).
- ERD (Entity-Relationship Diagram) — model al domeniului de aplicare cu entități, relații și atribute.
- Matrice CRUD — corespondența operațiilor Create/Read/Update/Delete cu entitățile și rolurile/funcțiile.

### Stiluri arhitecturale și evaluarea soluțiilor

- Arhitectura monolitică — abordare arhitecturală în care întregul sistem este dezvoltat ca un modul unic, indivizibil.
- Arhitectura de microservicii — abordare arhitecturală în care sistemul este construit ca un set de servicii mici, independente din punct de vedere al deployment-ului și scalabile.
- Trade-off (compromis) — alegere între caracteristici sau soluții mutual exclusive sau contradictorii, unde îmbunătățirea unei caracteristici se face pe seama deteriorării alteia.
- ATAM (Architecture Tradeoff Analysis Method) — metodă de evaluare a arhitecturii software, utilizată pentru analiza compromisurilor între atributele de calitate (de ex., performanță, scalabilitate).

### Arhitectura întreprinderii și framework-uri

- TOGAF (The Open Group Architecture Framework) — unul dintre cele mai răspândite framework-uri de arhitectură corporativă, incluzând metoda ADM (Architecture Development Method) pentru dezvoltarea și managementul arhitecturii.
- Zachman Framework — ontologie a artefactelor arhitecturii întreprinderii, reprezentată ca o matrice 6×6, clasificând diferite aspecte ale arhitecturii din perspective diferite.

### Abordări de analiză și procese de dezvoltare

- Abordarea rigidă (Hard Systems) — metodologie de analiză sistemică care presupune obiective și cerințe formalizabile în prealabil, descompunere și proiectare „de sus în jos", eficientă pentru sarcini bine definite.
- Abordarea flexibilă (Soft Systems) — metodologie de analiză sistemică aplicată la obiective neclare și puncte de vedere multiple ale stakeholderilor, orientată spre alinierea înțelegerii problemei și a schimbărilor dorite.
- SSM (Soft Systems Methodology) — metodologie specifică a abordării sistemice flexibile, dezvoltată de Peter Checkland, utilizând instrumente precum rich picture, definiții de bază și CATWOE.
- Waterfall (modelul cascadă) — metodologie clasică de dezvoltare software, unde etapele (analiză, proiectare, implementare, testare, implementare) se execută secvențial, cu finalizarea completă a etapei anterioare înainte de începerea celei următoare.
- Agile — grup de metodologii flexibile de dezvoltare software, orientate spre dezvoltare iterativă, adaptare la schimbări, interacțiune cu clientul și livrare continuă de valoare.

### Metode de alegere și erori tipice

- AHP (Analytic Hierarchy Process) — metodă de selecție multicriterială, permițând structurarea problemelor complexe și evaluarea alternativelor pe baza unei ierarhii de criterii.
- Gold-plating (sindromul „plăcuței de aur") — eroare în analiza sistemică, constând în adăugarea de funcționalitate care nu este cerută de stakeholderi, conducând la creșterea volumului și complexității proiectului.

## Referințe

- 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 sistemică pe înțelesul tuturor. YouTube
- Analiza sistemică în IT pe înțelesul tuturor. YouTube

## Bibliografie

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

## Note

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