# Учебно-методический комплекс по созданию технических заданий

> **Версия 2.1** | **Автор: Виталий Александрович Пиков** | **МАСКОМ**  
> **Дата обновления:** 6 июня 2026  
> **Назначение:** методичка и основа авторского курса по написанию технических заданий для программного обеспечения, автоматизированных систем и проектов безопасной разработки.

---

## 1. Главная идея курса

Техническое задание не должно быть документом "ради документа". Хорошее ТЗ появляется после анализа продукта, пользователей, архитектурных ограничений и угроз. Оно фиксирует то, что уже понято, согласовано и может быть проверено.

Курс строится вокруг инженерной формулы:

```
User Story + концепт интерфейса + архитектурные ограничения + модель угроз
+ требования ГОСТ/регуляторов + критерии приемки = проверяемое и безопасное ТЗ
```

ТЗ должно быть полезно сразу трем сторонам:

| Сторона | Что получает от качественного ТЗ |
|---|---|
| Заказчик | Контроль результата, бюджета, сроков и состава приемки |
| Исполнитель | Однозначный объем работ и защиту от бесконечных переделок |
| Комиссия/аудитор | Проверяемые критерии соответствия и набор артефактов |

---

## 2. Нормативная база

Методичка использует гибридный подход: ГОСТы задают документную дисциплину, инженерные практики дают удобный способ формулировать и проверять требования, а РБПО добавляет безопасность на уровне процесса разработки.

| Документ/подход | Как использовать в ТЗ |
|---|---|
| **ГОСТ 19.201-78** | Базовая структура ТЗ на программу или программное изделие: назначение, требования, документация, технико-экономические показатели, стадии, контроль и приемка. |
| **ГОСТ 34.602-2020** | Структура ТЗ на автоматизированную систему: общие сведения, цели, объект автоматизации, требования к системе, работы, разработка, контроль и приемка, ввод в действие, документирование. |
| **ГОСТ Р 59792-2021** | Связь ТЗ с предварительными испытаниями, опытной эксплуатацией и приемочными испытаниями АС. |
| **ГОСТ Р 56939-2024** | Требования к процессам разработки безопасного ПО: требования безопасности, управление конфигурацией, недостатки, анализ кода, безопасная сборка, секреты, SCA, поддержка и реагирование на уязвимости. |
| **ГОСТ Р 58412-2019** | Анализ угроз безопасности информации при разработке ПО; источник для определения мер защиты процессов РБПО. |
| **OWASP ASVS / OWASP Top 10 / CWE / CERT C/C++ / MISRA C/C++** | Практические источники требований безопасности, особенно для веб-, C/C++- и критичных систем. |
| **NIST SSDF, ISO/IEC 27001, ISO/IEC 27034** | Международная рамка для SSDLC, управления безопасностью и безопасной разработки приложений. |

Для ОКР особенно важен п. 4.15 ГОСТ Р 56939-2024: требования стандарта к ПО, разрабатываемому в рамках НИР/ОКР, предъявляются явным перечислением процессов в ТЗ. Допускается указывать не полный объем стандарта, условия применимости процессов и состав артефактов.

---

## 3. Что сделать до написания ТЗ

ТЗ является финалом первичного проектирования, а не его началом. До открытия шаблона нужно собрать пять слоев цифрового продукта.

| Слой | Вопрос | Выходной артефакт |
|---|---|---|
| Бизнес | Зачем создается система и какую проблему решает? | Цели, границы проекта, критерии успеха |
| Пользователь | Кто работает с системой и в каком контексте? | Роли, сценарии, user stories |
| Функционал | Что система должна делать? | Перечень функций, бизнес-правила, приоритеты |
| Интерфейсы | Где пользователь или система взаимодействуют с продуктом? | Wireframes, API-контракты, интеграционные точки |
| Backend и администрирование | Что обеспечивает работу внутри? | Данные, роли, журналы, настройки, эксплуатационные процессы |

Минимальный порядок работы:

1. Зафиксировать проблему и измеримый результат.
2. Описать заинтересованные стороны и роли пользователей.
3. Собрать пользовательские сценарии и бизнес-правила.
4. Выделить функциональные, нефункциональные и требования безопасности.
5. Определить внешние интерфейсы, данные и ограничения.
6. Провести первичное моделирование угроз и определить поверхность атаки.
7. Согласовать критерии приемки до передачи ТЗ в разработку.

---

## 4. Кодекс качества требований

Требование должно быть не красивой фразой, а рабочей единицей проектирования, разработки, тестирования и приемки.

