---
title: "Системный анализ в IT"
source: "https://systems-analysis.info/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_%D0%B2_IT"
wiki: "systems-analysis.info/wiki"
article: "Системный_анализ_в_IT"
language: "ru"
categories:
  - "Категория:Russian"
  - "Категория:Системный анализ"
  - "Категория:Системный анализ в IT"
revision_id: 394
wiki_created_at: 2026-09-06T22:08:14Z
wiki_modified_at: 2026-09-06T22:08:14Z
downloaded_at: 2026-09-07T22:19:32Z
---

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

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

**[Классический системный анализ](https://systems-analysis.info/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 "Системный анализ")** охватывает широкий спектр областей применения*,* не только разработку программного обеспечения, но и организационные изменения, стратегии и другие аспекты.<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/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_%D0%B2_IT#cite_note-SWEBOK-1)[\[2\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-Zowghi-2)</sup>

<!-- -->

- **Формализация и документирование требований**. Запросы преобразуются в проверяемые требования. Хорошо сформулированное [требование](https://systems-analysis.info/wiki/%D0%A2%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F "Требования") должно быть ясным и недвусмысленным, полным, непротиворечивым, проверяемым и трассируемым к более высокоуровневым целям; набор требований — согласованным и целостным.<sup>[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)[\[4\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NASA7123-4)</sup> В практике используются стандартизованные документы: SRS (*<a href="https://en.wikipedia.org/wiki/Software_requirements_specification" class="extiw" title="wikipedia:Software requirements specification">Software Requirements Specification</a>*) по ISO/IEC/IEEE 29148, а также, в отдельных отраслях, URS (*User Requirements Specification*) и функциональные спецификации.<sup>[\[5\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-5)[\[6\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-6)[\[7\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-7)</sup>

<!-- -->

- **Анализ и моделирование системы**. Для понимания того, *как* система будет работать и взаимодействовать с внешним миром, строятся модели: диаграммы прецедентов (Use Case) для сценариев использования, DFD для потоков данных и бизнес-процессов, диаграммы классов/компонентов и др. Модели служат основой для сопоставления альтернативных решений и архитектур.<sup>[\[8\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-8)[\[9\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-9)[\[10\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO42010-10)</sup>

<!-- -->

- **Оценка осуществимости и выбор решения**. Проводится *<a href="https://en.wikipedia.org/wiki/Feasibility_study" class="extiw" title="wikipedia:Feasibility study">feasibility study</a>* (техническая, организационная, экономическая, календарная осуществимость) и сравнение архитектурных альтернатив (*trade-off*). Для оценки качества архитектуры по атрибутам (напр., производительность, масштабируемость, модифицируемость) применяются методы вроде ATAM (*<a href="https://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_method" class="extiw" title="wikipedia:Architecture tradeoff analysis method">Architecture Tradeoff Analysis Method</a>*).<sup>[\[11\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-11)[\[12\]](https://systems-analysis.info/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_%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/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_%D0%B2_IT#cite_note-13)[\[14\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-14)</sup>

<!-- -->

- **Подготовка проектных артефактов**. По итогам анализа формируются:
  - утверждённая спецификация требований (с указанием их важности),
  - концептуальная [модель системы](https://systems-analysis.info/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B "Модель системы") (диаграммы/описания),
  - архитектурные и проектные решения (схемы данных, интерфейсы внешних систем),
  - план реализации (этапы/модули).
  - Критично обеспечивать *прослеживаемость* (bidirectional traceability) требований к элементам дизайна и тестам.<sup>[\[15\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-15)[\[4\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NASA7123-4)</sup>

Успех IT-проекта в значительной степени зависит от зрелых практик работы с требованиями и архитектурой. Исследование, проведенное McKinsey и Oxford, показало, что крупные IT-проекты часто выходят за рамки бюджета и сроков. Это исследование также подчеркнуло, как важно правильно управлять стратегией, взаимодействовать с заинтересованными сторонами и грамотно собирать требования. Все это может сильно повлиять на успех или провал проекта.<sup>[\[16\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-16)</sup>

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

**Системный анализ в IT** опирается на принципы системного мышления и адаптированные под разработку ПО методики. На практике комбинируются «жёсткие» и «мягкие» подходы, структурные методологии, объектно-ориентированные нотации, а также языки моделирования процессов и требований.

- **Жёсткий и мягкий подходы**. В ИТ-проектах жёсткий подход (hard systems) предполагает заранее формализуемые цели и требования, декомпозицию и проектирование «сверху вниз». Мягкий подход (soft systems) применяют при неясных целях и множественных точках зрения: используют элементы <a href="https://en.wikipedia.org/wiki/Soft_systems_methodology" class="extiw" title="wikipedia:Soft systems methodology">Soft Systems Methodology (SSM)</a> (напр., *rich picture*, корневые определения, CATWOE) для согласования понимания проблемы и желаемых изменений; затем результаты переводят в формальные требования.<sup>[\[17\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-17)[\[18\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-18)</sup>

<!-- -->

- **Методология SSM (Soft Systems Methodology)**. Изначально разработанная *Питером Чеклендом* для организационных изменений, SSM полезна на предпроектных этапах IT: от исследования проблемной ситуации и формулирования корневых определений (в т.ч. через CATWOE) до сопоставления концептуальных моделей с реальностью и достижения аккомодации между стейкхолдерами.<sup>[\[19\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-19)[\[20\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-20)</sup>

<!-- -->

- **Структурированные методологии: SADT/IDEF0**. SADT моделирует систему как иерархию функций; стандартная нотация IDEF0 (IEEE 1320.1) фиксирует функции и их I-C-O-M-интерфейсы (Inputs, Controls, Outputs, Mechanisms). Метод удобен для функциональной декомпозиции и согласования [границ системы](https://systems-analysis.info/wiki/%D0%93%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D1%8B_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B "Границы системы") независимо от алгоритмов.<sup>[\[21\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-21)[\[22\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-22)</sup>

<!-- -->

- **Объектно-ориентированный анализ:** <a href="https://en.wikipedia.org/wiki/Unified_Modeling_Language" class="extiw" title="wikipedia:Unified Modeling Language">UML</a> и <a href="https://ru.wikipedia.org/wiki/SysML" class="external text" rel="nofollow">SysML</a> (<a href="https://en.wikipedia.org/wiki/Model-based_systems_engineering" class="extiw" title="wikipedia:Model-based systems engineering">MBSE</a>). UML стал базовым языком для требований и дизайна (диаграммы прецедентов, классов, последовательностей и др.) и облегчает валидацию сценариев с пользователями; <a href="https://ru.wikipedia.org/wiki/SysML" class="external text" rel="nofollow">SysML</a> расширяет UML для системной инженерии (диаграммы требований, параметрические диаграммы) и опирается на подход MBSE, где модель — центральный артефакт сквозь этапы от требований до тестов.<sup>[\[23\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-23)[\[24\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-24)[\[25\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-25)</sup>

<!-- -->

- **Моделирование бизнес-процессов:** BPMN. Стандарт BPMN используют для графического описания процессов (пулы, потоки работ, события, шлюзы), включая сравнение *as-is/to-be* в спецификациях требований и интеграции.<sup>[\[26\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-26)[\[27\]](https://systems-analysis.info/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_%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/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_%D0%B2_IT#cite_note-28)[\[29\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-29)[\[30\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-30)[\[31\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-31)</sup>

<!-- -->

- **Связь с системной инженерией**. Для комплексных (киберфизических) систем применяют <a href="https://ru.wikipedia.org/wiki/V-Model" class="external text" rel="nofollow">V-модель</a>: на «левой» ветви — системный анализ и архитектура, на «правой» — интеграция, <a href="https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D1%80%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F" class="external text" rel="nofollow">верификация</a> и <a href="https://ru.wikipedia.org/wiki/%D0%92%D0%B0%D0%BB%D0%B8%D0%B4%D0%B0%D1%86%D0%B8%D1%8F" class="external text" rel="nofollow">валидация</a> с привязкой к артефактам левой ветви. Методы оценки архитектуры по качественным атрибутам включают ATAM (trade-off анализ).<sup>[\[32\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-32)[\[33\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-33)</sup>

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

## Связь с ИТ-архитектурой и архитектурой предприятия

Системный анализ в ИТ-проектах тесно связан с архитектурным проектированием. Роли аналитика и архитектора пересекаются: аналитик формулирует требования и логическую модель, архитектор определяет целевую структуру решения и технические компромиссы; работа ведётся совместно.

- **Архитектура ИТ-систем**. В узком смысле архитектура ПО — это организация компонентов, их отношения и принципы, которыми руководствуются при проектировании решения. Аналитику важно учитывать архитектурные стили (слоёная, клиент–серверная, микросервисная, событийно-ориентированная и др.), поскольку нефункциональные требования (надёжность, масштабируемость, модифицируемость) часто определяют архитектурные решения и их компромиссы.<sup>[\[34\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-AzureStyles-34)[\[35\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SEI_ATAM-35)</sup> На раннем этапе анализа формируют **архитектурное видение** (high-level vision) и прорабатывают черновой контур решения для проверки жизнеспособности требований (длина итераций и детализация зависят от методологии).<sup>[\[36\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-TOGAFIntro-36)</sup>

<!-- -->

- **Шаблоны и предварительные решения**. Для удовлетворения нефункциональных требований применяются архитектурные шаблоны (architectural patterns). Например, для асинхронного взаимодействия и слабой связности — publish–subscribe через брокер сообщений в событийно-ориентированной архитектуре.<sup>[\[37\]](https://systems-analysis.info/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_%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/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_%D0%B2_IT#cite_note-TOGAFIntro-36)</sup> Для поддержки требований и прослеживаемости используются каталоги и матрицы (напр., требования ↔ сервисы, функции ↔ компоненты), а также различаются ***Architecture Building Blocks*** и ***Solution Building Blocks***.<sup>[\[38\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-38)[\[39\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-39)</sup> Принципы и стандарты предприятия фиксируются в соответствующих каталогах и выступают внешними нефункциональными **требованиями** для проектных команд.<sup>[\[40\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-40)</sup> Соответствие решений целевой архитектуре подтверждается процедурой архитектурного комплаенса (Architecture Compliance Review).<sup>[\[41\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-41)</sup> Подход TOGAF предполагает предварительное **Architecture Vision** и последующую детализацию (данные/приложения/технологии) с планом миграции и управлением изменениями требований.<sup>[\[42\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-42)[\[43\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-43)</sup>

<!-- -->

- **Zachman Framework**. Ранняя и влиятельная онтология артефактов архитектуры предприятия, представленная как матрица 6×6 (перспективы × аспекты «что/как/где/кто/когда/почему»). Строка «дизайнер» соотносится с системным анализом и проектированием; колонки задают полноту рассмотрения данных, функций/процессов, ролей, расположения и мотивации. Фреймворк служит классификацией (а не методологией) и помогает обеспечить полноту описания решения в ландшафте предприятия.<sup>[\[44\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-Zachman1987-44)</sup>

<!-- -->

- **Связь с архитектурой предприятия (Enterprise Architecture, EA)**. Системный аналитик работает в контексте EA: новые требования трассируются к бизнес-возможностям и операционной модели; применяются стандарты и принципиальные ограничения предприятия (безопасность, совместимость и т.п.).<sup>[\[45\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-45)[\[36\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-TOGAFIntro-36)</sup> На стадии инициации формируется ***Architecture Vision*** (цели/ограничения, укрупнённые требования), далее аналитик детализирует, сохраняя прослеживаемость к видению и корпоративным стандартам; невыполнение стандартов выявляется на архитектурных ревью и может привести к доработкам решения.<sup>[\[36\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-TOGAFIntro-36)[\[46\]](https://systems-analysis.info/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_%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/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_%D0%B2_IT#cite_note-Royce-47)[\[48\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-DAU_SRR-48)[\[49\]](https://systems-analysis.info/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_%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/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_%D0%B2_IT#cite_note-MS_Agile-50)[\[51\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-MS_BDD-51)[\[52\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-MS_Trace-52)</sup>

<!-- -->

- **DevOps и SRE**. Частые релизы требуют операционных требований «по умолчанию»: автоматизации, наблюдаемости, отката. Нефункциональные требования формулируют как SLO/SLI, управляют error budget; в бэклог добавляют задачи на логи/метрики/трейсы/алерты; для выпуска без простоя — паттерны **blue/green** и др.<sup>[\[53\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SRE_SLO-53)[\[54\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-AzureMon-54)[\[55\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-AWS_BlueGreen-55)</sup>

<!-- -->

- **Управление требованиями и рисками**. Требования в ALM имеют статусы и связи с задачами/релизами/дефектами; обязательны version control, change impact analysis и регулярная реприоритизация.<sup>[\[56\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-Azure_Workflow-56)[\[57\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-Azure_Backlog-57)</sup>

<!-- -->

- **Обеспечение качества (QA)**. Качество закладывается на этапе требований: ревью, «Three Amigos», план *Acceptance Test Plan*, автотесты критериев приёмки (BDD/ATDD).<sup>[\[58\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-MS_Test-58)[\[59\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-MS_SpecFlow-59)</sup>

<!-- -->

- **Наблюдаемость и надёжность**. В требования включают SLA/SLO, MTTR и MTBF с измеримыми целями и методами контроля; параметры поступают от бизнеса/эксплуатации и закладываются в архитектуру и тесты надёжности.<sup>[\[60\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-IBM_MTTR-60)[\[61\]](https://systems-analysis.info/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_%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/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_%D0%B2_IT#cite_note-ISO29148-3)[\[62\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-IEEE830-62)[\[1\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

- **Корректность (Correctness)** — требование отражает подлинную потребность и согласовано с экспертами предметной области; подтверждается валидацией (review/inspection, прототипы, сценарии).<sup>[\[1\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SWEBOK-1)[\[4\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NASA7123-4)</sup>

<!-- -->

- **Полнота (Completeness)** — учтены существенные аспекты и условия.
  - *Полнота отдельного требования*: указаны необходимые детали (напр., «индикатор переходит в статус **красный при сбое**», а не просто «становится красным»).
  - *Полнота спецификации*: покрыты сценарии/роли, заданы NFR; достигается чек-листами и трассируемостью к бизнес-целям; полезен независимый аудит полноты (QA/review).<sup>[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Однозначность (Unambiguity)** — формулировки трактуются единственным образом; помогает глоссарий, шаблоны вида «система **должна делать A, когда B, если C**», примеры; диаграммы сопровождаются легендой. Проверка — принцип **«четырёх глаз»**.<sup>[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Согласованность (Consistency)** — требования не противоречат друг другу и внешним ограничениям; применяют структурирование, сводные таблицы атрибутов, командные ревью; сверяют регуляторику/стандарты.<sup>[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Проверяемость/тестируемость (Verifiability)** — достижение подтверждается тестом/демонстрацией/анализом; непроверяемые формулировки заменяют измеримыми критериями; для NFR задают метрики и заранее фиксируют критерии приёмки.<sup>[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **Изменяемость и трассируемость (Modifiability & Traceability)** — уникальные ID, логичная структура («одна мысль — один абзац»), отсутствие дубликатов; поддерживаются связи «требование ↔ источник/цель/дизайн/тест», ведётся матрица **трассируемости (RTM)**.<sup>[\[64\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NASA_RM-64)[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Ранжирование и приоритизация** — качество набора требований; используют техники **MoSCoW** и MCDM (напр., **AHP**); приоритизация совместно с бизнесом влияет на планирование и риски.<sup>[\[65\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-MoSCoW-65)[\[66\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-Saaty-66)</sup>

**Метрики качества требований** (примеры):<sup>[\[63\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NASA_SEH-63)[\[1\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

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

В зрелых процессах (напр., **CMMI** уровень 3+) действуют регламенты качества требований: формальные проверки, аудиты соответствия шаблонам, сбор/анализ метрик.<sup>[\[67\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SEI_CMMI-67)</sup> В критичных доменах (авионика, космос и др.) применяют **формальные методы** для повышения надёжности.<sup>[\[68\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NASA_FM-68)</sup>

## Типичные ошибки

В ИТ-проектах часто встречаются ошибки системного анализа: неполнота и неоднозначность требований, противоречия, размытые границы, игнорирование нефункциональных аспектов, пропущенная интеграция и запоздалая безопасность. Это приводит к переработкам, задержкам, увеличению затрат и дефектам.

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

- **Неполнота и пропущенные требования**. Упускаются роли с особыми правами, пограничные случаи и NFR. *Последствия:* переделки архитектуры и перенос запуска. Как избежать: чек-листы, мозговые штурмы «что если…», раннее подключение тестировщиков, трассируемость к бизнес-целям.<sup>[\[1\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SWEBOK-1)[\[69\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **Неясные, двусмысленные формулировки**. *Последствия:* разработчики реализуют «не то», заказчик недоволен. Как избежать: измеримые критерии, глоссарий, шаблоны «A, когда B, если C», peer‑review.<sup>[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)[\[69\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **Противоречивые требования**. *Последствия:* задержки на уточнения, переделки на интеграции. Как избежать: структурирование, сверка бизнес‑правил/регуляторики, сессии разрешения конфликтов, проверка согласованности на ревью.<sup>[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Синдром «золотой пластины» (gold‑plating)**. *Последствия:* рост объёма, усложнение, новые точки отказа. Как избежать: привязка каждого требования к цели/метрике; в Agile — не включать лишнее в backlog; фиксировать scope; см. <a href="https://ru.wikipedia.org/wiki/YAGNI" class="external text" rel="nofollow">YAGNI</a>.

<!-- -->

- **Избыточная детализация там, где не нужна.** Как избежать: отделять *что/зачем* (требования) от *как* (дизайн/реализация); применять *design‑free requirements* там, где уместно.<sup>[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Нарушение управляемости требованиями**. *Последствия:* путаница версий, реализация «не того». Как избежать: единый источник правды в ALM, историзация и статусы, RTM и change impact analysis; управление изменениями через CCB.<sup>[\[64\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NASA_RM-64)[\[1\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Отсутствие участия пользователей**. Как избежать: интервью, наблюдение, прототипы, регулярные показы; явная валидация со стейкхолдерами.<sup>[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Слишком длительный «аналитический паралич»**. Как избежать: зона достаточности, итеративность и timeboxing; запуск MVP/инкрементов и корректировка по обратной связи.<sup>[\[1\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Игнорирование нефункциональных требований**. Как избежать: выделять NFR (напр., FURPS+), задавать измеримые критерии, включать их в план тестирования и архитектурные решения.<sup>[\[1\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SWEBOK-1)[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **Коммуникационные ошибки и «человеческий фактор»**. Как решать: развивать интервьюирование и фасилитацию, сохранять нейтральность, фиксировать решения и источники требований (прослеживаемость к целям).<sup>[\[1\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-SWEBOK-1)</sup>

Большинство проблем сводятся к качеству формулировок, полноте и управляемости требований; применение стандартов ISO/IEC/IEEE 29148 и практик SWEBOK (валидируемость, прослеживаемость, итеративность) значительно снижает риск срывов сроков и переработок.<sup>[\[3\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/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_%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/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_%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/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_%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/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_%D0%B2_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Архитектура и решения (Architecture, ADR)**: результаты моделирования угроз; меры «безопасность по умолчанию» (шифрование, контроль доступа, секрет‑менеджмент, принцип наименьших привилегий); ограничения на использование данных/моделей; записи ADR с оценкой рисков и компромиссов.<sup>[\[71\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **План верификации и валидации (V&V / TEVV)**: сценарии тестирования моделей и данных; пороги приёмки для метрик качества; мониторинг дрейфа данных/модели; процедуры периодической переоценки и повторной валидации.<sup>[\[70\]](https://systems-analysis.info/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_%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/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_%D0%B2_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **План управления данными и моделями**: каталог источников и lineage; критерии качества и доступности данных; версии датасетов/моделей; расписание (до)обучения и контроль bias; политика доступа и хранения; план безопасной деактивации модели и удаления данных, если требуется.<sup>[\[70\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **Эксплуатация и наблюдаемость (Ops/Runbook)**: метрики доверия к ИИ и SLO; аудит и журналирование; алерты на деградацию/аномалии; план реагирования на инциденты; fallback/kill‑switch для ИИ‑компонент; требования к отчётности и пост‑инцидентному анализу.<sup>[\[70\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **Трассируемость** (end‑to‑end): явные связи «**требование ↔ контроль/проверка в конвейере**» и «**требование ↔ тест/мониторинг в эксплуатации**», чтобы можно было доказуемо проверять безопасность и качество на всём жизненном цикле.<sup>[\[71\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NIST_AI_RMF-70)</sup>
- **Роль системного аналитика**.
  - управляет контекстом и рисками ИИ (акторы, сценарии применения, допущения и ограничения данных);
  - обеспечивает трассируемость «**требование ↔ контроль безопасности в конвейере**»;
  - формулирует проверяемые нефункциональные требования (безопасность, прозрачность, наблюдаемость) на всём жизненном цикле системы.<sup>[\[70\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/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_%D0%B2_IT#cite_note-DoD_DevSecOps-71)</sup>

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

Термин «[системный анализ](https://systems-analysis.info/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 "Системный анализ")» исторически шире разработки ПО. <a href="https://systems-analysis.ru/systems_analysis.html" class="external text" rel="nofollow">Классический системный анализ</a> — подход к решению сложных междисциплинарных задач (социальных, экономических, управленческих), основанный на системном мышлении и количественных методах, обычно для поддержки управленческих решений. В ИТ под системным анализом понимают прикладную дисциплину в области инженерии программного обеспечения, ориентированную на создание информационных систем.

Ниже — ключевые отличия.

- **Цели и объект анализа**. Классический анализ решает плохо структурированные, «размытые» проблемы и улучшает уже существующие социотехнические системы (городская транспортная сеть, стратегия компании, экологическая политика). Объект — реальная система; задача — помочь ЛПР выбрать курс действий. Для системного анализа в ИТ цель — спроектировать и создать новую информационную систему или программный продукт, отвечающий требованиям. Объект — проектируемая система; фокус — поведение и характеристики, нужные пользователям.

<!-- -->

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

<!-- -->

- **Роли и артефакты**. В классическом анализе роль «системного аналитика» часто неформальна; результаты — аналитический отчёт, рекомендации, математические модели, сценарии «что‑если». В ИТ роль аналитика (или бизнес‑аналитика) формализована; выпускаются спецификации требований, модели системы (UML, ER), спецификации интерфейсов, user stories и backlog — артефакты, напрямую используемые разработчиками и тестировщиками.

<!-- -->

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

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

**[Системный аналитик в IT](https://systems-analysis.info/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%D1%82%D0%B8%D0%BA "Системный аналитик")** — специалист, отвечающий за системное мышление в проектировании и развитии информационных систем: формирование и валидацию требований, моделирование (UML/BPMN), согласование архитектурных решений и обеспечение интеграции. Роль и квалификационные требования в РФ закреплены в профстандарте и ФГОС.

**Основная цель вида профессиональной деятельности:** Обеспечение соответствия ИТ-сервиса, автоматизированной системы, автоматизированной информационной системы, автоматизированной системы управления, программного, информационного продукта или средства (далее - Система) окружению, исходным требованиям и ограничениям, целям автоматизации и автоматизированной деятельности путем разработки и передачи качественных и взаимоувязанных проектных решений заинтересованным сторонам при запуске и координации работ отдельных исполнителей на всем жизненном цикле Системы (*Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н*).<sup>[\[72\]](https://systems-analysis.info/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_%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) — соглашение о готовности элемента бэклога к разработке (ясность, оценка, критерии).
- Definition of Done (DoD) — соглашение о «завершённости» работы (код, тесты, документация, развёртывание).
- Ограничение (Constraint) — жесткое условие, ограничивающее решения (сроки, платформы, стандарты, лицензии).
- Допущение (Assumption) — предположение, принимаемое без доказательства, требующее последующей валидации.
- Качество требований — свойства по ISO 29148: еднозначность, полнота, непротиворечивость, проверяемость, атомарность.

### Формализация, трассируемость и приоритизация требований

- Формализация требований — процесс преобразования неформальных запросов в чёткие, проверяемые и однозначные требования.
- Трассируемость требований — возможность отслеживать жизненный цикл требования от его источника до реализации, тестирования и развёртывания.
- Bidirectional traceability (двунаправленная прослеживаемость) — способность отслеживать связи между требованиями, элементами дизайна и тестовыми сценариями как в прямом, так и в обратном направлении.
- MoSCoW — техника приоритизации требований, классифицирующая их как Must-have (должно быть), Should-have (следует иметь), Could-have (может быть) и Won't-have (не будет).
- BDD (Behavior-Driven Development) — методология разработки, в которой тесты пишутся на естественном языке, ориентированном на [поведение системы](https://systems-analysis.info/wiki/%D0%9F%D0%BE%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B "Поведение системы") с точки зрения пользователя (формат Given–When–Then).

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

- UML (Unified Modeling Language) — стандартизированный язык графического моделирования для спецификации, визуализации, конструирования и документирования компонентов программных систем.
- SysML (Systems Modeling Language) — расширение UML для системной инженерии, поддерживающее моделирование различных аспектов сложных систем, включая требования, поведение, структуру и параметры.
- BPMN (Business Process Model and Notation) — стандарт графической нотации для описания бизнес-процессов, позволяющий визуализировать потоки работ, события, шлюзы и пулы.
- MBSE (Model-Based Systems Engineering) — подход к системной инженерии, где модель является центральным артефактом на всех этапах [жизненного цикла системы](https://systems-analysis.info/wiki/%D0%96%D0%B8%D0%B7%D0%BD%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9_%D1%86%D0%B8%D0%BA%D0%BB_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B "Жизненный цикл системы"), от требований до тестирования.
- 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 (синдром «золотой пластины») — ошибка в системном анализе, заключающаяся в добавлении функциональности, которая не требуется стейкхолдерами, что ведёт к росту объёма и сложности проекта.

## См. также

- [Системный анализ](https://systems-analysis.info/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 "Системный анализ")
- [Системный аналитик](https://systems-analysis.info/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%D1%82%D0%B8%D0%BA "Системный аналитик")
- [Теория систем](https://systems-analysis.info/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC "Теория систем")
- [Наблюдатель в системном подходе](https://systems-analysis.info/wiki/%D0%9D%D0%B0%D0%B1%D0%BB%D1%8E%D0%B4%D0%B0%D1%82%D0%B5%D0%BB%D1%8C_%D0%B2_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D0%BE%D0%BC_%D0%BF%D0%BE%D0%B4%D1%85%D0%BE%D0%B4%D0%B5 "Наблюдатель в системном подходе")
- [Неопределенность в системе](https://systems-analysis.info/wiki/%D0%9D%D0%B5%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5 "Неопределенность в системе")

## Ссылки

- <a href="https://www.iso.org/standard/81702.html" class="external text" rel="nofollow">ISO/IEC/IEEE 15288:2023 — System life cycle processes</a>
- <a href="https://www.iso.org/standard/63712.html" class="external text" rel="nofollow">ISO/IEC/IEEE 12207:2017 — Software life cycle processes</a>
- <a href="https://www.iso.org/standard/72089.html" class="external text" rel="nofollow">ISO/IEC/IEEE 29148:2018 — Requirements engineering</a>
- <a href="https://www.iso.org/standard/74393.html" class="external text" rel="nofollow">ISO/IEC/IEEE 42010:2022 — Architecture description</a>
- <a href="https://www.iso.org/standard/78176.html" class="external text" rel="nofollow">ISO/IEC 25010:2023 — Product quality model (SQuaRE)</a>
- <a href="https://www.iso.org/standard/84661.html" class="external text" rel="nofollow">ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288</a>
- <a href="https://www.iso.org/standard/74909.html" class="external text" rel="nofollow">ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation)</a>
- <a href="https://www.iso.org/standard/68982.html" class="external text" rel="nofollow">ISO/IEC/IEEE 42020:2019 — Architecture processes</a>
- <a href="https://www.iso.org/standard/81291.html" class="external text" rel="nofollow">ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts</a>
- <a href="https://standards.ieee.org/ieee/1012/7324/" class="external text" rel="nofollow">IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation</a>

<!-- -->

- <a href="https://www.omg.org/spec/UML/2.5.1/About-UML" class="external text" rel="nofollow">UML 2.5.1 — OMG Specification</a>
- <a href="https://www.omg.org/spec/BPMN/2.0.2/" class="external text" rel="nofollow">BPMN 2.0.2 — OMG Specification</a>
- <a href="https://www.omg.org/spec/SysML/1.7/About-SysML" class="external text" rel="nofollow">SysML v1.7 — OMG Specification</a>

<!-- -->

- <a href="https://www.opengroup.org/togaf-standard-10th-edition-downloads" class="external text" rel="nofollow">TOGAF Standard, 10th Edition — The Open Group</a>
- <a href="https://www.opengroup.org/archimate-licensed-downloads" class="external text" rel="nofollow">ArchiMate 3.2 — The Open Group</a>

<!-- -->

- <a href="https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/" class="external text" rel="nofollow">SEI ATAM — Architecture Tradeoff Analysis Method</a>
- <a href="https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf" class="external text" rel="nofollow">NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF)</a>

<!-- -->

- <a href="https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf" class="external text" rel="nofollow">SWEBOK Guide v4.0a — IEEE Computer Society (PDF)</a>
- <a href="https://www.sebokwiki.org/" class="external text" rel="nofollow">Guide to the Systems Engineering Body of Knowledge (SEBoK)</a>

<!-- -->

- <a href="https://www.iiba.org/knowledgehub/business-analysis-body-of-knowledge-babok-guide/" class="external text" rel="nofollow">BABOK Guide v3 — IIBA</a>
- <a href="https://sre.google/books/" class="external text" rel="nofollow">Google SRE Books — Official site</a>
- <a href="https://learn.microsoft.com/en-us/azure/well-architected/" class="external text" rel="nofollow">Microsoft Azure Well-Architected Framework — Official docs</a>
- <a href="https://www.youtube.com/watch?v=mUlBwXnx2xw" class="external text" rel="nofollow">Системный анализ простыми словами. YouTube</a>
- <a href="https://www.youtube.com/watch?v=sk4vyYcVSso" class="external text" rel="nofollow">Системный анализ в IT простыми словами. YouTube</a>

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

- 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*. <a href="https://www.opengroup.org/togaf-standard-10th-edition-downloads" class="external text" rel="nofollow">Официальная бесплатная версия</a>.
- OMG (2017). *Unified Modeling Language (UML®) 2.5.1 Specification*. <a href="https://www.omg.org/spec/UML/2.5.1/PDF" class="external text" rel="nofollow">PDF</a>.
- OMG (2014). *Business Process Model and Notation (BPMN™) 2.0.2 Specification*. <a href="https://www.omg.org/spec/BPMN/2.0.2/PDF" class="external text" rel="nofollow">PDF</a>.
- OMG (2024). *Systems Modeling Language (SysML®) 1.7 Specification*. <a href="https://sysml.org/.res/docs/specs/OMGSysML-v1.7-24-01-07.pdf" class="external text" rel="nofollow">PDF</a>.
- The Open Group (2022). *ArchiMate® 3.2 Specification*. <a href="https://www.opengroup.org/archimate-licensed-downloads" class="external text" rel="nofollow">Официальная бесплатная загрузка (по лицензии)</a>.
- 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/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_%D0%B2_IT#cite_ref-SWEBOK_1-0)</sup> <sup>[1,01](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-SWEBOK_1-1)</sup> <sup>[1,02](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-SWEBOK_1-2)</sup> <sup>[1,03](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-SWEBOK_1-3)</sup> <sup>[1,04](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-SWEBOK_1-4)</sup> <sup>[1,05](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-SWEBOK_1-5)</sup> <sup>[1,06](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-SWEBOK_1-6)</sup> <sup>[1,07](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-SWEBOK_1-7)</sup> <sup>[1,08](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-SWEBOK_1-8)</sup> <sup>[1,09](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-SWEBOK_1-9)</sup> <sup>[1,10](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-SWEBOK_1-10)</sup> <sup>[1,11](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-SWEBOK_1-11)</sup> <sup>[1,12](https://systems-analysis.info/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_%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/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_%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/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_%D0%B2_IT#cite_ref-ISO29148_3-0)</sup> <sup>[3,01](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-ISO29148_3-1)</sup> <sup>[3,02](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-ISO29148_3-2)</sup> <sup>[3,03](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-ISO29148_3-3)</sup> <sup>[3,04](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-ISO29148_3-4)</sup> <sup>[3,05](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-ISO29148_3-5)</sup> <sup>[3,06](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-ISO29148_3-6)</sup> <sup>[3,07](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-ISO29148_3-7)</sup> <sup>[3,08](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-ISO29148_3-8)</sup> <sup>[3,09](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-ISO29148_3-9)</sup> <sup>[3,10](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-ISO29148_3-10)</sup> <sup>[3,11](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-ISO29148_3-11)</sup> <sup>[3,12](https://systems-analysis.info/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_%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/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_%D0%B2_IT#cite_ref-NASA7123_4-0)</sup> <sup>[4,1](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-NASA7123_4-1)</sup> <sup>[4,2](https://systems-analysis.info/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%D0%B2_IT#cite_ref-TOGAFIntro_36-0)</sup> <sup>[36,1](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-TOGAFIntro_36-1)</sup> <sup>[36,2](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-TOGAFIntro_36-2)</sup> <sup>[36,3](https://systems-analysis.info/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%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/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_%D0%B2_IT#cite_ref-NASA_SEH_63-0)</sup> <sup>[63,1](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-NASA_SEH_63-1)</sup> <sup>[63,2](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-NASA_SEH_63-2)</sup> <sup>[63,3](https://systems-analysis.info/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_%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/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_%D0%B2_IT#cite_ref-NASA_RM_64-0)</sup> <sup>[64,1](https://systems-analysis.info/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_%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/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_%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/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_%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/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_%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/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_%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/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_%D0%B2_IT#cite_ref-SEI_Pitfalls_69-0)</sup> <sup>[69,1](https://systems-analysis.info/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_%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/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_%D0%B2_IT#cite_ref-NIST_AI_RMF_70-0)</sup> <sup>[70,1](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-NIST_AI_RMF_70-1)</sup> <sup>[70,2](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-NIST_AI_RMF_70-2)</sup> <sup>[70,3](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-NIST_AI_RMF_70-3)</sup> <sup>[70,4](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-NIST_AI_RMF_70-4)</sup> <sup>[70,5](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-NIST_AI_RMF_70-5)</sup> <sup>[70,6](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-NIST_AI_RMF_70-6)</sup> <sup>[70,7](https://systems-analysis.info/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_%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/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_%D0%B2_IT#cite_ref-DoD_DevSecOps_71-0)</sup> <sup>[71,1](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-DoD_DevSecOps_71-1)</sup> <sup>[71,2](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-DoD_DevSecOps_71-2)</sup> <sup>[71,3](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-DoD_DevSecOps_71-3)</sup> <sup>[71,4](https://systems-analysis.info/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_%D0%B2_IT#cite_ref-DoD_DevSecOps_71-4)</sup> <sup>[71,5](https://systems-analysis.info/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_%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/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_%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>