Трассировка требований · Конспекты по бизнес-анализу

Главные идеи#

Четыре направления#

Вигерс и Битти описывают трассировку (traceability) в четырёх направлениях: - От потребностей к требованиям: каждая потребность заказчика покрыта требованиями. - От требований к потребностям: у каждого требования известен источник. - От требований к рабочим продуктам: каждое требование спроектировано, реализовано и протестировано. - От рабочих продуктов к требованиям: каждый фрагмент дизайна, кода или тестов существует не просто так — включая инфраструктурный код, о котором ни один пользователь прямо не просил.

Цепочка связей#

Полная цепочка идёт от бизнес-требований через пользовательские требования, функции продукта и атрибуты качества к функциональным требованиям, а дальше — к архитектуре и дизайну, коду и тестам всех уровней. Бизнес-правила служат источником требований на нескольких уровнях, а запрос на изменение может затронуть любое звено. Главный совет авторов: не поддерживайте все возможные связи. Выберите несколько, которые окупятся на вашем проекте. Может хватить и одного типа, например «функциональное требование → тест».

Зачем нужны связи#

Найти пропущенные требования (бизнес-требование, под которым ничего нет).
Найти лишние требования (функциональное требование без родителя).
Показать регулирующим органам, что каждое обязательное требование реализовано (это не то же самое, что доказать, что оно реализовано правильно).
Анализ влияния при изменениях и поиск всех мест, где реализовано изменившееся бизнес-правило.
Отслеживание статуса: отсутствующая связь означает ещё не сделанную работу.
Повторное использование пакета связанных требований, дизайна, кода и тестов.
Отладка: упавший тест указывает на код, где вероятнее всего ошибка.

Авторы предупреждают: устаревшие данные о связях хуже, чем никаких, потому что уводят людей по ложному следу. Сохраняйте тип связей, только если можете сказать, зачем он нужен.

Нефункциональные требования трассируются иначе#

Некоторые атрибуты качества никогда не превращаются в отдельный модуль. Требование ко времени отклика может определить выбор оборудования, алгоритма или архитектуры; требование к переносимости ограничивает, какими возможностями языка пользуются разработчики. Другие атрибуты, например целостность, порождают обычные производные функциональные требования (пароли, биометрический вход), которые трассируются как обычно.

Подозрительные связи#

Инструменты управления требованиями умеют помечать как подозрительные (suspect) все связи изменённого элемента. Кто-то проверяет каждый помеченный элемент и вручную снимает пометку, когда элемент подтверждён или обновлён. Так волна последствий изменения превращается в список дел.

Экономический выбор#

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

Как применять#

Объясните команде, зачем нужна трассировка и кто за что отвечает.
Для начала выберите один-два типа связей.
Выберите формат (одна широкая матрица или несколько двусторонних матриц) и место, где она будет храниться.
Решите, какие части продукта покрыть в первую очередь: самые критичные или самые изменчивые.
Назначьте владельца для каждого типа связей и координатора — часто это бизнес-аналитик. Связями «требование ↔ тест» обычно владеют тестировщики, связями «требование ↔ дизайн» — архитекторы или разработчики.
Встройте обновление связей в существующие шаги работы, чтобы связь записывалась в момент, когда часть работы завершена.
Договоритесь о правилах именования, чтобы у каждого связанного элемента был однозначный идентификатор.
Собирайте данные о связях небольшими порциями; никогда не откладывайте это до контрольной точки или конца проекта.
Периодически проводите аудит. Если требование помечено «реализовано и проверено», а связи у него неполные, значит, сбоит сам процесс трассировки.

Пример#

«Мастерская», вымышленная сеть веломастерских, трассирует требования к онлайн-записи в одной широкой матрице. Аналитик копирует утверждённую спецификацию (базовую версию), оставляет только идентификаторы и заполняет остальные столбцы по мере завершения работы, а не по мере её планирования. Поэтому заполненная ячейка подтверждает реально сделанную работу.

Пользовательское требование	Функциональное требование	Элемент дизайна	Код	Тесты
UR-03 Записаться на ремонт онлайн	FR-03.1 Показывать свободные окна в выбранной мастерской	Экран календаря записи	booking/slots	ST-12, UT-40
`UR-03`	FR-03.2 Удерживать окно 10 минут во время оформления записи	Сервис удержания окна	booking/hold	`ST-13`
UR-05 Получать сообщения о статусе ремонта	FR-05.1 Отправлять SMS, когда статус становится «Готов»	Сервис уведомлений	notify/sms	(пока нет)

Пустая ячейка в столбце тестов показывает, что FR-05.1 реализовано, но ещё не протестировано. Для связей «один ко многим» и «многие ко многим» лучше подходит набор двусторонних матриц: например, варианты использования в столбцах, функциональные требования в строках и «x» на каждом пересечении. Если требование отмечено под двумя вариантами использования, значит, оно используется повторно.

Подводные камни#

Трассировать всё «на всякий случай» → оставляйте только типы связей с названной целью.
Заполнять ячейки на этапе планирования → заполняйте их, когда работа сделана.
Откладывать трассировку на конец проекта → обновляйте связи непрерывно.
У связей нет владельца → назначьте владельца для каждого типа связей.

Источники и что почитать#

K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 29.