| Критерий | Что проверять |
|---|---|
| **1. Требование как требование** | Формулировка должна задавать обязанность: "Система должна...", "Исполнитель должен..."; описание текущего состояния не является требованием. |
| **2. Атомарность** | Один пункт описывает одну функцию, одно свойство или одно ограничение. Если пункт нельзя проверить одним тестом или одной группой связанных проверок, его надо разделить. |
| **3. Однозначность** | Термины определены в глоссарии, формулировка допускает одну трактовку для заказчика, аналитика, разработчика и испытателя. |
| **4. Проверяемость** | Для требования существует объективный способ проверки: тест, анализ, инспекция, демонстрация или документарный контроль. |
| **5. Реализуемость** | Требование выполнимо при заданных технологиях, сроках, бюджете, квалификации и ограничениях среды. |
| **6. Обоснованность** | У требования есть источник: бизнес-цель, пользовательский сценарий, нормативный акт, модель угроз, архитектурное ограничение. |
| **7. Полнота и неизбыточность** | Нужное поведение описано без пробелов; дублирование допускается только управляемо, через ссылки. |
| **8. Непротиворечивость** | Требования не конфликтуют между собой и с ограничениями безопасности, эксплуатации и архитектуры. |
| **9. Трассируемость** | У требования есть стабильный ID, связь с источником, задачами разработки, тест-кейсами и результатами приемки. |
| **10. Приоритизация** | Указана критичность или приоритет: Must/Should/Could, Critical/High/Medium/Low или иной согласованный словарь. |

Карточка требования:

| Поле | Пример |
|---|---|
| ID | `SEC-REQ-014` |
| Источник | Модель угроз `TM-03`, ГОСТ Р 56939-2024 п. 5.3, решение архитектурного совета |
| Формулировка | Система должна регистрировать все неуспешные попытки аутентификации с указанием идентификатора пользователя, времени, IP-адреса и причины отказа. |
| Критерий приемки | В журнале аудита появляется запись для каждой неуспешной попытки входа; запись доступна роли администратора безопасности. |
| Метод проверки | Функциональное испытание + инспекция журнала |
| Приоритет | High |
| Статус | Предъявлено / принято / реализуется / проверено / отклонено |

---

## 5. Функциональные, нефункциональные и требования безопасности

Функциональное требование отвечает на вопрос: **что система делает для пользователя или внешней системы**.

Пример:

```
FT-AUTH-001. Система должна предоставлять пользователю возможность входа
по адресу электронной почты и паролю.
```

Нефункциональное требование отвечает на вопрос: **с каким качеством, ограничением или уровнем сервиса работает система**.

Пример:

```
NFT-PERF-001. Время ответа API поиска объявлений не должно превышать 500 мс
для 95 процентиля запросов при нагрузке 100 одновременных пользователей.
```

Требование безопасности отвечает на вопрос: **как предотвратить угрозу, снизить риск, выполнить нормативное требование или исключить уязвимость**.

Пример:

```
SEC-AUTH-003. Система должна блокировать учетную запись на 15 минут после
5 последовательных неуспешных попыток аутентификации в течение 10 минут.
```

Проверка различается:

| Тип требования | Основной способ проверки |
|---|---|
| Функциональное | Функциональное тестирование, демонстрация сценария, приемочный тест |
| Нефункциональное | Нагрузочное тестирование, измерение, мониторинг, эксплуатационная проверка |
| Безопасность | Анализ требований, моделирование угроз, SAST, DAST, fuzzing, SCA, ручное ревью, документарный контроль РБПО |

---

## 6. Требования безопасности в ТЗ

Раздел безопасности не должен быть набором общих фраз. Он должен связывать угрозы, нормативные требования, процессы разработки и проверяемые артефакты.

### 6.1 Источники требований безопасности

| Источник | Что брать в ТЗ |
|---|---|
| Модель угроз | Активы, нарушители, сценарии атаки, поверхность атаки, меры нейтрализации |
| БДУ ФСТЭК, NVD, OSV | Известные уязвимости компонентов, требования к обновлениям и реагированию |
| OWASP ASVS / Top 10 / CWE | Требования к аутентификации, авторизации, сессиям, криптографии, логированию, API |
| CERT C/C++ / MISRA C/C++ | Требования к безопасному C/C++ коду, памяти, ошибкам, API, неопределенному поведению |
| ГОСТ Р 56939-2024 | Процессы РБПО и состав подтверждающих артефактов |
| Договор/ОКР/эксплуатационная среда | Ограничения по автономности, поставке, интернет-доступу, секретам, сборочной среде |

