---
title: "Системен анализ в IT"
source: "https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT"
wiki: "systems-analysis.info/int"
article: "Системен_анализ_в_IT"
language: "bg"
categories:
  - "Category:Bulgarian"
  - "Category:Systems analysis"
revision_id: 8765
wiki_created_at: 2026-09-07T01:22:19Z
wiki_modified_at: 2026-09-07T01:22:19Z
downloaded_at: 2026-09-07T23:27:13Z
---

# Системен анализ в IT

**Системен анализ в IT** (*Systems Analysis and Design*) — подход към проектирането и развитието на информационни системи от идея до експлоатация, включващ идентифициране на потребности, формализиране на изисквания, моделиране на предметната област и процесите, както и оценка на алтернативи и рискове. С други думи, системният анализ в IT е етап от разработката, при който специалистите изучават задачата, определят какво трябва да прави системата и разработват решения за нейното създаване.

**Класическият системен анализ** обхваща широк спектър от приложни области*,* не само разработка на софтуер, но и организационни промени, стратегии и други аспекти.<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>

## Предмет и задачи на системния анализ в IT

**Предмет** **на системния анализ в IT** е информационната система (софтуерен продукт и/или услуга) в целия си жизнен цикъл — от замисъла и обосновката до реализацията и експлоатацията.

**Задачата на системния анализ** — да трансформира бизнес-потребностите в съгласуван и проверяем набор от изисквания и архитектурни решения: да идентифицира и документира целите и ограниченията на заинтересованите страни, да формализира изисквания, да моделира предметната област и процесите, да оцени осъществимостта и рисковете на алтернативите и да обоснове избраната архитектура. В резултат се създават съгласувани документи и се установяват проследими връзки между изисквания, проектни решения и тестове. Това осигурява управляемост и контрол върху процеса на разработка.

Задачите на системния анализ включват:

