Меня зовут Егор Марюшко, я архитектор решений в «Ростелеком Информационные Технологии». Год назад на конференции "Игра в анализ" я подробно рассказывал о значимости и особенностях трассировки требований в проекте. Статья написана по мотивам моего доклада и поможет быстро разобраться в вопросе трассировки требований и внедрении её в повседневную работу. Послушать и посмотреть сам доклад можно тут.
Немного о себе: в IT с 2014 года, был в роли бизнес-эксперта, бизнес- и системного аналитика, руководителя отделов бизнес- и системного анализа, архитектора решений, преподаю курсы по бизнес и системному-анализу. Веду телеграм-канал "Образование по BA, SA, Архитектуре" (BA_SA_Arch_edu).
Что же такое трассировка требований?
Трассировка требований – это способность соотнести какой-либо элемент проекта с другим связанным с проектом элементом, особенно с тем, который имеет отношение к техническим требованиям проекта. Это официальное определение из RUP (Rational Unified Process).
Зачем нужна трассировка требований в проекте?
Цели трассировки требований – это:
повышение качества анализа влияния изменений на продукт, так называемый impact analysis;
повышение качества самого продукта за счёт того, что мы понимаем взаимосвязи и как изменения влияют на продукт;
сокращение трудозатрат.
Какие есть типы трассировки требований?
Первый тип трассировки – вертикальная, т.е. от общего/главного к частному/детальному. Это принцип иерархии, когда наверху есть главные бизнес-цели проекта, ниже – бизнес-правила, пользовательские требования, варианты использования (use case), системные требования. Так, сверху вниз мы можем проследить связи верхнеуровневых требований к самым детальным. И если мы меняем детальное требование, то можем посмотреть, укладывается ли наше новое требование в верхнеуровневые. И, наоборот, когда мы меняем верхнеуровневое требование, через трассировку мы найдём все детальные требования, на которые оно повлияет. Такая трассировка позволяет нам ничего не забыть и не потерять, в противном случае – мы можем получить дефект, когда мы выкатим доработку на прод, и это повлияет на качество нашего продукта.
Второй тип трассировки – горизонтальная, или кроссовая трассировка, когда мы делаем связи одного уровня. Это пример соцсети, когда через соцсети наши друзья все друг с другом так или иначе связаны. Например если в документации у нас много use case, то они могут пересекаться друг с другом, и быть связаны. Когда мы меняем один use case, благодаря кроссовой трассировке мы можем найти, какие другие use case поменяются у нас в проекте, таким образом отследить влияние на них и учесть в них изменения.
Что можно трассировать?
На самом деле, по статистике, чаще трассируются не сами требования, а проектные артефакты в которых они упоминаются. Через любой трекер задач мы можем видеть проект, дальше от проекта смотрим его фичи, а от фичей смотрим задачи. Это тоже трассировка.
Таким образом, мы можем понять, что за задача, к какому проекту она относится и какие в проекте есть фичи. Если мы учитываем по проекту все наши фичи, в том числе планируемые, мы формируем оцифрованный бэклог.
Далее по каждой фиче мы можем посмотреть связанные с ней задачи. Таким образом, трассировка проектных артефактов позволяет видеть перечень функциональностей и задач, оценить прогресс по проекту.
Может показаться, что это больше похоже на декомпозицию задач, чем на трассировку требований, но ведь одно не отменяет другого. Декомпозиция сама по себе подразумевает трассировку от общего к частному.
Рассмотрим ещё один пример, который больше относится к аналитике и непосредственно к требованиям. Основная его идея – связь двух реестров требований, когда есть артефакты первого реестра и артефакты второго реестра и нужно сделать между ними маппинг. Маппинг через трассировку сильно облегчит нам поиск и понимание связей в дальнейшей работе.
Где можно применить маппинг (трассировку) двух реестров?
Первый пример – это когда у нас уже длительное время существует громоздкий бизнес-процесс, мы его постоянно дорабатываем и совершенствуем. Чтобы увидеть, какие доработки уже были сделаны по данному бизнес-процессу, какие планируются, а какие уже в работе, мы можем взять артефакты, концептуальные решения, технические задания, спецификации, описывающие его доработки и связать их с этим бизнес-процессом. Таким образом, мы сразу будем видеть список доработок бизнес-процесса и их статус. Или смотрим на спецификацию и видим, к какому бизнес-процессу относится данная доработка. Всё это кажется очевидным, но когда у вас огромный проект федерального масштаба, команда 300+ человек и сотни спецификаций, то в них довольно легко запутаться.
Второй пример – это запросы и сами требования. У нас бывают проекты, где бизнес-заказчики дают довольно общие запросы на доработку. Эти запросы редко целиком ложатся в одно требование, скорее всего, они развалятся на несколько требований. Точно так же мы маппируем исходные запросы на конечные требования для дальнейшей реализации. Таким образом, заказчик всегда будет понимать, что его запрос покрыт теми или иными требованиями. А команда разработки понимает из какого запроса родилось это требование.
Третий пример – это функции и компоненты. Сейчас у нас век микросервисов, сервисов, компонентно-ориентированных систем. Нельзя сказать, что монолиты уйдут из нашей жизни навсегда, но фокус с них смещается на другие варианты архитектуры. В каждом компоненте есть какой-то набор функций, и мы можем эти функции маппировать на компоненты. Это тоже один из вариантов применения связи двух реестров артефактов.
Связь двух реестров применима к любым задачам, когда нужно увидеть, как одно соотносится с другим.
Четвёртый пример (самый хардкорный подход к трассировке требований) – это когда мы уже не ограничиваемся двумя реестрами, а делаем связь всех возможных требований и стараемся покрыть наш продукт или проект связями максимально детально.
Это довольно трудоемко, но мы гарантированно будем понимать, как существует и работает наша информационная система с точки зрения требований.
Use case (вариант использования, пользовательский сценарий), как показала практика, одна из центральных единиц в требованиях, относительно которой можно залинковать все остальное: бизнес-объекты, мокапы, через которые этот use case реализован, печатные формы, которые используются в рамках use case, атомарные user story, бизнес-правила. Можно маппировать use case и API интерфейсы через которые идет обращение к бэку. Можно маппировать бизнес-объекты на системную модель базы данных – какие есть таблицы и атрибуты. Простор для творчества безграничен. Вопрос только в трудозатратах и дадут ли вам время на то, чтобы всё это делать.
С чего начинать внедрять трассировку требований?
Я внедрял трассировку, структуру документирования и процесс управления требований в трех компаниях. Всегда нужно начинать с того, что вызывает самую большую боль. В одном из проектов самую большую боль у нас вызывала ситуация, где был список бизнес-процессов и тысячи спецификаций, и мы не понимали, какие спецификации модифицируют этот бизнес-процесс, на основе чего мы вообще этот бизнес-процесс реализован. Мы составили реестр бизнес-процессов и начали маппить новые, текущие или берущиеся в работу артефакты на эти бизнес-процессы.
Был опыт внедрения всеобщей трассировки, когда мы трассировали все на все. Это было довольно трудозатратно, но позволило быстро развить систему до крупного масштаба. Надо учесть, что система создавалась с нуля. То есть, когда у вас с нуля что-то создается, тогда всеобщую трассировку легко можно внедрить. Когда вы понимаете, что через какое-то время у вас будет огромный «звездолет», то лучше заложить подобную трассировку в самом начале. Если «звездолет» уже есть, но непонятно, как он работает, то надо начинать по кусочкам приводить его в порядок.
Каким образом в уже имеющемся «звездолете» проводить трассировку: снизу от артефактов или сверху от бизнес-процессов?
Нужно идти от проблемы. Посмотреть на все многообразие артефактов и понять, обо что больше всего людей спотыкается. Нельзя сказать, что надо обязательно начинать с user story или с use case. У вас вообще может не быть user story или use case или вы не документируете API. Понять, где находится болевая точка проекта, может только команда проекта. Для выявления таких точек очень хорошо помогает ретро. Если до этого вы никогда его не делали, то попробуйте его провести и обсудить, в каких артефактах минимально вы хотели бы навести порядок.
Когда начинать внедрять трассировку требований?
Ниже приведен график, на котором синим показан проект без трассировки требований, а красным показана кривая, где есть трассировка требований, и отмечена граница – примерно 100 артефактов в проекте.
Если у вас маленький проект, где меньше 100 артефактов, то смысла тратить время на то, чтобы сделать какие-то связи и трассировки, скорее всего, не будет. Но как только ваш проект начинает разрастаться, и в нём сотни, тысячи требований и артефактов, то трудозатраты на то, чтобы найти нужный артефакт, провести impact analysis, разобраться в проекте будут расти экспоненциально. Трассировка требований, конечно, не снизит эти трудозатраты до нуля, но она даст понятные инструменты для того, чтобы разобраться в проекте, как провести impact analysis, как не потерять изменения, которые будут проведены.
Представим, что мы даем новичку задачу, нужно на такой-то форме добавить такой-то атрибут. Где ему искать информацию? Если есть трассировка, то он видит все артефакты по бизнес-процессу к которому относится, экранная форма, с какими use case это связано. По трассировке, просто проверив каждый из артефактов, он уже сможет разобраться в бизнес-процессе, и качество его работы на выходе будет гораздо выше. Трассировка будет облегчать работу не только новичкам, но и тем, кто уже давно в проекте, просто потому у вас уже есть четкая структурированная картина.
Какие бывают инструменты для трассировки требований и артефактов?
Первый тип инструментов, самый простой, – это старые добрые матрицы трассировки. Их можно создавать вручную и использовать для этого Excel, Google Doc, Confluence, даже обычную доску с маркером.
Это, конечно, будет требовать ручной работы, но важно сделать первый шаг к наведению порядка и упрощению вашей жизни.
Чем наполнить матрицу трассировки, вы решаете сами с проектной командой. Это могут быть use case, замаппленные на тест-кейсы, или бизнес-объекты, замаппленные на use case, или use case на use case. В одном из проектов мы использовали трассировку через матрицу, где бизнес-объекты в мастер-системах были замапплены на бизнес-объекты в слэйв-системах. Таким образом мы видели, какая система мастер по такому-то объекту, а какие системы - слейв по этому объекту. И если в мастер-компоненте менялся бизнес-объект, мы проверяли, чтобы слэйв-объект не стал неконсистентным.
Второй тип инструментов – это системы управления требованиями (СУТ). Их все можно разделить на две категории:
1. Специализированное программное обеспечение. К ним относятся Sparx Enterprise Architect, Confluence Atlassian + плагин Requirement Yogi, Jama, IBM Telelogic DOORS, IBM Rational RequisitePro, Техэксперт, и другие. Они заточены под то, чтобы делать трассировку требований. По Requirement Yogi я ранее делал доклад, можно посмотреть его тут. Во-вторых, это, по факту, самый простой способ поверх Confluence наладить трассировку требований.
2. Любое программное обеспечение, которое используют в качестве систем управления требованиями. Это и Jira, потому что она позволяет линковать различные артефакты, и Redmine, и Confluence Atlassian через метки страниц, и Google таблицы. Можно много всего адаптировать в качестве системы управления требованиями, к тому же сделать это быстро и просто.
Что является залогом успешного применения трассировки требований?
Во-первых, это простота создания связей, когда вы можете быстро и легко идентифицировать ваш артефакт или требование, и сделать для него якорь, уникальный идентификатор или ссылку на него.
Во-вторых, это визуализация и построение отчетов по связям, когда система управления требованиями и инструменты трассировки позволяют быстро и легко строить матрицу трассировок. Просмотр связей в этих таблицах это и есть impact analysis.
В-третьих, это обязательность создания связи. Только неотвратимость трассировки делает ее хорошим инструментом. Трассировка требований должна обязательно быть включена в какой-либо нормоконтроль или согласование. Потому что как только это становится необязательным, оно перестает работать. Проект, вообще не покрытый трассировками, лучше проекта, покрытого трассировками наполовину.
Надеюсь, мой опыт будет вам полезен! До встреч в следующей статье!