Матрица отслеживания требований или Requirements Traceability Matrix – что это и зачем нужно

Одним из инструментов управления проектами является матрица отслеживания требований (на английском – Requirements Traceability Matrix или просто RTM), вот о ней давайте сегодня и поговорим.

Что такое Requirements Traceability Matrix

Матрица отслеживания требований (а также матрица трассировки, матрица требований проекта, матрица соответствия  требований, матрица трассируемости, матрица прослеживания и еще десяток вольных переводов Requirements Traceability Matrix или сокращенно RTM на русский язык) – это документ с таблицей (или несколькими таблицами), в которой отслеживается весь жизненный цикл требований к системе, от целей проекта и исходных бизнес-требований на момент определения объема проекта до тест-кейсов, на которых будет проверяться разработанный функционал, и до конкретных элементов/модулей/кусочков системы. Также может (и должна!) трассироваться история изменений требований, если таковая будет.

В русскоязычном интернете можно найти много статей, где этот инструмент описан более узко, чаще всего его упрощают до матрицы, в которой отображают связь функциональных требований с тест-кейсами, которыми они проверяются.  Это не совсем корректно –  как и практически любой инструмент в управлении проектами, матрица трассировки требований может и должна быть адаптирована под задачи конкретного проекта. Ну и в целом само слово “трассировка” переводится с английского как “возможность отслеживания”, а отслеживать в проекте нужно все-таки не только покрытие тестами. Ошибка идет, похоже, от того, что на курсах тестировщиков матрицу трассировки слушателям “продают” как инструмент тестирования, поэтому если такое увидите – не верьте.

Зачем нужна матрица трассировки

Собственно, как и все в управлении проектами, матрица трассировки направлена на повышение прозрачности и снижение риска что-то забыть или, наоборот, сделать лишнее (=зря потратить время и деньги). В основном это инструмент бизнес-аналитика, но если говорить об управлении проектом, то матрица трассировки позволяет руководителю проекта:

1. Убедиться, что в проект не напихали лишних задач – все же сталкивались с тем, что вы начинали делать какую-нибудь системку для автоматизации сдачи авансовых отчетов, а заканчивали монструозной ERP-системой из палок и прочей субстанции? Вот тут-то больше всего и пригождается матрица требований, давая возможность однозначно связать цель проекта -> бизнес-требования -> функциональные требования -> юзер кейсы и т .д. и выкинуть все лишнее, не приводящее к обозначенной в уставе цели. Или наоборот, убедиться, что ничего не забыли, тоже полезно.
2. Получить удобный инструмент для анализа влияния – если кто-то из стейкхолдеров захотел что-то поменять в проекте, то достаточно будет пройти по цепочке трассировки в матрице, чтобы понять, на что это изменение повлияет, причем это работает в обе стороны – как при изменении бизнес-требований, так и при изменении какого-то уже разработанного элемента. Это отличное дополнение к процессу управления изменениями в проекте.
3. Сэкономить кучу времени на поиск информации, переделки, ошибки, “ой, мы сделали не то” или “ой, это мы не протестировали”. Ну и бонусом – не бесить лишний раз стейкхолдеров, переспрашивая одно и то же.
4. Организовать единую точку коммуникации (все в одном месте), за счет чего – снизить риски и, соответственно, стоимость и сроки проекта.
5. Сохранить историю – если проект “не полетит” или с вас спросят “а нафига вы делали вот это?” – вы всегда сможете отследить источник этого “нафига” и ткнуть в него пальцем. В идеальном мире у руководителя проекта, конечно, спрашивать такое не должны, но мы-то в реальном мире живем. Ну и в целом такой артефакт будет полезен для будущих проектов, когда через год-два-пять кто-то захочет внести изменения в вашу систему или, например, интегрироваться с ней.

Оффтоп, но про анализ влияния – все же видели это описание, так точно объясняющее наши ИТ-будни?

На этой позитивной ноте – идем дальше!

Как выглядит матрица отслеживания требований

На старте разработки руководитель проекта совместно с бизнес-аналитиками определяет, что именно нужно отслеживать в проекте и готовит шаблон документа.

В минимальном варианте трассировка может быть, например, такой – Бизнес-требования -> Функциональные требования -> Тест-кейсы. Теоретически можно обойтись одним листом в экселе.

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

Для больших и комплексных систем, где обойтись просто табличкой нельзя, используется специализированное программное обеспечение, например, RequisitePro, Mantis, JIRA и так далее. Работа в них требует определенных усилий по налаживаю процесса в команде, но обычно оно того стоит, если проект большой. Иначе в какой-то момент таблицы в экселе с тысячей строк просто станут неуправляемыми.

Пара практических моментов

В теории все классно (как всегда), но на практике при использовании RTM я бы посоветовала учитывать следующие нюансы:

1. Оцените, точно ли вам нужна матрица требований и готовы ли вы ее вести и постоянно обновлять, т.к. это достаточно трудоемкий процесс. Если нет – лучше не начинать.
2. Если решили использовать матрицу – расскажите команде, что это и какие выгоды принесет. А то все снова будут думать, что у вас просто много свободного времени.
3. Обязательно присвойте каждому элементу (требованию, тест-кейсу и т.д.) уникальный “говорящий” ID типа REQ-27 или TEST-67, ориентироваться в документе будет гораздо проще.
4. Используйте гиперссылки в экселе для быстрого перехода к связанным элементам, один раз придется проставить, но удобство использования возрастет кратно.
5. Организуйте четкий процесс управления версионностью, ситуация, когда несколько человек думают, что работают над одним документом, а на самом деле вносят изменения в разные – страшный сон руководителя проекта (кроме шуток, мне один раз такой снился).
6. Попробуйте начать с минимального варианта, а не сразу замахиваться на максимальный.
7. Лучше используйте ПО, если оно есть в вашей компании, в большинстве случаев матрицу требований вести намного удобнее (хотя бывают и исключения). Однако ПО – это все-таки способ, поэтому понимать смысл матрица как инструмента все-таки нужно.

Где найти больше информации про матрицу трассировки и про управление требованиями в целом

Если после прочтения поста у вас возникнет непреодолимое желание разобраться в этой теме еще подробнее – есть целый международный стандарт бизнес-анализа Business Analysis Body of Knowledge, руководство к своду знаний по бизнес-анализу от Международного института IIBA (или попросту BABOK), сейчас, по-моему, актуальна третья версия. Один из его ключевых разделов – управление жизненным циклом требований (Requirements Life Cycle Management), в нем как раз есть подраздел про трассировку. Кстати, когда-то давно в блоге даже был гостевой пост от читательницы, сдавшей экзамен по BABOK, почитать можно тут.

В качестве альтернативы (если после PMBoK вы пообещали себе больше никогда не читать своды знаний) – единственный и неповторимый Карл Вигерс с его  легендарной книжкой “Разработка требований к программному обеспечению”, читается легче и интереснее.

А если, наоборот, хочется чего-то “покрепче” – найти много чего про управления требованиями можно еще в стандарте CMMI (Capability Maturity Model Integration), там есть целая процессная область Requirements Management.

Пример матрицы трассировки

Скоро будет:)

Используете матрицу отслеживания требований в своих проектах? Расскажите!