### 6.2 Пример блока РБПО для ОКР

```
В связи с тем, что разработка Программного комплекса ведется в рамках ОКР,
требования ГОСТ Р 56939-2024 предъявляются в соответствии с п. 4.15
настоящего стандарта путем явного перечисления процессов, подлежащих
реализации, условий их применимости и состава подтверждающих артефактов.
```

Рекомендуемый минимальный набор процессов для включения в ТЗ:

| Процесс ГОСТ Р 56939-2024 | Что требовать от Исполнителя |
|---|---|
| 5.3 Требования безопасности | Регламент управления требованиями безопасности; реестр требований с ID, формулировкой, датой, приоритетом, сроком, предъявившим и принявшим лицом. |
| 5.4 Управление конфигурацией | Регламент конфигурационного управления; правила ветвления, версионирования, маркировки сборок и состава поставки. |
| 5.5 Недостатки и изменения | Регламент управления дефектами и запросами на изменение; журнал решений и статусов. |
| 5.10 Статический анализ | Регламент SAST; профиль правил; отчет первичного и финального анализа; разметка срабатываний. |
| 5.12, 5.13 Безопасная сборка | Описание системы сборки, состава инструментов, сборочной среды, журналов сборки и контроля целостности. |
| 5.14 Доступ и целостность кода | Модель ролей в репозитории; правила review; защита веток; журнал доступа. |
| 5.15 Секреты | Регламент обращения с секретами; запрет хранения секретов в исходном коде; результаты проверки secret scanning. |
| 5.16 Композиционный анализ | Перечень зависимостей, SBOM/PPK, лицензии, источники, версии, отчеты SCA по уязвимостям. |
| 5.18 Функциональное тестирование | План тестирования, журналы, отчеты, связь с требованиями. |
| 5.22, 5.23 Поддержка и уязвимости | Регламент поддержки, порядок приема сообщений об уязвимостях, оценка критичности и выпуск исправлений. |
| 5.25 Вывод из эксплуатации | Регламент завершения поддержки и уведомления пользователей. |

### 6.3 Критерий приемки для РБПО

Проверка выполнения требований РБПО проводится документарным контролем и выборочной инструментальной проверкой:

1. Исполнитель предоставляет утвержденные регламенты по перечисленным процессам.
2. Исполнитель предоставляет фактические проектные артефакты: реестр требований безопасности, журналы сборки, отчеты SAST/SCA, перечень зависимостей, протоколы тестирования.
3. Финальная сборка не содержит неисправленных критических и высоких уязвимостей, если иное не согласовано отдельным решением с анализом риска.
4. Все отклонения имеют статус, владельца, срок устранения или документированное решение о принятии риска.

---

## 7. Связь ТЗ с ПМИ

Каждое требование должно иметь проверку. Если требование нельзя перенести в программу и методику испытаний, оно не готово.

Матрица трассируемости:

| ID требования | Источник | Метод проверки | Пункт ПМИ | Ожидаемый результат |
|---|---|---|---|---|
| `FT-ORD-001` | User Story `US-05` | Функциональный тест | `PMI-FT-012` | Пользователь создает заказ из корзины |
| `NFT-PERF-002` | SLA проекта | Нагрузочное испытание | `PMI-NFT-004` | p95 ответа API не выше 500 мс |
| `SEC-SCA-001` | ГОСТ Р 56939-2024 п. 5.16 | Документарный контроль + SCA | `PMI-SEC-008` | Есть SBOM/PPK и отчет без критических неисправленных уязвимостей |

Методы проверки:

| Метод | Когда применять |
|---|---|
| Демонстрация | Пользовательский сценарий виден в интерфейсе |
| Тест | Поведение можно воспроизвести по шагам |
| Измерение | Нужны численные показатели: время, нагрузка, доступность |
| Анализ | Проверяется код, архитектура, модель угроз или конфигурация |
| Инспекция | Проверяются документы, журналы, настройки, права доступа |

---

## 8. Антипаттерны

