Так, сверху вниз мы https://deveducation.com/ можем проследить связи верхнеуровневых требований к самым детальным. И если мы меняем детальное требование, то можем посмотреть, укладывается ли наше новое требование в верхнеуровневые. И, наоборот, когда мы меняем верхнеуровневое требование, через трассировку мы найдём все детальные требования, на которые оно повлияет. Такая трассировка позволяет нам ничего не забыть и не потерять, в противном случае – мы можем получить дефект, когда мы выкатим доработку на прод, и это повлияет на качество нашего продукта. Я внедрял трассировку, структуру документирования и процесс управления требований в трех компаниях. Мы составили реестр бизнес-процессов и начали маппить новые, текущие или берущиеся в работу артефакты на эти бизнес-процессы.
Варианты Связей В Матрице Трассируемости
Во-первых, это простота создания связей, когда вы можете быстро и легко идентифицировать ваш артефакт или требование, и сделать для него якорь, уникальный идентификатор или ссылку на него. К ним относятся Sparx Enterprise Architect, Confluence Atlassian + плагин Requirement Yogi, Jama, IBM Telelogic DOORS, IBM Rational RequisitePro, Техэксперт, и другие. По Requirement Yogi я ранее делал доклад, можно посмотреть его тут. Во-вторых, это, по факту, самый простой способ поверх Confluence наладить трассировку требований. Может показаться, что это больше похоже на декомпозицию задач, чем на трассировку требований, но ведь одно не отменяет другого. Декомпозиция сама по себе подразумевает трассировку от общего к частному.
Нельзя сказать, что надо обязательно начинать с consumer story или с use case. У вас вообще может не быть user story или use case или вы не документируете API. Понять, где находится болевая точка проекта, может только команда проекта. Если до этого вы никогда его не делали, то попробуйте его провести и обсудить, в каких артефактах минимально вы хотели бы навести порядок. У нас бывают проекты, где бизнес-заказчики дают довольно общие запросы на доработку.
Маппинг через трассировку сильно облегчит нам поиск и понимание связей в дальнейшей работе. На самом деле, по статистике, чаще трассируются не сами требования, а проектные артефакты в которых они упоминаются. Через любой трекер задач мы можем видеть проект, дальше от проекта смотрим его фичи, а от фичей смотрим задачи. Это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
- Проект, вообще не покрытый трассировками, лучше проекта, покрытого трассировками наполовину.
- Далее по каждой фиче мы можем посмотреть связанные с ней задачи.
- Если «звездолет» уже есть, но непонятно, как он работает, то надо начинать по кусочкам приводить его в порядок.
Чем наполнить матрицу трассировки, вы решаете сами с проектной командой. Это могут быть use case, замаппленные на тест-кейсы, или бизнес-объекты, замаппленные на use case, или use case на use case. В одном из проектов мы использовали трассировку через матрицу, где бизнес-объекты в мастер-системах были замапплены на бизнес-объекты в слэйв-системах. Таким образом мы видели, какая система мастер по такому-то объекту, а какие системы – слейв по этому объекту.
Далее по каждой фиче мы можем посмотреть связанные с ней задачи. Таким образом, трассировка проектных артефактов позволяет видеть перечень функциональностей и задач, оценить прогресс по проекту. Для больших и комплексных систем, где обойтись просто табличкой нельзя, используется специализированное программное обеспечение, например, RequisitePro, Mantis, JIRA и так далее. Работа в них требует определенных усилий по налаживаю процесса в команде, но обычно оно того стоит, если проект большой.
Матрица Отслеживания Требований Или Requirements Traceability Matrix – Что Это И Зачем Нужно
И если в мастер-компоненте менялся бизнес-объект, мы проверяли, чтобы слэйв-объект не стал неконсистентным. Если у вас маленький проект, где меньше 100 матрица трассируемости артефактов, то смысла тратить время на то, чтобы сделать какие-то связи и трассировки, скорее всего, не будет. Трассировка требований, конечно, не снизит эти трудозатраты до нуля, но она даст понятные инструменты для того, чтобы разобраться в проекте, как провести impression analysis, как не потерять изменения, которые будут проведены.
Был опыт внедрения всеобщей трассировки, когда мы трассировали все на все. Это было довольно трудозатратно, но позволило быстро развить систему до крупного масштаба. То есть, когда у вас с нуля что-то создается, тогда всеобщую трассировку легко можно внедрить. Когда вы понимаете, что через какое-то время у вас будет огромный «звездолет», то лучше заложить подобную трассировку в самом начале. Если «звездолет» уже есть, но непонятно, как он работает, то надо начинать по кусочкам приводить его в порядок. Сейчас у нас век микросервисов, сервисов, компонентно-ориентированных систем.
Если есть трассировка, то он видит все артефакты по бизнес-процессу к которому относится, экранная форма, с какими use case это связано. По трассировке, просто проверив каждый из артефактов, он уже сможет разобраться в бизнес-процессе, и качество его работы на выходе будет гораздо выше. Трассировка будет облегчать работу не только новичкам, но и тем, кто уже давно в проекте, просто потому у вас уже есть четкая структурированная картина.
Первый пример – это когда у нас уже длительное время существует громоздкий бизнес-процесс, мы его постоянно дорабатываем и совершенствуем. Таким образом, мы сразу будем видеть список доработок бизнес-процесса и их статус. Или смотрим на спецификацию и видим, к какому бизнес-процессу относится данная доработка. Всё это кажется очевидным, но когда у вас огромный проект федерального масштаба, команда 300+ человек и сотни спецификаций, то в них довольно легко запутаться. Также может (и должна!) трассироваться история изменений требований, если таковая будет.
На старте разработки руководитель проекта совместно с бизнес-аналитиками определяет, что именно нужно отслеживать в проекте и готовит шаблон документа.
Нельзя сказать, что монолиты уйдут из Разработка программного обеспечения нашей жизни навсегда, но фокус с них смещается на другие варианты архитектуры. В каждом компоненте есть какой-то набор функций, и мы можем эти функции маппировать на компоненты. Это тоже один из вариантов применения связи двух реестров артефактов.
Иначе в какой-то момент таблицы в экселе с тысячей строк просто станут неуправляемыми. Меня зовут Егор Марюшко, я архитектор решений в «Ростелеком Информационные Технологии». Год назад на конференции “Игра в анализ” я подробно рассказывал о значимости и особенностях трассировки требований в проекте. Статья написана по мотивам моего доклада и поможет быстро разобраться в вопросе трассировки требований и внедрении её в повседневную работу.
Эти запросы редко целиком ложатся в одно требование, скорее всего, они развалятся на несколько требований. Точно так же мы маппируем исходные запросы на конечные требования для дальнейшей реализации. Таким образом, заказчик всегда будет понимать, что его запрос покрыт теми или иными требованиями.