- **Идентифициране на потребностите и целите на заинтересованите страни**. Аналитикът събира и уточнява очакванията на възложителите, потребителите и другите заинтересовани страни; използват се интервюта, анкети, наблюдение и анализ на текущите процеси. На изхода се формира първична **спецификация на изискванията** с разделение на функционални („какво трябва да прави системата") и нефункционални (надеждност, производителност, сигурност и др.).<sup>[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)[\[2\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-Zowghi-2)</sup>

<!-- -->

- **Формализиране и документиране на изисквания**. Заявките се преобразуват в проверяеми изисквания. Едно добре формулирано изискване трябва да бъде ясно и недвусмислено, пълно, непротиворечиво, проверяемо и проследимо към по-високоравнищни цели; наборът от изисквания — съгласуван и цялостен.<sup>[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)[\[4\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NASA7123-4)</sup> На практика се използват стандартизирани документи: SRS (*Software Requirements Specification*) по ISO/IEC/IEEE 29148, а също в отделни отрасли — URS (*User Requirements Specification*) и функционални спецификации.<sup>[\[5\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-5)[\[6\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-6)[\[7\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-7)</sup>

<!-- -->

- **Анализ и моделиране на системата**. За разбиране на това *как* ще работи системата и ще взаимодейства с външния свят се изграждат модели: диаграми на прецедентите (Use Case) за сценарии на използване, DFD за потоци от данни и бизнес процеси, диаграми на класовете/компонентите и др. Моделите служат като основа за сравняване на алтернативни решения и архитектури.<sup>[\[8\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-8)[\[9\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-9)[\[10\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO42010-10)</sup>

<!-- -->

- **Оценка на осъществимостта и избор на решение**. Провежда се *feasibility study* (техническа, организационна, икономическа, календарна осъществимост) и сравнение на архитектурни алтернативи (*trade-off*). За оценка на качеството на архитектурата по атрибути (напр. производителност, мащабируемост, модифицируемост) се прилагат методи като ATAM (*Architecture Tradeoff Analysis Method*).<sup>[\[11\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-11)[\[12\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ATAM-12)</sup> Изборът между, например, монолитна и микросервисна архитектура <a href="https://aws.amazon.com/ru/compare/the-difference-between-monolithic-and-microservices-architecture/" class="external autonumber" rel="nofollow">[3]</a> се основава на явни компромиси (сложност на експлоатацията vs. независима мащабируемост и скорост на доставка) по препоръки на индустриални насоки.<sup>[\[13\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-13)[\[14\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-14)</sup>

<!-- -->

- **Подготовка на проектни артефакти**. По итогите от анализа се формират:
  - утвърдена спецификация на изисквания (с указване на тяхната важност),
  - концептуален модел на системата (диаграми/описания),
  - архитектурни и проектни решения (схеми на данни, интерфейси на външни системи),
  - план за реализация (етапи/модули).
  - Критично е да се осигури *проследяемост* (bidirectional traceability) на изискванията към елементите на дизайна и тестовете.<sup>[\[15\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-15)[\[4\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NASA7123-4)</sup>

Успехът на IT-проекта в значителна степен зависи от зрелите практики за работа с изисквания и архитектура. Изследване, проведено от McKinsey и Oxford, показа, че мащабните IT-проекти често надхвърлят бюджета и сроковете. Това изследване подчерта и колко е важно правилното управление на стратегията, взаимодействието със заинтересованите страни и компетентното събиране на изисквания. Всичко това може силно да повлияе върху успеха или провала на проекта.<sup>[\[16\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-16)</sup>

## Подходи и методологии в системния анализ на IT

**Системният анализ в IT** се опира на принципите на системното мислене и адаптирани към разработката на ПО методики. На практика се комбинират „твърди" и „меки" подходи, структурни методологии, обектно-ориентирани нотации, а също езици за моделиране на процеси и изисквания.

- **Твърд и мек подход**. В IT-проектите твърдият подход (hard systems) предполага предварително формализируеми цели и изисквания, декомпозиция и проектиране „отгоре надолу". Мекият подход (soft systems) се прилага при неясни цели и множество гледни точки: използват се елементи на Soft Systems Methodology (SSM) (напр. *rich picture*, коренни определения, CATWOE) за съгласуване на разбирането на проблема и желаните промени; след това резултатите се преобразуват в формални изисквания.<sup>[\[17\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-17)[\[18\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-18)</sup>

<!-- -->

- **Методология SSM (Soft Systems Methodology)**. Първоначално разработена от *Питър Чеклънд* за организационни промени, SSM е полезна в предпроектните етапи на IT: от изследване на проблемната ситуация и формулиране на коренни определения (включително чрез CATWOE) до сравняване на концептуални модели с реалността и постигане на акомодация между заинтересованите страни.<sup>[\[19\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-19)[\[20\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-20)</sup>

<!-- -->

- **Структурирани методологии: SADT/IDEF0**. SADT моделира системата като йерархия от функции; стандартната нотация IDEF0 (IEEE 1320.1) фиксира функциите и техните I-C-O-M-интерфейси (Inputs, Controls, Outputs, Mechanisms). Методът е удобен за функционална декомпозиция и съгласуване на границите на системата независимо от алгоритмите.<sup>[\[21\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-21)[\[22\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-22)</sup>

<!-- -->

- **Обектно-ориентиран анализ:** UML и SysML (MBSE). UML се е превърнал в базов език за изисквания и дизайн (диаграми на прецедентите, класовете, последователностите и др.) и улеснява валидацията на сценарии с потребители; SysML разширява UML за системното инженерство (диаграми на изисквания, параметрични диаграми) и се основава на подхода MBSE, при който моделът е централен артефакт през всички етапи от изисквания до тестове.<sup>[\[23\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-23)[\[24\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-24)[\[25\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-25)</sup>

<!-- -->

- **Моделиране на бизнес процеси:** BPMN. Стандартът BPMN се използва за графично описание на процеси (пулове, потоци от работи, събития, шлюзове), включително сравнение *as-is/to-be* в спецификации на изисквания и интеграция.<sup>[\[26\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-26)[\[27\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-27)</sup>

<!-- -->

- **Връзка с инженерията на изисквания**. Процесът включва етапи elicitation–analysis–specification–validation–change management; критериите за „добро изискване" и структурата на SRS са регламентирани от ISO/IEC/IEEE 29148. За приоритизиране се прилагат техники **MoSCoW** (Must/Should/Could/Won't) и методи за многокритериален избор, например AHP. В гъвкавите процеси дейността по системен анализ се отразява в backlog refinement и проследяемостта на изискванията.<sup>[\[28\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-28)[\[29\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-29)[\[30\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-30)[\[31\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-31)</sup>

<!-- -->

- **Връзка със системното инженерство**. За комплексни (киберфизически) системи се прилага V-моделът: в „лявото" разклонение — системен анализ и архитектура, в „дясното" — интеграция, верификация и валидация с обвързване към артефактите на лявото разклонение. Методите за оценка на архитектурата по качествени атрибути включват ATAM (trade-off анализ).<sup>[\[32\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-32)[\[33\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-33)</sup>

Системният анализ в IT съчетава изпитани подходи — от меки методики за съгласуване на визията до формални нотации и стандарти. Изборът на инструменти се определя от степента на определеност на задачата: при висока несигурност ролята на SSM и фасилитацията се усилва, при ясни граници — формалните модели (UML/SysML, IDEF0, BPMN) и регламентите.

## Връзка с IT-архитектурата и архитектурата на предприятието

Системният анализ в IT-проектите е тясно свързан с архитектурното проектиране. Ролите на аналитика и архитекта се припокриват: аналитикът формулира изисквания и логическия модел, архитектът определя целевата структура на решението и техническите компромиси; работата се извършва съвместно.

- **Архитектура на IT-системите**. В тесен смисъл архитектурата на ПО е организацията на компонентите, техните взаимоотношения и принципите, от които се ръководят при проектирането на решението. За аналитика е важно да отчита архитектурните стилове (слоеста, клиент–сервърна, микросервисна, събитийно-ориентирана и др.), тъй като нефункционалните изисквания (надеждност, мащабируемост, модифицируемост) често определят архитектурните решения и техните компромиси.<sup>[\[34\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-AzureStyles-34)[\[35\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SEI_ATAM-35)</sup> На ранния етап на анализа се формира **архитектурна визия** (high-level vision) и се разработва чернова контур на решението за проверка на жизнеспособността на изискванията (дължината на итерациите и детайлизацията зависят от методологията).<sup>[\[36\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-TOGAFIntro-36)</sup>

<!-- -->

- **Шаблони и предварителни решения**. За задоволяване на нефункционални изисквания се прилагат архитектурни шаблони (architectural patterns). Например, за асинхронно взаимодействие и слаба свързаност — publish–subscribe чрез брокер на съобщения в събитийно-ориентирана архитектура.<sup>[\[37\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-AzureEvent-37)</sup>

<!-- -->

- **TOGAF (The Open Group Architecture Framework)**. Един от най-разпространените фреймуърки за корпоративна архитектура; включва метода ADM (Architecture Development Method) и артефакти за управление на архитектурата (хранилище, каталози/матрици, принципи). В TOGAF управлението на изискванията е сквозен процес, интегриран във всички фази на ADM.<sup>[\[36\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-TOGAFIntro-36)</sup> За поддръжка на изисквания и проследяемост се използват каталози и матрици (напр. изисквания ↔ услуги, функции ↔ компоненти), а също се разграничават ***Architecture Building Blocks*** и ***Solution Building Blocks***.<sup>[\[38\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-38)[\[39\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-39)</sup> Принципите и стандартите на предприятието се фиксират в съответните каталози и служат като външни нефункционални **изисквания** за проектните екипи.<sup>[\[40\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-40)</sup> Съответствието на решенията с целевата архитектура се потвърждава с процедурата за архитектурно съответствие (Architecture Compliance Review).<sup>[\[41\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-41)</sup> Подходът TOGAF предполага предварителна **Architecture Vision** и последваща детайлизация (данни/приложения/технологии) с план за миграция и управление на промените в изискванията.<sup>[\[42\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-42)[\[43\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-43)</sup>

<!-- -->

- **Zachman Framework**. Ранна и влиятелна онтология на артефактите на архитектурата на предприятието, представена като матрица 6×6 (перспективи × аспекти „какво/как/къде/кой/кога/защо"). Редът „дизайнер" съответства на системния анализ и проектирането; колоните задават пълнотата на разглеждане на данни, функции/процеси, роли, местоположение и мотивация. Фреймуъркът служи като класификация (а не методология) и помага да се осигури пълнота на описанието на решението в ландшафта на предприятието.<sup>[\[44\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-Zachman1987-44)</sup>

<!-- -->

- **Връзка с архитектурата на предприятието (Enterprise Architecture, EA)**. Системният аналитик работи в контекста на EA: новите изисквания се проследяват до бизнес-възможностите и оперативния модел; прилагат се стандарти и принципни ограничения на предприятието (сигурност, съвместимост и др.).<sup>[\[45\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-45)[\[36\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-TOGAFIntro-36)</sup> На етапа на иницииране се формира ***Architecture Vision*** (цели/ограничения, укрупнени изисквания), след което аналитикът детайлизира, запазвайки проследяемостта към визията и корпоративните стандарти; неизпълнението на стандартите се открива на архитектурните ревюта и може да доведе до доработки на решението.<sup>[\[36\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-TOGAFIntro-36)[\[46\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-46)</sup>

Обобщение: системният анализ и архитектурното проектиране образуват връзката „изисквания → архитектурни решения → компромиси по качествени атрибути". Изборът на методи (стилове/шаблони, артефакти на TOGAF, класификация на Zachman) се определя от характера на проекта и рамката на корпоративната архитектура.

## Процеси и практики

Системният анализ се интегрира в целия жизнен цикъл на разработка и експлоатация на ПО, свързвайки бизнес-целите, архитектурата и доставката. Включва предпроектно изследване, избор на подход, формиране на проверяеми артефакти и изисквания за надеждност, производителност, сигурност и поддръжка. При каскадния модел анализът се извършва преди проектирането и реализацията, при гъвкавите методи — непрекъснато чрез итерации, а при DevOps — с акцент върху оперативните цели. Независимо от подхода, анализът осигурява проследяемост, управление на промените и рисковете, документиране на архитектурните компромиси и спазване на нормативните ограничения, правейки разработката предвидима и управляема.

- **Класически SDLC (Waterfall)**. Етапът System Analysis & Requirements Definition предхожда проектирането и реализацията; изискванията се фиксират в детайлна **SRS** като основа за планиране и договори. Ефективен е в стабилни и регулирани домейни; рисковете от „замразяване" на изисквания се намаляват с SRR/ревюта и управление на промените чрез **CCB**.<sup>[\[47\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-Royce-47)[\[48\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-DAU_SRR-48)[\[49\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NASA_CCB-49)</sup>

<!-- -->

- **Гъвкави методологии (Agile)**. Анализът е непрекъснат: вместо финална SRS се поддържа продуктов бэклог от user stories с критерии за приемане, уточняван на backlog refinement; прилага се **BDD** (Given–When–Then); рискът от загуба на цялостна архитектура се компенсира с ранна архитектурна разработка и прозрачна проследяемост изисквания ↔ реализация/тестове.<sup>[\[50\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-MS_Agile-50)[\[51\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-MS_BDD-51)[\[52\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-MS_Trace-52)</sup>

<!-- -->

- **DevOps и SRE**. Честите релийзи изискват оперативни изисквания „по подразбиране": автоматизация, наблюдаемост, откат. Нефункционалните изисквания се формулират като SLO/SLI, управлява се error budget; в бэклога се добавят задачи за логове/метрики/трейсове/алерти; за пускане без престой — паттерни **blue/green** и др.<sup>[\[53\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SRE_SLO-53)[\[54\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-AzureMon-54)[\[55\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-AWS_BlueGreen-55)</sup>

<!-- -->

- **Управление на изисквания и рискове**. Изискванията в ALM имат статуси и връзки с задачи/релийзи/дефекти; задължителни са version control, change impact analysis и редовна репriоритизация.<sup>[\[56\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-Azure_Workflow-56)[\[57\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-Azure_Backlog-57)</sup>

<!-- -->

- **Осигуряване на качество (QA)**. Качеството се залага на етапа на изискванията: ревюта, „Three Amigos", план *Acceptance Test Plan*, автотестове на критериите за приемане (BDD/ATDD).<sup>[\[58\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-MS_Test-58)[\[59\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-MS_SpecFlow-59)</sup>

<!-- -->

- **Наблюдаемост и надеждност**. В изискванията се включват SLA/SLO, MTTR и MTBF с измерими цели и методи за контрол; параметрите постъпват от бизнеса/експлоатацията и се залагат в архитектурата и тестовете за надеждност.<sup>[\[60\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-IBM_MTTR-60)[\[61\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-GCloud_Obs-61)</sup>

## Метрики и качество на артефактите

За оценка на работата на системния аналитик и качеството на резултатите му се прилагат общоприети критерии. **Качествените изисквания и модели** са основа на успешния проект, затова се управляват в целия жизнен цикъл (elicitation → specification → verification/validation → change management). Базовите атрибути за качество на изисквания са закрепени в стандартите ISO/IEC/IEEE 29148 и (исторически) IEEE 830.<sup>[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)[\[62\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-IEEE830-62)[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

- **Коректност (Correctness)** — изискването отразява истинска потребност и е съгласувано с експерти от предметната област; потвърждава се с валидация (review/inspection, прототипи, сценарии).<sup>[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)[\[4\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NASA7123-4)</sup>

<!-- -->

- **Пълнота (Completeness)** — отчетени са съществените аспекти и условия.
  - *Пълнота на отделното изискване*: посочени са необходимите детайли (напр. „индикаторът преминава в статус **червен при отказ**", а не просто „става червен").
  - *Пълнота на спецификацията*: покрити са сценарии/роли, зададени са NFR; постига се с чек-листи и проследяемост към бизнес-целите; полезен е независим одит на пълнотата (QA/review).<sup>[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Еднозначност (Unambiguity)** — формулировките се тълкуват по единствен начин; помагат глосар, шаблони от вида „системата **трябва да прави A, когато B, ако C**", примери; диаграмите се придружават от легенда. Проверка — принципът **„четири очи"**.<sup>[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Съгласуваност (Consistency)** — изискванията не си противоречат помежду си и на външните ограничения; прилагат се структуриране, сводни таблици с атрибути, екипни ревюта; сверяват се нормативни актове/стандарти.<sup>[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Проверяемост/тестируемост (Verifiability)** — постигането се потвърждава с тест/демонстрация/анализ; непроверяемите формулировки се заменят с измерими критерии; за NFR се задават метрики и критериите за приемане се фиксират предварително.<sup>[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Изменяемост и проследяемост (Modifiability & Traceability)** — уникални идентификатори, логична структура („една мисъл — един абзац"), отсъствие на дубликати; поддържат се връзки „изискване ↔ източник/цел/дизайн/тест", поддържа се матрица **на проследяемостта (RTM)**.<sup>[\[64\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NASA_RM-64)[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Класиране и приоритизиране** — качество на набора от изисквания; използват се техники **MoSCoW** и MCDM (напр. **AHP**); приоритизирането съвместно с бизнеса влияе върху планирането и рисковете.<sup>[\[65\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-MoSCoW-65)[\[66\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-Saaty-66)</sup>

**Метрики за качество на изисквания** (примери):<sup>[\[63\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NASA_SEH-63)[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

- плътност на дефектите в изисквания (забележки на 100 изисквания);
- брой промени след базовото фиксиране;
- coverage-метрики: дял на изискванията с тестове; дял на изискванията, проследими към бизнес-цели;
- стабилност на изискванията (отношение на добавените/изтритите към общия брой за период);
- размер/сложност на спецификацията (средно число изисквания в use case, дълбочина на декомпозицията);
- удовлетвореност на заинтересованите страни (анкета).

В зрели процеси (напр. **CMMI** ниво 3+) действат регламенти за качество на изисквания: формални проверки, одити за съответствие с шаблони, събиране/анализ на метрики.<sup>[\[67\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SEI_CMMI-67)</sup> В критични домейни (авиация, космос и др.) се прилагат **формални методи** за повишаване на надеждността.<sup>[\[68\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NASA_FM-68)</sup>

## Типични грешки

В IT-проектите често се срещат грешки в системния анализ: непълнота и двусмисленост на изисквания, противоречия, размити граници, игнориране на нефункционални аспекти, пропусната интеграция и закъсняла сигурност. Това води до преработки, забавяния, увеличение на разходите и дефекти.

Типични проблеми, техните последствия и начини за предотвратяване.

- **Непълнота и пропуснати изисквания**. Пропускат се роли с особени права, гранични случаи и NFR. *Последствия:* преработки на архитектурата и отлагане на пускането. Как да се избегне: чек-листи, мозъчни щурмове „ами ако…", ранно включване на тестери, проследяемост към бизнес-цели.<sup>[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)[\[69\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **Неясни, двусмислени формулировки**. *Последствия:* разработчиците реализират „грешното", възложителят е недоволен. Как да се избегне: измерими критерии, глосар, шаблони „A, когато B, ако C", peer‑review.<sup>[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)[\[69\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **Противоречиви изисквания**. *Последствия:* забавяния за уточнения, преработки при интеграцията. Как да се избегне: структуриране, сверяване на бизнес‑правила/нормативни актове, сесии за разрешаване на конфликти, проверка на съгласуваността при ревюта.<sup>[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Синдром „златна плоча" (gold‑plating)**. *Последствия:* нарастване на обема, усложняване, нови точки на отказ. Как да се избегне: обвързване на всяко изискване с цел/метрика; в Agile — да не се включва излишното в backlog; фиксиране на scope; вж. YAGNI.

<!-- -->

- **Прекомерна детайлизация там, където не е нужна.** Как да се избегне: отделяне на *какво/защо* (изисквания) от *как* (дизайн/реализация); прилагане на *design‑free requirements* там, където е уместно.<sup>[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Нарушение на управляемостта на изисквания**. *Последствия:* объркване на версии, реализиране на „грешното". Как да се избегне: единен източник на истина в ALM, историзация и статуси, RTM и change impact analysis; управление на промените чрез CCB.<sup>[\[64\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NASA_RM-64)[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Отсъствие на участие на потребителите**. Как да се избегне: интервюта, наблюдение, прототипи, редовни демонстрации; явна валидация със заинтересованите страни.<sup>[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Прекалено дълъг „аналитичен паралич"**. Как да се избегне: зона на достатъчност, итеративност и timeboxing; пускане на MVP/инкременти и корекция по обратна връзка.<sup>[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Игнориране на нефункционалните изисквания**. Как да се избегне: обособяване на NFR (напр. FURPS+), задаване на измерими критерии, включването им в плана за тестване и архитектурните решения.<sup>[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Комуникационни грешки и „човешки фактор"**. Как да се реши: развиване на умения за интервюиране и фасилитация, запазване на неутралност, фиксиране на решения и източници на изисквания (проследяемост към цели).<sup>[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

Повечето проблеми се свеждат до качеството на формулировките, пълнотата и управляемостта на изисквания; прилагането на стандарти ISO/IEC/IEEE 29148 и практики SWEBOK (валидируемост, проследяемост, итеративност) значително намалява риска от срив на сроковете и преработки.<sup>[\[3\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

## Ограничения

Въпреки своята ефективност при намаляване на несигурността, системният анализ има своите ограничения:

- **Реалността е изменчива и сложна.** Невъзможно е да се отчетат всички фактори, особено при дългосрочни проекти. Някои изисквания неизбежно ще се проявят едва след пускането на системата. Важно е да се стремим към минимизиране на изненадите, но трябва да сме готови за промени.
- **Изискванията зависят от хората.** Бизнес-приоритетите, законите и пазарът могат да се променят. Системният анализ фиксира текущото състояние и не може да предвиди всички външни промени. За адаптиране е необходимо редовно актуализиране на изискванията и итеративна работа.
- **Потребителите не винаги знаят какво искат, докато не видят.** Това е известно ограничение. Прототипирането и гъвкавите методологии, като Agile, помагат за преодоляването на този проблем. Анализът на хартия има своите граници и за получаване на точни данни е необходима обратна връзка от реализации.
- **Баланс между време и качество.** Прекалено детайлният анализ може да остарее. В иновативни области е по-добре бързо да се създаде минимален жизнеспособен продукт (MVP) и да се получат реални данни. Системният анализ е ефективен в стабилни области, но в изследователски проекти (R&D) ролята му е ограничена.
- **Човешкият фактор.** Дори и най-добрите методологии не компенсират некомпетентността на аналитика или недостъпността на възложителя. Важно е всички участници в процеса да бъдат ангажирани и мотивирани.

## Влияние на съвременните технологии върху системния анализ в IT

Системният анализ в IT непрекъснато еволюира под въздействието на технологичните иновации. Аналитикът на XXI век работи в условия на взривен ръст на данните, повсеместно внедряване на ИИ, бърз цикъл на разработка и повишено внимание към сигурността. Успешната практика на системния анализ изисква усвояване на нови знания (Data Science, киберсигурност, облачни технологии) и гъвкавост в прилагането на методи.

- **Данни и AI/ML: какво се добавя към анализа**. За системи с ИИ още от самото начало се фиксират целите и контекстът на приложение, изискванията към източниците и качеството на данните, а също метриките на доверие към решенията на модела (надеждност, сигурност, обяснимост, поверителност, справедливост). Планират се проверки **TEVV** (testing, evaluation, verification, validation), мониторинг в експлоатация и безопасно изключване/извеждане на модела. Тези стъпки съответстват на функциите **GOVERN–MAP–MEASURE–MANAGE** от рамката NIST за управление на рисковете на ИИ; те се отразяват в SRS, архитектурата и плановете за верификация/експлоатация.<sup>[\[70\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NIST_AI_RMF-70)</sup>

<!-- -->

- **DevSecOps: сигурност „вляво" и по подразбиране**. Вграждането на сигурността в свеки етап на **CI/CD** се превръща в норма: автоматични проверки (SAST/DAST), сканиране на зависимости и контейнери, политики за разгръщане, базова наблюдаемост. Използват се доверени регистри на артефакти и стандартизирани „закалени" образи; прилагат се принципи на нулево доверие. В системния анализ предварително се описват **контролни точки на конвейера** (условия за преминаване на стадии), връзката на изискванията с контролите за сигурност и правилата за преход между среди (dev/test/stage/prod).<sup>[\[71\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-DoD_DevSecOps-71)</sup>

<!-- -->

- **Какво се променя в документите (артефактите)**. Кой раздел се появява или се уточнява в ключовите документи при наличие на Big Data и AI/ML и при работа по DevSecOps:
  - **SRS / Спецификация на изисквания**: цели и контекст на приложение на ИИ; изисквания към данните (произход, качество, етични и правни ограничения); метрики на модела (точност, надеждност, време за отговор); план TEVV (testing, evaluation, verification, validation); изисквания за прозрачност/обяснимост и поверителност; критерии за изключване/извеждане на модела от експлоатация.<sup>[\[70\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Архитектура и решения (Architecture, ADR)**: резултати от моделиране на заплахи; мерки „сигурност по подразбиране" (криптиране, контрол на достъпа, управление на тайни, принцип на минимални привилегии); ограничения за използване на данни/модели; записи ADR с оценка на рисковете и компромисите.<sup>[\[71\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **План за верификация и валидация (V&V / TEVV)**: сценарии за тестване на модели и данни; прагове за приемане за метрики на качеството; мониторинг на дрейфа на данни/модел; процедури за периодична преоценка и повторна валидация.<sup>[\[70\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Политики CI/CD и „порти" на конвейера**: автоматични проверки SAST/DAST, SCA (зависимости), сканиране на контейнери; подписване и съхранение на артефакти в доверени регистри; правила за продвижение между среди (dev/test/stage/prod) и условия за блокиране на сборката при провал на проверките; изисквания за наблюдаемост по подразбиране.<sup>[\[71\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **План за управление на данни и модели**: каталог на източници и lineage; критерии за качество и наличност на данни; версии на dataset-и/модели; разписание за (до)обучение и контрол на bias; политика за достъп и съхранение; план за безопасна деактивация на модела и изтриване на данни при необходимост.<sup>[\[70\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Експлоатация и наблюдаемост (Ops/Runbook)**: метрики на доверие към ИИ и SLO; одит и журналиране; алерти за деградация/аномалии; план за реагиране при инциденти; fallback/kill‑switch за ИИ‑компоненти; изисквания за отчетност и пост-инцидентен анализ.<sup>[\[70\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **Проследяемост** (end‑to‑end): явни връзки „**изискване ↔ контрол/проверка в конвейера**\\ и „**изискване ↔ тест/мониторинг в експлоатацията**\\, за да може доказуемо да се проверява сигурността и качеството в целия жизнен цикъл.<sup>[\[71\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NIST_AI_RMF-70)</sup>
- **Роля на системния аналитик**.
  - управлява контекста и рисковете на ИИ (актьори, сценарии на приложение, допускания и ограничения на данните);
  - осигурява проследяемост „**изискване ↔ контрол за сигурност в конвейера**";
  - формулира проверяеми нефункционални изисквания (сигурност, прозрачност, наблюдаемост) в целия жизнен цикъл на системата.<sup>[\[70\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-DoD_DevSecOps-71)</sup>

## Отлики от класическия системен анализ

Терминът „системен анализ" исторически е по-широк от разработката на ПО. Класическият системен анализ е подход към решаване на сложни интердисциплинарни задачи (социални, икономически, управленски), основан на системното мислене и количествени методи, обикновено за подкрепа на управленски решения. В IT под системен анализ се разбира приложна дисциплина в областта на инженерията на ПО, ориентирана към създаване на информационни системи.

По-долу — ключовите отлики.

- **Цели и обект на анализа**. Класическият анализ решава слабо структурирани, „размити" проблеми и подобрява вече съществуващи социотехнически системи (градска транспортна мрежа, стратегия на компания, екологична политика). Обектът е реалната система; задачата е да се помогне на вземащия решения да избере курс на действие. За системния анализ в IT целта е да се проектира и създаде нова информационна система или софтуерен продукт, отговарящ на изискванията. Обектът е проектираната система; фокусът е поведението и характеристиките, необходими на потребителите.

<!-- -->

- **Методологически основи**. Класическите школи се опират на системното мислене и често на математиката. Твърдият подход (hard systems) — формализация на проблема, количествени критерии, оптимизация (като в *operations research*). Меките методологии (soft systems) признават множествеността на гледните точки; пример — *Soft Systems Methodology (SSM)*, при която чрез дискусии и концептуални модели се съгласуват желаните промени. В IT основата са инженерните дисциплини: инженерия на изисквания, проектиране на ПО, архитектурни фреймуърки. Прилагат се стандартизирани процеси (ISO/IEC/IEEE 15288, 12207, 29148), нотации UML/SysML и практики за управление на промените.

<!-- -->

- **Роли и артефакти**. В класическия анализ ролята на „системния аналитик" често е неформална; резултатите — аналитичен доклад, препоръки, математически модели, сценарии „ами ако". В IT ролята на аналитика (или бизнес-аналитика) е формализирана; издават се спецификации на изисквания, модели на системата (UML, ER), спецификации на интерфейси, user stories и backlog — артефакти, директно използвани от разработчиците и тестерите.

<!-- -->

- **Жизнен цикъл и процес**. Класическият анализ няма единен шаблон: стъпките зависят от проблема (в SSM — от изследване на ситуацията до внедряване на промени). В IT са приети стандартни цикли SDLC: при каскадния модел има отделна фаза за анализ на изисквания; при итеративните и гъвкавите подходи анализът е постоянна дейност на всеки спринт. Съвременните практики (DevOps, CI/CD) разширяват рамките на анализа към експлоатацията: отчитат се изисквания за поддръжка, наблюдаемост и актуализируемост. С други думи, системният анализ в IT е вграден в жизнения цикъл на разработката, докато класическият по-често се изпълнява като проектна/консултантска дейност.

## Системен аналитик

**Системен аналитик в IT** — специалист, отговорен за системното мислене при проектирането и развитието на информационни системи: формиране и валидация на изисквания, моделиране (UML/BPMN), съгласуване на архитектурни решения и осигуряване на интеграция. Ролята и квалификационните изисквания в РФ са закрепени в професионален стандарт и ФГОС.

**Основна цел на вида професионална дейност:** Осигуряване на съответствие на IT-услугата, автоматизираната система, автоматизираната информационна система, автоматизираната система за управление, програмния, информационния продукт или средство (по-нататък — Системата) на обкръжението, изходните изисквания и ограничения, целите на автоматизацията и автоматизираната дейност чрез разработване и предаване на качествени и взаимосвързани проектни решения на заинтересованите страни при стартиране и координиране на работата на отделни изпълнители в целия жизнен цикъл на Системата (*Професионален стандарт „Системен аналитик" (заповед на Министерство на труда на РФ от 27.04.2023 № 367н*).<sup>[\[72\]](https://systems-analysis.info/int/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5%D0%BD_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D0%B2_IT#cite_note-72)</sup>

## Речник на ключовите термини

### Базови понятия и участници

- Системен анализ в IT — дисциплина, предметът на която е информационната система в целия ѝ жизнен цикъл, от замисъла до експлоатацията.
- Заинтересовани страни (стейкхолдъри) — лица или групи, заинтересовани от проекта или засегнати от него (възложители, потребители, мениджъри).
- Проектни артефакти — документи и резултати, създавани в хода на проекта, като спецификации, модели, планове и решения.

### Изисквания: видове и документация

- Функционални изисквания — описват какво трябва да прави системата; нейните функции и поведение.
- Нефункционални изисквания — описват атрибутите на качеството на системата (надеждност, производителност, сигурност, удобство за ползване, мащабируемост и др.).
- Спецификация на изисквания (първична) — документ, съдържащ изходния набор от изисквания, събрани на началните етапи на проекта.
- SRS (Software Requirements Specification) — стандартизиран документ, подробно описващ изискванията към ПО съгласно международни стандарти (напр. ISO/IEC/IEEE 29148).
- URS (User Requirements Specification) — документ, описващ изискванията на потребителя към системата от гледна точка на бизнес процесите и очакванията на крайния потребител.

<!-- -->

- Архитектурно-значими изисквания (ASR) — изисквания, съществено влияещи върху архитектурните решения и компромисите.
- Кроснофункционални изисквания (CFR) — синоним на нефункционалните изисквания, подчертаващ техния сквозен характер.
- Критерии за приемане (Acceptance Criteria) — проверяеми условия, при изпълнението на които работата по изискването се счита за приета.
- Definition of Ready (DoR) — споразумение за готовността на елемент от backlog за разработка (яснота, оценка, критерии).
- Definition of Done (DoD) — споразумение за „завършеността" на работата (код, тестове, документация, разгръщане).
- Ограничение (Constraint) — твърдо условие, ограничаващо решенията (срокове, платформи, стандарти, лицензи).
- Допускане (Assumption) — предположение, приемано без доказателство, изискващо последваща валидация.
- Качество на изисквания — свойства по ISO 29148: еднозначност, пълнота, непротиворечивост, проверяемост, атомарност.

### Формализация, проследяемост и приоритизиране на изисквания

- Формализация на изисквания — процес на преобразуване на неформални заявки в ясни, проверяеми и еднозначни изисквания.
- Проследяемост на изисквания — възможността да се проследява жизненият цикъл на изискването от неговия източник до реализацията, тестването и разгръщането.
- Bidirectional traceability (двупосочна проследяемост) — способността да се проследяват връзките между изисквания, елементи на дизайна и тестови сценарии в двете посоки.
- MoSCoW — техника за приоритизиране на изисквания, класифицираща ги като Must-have (задължително), Should-have (препоръчително), Could-have (желателно) и Won't-have (няма да бъде).
- BDD (Behavior-Driven Development) — методология за разработка, при която тестовете се пишат на естествен език, ориентиран към поведението на системата от гледна точка на потребителя (формат Given–When–Then).

### Нотации и моделиране

- UML (Unified Modeling Language) — стандартизиран език за графично моделиране за спецификация, визуализация, конструиране и документиране на компоненти на програмни системи.
- SysML (Systems Modeling Language) — разширение на UML за системно инженерство, поддържащо моделиране на различни аспекти на сложни системи, включително изисквания, поведение, структура и параметри.
- BPMN (Business Process Model and Notation) — стандарт за графична нотация за описание на бизнес процеси, позволяващ визуализиране на потоци от работи, събития, шлюзове и пулове.
- MBSE (Model-Based Systems Engineering) — подход към системното инженерство, при който моделът е централен артефакт на всички етапи от жизнения цикъл на системата, от изисквания до тестване.
- ArchiMate — нотация за корпоративна архитектура (бизнес, приложения, технологии) и техните връзки.
- DMN (Decision Model and Notation) — моделиране на бизнес решения и таблици с правила.
- DFD (Data Flow Diagram) — диаграми на потоци от данни (контекст, нива на декомпозиция).
- ERD (Entity-Relationship Diagram) — модел на предметната област със същности, връзки и атрибути.
- CRUD-матрица — съответствие на операциите Create/Read/Update/Delete към същности и роли/функции.

### Архитектурни стилове и оценка на решения

- Монолитна архитектура — архитектурен подход, при който цялата система се разработва като единен, неделим модул.
- Микросервисна архитектура — архитектурен подход, при който системата се изгражда като набор от малки, независимо разгръщани и мащабируеми услуги.
- Trade-off (компромис) — избор между взаимоизключващи се или противоречиви характеристики или решения, при който подобряването на една характеристика се осъществява за сметка на влошаване на друга.
- ATAM (Architecture Tradeoff Analysis Method) — метод за оценка на архитектурата на ПО, използван за анализ на компромисите между качествени атрибути (напр. производителност, мащабируемост).

### Корпоративна архитектура и фреймуърки

- TOGAF (The Open Group Architecture Framework) — един от най-разпространените фреймуърки за корпоративна архитектура, включващ метода ADM (Architecture Development Method) за разработка и управление на архитектурата.
- Zachman Framework — онтология на артефактите на архитектурата на предприятието, представена като матрица 6×6, класифицираща различни аспекти на архитектурата от различни перспективи.

### Подходи към анализа и процесите на разработка

- Твърд подход (Hard Systems) — методология на системния анализ, предполагаща предварително формализируеми цели и изисквания, декомпозиция и проектиране „отгоре надолу", ефективна за ясно дефинирани задачи.
- Мек подход (Soft Systems) — методология на системния анализ, прилагана при неясни цели и множество гледни точки на заинтересованите страни, насочена към съгласуване на разбирането на проблема и желаните промени.
- SSM (Soft Systems Methodology) — конкретна методология на мекия системен подход, разработена от Питър Чеклънд, използваща такива инструменти като rich picture, коренни определения и CATWOE.
- Waterfall (каскаден модел) — класическа методология за разработка на ПО, при която етапите (анализ, проектиране, реализация, тестване, внедряване) се изпълняват последователно, с пълно завършване на предходния етап преди началото на следващия.
- Agile — група от гъвкави методологии за разработка на ПО, ориентирани към итеративна разработка, адаптация към промените, взаимодействие с възложителя и непрекъсната доставка на стойност.

### Методи за избор и типични грешки

- AHP (Analytic Hierarchy Process) — метод за многокритериален избор, позволяващ структуриране на сложни проблеми и оценяване на алтернативи въз основа на йерархия от критерии.
- Gold-plating (синдром „златна плоча") — грешка в системния анализ, изразяваща се в добавяне на функционалност, която не се изисква от заинтересованите страни, което води до нарастване на обема и сложността на проекта.

## Препратки

- 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
- Системен анализ с прости думи. YouTube
- Системен анализ в IT с прости думи. YouTube

## Литература

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

## Бележки

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