| Плохо | Почему плохо | Как исправить |
|---|---|---|
| "Система должна быть безопасной" | Нельзя проверить | Разложить на угрозы, меры и критерии: MFA, RBAC, аудит, TLS, SAST/SCA, журналы |
| "Исполнитель должен учитывать ГОСТ Р 56939" | Нет состава работ и артефактов | Перечислить процессы, условия применимости и документы по п. 4.15 ГОСТ Р 56939-2024 |
| "Не использовать внешние модули, кроме Open Source" | Противоречие | Разрешить только включенные в дистрибутив и проверенные зависимости, без загрузки из интернета при сборке/эксплуатации |
| "Интерфейс должен быть удобным" | Субъективно | Указать сценарии, критерии доступности, время выполнения операции, UX-ограничения |
| "Все отчеты должны быть PDF, а отчет мониторинга обновляется каждые 5 секунд" | Конфликт требований | Разделить статические отчеты и экран мониторинга |
| "Кнопка должна быть синей 14px" | Дизайн-решение выдается за требование | Сослаться на дизайн-систему и критерии доступности/согласованности |

---

## 9. Практический шаблон раздела требования

```
REQ-ID:
Тип: функциональное / нефункциональное / безопасность / процессное
Источник:
Формулировка:
Обоснование:
Критерий приемки:
Метод проверки:
Связанные требования:
Риски и ограничения:
Приоритет:
Владелец:
Статус:
```

Пример:

```
REQ-ID: SEC-SBOM-001
Тип: безопасность / процессное
Источник: ГОСТ Р 56939-2024 п. 5.16; политика SCA проекта
Формулировка: Исполнитель должен сформировать и передать Заказчику перечень
используемых сторонних компонентов ПО с указанием наименования, версии,
поставщика, лицензии и источника получения.
Обоснование: Требование необходимо для контроля состава поставки, лицензий
и известных уязвимостей.
Критерий приемки: Предоставлен SBOM/PPK в согласованном формате; по каждому
компоненту указаны версия, лицензия и источник; отсутствуют компоненты
с неизвестным происхождением.
Метод проверки: Документарный контроль + выборочная сверка с дистрибутивом.
Приоритет: High.
```

---

## 10. Как использовать материалы курса

Рекомендуемый маршрут для слушателя:

1. Пройти разделы 1-4 этой методички и выписать критерии качества требований.
2. Выбрать шаблон под тип проекта: ГОСТ 19.201-78, ГОСТ 34.602-2020, MVP, малый проект или Agile.
3. Заполнить пять слоев продукта до написания требований.
4. Сформировать требования с ID, источником и критерием приемки.
5. Отдельно выделить требования безопасности и процессные требования РБПО.
6. Составить матрицу трассируемости ТЗ -> задачи -> тесты -> ПМИ -> артефакты приемки.
7. Проверить документ по чек-листу качества ТЗ.

Связанные материалы в комплекте:

- `materials/дополнительно/чек-лист-ТЗ.md` — чек-лист проверки качества ТЗ.
- `materials/дополнительно/сравнение-ГОСТов.md` — выбор стандарта под тип проекта.
- `materials/шаблоны/` — заготовки ТЗ для разных типов работ.
- `materials/примеры/` — демонстрационные примеры структуры требований.

---

## 11. Финальный quality gate перед передачей ТЗ в разработку

ТЗ можно передавать в разработку, если выполнены все условия:

- Цель проекта и границы работ зафиксированы.
- Все роли пользователей и заинтересованные стороны описаны.
- Функциональные, нефункциональные и требования безопасности разделены.
- У каждого требования есть ID, источник и критерий приемки.
- Термины вынесены в глоссарий.
- Противоречия между требованиями устранены или вынесены на решение.
- Для требований безопасности определены источники: модель угроз, нормативные документы, базы уязвимостей, стандарты кодирования.
- Для ОКР процессы ГОСТ Р 56939-2024 перечислены явно, с условиями применимости и составом артефактов.
- Для зависимостей определены правила SCA, SBOM/PPK, проверки лицензий и реагирования на уязвимости.
- Составлена матрица трассируемости ТЗ -> ПМИ.

Короткая формула проверки:

```
Если требование нельзя понять одинаково, реализовать, проверить и принять,
оно еще не готово для ТЗ.
```

---

## 12. Контакты

**Виталий Александрович Пиков**  
Преподаватель НОУ ДПО «УЦБИ «МАСКОМ», эксперт в области информационной безопасности и разработки безопасного программного обеспечения.

- Email: [vitaly@pikov.expert](mailto:vitaly@pikov.expert)
- Telegram: [@UnderLineSecurity](https://t.me/UnderLineSecurity)
- Сайт: [pikov.expert](https://pikov.expert)

Материал предназначен для образовательного использования в авторском курсе по техническим заданиям и разработке безопасного программного обеспечения.