Поделиться через

Структурирование требований в виде плана продукта

  • Статья

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

В этом разделе описывается один из способов составления плана на основе набора требований. Это лишь один из многих способов, которые можно использовать в Visual Studio, и его необходимо адаптировать в соответствии с потребностями.

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

Требования и функции

В этом методе используется два вида требований: клиентские требования и функции. Клиентские требования — это результат анализа пожеланий клиента в отношении продукта. Функции — это элементы плана продукта, соответствующие небольшим подмножествам клиентских требований. Каждая функция может включать элементы клиентских требований, основанных на разных аспектах опыта использования продукта и разных функциональных областях.

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

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

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

  • Существует два вида клиентских требований.

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

    • Требования к качеству обслуживания содержат критерии производительности, безопасности, удобства работы и проч.

  • Эти требования можно представить в виде рабочих элементов требований типа, задав в поле "Тип требования" значение "Сценарий" или "Качество обслуживания". Для получения дополнительной информации см. Разработка требований.

  • Эти рабочие элементы требований необходимо связать с системными тестами, чтобы обеспечить тестирование всех требований. См. раздел Планирование ручных тестов с помощью Team Web Access.

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

  • Отчет Отчет "Ход реализации требований" (CMMI) можно использовать для отслеживания удовлетворенных требований.

Функции

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

  • Введите функции в качестве рабочих элементов требований, значение поля "Тип требований" — Функция.

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

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

    • "Покупатель может выбрать книгу из списка и добавить ее в корзину".

    • "В списке книг отображаются цены. В корзине указывается общая стоимость книг".

    • "Поставщики могут прикреплять к книгам теги. Покупатели могут фильтровать списки книг по тегам".

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

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

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

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

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

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

  • Для составления списка функций используется запрос требований к продукту.

Поиск функций

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

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

Декомпозиция сценария

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

Для этого чаще всего используются раскадровки. Раскадровка — это последовательность рисунков, иллюстрирующих сценарий. На UML-схеме действий можно показать альтернативные пути, а UML-схема последовательности позволяет обсуждать взаимодействие между несколькими субъектами. После использования этих инструментов для анализа сценария, можно ввести разложенные на составные части сценарии в Team Explorer. Это позволяет связывать тестовые случаи со сценариями и обеспечивает выполнение требований. Дополнительные сведения см. в разделах UML-схемы деятельности: рекомендации и UML-схемы последовательностей: правила работы.

Функции и требования, реализуемые в каждой итерации

Функция — это требование, обобщающее возможности пользователя по завершении каждой итерации. Для каждой итерации можно создать несколько функций. Введите их в качестве рабочих элементов требований, задав в поле "Тип требований" значение "Функция".

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

  • Итерация 1

    • Клиент выбирает позиции из меню, добавляет их в заказ и добавляет адрес доставки.

  • Итерация 2

    • Клиенты выбирают один из ресторанов из отображенного списка.

    • По завершении заказа клиентом заказ отображается на экране выбранного ресторана.

    • В заказе отображаются цены позиций и общая стоимость заказа.

  • Итерация 3

    • Ресторан помечает заказ как "Выполнено" после отправки еды клиенту. Заказ фиксируется на счету ресторана.

    • Каждый ресторан может составлять и обновлять свое меню.

    • Клиент может просмотреть меню каждого ресторана перед выбором заведения.

  • Итерация 4

    • Клиент вводит сведения об оплате, сделав заказ. Когда ресторан помечает заказ как "Выполнено", с карты клиента снимаются средства для оплаты.

    • Ресторан получает оплату за заказы, помеченные как "Выполнено".

  • Итерация 5

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

Частично реализованные сценарии

Разбиение сценариев на более мелкие шаги позволяет отделить шаги, которые можно реализовать на более ранних этапах проекта, от более поздних.

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

  • Итерация 6 — Ресторан может выбрать цветовую схему и шрифт меню и загрузить собственный логотип и изображения блюд.

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

Ввод и изучение функций

Создайте рабочие элементы с типом "Требование" и задайте в поле "Тип требования" значение "Функция". В названии функции укажите краткое описание.

Отслеживание функций к требованиям

Связать функции с требованиями можно следующими способами.

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

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

Функции качества обслуживания

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

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

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

Планирование продукта

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

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

На собрании необходимо обсудить последовательность разработки функций. Для этого можно спроецировать или вывести на общий экран представление запроса требований к продукту и отсортировать функции по итерации в Office Excel.

Кроме того, можно расположить функции в заданной последовательности и проанализировать, какие из них могут быть реализованы в каждой итерации. Например, разработчики могут обсудить, нужно ли перенести функцию "Клиент может просматривать цены" из Итерации 2 в Итерацию 3 отдельно, не в последовательности. Чтобы расположить элементы в последовательности, необходимо добавить в электронную таблицу дополнительный столбец с именем "Ранг". Отсортируйте электронную таблицу по этому столбцу. Ранги не сохраняются в Team Foundation Server, но можно сохранить электронную таблицу. При повторном открытии электронной таблицы нужно щелкнуть любую ячейку таблицы рабочих элементов, затем щелкнуть "Обновить" на вкладке "Рабочая группа".

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

Планирование итераций

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

Планирование итераций предполагает выполнение следующих действий.

  • Создайте задачи разработки и тестирования и свяжите их (в качестве дочерних элементов) с требованиями функций.

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

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

Для получения дополнительной информации см. Планирование итерации (CMMI).