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