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) предполагает явное выделение цикла проектирования, на котором:

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

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

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

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

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

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

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