Управление требованиями
Ответственная и качественная разработка требований к ПО требует собственного процесса управления.
Идентификация требований
Уникальный идентификатор требования используется для ссылки на требование, при создании зависимостей или при экспорте и печати документов. По умолчанию Devprom ALM самостоятельно присваивает требованиям идентификаторы вида R-NNN, где NNN - число. Данная идентификация сквозная для всей документации, заведенной в систему. Это гарантирует уникальность идентификатора и позволяет однозначно ссылаться на требование по нему.
Вы можете сформировать собственную схему идентификации артефактов, отличную от той, что используется в системе по умолчанию. Для этого необходимо открыть настройки атрибута "UID" и задать там формулу для вычисления значения по умолчанию.
В качестве формулы для вычисления идентификатора требования необходимо записать выражение по примеру из описания. Вот несколько вариантов пользовательской идентификации требований:
- {Тип требования.Краткое название,R}.{Id} - в начале ИД требования будет указано краткое название его типа, например, СТ.123
- {Тип требования.Краткое название,R}-{IdProject} - Значение поля "IdProject" заполняется автоматическим счетчиком в рамках проекта. В каждом проекте счетчик начинается с 1. Таким образом, вы можете получить такие идентификаторы: БТ-1, СТ-2 и т.п.
- {Тип требования.Краткое название,R}-{IdType} - Значение поля "IdType" заполняется счетчиком для каждого типа требования. Таким образом, вы можете получить такие идентификаторы: БТ-1, СТ-1 и т.п.
- {Тип требования.Краткое название,R}-{IdHierarchy} - Значение поля "IdHierarchy" заполняется счетчиком в рамках иерархии (документа), то есть счетчик будет увеличиваться для каждого следующего дочернего элемента внутри документа.
- {Тип требования.Краткое название,R}-{IdParent} - Значение поля "IdParent" заполняется счетчиком в рамках родительского раздела, то есть счетчик будет увеличиваться для каждого следующего дочернего элемента внутри одного раздела.
Вы можете формировать идентификатор с использованием дополняющих нулей, например, задав выражение {Id,6} система будет формировать идентификатор в виде 000001, 000002 и т.д.
Типы требований
Разные по назначению требования удобно помечать разными типами. В приложении используйте фильтры или группировки для работы над разными типами требований. Каждому типу требований можно сопоставить шаблон по умолчанию. При создании требования он будет использован как заготовка, которую нужно будет заполнить.
| Опция | Назначение |
|---|---|
| Требования реализуются | Используется в схеме "Разработка по требованиям". На основе бизнес-требований не создают задачи на разработку (доработки). Доработки создают на основе функциональных или системных требований. Чтобы не вводить пользователей в заблуждение, для разных типов требований необходимо корректно выставить значения этой опции. |
| Требования тестируются | По аналогии с реализацией требований - не все виды требований участвуют в процессе тестирования. Установите эту опцию для тех требований, по которым нужно рассчитывать процент покрытия тестами. |
| Может быть производным | Между требованиями можно устанавливать причинно-следственные связи. Установите эту опцию, чтобы отличать какие типы требований могут быть исходными (например, бизнес-требования), а какие - производными (например, функциональные требования). |
| Идентификация требований не используется | Некоторые разделы документов требований не являются требованиями по сути, однако, формируют важный контекст, необходимый для понимания остальных требований. Такие разделы могут быть обязательными с точки зрения требований к подготовке документации. Во встроенных процессах для таких требований предназначен тип "Общая информация". Идентификация таких требований не нужна. Например, при выгрузке во внешние форматы у разделов документа не будет добавляться ИД требования. |
| Является заголовком документа |
Данная настройка позволяет управлять визуализацией названия требования в составе документа, а также при выгрузке во внешние форматы. Требования данного типа не будут нумероваться и выделяться заголовочными стилями. Фактически образуется список требований.
|
| Дочерние типы | Вы можете ограничить перечень типов требований, которые могут быть дочерними для данного типа требований. |
| Производные типы | Вы можете ограничить перечень типов требований, которые могут быть производными для данного типа требований. |
Для каждого типа требований могут быть определены свои наборы пользовательских атрибутов.
Жизненный цикл
Требование как проектное решение (в области бизнеса или технической реализации) проходит несколько стадий эволюции - оно разрабатывается (документируется), уточняется (с вовлечением проектировщиков и тестировщиков), согласуется с заказчиком и затем реализуется в программном коде.
В разных проектах или для разных типов требований жизненный цикл может отличаться. Проектная команда настраивает ЖЦ требований для своего проекта самостоятельно. В процессе "Разработка по требованиям" мы уже настроили несколько полезных правил, например:
- Запрет редактирования текста требования после согласования. Чтобы отредактировать текст, требование нужно вернуть на стадию "В работе" и при этом указать источник изменения - исходное пожелание, либо изменившееся бизнес-требование.
- Отметка об устаревании производных артефактов. Чтобы каждое изменение (вплоть до пропущенной запятой) не приводило устареванию тестовой документации (или других производных артефактов), эту операцию выполняем только при переводе требования в состояние "Готово". Таким образом, восстанавливая целостность проектной документации, мы работаем сразу с порциями изменений.
Синхронное (каскадное) изменение состояний родительских или дочерних требований можно использовать для ускорения управления статусами. Например, при согласовании документа достаточно согласовать корневой раздел (заголовок документа), чтобы все его подразделы также отметились как согласованные. Такие синхронные операции настраиваются в ЖЦ требований при помощи соответствующих системных действий. Поскольку эта массовая операция, то пользователь может получить неожиданный результат. Чтобы предупредить пользователя о выполнении таких операций, при добавлении системного действия установите галочку:
Перед выполнением перехода или изменением статуса система предупредит пользователя о выполнении данного системного действия.
Трассировки
Трассировки между требованиями образуются причинно-следственными связями и покрытиями. Трассировки образуются в процесс работы над проектными артефактами. Трассировки можно создавать и редактировать вручную на вкладке "Трассировки".
Трассировки используются для следующих задач:
Контроль полноты
Табличное представление зависимостей между различными типами требований, например, бизнес- и системными требованиями, называется матрицей трассируемости. Этот инструмент позволяет:
- Контролировать целостность разрабатываемого продукта, выявлять расхождения между тем, что требуется и тем, что реализуется.
- Существенно сократить время на анализ изменений, последующих за появлением новой заявки от пользователей.
- Поддерживать производные требования в актуальном состоянии.
Матрица трассируемости позволяет мгновенно получить ответы на вопросы:
- как именно были учтены исходные пожелания, когда они будут реализованы;
- учли ли мы все важные пожелания в очередной версии бизнес-требований или версии продукта;
- откуда появилось бизнес-требование, какая у него важность;
- как будут реализованы бизнес-требования путем изучения системных требований;
- все ли необходимые бизнес-требования отражены в системных требованиях и т.п.
Для настройки фильтрации требований в столбцах Исходные требования или Производные требования, используйте кнопку с точками.
Управление бюджетом
Отчет "Трудозатраты по требованиям" показывает плановые трудозатраты и фактические, предоставляя возможность оценить перерасход бюджета, либо наоборот свободные ресурсы. Плановые трудозатраты (Оценка) указываются для каждого атомарного требования, которое будет реализовываться. Фактические трудозатраты вычисляются приложением на основе задач на разработку, тестирование и других задач.
Значения на красном фоне означают превышение над бюджетом, на зеленом - наличие свободных ресурсов. Используйте отчет для определения возможности изменить требования без пересогласования бюджета.
Вы можете детализировать плановые расходы по требованиям, путем декомпозиции требований на задачи или доработки. В этом случае, в отчете будет представлена разбивка плановых трудозатрат по типам работ.
При использовании модуля "Управление финансами и бюджетом проекта" вы сможете увидеть эту информацию в разрезе стоимости расходов на время, запланированное или затраченное участником проекта. Используйте для этого модуль "Расходы по требованиям".
При создании бейзлайна, система сохраняет значения оценки, затрат и стоимости, таким образом, в режиме сравнения вы можете увидеть изменения (в скобках) по данным показателям между различными версиями документа.
