Привет, Хабр! Меня зовут Таня Маркина, я руковожу аналитиками на продукте MaxPatrol SIEM в Positive Technologies. В 2023 году, еще до работы в Positive Technologies, я исследовала разные системы управления требованиями (СУТ), чтобы выбрать лучший вариант и обосновать его покупку своим руководителям.
В этой статье расскажу, какие существуют системы управления требованиями, чем они друг от друга отличаются и какие из них самые удобные.
Не каждый инструмент можно считать СУТ
Для начала хочется сказать, что полноценная система управления требованиями должна позволять:
создавать требования,
анализировать требования,
управлять изменениями требований,
осуществлять трассировку требований,
выдавать гибкую отчетность под разные проекты.
К примеру, знакомые многим Jira и Confluence нельзя считать СУТ, потому что они изначально созданы под другие задачи.
Большинство (80%) опрошенных аналитиков хотели бы внедрить СУТ в свою работу
Параллельно с тестированием демок я опросила 100 коллег в чатах и среди знакомых (все они работают в разных компаниях), чтобы узнать их опыт использования СУТ и задать интересующие меня вопросы. Вот что показал опрос.
Оказалось, больше половины опрошенных знают, что такое система управления требованиями. Если бы я не обговаривала сразу, что Jira и Confluence мы не считаем системами управления требованиями в чистом виде, процент был бы больше.
Еще выяснилось, что почти никто не использует такие системы в работе — по разным причинам. По факту все идут своим путем: это подтверждает то, что на каждой конференции мы встречаем доклад на тему «Как мы организовывали написание требований в своей компании». Непопулярность использования СУТ также подтверждает количество и актуальность статей на эту тему. Почему-то про это не пишут. Значит, видимо, и не используют.
Радует, что большинство аналитиков после знакомства с какой-нибудь системой управления требованиями считают, что ее стоит использовать.
Сравнение инструментов
В конце прошлого года я закончила исследовать различные инструменты. Ниже представлены логотипы инструментов, которые я рассматривала. Возможно, какие-то из них вам уже знакомы.
Для удобства сравнения я выбрала 17 показателей и разделила их на четыре группы:
основные требования,
интеграция с сервисами,
удобство,
дополнительные требования.
Основные требования. Одна из основных задач аналитика — написание требований. Соответственно, в первую очередь я проверяла возможность написания технических требований, пользовательских историй, связь ТТ с US.
Интеграция с сервисами. Так как аналитики — не единственная команда, которая работает с документацией, интеграция с софтом и инфраструктурой рабочих инструментов других команд очень важна. Иначе тестировщики, разработчики и другие коллеги просто не смогут полноценно пользоваться документацией.
Я проверяла интеграцию инструментов с четырьмя сервисами:
Jira. Рассматривала ее как инструмент хранения задач для разработки, потому что на момент исследования это был рабочий инструмент в моей компании. Кроме того, Jira по сей день является самой популярной программой для ведения задач разработчиков.
EA. Выбрала как сервис хранения архитектуры, потому что его знают почти все.
Allure и Figma. Выбрала их потому, что если есть интеграция с этими продуктами, то с чуть менее известными она проходит достаточно легко.
Еще я смотрела на интеграцию с сервисами хранения менеджерских задач, но в ходе исследования поняла, что ни с одним софтом СУТ не интегрируется.
Удобство. Аналитики по восемь часов в день пишут требования, должна же быть какая-то красота в нашей работе? Хочется, чтобы инструмент был визуально приятным и интуитивно понятным. Поэтому я оценивала интерфейс.
Также считаю важным, когда у сервиса есть обучающие видеоролики и техподдержка, которая ответит на вопросы при возникновении сложностей. Не хочется самостоятельно гуглить и разбираться, как пользовался системой. Поэтому смотрела на их наличие тоже.
Дополнительные требования. В ходе исследования добавилась еще одна группа показателей — это три важные фичи, которые я не учла на старте, но встретила в процессе исследования в некоторых инструментах: песочницы, импорт из Excel и свой тестовый модуль.
Получилась вот такая сравнительная таблица.
Показатель | Jama | Visure Solutions | Reqview | Devprom | Техэксперт | Notion | SparX EA | DOORS NG | rmToo | Xuse | SILA UNION | Casecomplete | Q.REQUIREMENTS | |
Интеграция с Jira (Хранение задач на разработку) | + | + | + | -3 | ? | -1 | -2 | + | + | - | - | ? | + | ? |
Интеграция с EA (Хранение архитектуры) | + | + | + | - | ? | - | + | - | - | - | - | + | ? | ? |
Интеграция с Allure (Тестирование) | - | + | - | - | - | - | - | - | - | - | - | - | - | - |
Интеграция с Figma (Дизайн) | - | - | - | - | - | - | - | - | + | - | - | - | - | - |
Технические требования (ТТ) | + | + | + | + | + | + | + | + | + | + | + | + | + | + |
User story (US) | + | + | + | + | + | + | + | + | + | + | + | + | + | + |
Связь ТТ с US | + | + | + | + | + | + | + | + | + | + | + | + | + | + |
Трассировка требований | + | + | - | + | + | + | + | + | - | - | - | - | - | + |
Песочница | + | + | + | - | - | - | + | + | - | - | - | - | + | - |
Импорт из Excel | + | + | + | + | - | + | + | + | + | - | + | + | + | - |
Тестовый модуль (написание тестов и тест-планов) | + | - | + | - | - | + | + | - | - | - | - | ? | + | - |
Trial версия | + | + | + | Демо со специалистами | + | - | + | - | - | - | - | Демо со специалистами | + | + |
Качественный интерфейс | + | + | + | + | + | + | + | + | - | - | - | - | - | + |
Обучение работе с продуктом | + | + | - | + | + | + | + | + | - | - | - | - | - | - |
Jama, Visure, ReqView — лучшие зарубежные СУТ
Проанализировав таблицу выше, я отобрала тройку лучших сервисов. Мой краш, конечно, — Jama.
Jama. Если человек попробовал этот софт, все остальное меркнет. Сервис продуман до мелочей: настолько, что можно даже вставлять изображения и выбирать предметную область, в которой работаешь. Например, разработка продуктов в автомобильной промышленности требует автомобильного программного обеспечения. Jama Connect для автомобильной промышленности создан с учетом ключевых инфраструктур, которые поддерживают критически важные стандарты и правила безопасности при разработке автомобильной продукции, сертифицирован по стандарту ISO 26262.
Еще у Jama отличный интерфейс. Все как мы любим — цветное, понятное и структурированное. Сами посмотрите. Ниже приведены скриншоты интерфейса Jama (источник).
Я пользовалась только пробной версией, но мне удалось пообщаться с коллегами из «Автомотив», которые использовали Jama в своей работе. У них количество технических требований переваливает не за сотни и даже не за сотни тысяч, а за миллионы, но сервис отлично справляется. Еще круто, что благодаря возможности интеграции и удобству интерфейса разработчики любят читать требования.
Если вдруг кто-то в России захочет сделать аналогичный софт, то это явно то, на что надо равняться. Мне кажется, сервис не оставит равнодушным никого.
Visure. Он попроще и с точки зрения удобства уступает Jama, но в целом конкурентоспособен.
С помощью Visure можно создавать и редактировать требования и управлять ими. Можно легко экспортировать требования в Word и Excel.
Помимо управления требованиями, Visure позволяет управлять тестированием, отслеживать дефекты и проблемы, управлять изменениями и рисками. Он обеспечивает управление конфигурацией, отслеживание версий, базовую структуру для всех артефактов и позволяет инженерным командам получить полную сквозную прослеживаемость в рамках нескольких проектов.
Еще есть возможность прослеживать исходный код до требований и функциональности, отслеживать компоненты по проектам или историю изменений, а также требования безопасности, созданные для снижения конкретных факторов высокого риска.
Кроме того, с помощью Visure можно в режиме реального времени получить доступ к панели отслеживания, чтобы увидеть процент элементов, которые отслеживаются или не отслеживаются. Это позволит обеспечить прослеживаемость на любом уровне, от высокоуровневых требований заказчика до требований к программному, аппаратному и механическому обеспечению, а также рисков и испытаний.
Сквозная прослеживаемость позволяет ускорить вывод продукции на рынок и снизить затраты на проверку и разработку. Это необходимая платформа для инженерных команд, создающих сложные продукты и системы в «тяжелых» регулируемых отраслях. Взгляните на интерфейс Visure (источник).
ReqView. Одно из ключевых преимуществ ReqView — надежные функции отслеживания. Пользователи могут устанавливать связи между различными требованиями, создавая родительско-дочерние отношения и зависимости. Это упрощает отслеживание того, как изменения одного требования могут повлиять на другие, обеспечивая лучший контроль за объемом проекта.
ReqView обеспечивает гибкость настройки атрибутов и шаблонов, используемых для документации требований. Это позволяет организациям адаптировать инструмент к своим конкретным процессам и шаблонам сбора требований.
Еще круто, что ReqView позволяет нескольким членам команды одновременно работать над документами требований в режиме реального времени.
Devprom и «Техэксперт» — достойные российские аналоги
В отличие от зарубежных сервисов лицензию на использование этих инструментов можно приобрести.
Devprom. Программа позволяет совместно создавать полноценные требования из браузера, документировать UML-модели, формулы и алгоритмы, просматривать изменения в моделях и формулах.
Софт отличается удобной работой с реестром требований: обсуждение, рецензирование и согласование требований в команде. Также он позволяет быстро и просто поставить задачи разработчикам и тестировщикам.
Что касается аспектов работы с требованиями, у Devrom есть версионирование требований и бейзлайны, трассировка требований на проектные артефакты, загрузка и выгрузка требований в форматах Word, Open Document, HTML, PDF, Excel с использованием пользовательских шаблонов.
Есть полностью настраиваемый процесс работы над требованиями, расширяемая модель данных, присутствует сбор и визуализация метрик для анализа проблем и повышения продуктивности. Судите сами (источник интерфейса Devrom):
«Техэксперт». Для меня сервис стал неким открытием. Он позволяет создавать требования из нормативных документов, технических заданий и других технических документов. В системе автоматизирована работа специалистов по согласованию и утверждению требований. Есть много функций по работе с требованиями:
установка связей и трассировки между требованиями,
установка зависимостей,
автоматический контроль актуальности,
управление изменениями требований
создание редакций (ревизий), классификация, обсуждение и согласование.
Объединение требований в единую иерархическую структуру позволяет получить полную картину изделия или процесса. Структурирование требований по уровням существенно улучшает понимание конечной цели, повышает взаимодействие участников разработки, помогает избежать дублирования работ.
Многопользовательская работа с требованиями позволяет проводить обсуждения с экспертами, руководителями, заказчиками, согласовывать и утверждать требования, распределять задачи между исполнителями.
Отслеживание изменений в требованиях, установка прямой связи между требованием и документом-основанием, а также ежедневная автоматическая актуализация позволяют отследить малейшие изменения и своевременно принять необходимые меры.
Программа позволяет формировать отчетность и искать похожие требования. Помимо всего сказанного, есть еще и API для взаимодействия со сторонними системами (CAD, PLM и другими). Есть и недостатки, например, экспорт данных возможен только в формате ReqIF.
Альтернативы СУТ
Если руководители в вашей компании пока не видят необходимости приобретать СУТ, но при дальнейшем росте продукта это, возможно, потребуется, можно уже на начальном этапе воспользоваться сервисами, описанными ниже. В дальнейшем это упростит переход на систему управления требованиями.
Плагин Requirements Yogi для Confluence. Возможно, вы про него слышали или уже используете. Плагин хорош для описания фич, позволяет отслеживать изменения фич, понимать продукт в целом, делать baseline-требования. Если продукт сложный и многослойный, то этот плагин тоже удобно использовать.
Однако Confluence не выдержит описаний всех технических и функциональных требований для продукта.
Если у вас вдруг куплен такой плагин, в любом случае советую его попробовать. У него также есть демоверсия.
Excel. На моем предыдущем месте работы мы использовали старый добрый Excel, потому что он выдерживает эти «стопятьсот» миллионов строк. Он реально их выдерживает.
Но это не единственный его плюс. У Excel также есть отсылки к пользовательским требованиям, к документам архитектуры, фичам и техническим требованиям, а также к тестированию. Поэтому все команды участвовали в заполнении этих документов. Еще круто, что разные ресурсы-«шары» поддерживают многопользовательское изменение документов этого типа.
Мы не придумывали свой шаблон — основывались на шаблонах лучших СУТ. Использовали идентификатор требования, версию требования, описание. Они были уже более детализированы, с отсылками к пользовательским кейсам, планированию (у нас было квартальное планирование PI). Каждая фича велась в отдельном файле, который мы называли воркбуком.
Использование Excel помогло оптимизировать написание требований и сократить отставание от разработки с шести месяцев до двух.
Также считаю важным добавить, что иногда можно обойтись без СУТ. Например, в случае с MVP достаточно написать краткие требования, выпустить продукт на рынок и посмотреть, нужен ли он кому-то.
Главное
Полноценная система управления требованиями должна позволять создавать и анализировать требования, управлять изменениями требований, осуществлять их трассировку, выдавать отчетность, которая зависит от проекта.
Jama, Visure, Reqview — лучшие СУТ по результатам исследования.
Devprom и «Техэксперт» — достойные российские аналоги.
Помимо СУТ можно использовать плагин Requirements Yogi для Confluence или старый добрый Excel.
Иногда можно обойтись без СУТ. Например, при создании MVP.
Приглашаем вас на митап позитивных аналитиков.
Он пройдет 20 июня с 19:00 до 22:00 в Санкт-Петербурге по адресу: улица Казанская, 7, пространство FREEDOM. Вас ждут три доклада:
● Есть ли место системному аналитику в аджайле.
● От аналитика к менеджеру. Когда нам точно туда надо.
● Что ждут от аналитика в ИБ.
Еще будут настолки, фуршет и общение с единомышленниками. Участие бесплатное. Регистрируйтесь и приходите!
Татьяна Маркина
Руководитель группы проектирования систем контроля защищенности, Positive Technologies
