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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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