Похожие презентации:
Лк4. Документация этапа разработки
1. Документация процесса разработки ПО
Документирование – это формализованное описаниеинформации, созданной в течение всего жизненного цикла
программного обеспечения
Процесс документирования - это набор действий, с
помощью которых планируют, проектируют,
разрабатывают, выпускают, распространяют и
сопровождают документы, участвующие в разработке ПО,
а также для пользователей системы
2. Жизненный цикл разработки ПО
3. Сбор и анализ требований
Документ спецификации требований (SRS)Ключевые компоненты
Software Requirements Specification
Функциональные требования —
является фундаментальным
документом, который закладывает
основу для всего проекта
Он содержит детальное описание
того, что должна делать система, и
служит контрактом между заказчиком
и командой разработки
описание возможностей системы
Нефункциональные требования —
производительность, безопасность,
масштабируемость
Бизнес-правила и ограничения
проекта
Критерии приемки для каждого
требования
Приоритеты и зависимости между
требованиями
4. Планирование
План проектаУправление рисками
Комплексный документ, описывающий
Документация по идентификации,
все аспекты выполнения проекта:
расписание, ресурсы, бюджет,
команду и процессы коммуникации
Детальная временная шкала с
вехами
Распределение ролей и
ответственности
Процедуры управления
изменениями
оценке и минимизации рисков
проекта. Включает план реагирования
на потенциальные проблемы
Регистр рисков с вероятностью и
воздействием
Стратегии снижения и предотвращения
План мониторинга
5. Документы процесса разработки программного обеспечения
Этап жизненного циклаПредпроектная стадия
Вид документа
Назначение и
содержание
Артефакты
Техническое задание
(ТЗ)
Формализация
требований
заказчика.
• Основание для
разработки
• Цели и задачи
• Требования к
системе
- Техникоэкономическое
обоснование
- UML-диаграмма
прецедентов
- Спецификация
требований
Концепция проекта
Общее видение
системы,
рыночные
возможности,
целевая аудитория
- Бизнестребования
- Анализ рынка
- Roadmap проекта
Сбор требований к
системе
6. Проектирование архитектуры и системы
UML-диаграммыУнифицированный язык моделирования
Архитектурная документация представляет
собой детальное описание структуры
системы, взаимодействия её компонентов и
технических решений. Она служит чертежом
для разработчиков и основой для
технических дискуссий в команде
Описание интерфейсов
Детальная спецификация API,
протоколов взаимодействия между
модулями, форматов данных и
контрактов между компонентами
системы
используется для визуализации
структуры классов, взаимодействий
объектов, последовательности
операций и других аспектов системы
Диаграммы классов
Диаграммы последовательностей
Диаграммы компонентов
Схемы потоков данных
Визуализация движения данных через
систему, показывающая источники,
обработку, хранилища и получателей
информации. Критически важна для
понимания бизнес-логики и интеграций
7. Проектирование пользовательского интерфейса (UI/UX)
UX-документация включает картыпользовательских путей (user journey maps),
персоны пользователей, описания
взаимодействий и навигационную структуру.
Каждый элемент интерфейса должен быть
документирован с точки зрения его
назначения, поведения и влияния на
пользовательский опыт
Документация доступности
Спецификации по обеспечению
доступности для людей с
ограниченными возможностями
Прототипы
Низко- и высокодетализированные
макеты интерфейса,
демонстрирующие расположение
элементов и базовую логику
взаимодействия
Сценарии использования
Детальное описание
пользовательских путей, включая
последовательность действий, точки
входа и ожидаемые результаты
8. Документы процесса разработки программного обеспечения
Этап жизненногоцикла
Назначение и
содержание
Артефакты
Спецификация
архитектуры
Описание структуры
системы и
технологических
решений
- Диаграмма
компонентов (UML)
- Схема
развертывания
- Технологический
стек
Проект базы данных
Моделирование
структур данных
- ER-диаграмма
- Схема базы данных
- Словарь данных
Технический проект
Детальное описание
системы
Вид документа
Проектирование
9. Разработка и кодирование
На этапе разработки документация создаётсянепосредственно в исходном коде через
комментарии, а также в виде отдельных
технических описаний модулей и компонентов.
Качественные комментарии объясняют не
только что делает код, но и почему выбрано
конкретное решение
Инструменты автоматической генерации
документации
Javadoc — для Java-проектов, генерирует HTMLдокументацию из специальных комментариев
Doxygen — универсальный инструмент для C++, C,
Java, Python и других языков
JSDoc — для JavaScript-проектов
Sphinx — популярен в Python-сообществе
Документирование кода
На этапе разработки документация
создаётся непосредственно в исходном
коде через комментарии, а также в виде
отдельных технических описаний
модулей и компонентов. Качественные
комментарии объясняют не только что
делает код, но и почему выбрано
конкретное решение
Техническая документация
Отдельные документы описывают
Архитектуру модулей и их
взаимодействие
API и публичные интерфейсы библиотек
Алгоритмы и структуры данных
Зависимости и используемые
библиотеки
Инструкции по сборке и конфигурации
10. Документы процесса разработки программного обеспечения
Этап жизненногоцикла
Разработка
Назначение и
содержание
Артефакты
Ведомость
программных
модулей
Учет компонентов
системы
- Реестр модулей
- Описание
назначения каждого
модуля
Ведомость
зависимостей
Учет внешних
библиотек и их
версий
- Список
зависимостей
(requirements.txt,
package.json)
Технический проект
Детальное описание
системы
Вид документа
11. Тестирование
Тест-планыТестирование
Виды тестирования и их документация:
Модульное тестирование - тестирование
отдельных компонентов и функций.
Документируется в виде автоматических тестов
с комментариями и отчётов о покрытии кода
Интеграционное тестирование Проверка
взаимодействия компонентов. Требует
документирования интерфейсов, протоколов и
сценариев взаимодействия
Системное тестирование Проверка системы в
целом. Документация включает сквозные
сценарии, тесты производительности и
нагрузочного тестирования
Приемочное тестирование Валидация
соответствия требованиям заказчика.
Документируется в виде acceptance criteria и
протоколов приёмки
Стратегические документы, описывающие
общий подход к тестированию, охват,
ресурсы, расписание и критерии
входа/выхода для каждого типа
тестирования
Тест-кейсы
Детальные сценарии тестирования с
предусловиями, шагами выполнения,
ожидаемыми результатами и
фактическими результатами после
выполнения
Отчёты о тестировании
Документы, суммирующие результаты
тестирования, включая статистику
выполнения, найденные дефекты,
покрытие кода и рекомендации
12. Документы процесса разработки программного обеспечения
Этап жизненногоцикла
Назначение и
содержание
Артефакты
План
тестирования
Организация процесса
тестирования
- Тест-план
- Чек-листы
- Сценарии
тестирования
Протоколы
тестирования
Фиксация результатов
тестирования
- Баг-реports
- Отчеты о тестировании
- Акты испытаний
Вид документа
Тестирование
13. Внедрение и развертывание
Подготовка окруженияВнедрение и развертывание
Критические документы разверты вания :
Детальные требования к инфраструктуре:
серверам, сетевой конфигурации, базам
данных, операционным системам и
вспомогательному ПО
Установка компонентов
Чек-листы предразвёртывания и
Пошаговые инструкции по установке всех
Схемы сетевой топологии и портов
компонентов системы с указанием
последовательности, параметров
конфигурации и проверочных действий
Инструкции по настройке балансировщиков
Настройка и конфигурация
постразвёртывания
нагрузки
Документация по мониторингу и алертам
Процедуры резервного копирования
План отката и восстановления
Включает пошаговые инструкции по возврату к предыдущей
версии, восстановлению данных из резервных копий и
коммуникационный план для информирования
Руководство по настройке параметров
системы, интеграций с внешними
сервисами, политик безопасности и
мониторинга
Миграция данных
Процедуры переноса данных из старых
систем, включая скрипты конвертации,
валидацию и план отката в случае
проблем
14. Документы процесса разработки программного обеспечения
Этап жизненногоцикла
Вид документа
Руководство
пользователя
Назначение и
содержание
Артефакты
Описание работы с
системой для
конечных
пользователей
- Пошаговые
инструкции
- Скриншоты
интерфейса
- Примеры
использования
Инструкции по
установке и
поддержке системы
- Процедуры
установки
- Настройка
конфигурации
- Меры безопасности
Внедрение
Руководство
администратора
15. Эксплуатация и сопровождение
Руководства пользователяЭксплуатация и сопровождение
Поддержка и инциденты:
Подробные инструкции по работе с
системой для конечных пользователей,
включающие описание функционала,
пошаговые сценарии использования, FAQ
и решение типичных проблем
Журналы инцидентов документируют все
обращения в службу поддержки
Описание проблемы и симптомов
Шаги по воспроизведению
Временная шкала событий
Примененные решения
Рекомендации по предотвращению
Руководства администратора
Техническая документация для
администраторов системы: управление
пользователями, настройка параметров,
мониторинг производительности,
процедуры обслуживания и устранения
неисправностей
Документация обновлений
База знаний (knowledge base) накапливает решения типичных
проблем и становится бесценным ресурсом для команды
Детальные описания новых функций,
поддержки и пользователей. Каждый решенный инцидент
исправленных дефектов, известных
пополняет эту базу, постепенно снижая нагрузку на поддержку
проблем и инструкций по обновлению с
предыдущих версий
16. Документы процесса разработки программного обеспечения
Этап жизненногоцикла
Вид документа
Назначение и
содержание
Артефакты
Акт сдачи-приемки
Формальное
принятие системы в
эксплуатацию
- Акт выполненных
работ
- Протокол приемки
Правила поддержки и
развития системы
- Процедуры
обновления
- Политика
исправления ошибок
Сопровождение
Регламент
сопровождения
17. Виды документации в проекте
Поль зоват ел ь ская документация33% проектной документации
Руководства пользователя
FAQ и база знаний
Системная документация
Обучающие материалы
33% проектной документации
Видеоинструкции
Технические спецификации
Архитектурные схемы
Документация кода и API
Базы данных и модели данных
Процессная документация
34% проектной документации
Планы проекта
Отчёты о статусе
Протоколы совещаний
Управление рисками
Эффективная документация в проекте разработки ПО должна охватывать все три категории, обеспечивая полное покрытие
инф ормационных потребностей различных стейкхолдеров. Системная документация критична для технических
специалистов, пользовательская — для конечных пользователей и обучения, а процессная — для управления проектом и
обеспечения прозрачности
18. Дополнительные документы, сопровождающие разработку
КатегорияДокументы
Организационные
- План-график работ
- Отчеты о выполнении этапов
- Протоколы совещаний
Качество
- Стандарты кодирования
- Чек-листы код-ревью
- Метрики качества ПО
Управление
- Отчеты о статусе проекта
- Матрица ответственности
- Реестр рисков
19. Форматы и инструменты для документации
Статичные документыPDF, Word, LaTeX для формальной документации, требующей утверждения и архивирования
Wiki-системы
Коллаборативные платформы для постоянно обновляемой документации команды
HTML и веб-форматы
Динамические веб-страницы с поиском, навигацией и интерактивными элементами
Markdown
Легковесный формат разметки, идеальный для документации в репозиториях
20. Форматы и инструменты для документации
Выбор правильных форматов и инструментов для документации напрямую влияетна её доступность, актуальность и удобство использования. Современная
разработка предполагает использование разнообразных средств
документирования
Интеграция с DevOps-инфраструктурой
Системы контроля версий
Версионирование и историю изменений
Синхронизацию кода и документации
CI/CD для документации – автоматизация процессов документирования
Автоматическая генерация из кода
Проверка ссылок и форматирования
Публикация при коммитах
Создание версионированных релизов
21. Риски и проблемы в документации
Устаревание документацииБыстрые изменения в коде и требованиях часто опережают обновление
документации. Результат — несоответствие между документами и реальным
состоянием системы, что подрывает доверие к документации в целом
Недостаточная детализация
Слишком общие или поверхностные описания не дают достаточно информации
для понимания системы. Пользователи и разработчики вынуждены тратить время
на изучение кода или эксперименты.
Избыточность документации
Создание документов «на всякий случай», которые никто не читает. Это тратит
ресурсы команды и создаёт дополнительную нагрузку по поддержке бесполезных
артефактов.
Отсутствие ответственности
Когда за документацию никто конкретно не отвечает, она неизбежно приходит в
упадок. Размытая ответственность ведёт к тому, что обновления откладываются
бесконечно
22. Качество документации
Включение проверки документации в процесс code review. Изменения в кодедолжны сопровождаться обновлением соответствующей документации, что
проверяется на этапе peer review
Использование инструментов автоматической генерации документации из кода,
комментариев и аннотаций. Это снижает ручной труд и обеспечивает
синхронизацию кода и документации.
Чёткое распределение ответственности за различные виды документации. Роль
tech writer или documentation owner в команде
Развитие культуры документирования в команде через обучение, воркшопы и
обмен опытом. Демонстрация ценности хорошей документации на конкретных
примерах
23. Метрики качества документации
Регулярный аудит документации по этим метрикампомогает выявить проблемные области и отслеживать
улучшения. Важно не только собирать метрики, но и
действовать на основе полученных данных, постоянно
совершенствуя процессы и инструменты
документирования
95%
Актуальность
Процент документов, обновлённых в течение
последнего спринта или релиза
4.5
Полезность
Средняя оценка пользователей
документации по 5-балльной шкале
80%
Покрытие
Процент компонентов системы, имеющих
актуальную документацию
15
Время поиска
Среднее время (в минутах) для нахождения
нужной информации
24. Примеры ключевых документов на разных этапах
25. Взаимодействие команды и документация
Документация служит важнейшим инструментом коммуникации в современныхраспределённых и кросс-функциональных командах. Она преодолевает барьеры
времени, расстояния и специализации
Передача
знаний
окументация — мост между разработчиками, тестировщиками, дизайнерами,
product-менеджерами и заказчиками
Онбординг новых сотрудников, обучение смежным областям, сохранение
знаний при ротации
Коммуникация
между ролями
Документирование архитектурных решений (ADR ) помогает понять
Фиксация
решений
контекст и обоснование выбора
Делает процессы и решения видимыми для всех
стейкхолдеров, повышая доверие и
вовлечённость
Прозрачность
Позволяет команде из разных часовых поясов эффективно сотрудничать без
Асинхронная
работа
постоянных встреч
26.
Документация и автоматизация процессовСовременные инструменты и практики позволяют значительно автоматизировать создание, обновление и распространение документации, снижая ручной труд и повышая её качество.
Интеграция с PM-системами
CI/ CD для документации
Автоматические отчёты
J ira, Trello, Azure DevOps автоматически формируют документацию
Автоматическое тестирование, сборка и публикация документации
Генерация отчётов по тестированию, покрытию кода,
из тикетов, stories и задач
при каждом коммите
производительности из результатов автотестов
Инструменты автоматизации
Генераторы из кода
OpenAPI/Swagger
Javadoc, Doxygen, JSDoc, Sphinx — автоматическое создание API-документации из комментариев в
Описание R E S T API в стандартизированном ф ормате с автоматической генерацией интерактивной
исходном коде. Обеспечивает синхронизацию кода и документации.
документации, клиентских S DK и mock-серверов.
Статичные генераторы
Docs-as-Code
Jekyll, Hugo, MkDocs — создание статичных веб-сайтов документации из Markdown-файлов, интеграция
Хранение документации в том же репозитории, что и код, использование PR -процесса для review,
с Git, версионирование.
автоматический deploy при merge.
Автоматизация не только экономит время, но и снижает вероятность человеческих ошибок, обеспечивает консистентность форматиров ания и структуры документации. Pipeline автоматического тестирования может
проверять корректность ссылок, валидность примеров кода и соответствие стандартам.
Интеграция с системами мониторинга и логирования позволяет автоматически обновлять операционную документацию данными о реальной работе системы — метрики производительности, частота ошибок,
использование ресурсов.
27.
Документирование API и внешних интерфейсовAPI-документация критически важна для интеграций, сторонних разработчиков и микросервисных архитектур. Качественная документация API определяет успех его adoption и снижает нагрузку на поддержку.
01
02
Обзор и введение
Справочник эндпоинтов
Описание назначения API, ключевых концепций, базового UR L, аутентификации и общего процесса работы с API
Детальное описание каждого эндпоинта: HTTP -метод, путь, параметры, тело запроса, форматы ответов,
возможные ошибки
03
04
Примеры и туториалы
Changelog и версионирование
Реальные примеры запросов и ответов, пошаговые руководства для типичных сценариев использования
Документация изменений между версиями, политика deprecation, миграционные руководства
Стандарты и инструменты
REST API
SOAP
GraphQL
OpenAPI Specification 3.0
WSDL-спецификации
Самодокументируемая схема
Swagger UI для интерактивной документации
XML Schema definitions
GraphiQL playground
Postman Collections
SOAP UI для тестирования
Introspection queries
RE S Tful best practices
WS-* стандарты
Schema SDL
Интерактивная документация
Современная API-документация должна быть интерактивной — позволять пользователям тестировать запросы прямо в браузере. Инструменты вроде Swagger UI, ReDoc или Postman предоставляют такой функционал из
коробки. Это значительно ускоряет понимание API и снижает порог входа для разработчиков.
Документация для разработчиков интеграций должна включать информацию о rate limiting, квотах, SLA, процедурах получения API-ключей и support channels. SDK и библиотеки для популярных языков программирования с
собственной документацией значительно повышают adoption API.
28.
Документация безопасностиВ эпоху возрастающих киберугроз документация по безопасности становится критически важным элементом разработки ПО. Она охватывает меры защиты, политики и процедуры обеспечения безопасности системы.
1
2
Модель угроз
Политики безопасности
Документирование потенциальных угроз безопасности, векторов атак, уязвимостей системы и рисков. Включает
Описание политик аутентификации, авторизации, управления доступом (RBAC, ABAC), парольных политик,
анализ критичности различных компонентов и данных.
шифрования данных в покое и в передаче.
3
4
Архитектура безопасности
Compliance и стандарты
Схемы сетевой безопасности, межсетевых экранов, DMZ, сегментации сети, защищенных каналов связи.
Документирование соответствия требованиям GDPR, PCI DSS, HIPAA, SOC 2 и других релевантных стандартов.
Документация по защите на уровне приложения.
Процедуры аудита и сертификации.
Отчёты по безопасности
Vulnerability Assessment
Penetration Testing
Регулярное сканирование на уязвимости:
Отчёты по тестированию на проникновение:
Результаты SAST/DAST тестирования
Методология и сценарии тестирования
Найденные уязвимости с оценкой серьёзности (CVSS)
Успешные и неуспешные атаки
Планы устранения критических проблем
Рекомендации по усилению защиты
Статус патчинга известных CVE
Проверка исправлений
План реагирования на инциденты
Критически важный документ, описывающий процедуры действий при обнаружении инцидента безопасности. Включает определения типов инцидентов, процессы эскалации, контакты ответственных лиц, шаги по изоляции угрозы, сбору
forensics-данных, восстановлению сервисов и постинцидентному анализу. План должен регулярно тестироваться через security drills.
29.
Документация для DevOps и инфраструктурыDevOps-культура требует инфраструктуру как код (Infrastructure as Code) и соответствующую документацию, обеспечивающую воспроизводимость, надёжность и прозрачность окружений.
Скрипты развертывания
Архитектура инфраструктуры
CI/CD пайплайны
Документированные скрипты Ansible, Terraform, CloudFormation для
Схемы облачной инфраструктуры, описание сервисов
Описание этапов continuous integration и delivery: сборка,
автоматизации provisioning инфраструктуры. Включают комментарии,
AWS/ Azure/ GCP, конфигурации load balancers, databases, caching
тестирование, статический анализ, упаковка, деплой. Конфигурации
README с инструкциями запуска, требования к окружению.
layers. Документация disaster recovery и backup strategies.
Jenkins, GitLab CI, GitHub Actions.
Мониторинг и логирование
Метрики системы
Процедуры troubleshooting
Документация ключевых метрик производительности (KPI), thresholds для алертов, dashboards в
Runbooks для типичных проблем, диагностические команды, чек-листы для инцидентов, контакты
Grafana/ Datadog, SLI/ SLO определения
дежурной команды
1
2
3
Структура логов
Форматы логов, уровни логирования, централизованное хранение (ELK, Splunk), политики ротации и
retention
Конфигурационные файлы (Docker Compose, Kubernetes manifests) должны быть документированы и версионированы в Git. Каждое изменение конфигурации проходит через pull request с описанием причин
изменения и потенциального impact. Использование GitOps подхода делает инфраструктуру полностью прозрачной и аудируемой.
Документация по мониторингу должна включать описание каждой настроенной метрики — что она измеряет, почему важна, какие значения считаются нормальными, и какие действия предпринимать при
отклонениях. Это критично для эффективного реагирования on-call команды.
30.
Документация для поддержки и сопровожденияЭффективная поддержка пользователей и стабильная работа системы невозможны без качественной документации, ориентированной на решение проблем и оперативное реагирование.
База знаний (Knowledge Base)
Troubleshooting Guide
Escalation Procedures
Структурированное хранилище решений типичных проблем, часто
Систематическое руководство по диагностике и устранению
Чёткие процедуры эскалации проблем: критерии для повышения
задаваемых вопросов, инструкций по настройке и использованию
неисправностей. Включает симптомы проблем, возможные причины,
приоритета, контакты ответственных специалистов, SLA по времени
системы. Постоянно пополняется на основе реальных обращений в
шаги диагностики, решения и превентивные меры.
реакции для разных уровней серьёзности.
поддержку.
Операционные процедуры
Runbooks — детальные пошаговые инструкции для операционных задач:
Запуск и остановка сервисов
Процедуры резервного копирования и восстановления
Scaling операции (добавление/удаление ресурсов)
Обновление системных компонентов
Ротация секретов и сертификатов
Очистка дискового пространства
Планирование обновлений
Документация по обновлениям и миграциям должна включать:
Описание изменений и новых функций в каждом релизе
Breaking changes и требуемые адаптации
Пошаговые инструкции по обновлению с указанием downtime
Процедуры миграции данных и их валидации
План отката (rollback) при критических проблемах
Тестирование обновления в staging-окружении
Коммуникационный план для информирования пользователей
Качественные runbooks позволяют даже junior-специалистам выполнять сложные операционные задачи без риска,
освобождая время senior-инженеров для стратегических задач. Каждый runbook должен быть протестирован и
регулярно обновляться.
31.
Кейсы и примеры из практикиРеальные примеры из индустрии демонстрируют как критическую важность качественной документации, так и последствия её отсутствия. Рассмотрим несколько показательных случаев.
Кейс 1 : Спасение проекта документацией
Кейс 2: Цена отсутствия документации
Крупная финтех-компания столкнулась с риском срыва сроков миграции на новую
Стартап в сфере здравоохранения потерял единственного senior-разработчика, знавшего
платёжную систему. Критичным фактором успеха стала детальная документация legacy-
архитектуру системы. Отсутствие документации привело к 6 месяцам изучения кода,
системы, созданная уходящей командой.
множественным багам при попытках модификаций и, в итоге, к решению о полном
Благодаря подробным описаниям бизнес-логики, интеграций и edge-cases, новая команда
переписывании системы.
смогла спланировать миграцию без потери функциональности и завершить проект в срок.
Стоимость переписывания превысила $500,000 и задержала выход на рынок на год.
Документация сэкономила месяцы на reverse engineering.
Инвестиции в документацию в $50,000 могли бы предотвратить эту катастрофу.
Успешные примеры документации
01
02
03
Stripe — эталон API-документации
K ubernetes — масштабная open source
документация
GitLab — documentation-first культура
множестве языков, встроенным API explorer и детальными
Многоуровневая документация для разных аудиторий: от
код. Каждая фича не считается завершённой без документации.
гайдами по интеграции. Считается золотым стандартом в
начинающих до экспертов. Включает концепции, туториалы,
Результат — одна из лучших документаций в DevOps-индустрии.
индустрии.
reference, contributing guide. Поддерживается глобальным
Интерактивная документация с живыми примерами кода на
Компания требует обновления документации в том же MR, что и
сообществом.
Эти примеры показывают, что инвестиции в документацию — это не затраты, а стратегическое преимущество. Компании с сильной культурой документирования быстрее масштабируются, легче
привлекают и адаптируют таланты, и создают более надёжные продукты.
32.
Документация — фундамент качества и устойчивости ПОДокументация — это не формальность, не досадная необходимость, а стратегический актив, определяющий успех проекта.
1
Примите системный подход
2
Сделайте документацию частью культуры
3
Инвестируйте в инструменты и автоматизацию
4
Постоянно совершенствуйте
Документация не должна создаваться хаотично. Разработайте стратегию, определите стандарты, внедрите процессы и инструменты.
Воспитывайте понимание ценности документации в команде. Отмечайте хорошие примеры, обучайте, делайте документирование естественной частью workflow.
Правильные инструменты делают документирование легче и эффективнее. Автоматизация обеспечивает актуальность без дополнительных усилий.
Документация, как и код, требует рефакторинга. Регулярно пересматривайте, обновляйте, улучшайте. Адаптируйте под меняющиеся нужды проекта.
33. Структура Технического Задания
Содержание:1.
Общие положения (основание, наименование, цели)
2.
Назначение и цели создания системы
3.
Требования к системе (функциональные, нефункциональные)
4.
Этапы и стадии разработки
5.
Порядок контроля и приёмки
6.
Приложения (схемы, прототипы, глоссарий)
34. ТЗ — Функциональные требования
IDФункция
Приоритет
Критерии
приемки
Статус
FR-1
Авторизация
Высокий
Вход за 3 сек,
2FA
✅
FR-2
Поиск данных
Средний
Результаты за 2
сек
Программирование