Требования к системе управления требованиями

06.02.2017 20:19

На просторах интернета периодически появляются статьи, сравнивающие возможности программных инструментов для управления требованиями по разным критериям. Я одно время коллекционировал ссылки на эти статьи, но довольно скоро выяснилось, что они очень быстро утрачивают свежесть. Одни продукты уходят с рынка, другие появляются. «Протухают» сами ссылки, переставая куда-либо ссылаться. Но самое главное: стремительно изменяются представления о том, как должна выглядеть и что должна уметь система управления требованиями (СУТ), и поэтому устаревают критерии оценки, которые когда-то казались актуальными авторам этих статей.

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

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

Перед тем как привести этот перечень верхнеуровневых требований к системе управления требованиями, я должен сделать пару пояснений.

Во-первых, сам термин «управление требованиями» понимается всеми по-разному. Определения, которые даются в разных сводах знаний, довольно расплывчаты и допускают разные толкования. В моём понимании, управлять требованиями можно в узком смысле и в широком.

Управление требованиями в узком смысле относится только к процессу разработки требований. Оно реализуется с помощью версий и вариантов требований, трассировок требований друг на друга, а также «статусов», отражающих жизненный цикл требования в процессе его разработки. Аналитикам обычно хорошо понятна только эта часть управления, а те статусы, которые не относятся напрямую к разработке требований, — это для них только следы процессов, которые находятся вне зоны их контроля.

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

Система управления требованиями должна поддерживать управление и в узком, и в широком смысле. В таблице критериев я разнёс соответствующие возможности по разделам «Разработка требований» и «Управление требованиями».

Во-вторых, на мой взгляд, успех внедрения системы управления требованиями определяется её функциональными возможностями меньше, чем наполовину. Поскольку СУТ влияет практически на все процессы разработки продукта, она затрагивает и интересы всех участников этих процессов. Успех внедрения в большей степени зависит от того, насколько СУТ удовлетворяет эти интересы, а именно:

  • Насколько легко её можно интегрировать с уже внедрёнными в компании системами: базой знаний, трекером задач, системой управления исходным кодом, инструментами тестирования и документирования.

  • Адаптируется ли она под процессы, уже сложившиеся в компании, или, наоборот, требует подстройки или даже ломки процессов под себя.

  • Насколько удобно её использовать людям, использующим требования, а не только разрабатывающим их. Или, другими словами, добавляет им система новой работы или, наоборот, уменьшает её объём.

Если СУТ не соответствует их интересам, то она с большой вероятностью будет отторгнута компанией. Люди просто не станут её использовать.

Эти интересы влияют практически на все ключевые возможности СУТ. Это влияние в таблице отражено в описании возможностей. Часто эти описания пересекаются, особенно когда речь идёт об интеграции с другими системами. Те возможности, которые можно описательно отделить от остальных, вынесены в отдельный раздел таблицы — «Приживаемость системы».

А вот и сама таблица.

Возможность

Описание

Разработка требований

Декомпозиция требований

СУТ должна обеспечивать лёгкое разбиение сложных требований на составные части до атомарных требований, с возможностью их «обратной сборки» в сводные требования. При этом все функции управления требованиями должны быть применимы к этим атомарным требованиям.

Лёгкость разбиения в данном случае является ключевой особенностью. В идеале у аналитика, разрабатывающего требования, должна быть возможность сделать атомарным требованием любой фрагмент текста «в один клик», не отвлекаясь при этом на оформление дополнительных атрибутов.

Типизация и шаблонизация требований

СУТ должна обеспечивать возможность создания требований различных типов из настраиваемых шаблонов. Для этого в ней должны быть реализованы:

  • классификация типов требований;

  • управление шаблонами требований (настройка шаблонов для каждого типа требований).

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

Классификация требований

СУТ должна обеспечивать классификацию требований по различным настраиваемым классификационным признакам, а также поиск и отбор требований по этим признакам.

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

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

Трассировка требований друг на друга

