Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
07 апреля 2022 Все для начинающего РМа
1

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

Юлия Бажанова
Редактор проекта, РМР, ICP-PPM




Одним из инструментов управления проектами является матрица отслеживания требований (на английском – 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.

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

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

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





комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

1комментарий

сначала новые
по рейтингу сначала новые по хронологии

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: