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

Возможность

Описание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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