Devprom ALM: Руководство пользователя

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

Мы собираем и делимся с вами лучшими практикам по созданию проектной документации и документированию требований в частности.

Условно, всех подходы можно разделить на две большие группы:

• все в одном документе;
• разные документы для разных целей;

Этот подход хорошо известен под названием "Техническое задание" (сокращенно ТЗ). Основное его преимущество в том, что мы пишем один документ, затем его печатаем, а затем согласуем и подписываем с заказчиком. Для этих целей это удобно - все что нужно в одном документе, он проверяется на целостность, непротиворечивость, полноту и т.п.

Проблема однако в том, что не существует одного формата создания ТЗ (или ЧТЗ). Для разных классов программных продуктов или программно-аппаратных систем сообществом разработано несколько вариантов. На уровне государственного регулирования также существует несколько стандартов документирования технических заданий. При разработке больших систем функциональности становится так много, что работать с одним только ТЗ становится крайне неудобно.

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

Шаблон ТЗ по ГОСТ 34 вы можете найти внутри проекта, созданного по шаблону "Водопад".

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

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

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

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

Для описания бизнес-требований вербально (текстом) наилучшим образом подходят такие документы как Business Requirements Document (BRD) или Бизнес-кейс. Как правило, в таких документах содержится описание бизнес-процессов, их временных характеристик, передачу или преобразование рабочих продуктов, задействованные роли и описание причинно-следственных связей.

Альтернативным вариантом описания таких требований является использование языков моделирования, например BPMN, IDEF и т.п.

Хорошей практикой является трассировка бизнес-требований (или системных требований) к целям, для достижения которых и необходимо реализовывать эти требования. Информация о целях может содержаться в документах, в одном из разделов. Однако, в Devprom ALM для этого лучше использовать дерево функций, где не верхнем уровне располагаются бизнес-цели, а на нижних - крупные функции системы, бизнес-функции или фичи продукта.

Фреймворк Rational Unified Process предлагает форму для записи системных требований (функциональных и нефункциональных) в виде спецификации, так называемый SRS:

Храните варианты использовать по каждой подсистеме в отдельном документе. Если варианты использования (Use Cases) сложны и объемны, декомпозируйте их на составные части (слайсы, расширения, альтернативные сценарии).

Низкоуровневые требования (системную архитектуру, дизайн) удобно записываться в формате "4+1" предложенной Филиппом Кратченом, либо аналогично в формате SAD (Software Architecture Document, RUP).

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

Например, в одном документе мы можем собрать функциональные требования (в формате Варианта использования), а также требования к дизайну, то есть системные требования (в формате UML-модели):

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

Чтобы ошибка не дошла до тестирования вообще, могут помочь системные требования, связанные таким образом, что требование к поддержанию контракта со стороны потребителя, будет являться производным от требования, описывающего данный контракт (система-поставщик контракта). В этом случае, при модификации требования к контракту, Devprom ALM отметит все производные требования (а таких систем может быть с десяток) признаком "Устарело". Все потенциальные нестыковки можно будет учесть и запланировать доработку систем-потребителей под новую версию программного интерфейса (контракта).

И, конечно же, такие требования могут быть размещены в разных проектах.