СУТ должна поддерживать связи между требованиями. Должен поддерживаться настраиваемый набор видов связей.

Например: связывание бизнес-требований с функциональными требованиями, связывание влияющих друг на друга функциональных требований.

Наиболее очевидный вид связи — между родительскими и дочерними требованиями. В зависимости от особенностей продукта, могут потребоваться связи других видов.

Графическое моделирование требований

СУТ должна поддерживать возможность разработки требований в виде визуальных моделей (например, моделей UML и моделей бизнес-процессов).

Эта возможность может обеспечиваться интегрированной поддержкой средств моделирования или включением моделей в тексты требований. При этом к графическим моделям должны быть применимы все возможности разработки и управления требованиями.

Согласование требований с клиентами

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

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

Хранение первичных документов с требованиями

СУТ должна поддерживать хранение документов, являющихся источниками требований (например, полученные от заказчика), и обеспечивать лёгкий доступ к ним.

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

Экспорт сводных документов требований

СУТ должна поддерживать экспорт наборов требований, отобранных по различным критериям, в виде файлов, основанных на шаблонах.

Эта возможность необходима в тех случаях, когда стандарты разработки требуют создания таких документов (например, если процесс должен соответствовать ГОСТу), или если на определённых этапах создания продукта требования должны быть представлены в виде сводных документов — например, как приложения к договорам.

Управление требованиями

Версионирование требований

СУТ должна поддерживать ведение версий каждого отдельного требования.

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

Варианты требований

СУТ должна поддерживать ведение нескольких вариантов отдельных требований.

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

Управление статусами требований

В СУТ должен быть реализован настраиваемый набор статусов требований, отражающий их жизненный цикл в рамках бизнес-процессов компании. Должна быть возможность управления жизненным циклом как требования в целом, так и конкретной версии требования.

Например, нужно отслеживать статусы: готовности требований, согласования, реализации, документирования и т. п.

Если в компании используются автоматизированные инструменты для управления этими процессами, то эта возможность реализуется в рамках интеграции с этими инструментами.

Трассировка требований на рабочие продукты

СУТ должна обеспечивать связь требований с рабочими продуктами процессов разработки. Для этого СУТ должна поддерживать интеграцию с инструментами управления этими рабочими продуктами.

Под рабочими продуктами, в частности, понимаются:

  • исходный код

  • рабочие продукты тестирования — тесты, тестовые планы и т. п.

  • документация

Управление задачами, связанными с требованиями

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

В частности, это нужно для таких видов задач: разработка и согласование требований, работы по реализации, тестированию, исправлению ошибок, выпуску релизов, версий и других видов поставок.

Управление базовыми линиями (baseline) требований

СУТ должна поддерживать управление базовыми линиями требований. Должна быть возможность отнесения к выбранной базовой линии конкретных версий отдельных требований, в том числе с использованием групповых операций. Кроме того, для управления базовыми линиями в СУТ должны быть реализованы отчёты, позволяющие оценивать состояние базовых линий по различным критериям.

Базовые линии (aka срезы) могут использоваться для планирования и фиксации требований к различным видам поставок (релизам, сборкам, версиям, патчам и т. п.).

Приживаемость системы

Удалённый многоплатформенный доступ

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

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

Интеграция с используемыми в компании инструментами

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

Интеграция предполагает настраиваемый автоматический двусторонний обмен данными с этими инструментами.

 



Автор статьи


Григорий Печёнкин

Партнёры и друзья



Продолжая использовать этот сайт, вы даете согласие на обработку файлов cookie, пользовательских данных (включая сведения о местоположении, тип и версия ОС, тип и версия браузера, тип устройства и разрешение его экрана, источник откуда пришел на сайт пользователь, с какого сайта или по какой рекламе, язык ОС и Браузера, какие страницы открывает и на какие кнопки нажимает пользователь, IP-адрес). Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте сайт. Вы можете узнать, как используются эти данные, ознакомившись с Политикой конфиденциальности.
Ясно, больше не показывать это сообщение