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

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

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

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

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

Краткость это хорошо, но успех проекта будет зависеть от качества требований. Писать качественные истории нужно научиться. Используйте принципы INVEST, как чек-лист провеки качества разработанных историй.

Не следует путать описание функциональных требования в формате Use Cases и пользовательских требований в формате User Story - это два сильно разных взгляда на требования к ПО. В одной пользовательской истории могут содержаться несколько Use Cases. Пользовательские истории не являются способом структурирования требований к ПО.

Идентификация

Вы можете сформировать собственную схему идентификации артефактов, отличную от той, что используется в системе по умолчанию. Для этого необходимо открыть настройки атрибута "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 и т.д.

Риски разработки ПО на основе пользовательских требований заключаются в том, что:

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

Снизить эти риски поможет практика разработки поддерживающих требований.

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

Почему плохо записывать системные требования непосредственно в самой истории? История пользователя по определению должна быть небольшой. Критерии завершенности и критерии приемки увеличивают ее описание. Системные требования в виде макетов (и детальных требований к ним), алгоритмов и различных моделей, сделают историю очень громоздкой и не удобной в работе. Более того, найти нужные системные требования затем станет просто невозможно, не говоря уже о внесении изменений в них.

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

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

Разработка основанная на требованиях (Requirements driven development, RDD) предполагает явное выделение цикла проектирования, на котором:

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

После цикла проектирования, на основе созданных задач на разработку (доработок) организуется цикл разработки:

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

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

Иногда разработку по требованиям путают с каскадной разработкой (или разработкой по ГОСТ-ам). Объем проектируемых требований (размер инкремента) можно регулировать в соответствии с условиями проекта.

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

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

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

У документарного и спискового представления реестра есть свои плюсы и минусы:

Для выполнения различных задач по документированию и управлению, выбирайте наиболее подходящее представление работы с документами, Devprom ALM поддерживает их все.

Загрузите ваши документы с требованиями в формате MSWord, OpenDocument или Excel. Приложение автоматически разберет их на разделы в соответствии со структурой, заданной в документе. Для разделения документа на требования используется разметка заголовочными стилями (Заголовок 1, Заголовок 2 и т.п.).

Пользовательская разметка документов

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

Например, для преобразования текста, содержащего фразу "Системное требование" в системные требования и сохранении ссылки на эти требования в разделе документа, вы можете разработать такой скрипт:

В результате импорта документа система создаст системные требования, а ссылки на них разместит в документе требований:

Экспорт во внешние форматы

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

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

Для повторного импорта документов, измененных заинтересованными лицами вне системы, используйте опцию выгрузки "Экспортировать исходный код UML-моделей и формул". Таким образом, после импорта эти объекты вновь станут редактируемыми, так как при экспорте они преобразуются в изображения.

Для импорта откройте документ и в меню Действия выберите соответствующий пункт меню.

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

Требования могут быть связаны с другими требованиями или другими проектными артефактами.

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

Связи можно визуализировать на сетевой диаграмме (на вкладке Связи):

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

Шаблоны требований - это типовые заготовки, которые можно использовать при документировании требований. Шаблоны вставляются при указании символа # (решетка). Если шаблон определен как шаблон по умолчанию, то при создании требования будет сразу подставлен этот шаблон. Для разных типов требований можно использовать разные шаблоны по умолчанию. Мы уже включили в типовые процессы несколько распространенных шаблонов, но вы их можете удалить и использовать собственные наработки.

Помимо шаблонов страниц, вы можете формировать шаблоны документов. Например, это может быть типовой документ для создания ТЗ или спецификации по тому образцу, который принят в вашей организации. Для создания шаблона импортируйте вашу заготовку в Devprom ALM или наберите структуру средствами приложения. В меню "Действия" в режиме работы с документом выберите "Создать шаблон". Для создания документа по шаблону используйте кнопки с их названиями:

Повторное использование требований возможно реализовать несколькими способами.

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

Чтобы создать копию документа с требованиями в другом проекте, достаточно выбрать пункт "Дублировать" в меню "Действия" в режиме работы с документом. В реестре требований любой куст или требование можно скопировать (продублировать) в текущий или другой проект при помощи действия "Копировать".

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

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

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

Для проектирования и документирования макетов графического интерфейса пользователя (ГИП или UI) используйте встроенную возможность создания draw.io диаграмм, с использованием библиотеки "Макеты".

Вставьте новую диаграмму:

В перечне библиотек подключите "Макеты" и создавайте проект пользовательских интерфейсов:

Для моделирования технического устройства (дизайна) проектируемой системы используются UML-модели и другие нотации (IE, IDEFx и т.п.). Такие модели могут уточнять функциональные/нефункциональные требования, однако, при значительном количестве элементов, работа с ними становится крайне неудобной. Более того, элементы дизайна могут обладать массой специфических характеристик, которые необходимо записывать, использовать и анализировать.

Для хранения и учета элементов дизайна проектируемой системы используйте модуль "Компоненты". Это иерархическое представление элементов дизайна, таких как логические или технические подсистемы, модули, сущности, объекты и т.п. Справочник "Тип компонента" позволяет сформировать необходимую номенклатуру используемых элементов дизайна. При помощи модуля Настройки - Атрибуты вы можете задать дополнительные пользовательские атрибуты специфичные для отдельных типов компонентов или общие для всех типов компонентов.

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

Вы можете импортировать компоненты из внешних источников, например, Excel. Если в Excel заполнить поле UID, то после импорта сохранится та схема идентификации компонентов, которая была при импорте из Excel.

Трассировка на требования

Связь с исходными требованиями позволяет задокументировать важные требования, предъявляемые к элементам дизайна. Между компонентами и требованиями связь "многие-ко-многим". Связь доработок (историй пользователя) с компонентами позволяет задокументировать влияние реализации этих требований на конкретные компоненты (элементы дизайна) системы.

Диаграммы

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

Диаграмму можно вставить в требование, при помощи модуля "Вставить модуль/отчёт". При этом элементы диаграммы кликабельный и позволяют быстро перейти от требования к конкретному компоненту.

Стоимость

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

Стоимость компонентов, содержащих вложенные (дочерние) компоненты, включает их стоимость.

Идентификация

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

Вы можете сформировать собственную схему идентификации артефактов, отличную от той, что используется в системе по умолчанию. Для этого необходимо открыть настройки атрибута "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 и т.д.

Ответственная и качественная разработка требований к ПО требует собственного процесса управления.

Уникальный идентификатор требования используется для ссылки на требование, при создании зависимостей или при экспорте и печати документов. По умолчанию 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 и т.д.

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

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

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

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

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

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

Перед выполнением перехода или изменением статуса система предупредит пользователя о выполнении данного системного действия.

Трассировки между требованиями образуются причинно-следственными связями и покрытиями. Трассировки образуются в процесс работы над проектными артефактами. Трассировки можно создавать и редактировать вручную на вкладке "Трассировки".

Трассировки используются для следующих задач:

Табличное представление зависимостей между различными типами требований, например, бизнес- и системными требованиями, называется матрицей трассируемости. Этот инструмент позволяет:

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

Матрица трассируемости позволяет мгновенно получить ответы на вопросы:

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

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

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

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

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

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

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

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

При помощи вставки модуля в текст документации можно быстро сформировать таблицу терминов:

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

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

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

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

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

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

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

Шаблон ТЗ по ГОСТ 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 отметит все производные требования (а таких систем может быть с десяток) признаком "Устарело". Все потенциальные нестыковки можно будет учесть и запланировать доработку систем-потребителей под новую версию программного интерфейса (контракта).

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