Форматы документирования

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

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

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

Бизнес-требования

Файлы, полученные из внешних источников (регламенты, законы, переписка и т.п.)

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

Требования, записанные в форме бизнес-моделей, например, с использованием нотации BPMN.

Системные требования

Техническое задание - документ, содержащий требования разного типа и текст общего характера.

Спецификация - документ, содержащий требования одного типа, касающиеся одной подсистемы.

Use Cases (или варианты использования) - требование записано определенным образом, описывающим взаимодействия с системой.

UML-модели - требования к информационным, структурным и поведенческим аспектам системы, записанные на общеизвестном языке моделирования.

Макеты UI - требования к пользовательскому интерфейсу.

Схемы работы с требованиями

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

Пользовательские истории

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

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

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

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

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

Поддерживающие требования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Документы и реестр

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

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

Плюсы Минусы
Документ требований

На одном экране видны связанные друг с другом разделы документа.

Цельное описание задачи.

Можно выставлять/контролировать требования к полноте, непротиворечивости.

Удобно согласовывать.

Можно версионировать и создавать бейзлайны.

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

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

Реестр (список) требований

Нет избытка информации (текста требований) при работе с атрибутами или связями требований.

Можно быстро выполнять массовые операции: оценка, реализация.

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

На произвольном наборе требований невозможно проверить полноту непротиворечивость и целостность документации и продукта.

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

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

Импорт/экспорт и печать

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

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

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

Проектные конфигурации

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

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

Виды связей

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

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

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

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

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

Типы требований

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

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

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

Шаблоны

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

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