Матрица Соответствия Требований Necessities Traceability Matrix

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

Только неотвратимость трассировки делает ее хорошим инструментом. Трассировка требований должна обязательно быть включена в какой-либо нормоконтроль или согласование. Потому что как только это становится необязательным, оно перестает работать. Проект, вообще не покрытый трассировками, лучше проекта, покрытого трассировками наполовину.

Типы Матриц

• Так, сверху вниз мы можем проследить связи верхнеуровневых требований к самым детальным.
• Такая трассировка позволяет нам ничего не забыть и не потерять, в противном случае – мы можем получить дефект, когда мы выкатим доработку на прод, и это повлияет на качество нашего продукта.
• Нельзя сказать, что монолиты уйдут из нашей жизни навсегда, но фокус с них смещается на другие варианты архитектуры.
• И если мы меняем детальное требование, то можем посмотреть, укладывается ли наше новое требование в верхнеуровневые.
• Если мы учитываем по проекту все наши фичи, в том числе планируемые, мы формируем оцифрованный бэклог.

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

Компоненты Rtm-матрицы

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

Если есть https://deveducation.com/ трассировка, то он видит все артефакты по бизнес-процессу к которому относится, экранная форма, с какими use case это связано. По трассировке, просто проверив каждый из артефактов, он уже сможет разобраться в бизнес-процессе, и качество его работы на выходе будет гораздо выше. Трассировка будет облегчать работу не только новичкам, но и тем, кто уже давно в проекте, просто потому у вас уже есть четкая структурированная картина.

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

А команда разработки понимает из какого запроса родилось это требование. Рассмотрим ещё один пример, который больше относится к аналитике и непосредственно к требованиям. Основная его идея – связь двух реестров требований, когда есть артефакты первого реестра и артефакты второго реестра и нужно сделать между ними маппинг.

Что Такое Трассировка Требований В Проекте И Почему Она Важна?

Второй тип трассировки – горизонтальная, или кроссовая трассировка, когда мы делаем связи одного уровня. Это пример соцсети, когда через соцсети наши друзья все друг с другом так или иначе связаны. Например если в документации у нас много use case, то они могут пересекаться друг с другом, и быть связаны. Когда мы меняем один use case, благодаря кроссовой трассировке мы можем найти, какие другие use case поменяются у нас в проекте, таким образом отследить влияние на них и учесть в них изменения. Любое программное обеспечение, которое используют в качестве систем управления требованиями.

Эти запросы редко целиком ложатся в одно требование, скорее всего, они развалятся на несколько требований. Точно так же мы маппируем исходные запросы на конечные требования для дальнейшей реализации. Таким образом, заказчик всегда будет понимать, что его запрос покрыт теми или иными требованиями.

Это довольно трудоемко, но мы гарантированно будем понимать, как существует и работает наша информационная система с точки зрения требований. Основная задача матрицы — связать каждое требование с соответствующими тест—кейсами, что обеспечивает полное покрытие аспектов. Если требование состоит из нескольких частей, для каждой из них разрабатываются отдельные тесты. Данный тестовый артефакт является неотъемлемой частью тестирования. Связь двух реестров применима к любым задачам, когда нужно увидеть, как одно соотносится с другим.

Таким образом, мы можем понять, что за задача, к какому проекту она относится и какие в проекте есть фичи. Если мы учитываем по проекту все наши фичи, в том числе планируемые, мы формируем оцифрованный бэклог. А если, наоборот, хочется чего-то “покрепче” – найти много чего про управления требованиями можно еще в стандарте CMMI (Capability Maturity Model Integration), там есть целая процессная область Necessities Administration. Первый тип инструментов, самый простой, – это Ручное тестирование старые добрые матрицы трассировки. Их можно создавать вручную и использовать для этого Excel, Google Doc, Confluence, даже обычную доску с маркером.

Одним из инструментов управления проектами является матрица отслеживания требований (на английском – Requirements Traceability Matrix или просто RTM), вот о ней давайте сегодня и поговорим. Матрица отслеживания требований (RTM-матрица) — это документ, который обычно создается в виде таблицы, позволяющий следить за полным жизненным циклом требований к проекту. Матрица фиксирует именно требования к продукту, с момента постановки цели проекта и его бизнес-требований и вплоть до тест-кейсов. RTM-матрица может использоваться в различных проектах, включая разработку программного обеспечения, системную интеграцию, проекты Agile и т.д. Посмотреть на все многообразие артефактов и понять, обо что больше всего людей спотыкается.

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