← Бизнес- и системный анализ: профессия аналитика с нуля
Lesson
Артефакты постановки: SRS, глоссарий, трассировка
Описать назначение и структуру ключевых артефактов: спецификации требований (SRS), глоссария и матрицы трассировки требований.
Три главных артефакта аналитика
Три главных артефакта аналитика
Когда требования выявлены, их нужно зафиксировать в виде документов — артефактов. Три ключевых артефакта: SRS (спецификация требований), глоссарий и матрица трассировки (RTM).
SRS (Software Requirements Specification) — главный документ с требованиями. Стандарт IEEE 830 предлагает следующую структуру: Введение и контекст (назначение системы, границы, ссылки на другие документы) → Общее описание (кто пользуется, ограничения, допущения) → Конкретные требования — функциональные (что система делает) и нефункциональные (как: производительность, безопасность, удобство). Хорошая SRS однозначна, полна и проверяема.
Глоссарий — список терминов с их точными определениями. Он устраняет разночтения: когда заказчик говорит «клиент», а разработчик слышит «пользователь», возникают ошибки. Глоссарий фиксирует, что именно имеется в виду под каждым ключевым словом проекта.
Матрица трассировки требований (RTM, Requirements Traceability Matrix) связывает каждое требование с его источником (откуда оно появилось), с реализацией (какой компонент/функция его выполняет) и с тестами (какой тест его проверяет). Forward traceability — от требования к реализации/тестам. Backward traceability — от теста/компонента к требованию. Bidirectional (двусторонняя) — оба направления одновременно. RTM гарантирует: ничего не потеряно (каждое требование реализовано и протестировано) и ничего лишнего (каждый компонент и тест обоснован требованием).
Lesson notes
Три главных артефакта аналитика
Когда требования выявлены, их нужно зафиксировать в виде документов — артефактов. Три ключевых артефакта: SRS (спецификация требований), глоссарий и матрица трассировки (RTM).
SRS (Software Requirements Specification) — главный документ с требованиями. Стандарт IEEE 830 предлагает следующую структуру: Введение и контекст (назначение системы, границы, ссылки на другие документы) → Общее описание (кто пользуется, ограничения, допущения) → Конкретные требования — функциональные (что система делает) и нефункциональные (как: производительность, безопасность, удобство). Хорошая SRS однозначна, полна и проверяема.
Глоссарий — список терминов с их точными определениями. Он устраняет разночтения: когда заказчик говорит «клиент», а разработчик слышит «пользователь», возникают ошибки. Глоссарий фиксирует, что именно имеется в виду под каждым ключевым словом проекта.
Матрица трассировки требований (RTM, Requirements Traceability Matrix) связывает каждое требование с его источником (откуда оно появилось), с реализацией (какой компонент/функция его выполняет) и с тестами (какой тест его проверяет). Forward traceability — от требования к реализации/тестам. Backward traceability — от теста/компонента к требованию. Bidirectional (двусторонняя) — оба направления одновременно. RTM гарантирует: ничего не потеряно (каждое требование реализовано и протестировано) и ничего лишнего (каждый компонент и тест обоснован требованием).