Управление требованиями : Определение системы и управление границами

Определение системы и управление границами

Features

Выделение features

Когда собраны все проблемы и пожелания (выраженные в виде “не нравится” и “хочу”), следует определить границы проекта и описать будущий продукт в терминах, понятных заказчику. Это делается при помощи описания свойств (feature: особенность, признак, свойство). Определение “feature” в RUP это: “наблюдаемая внешне услуга продукта, при помощи которой продукт непосредственно удовлетворяет конкретные потребности конкретных заинтересованных лиц”. Обратите внимание, мы не переходим непосредственно к детальной спецификации проекта, а согласуем видение, каким же должен быть наш продукт. Каждое свойство формулируется как “product will (do something, conform to standard…, use legacy system for…)…”. Feature может определять разные стороны продукта, такие как (см. классификатор требований):

• Поведение (behavior);
• Данные (data);
• Взаимодействие с другими системами (interaction);
• Ограничения (restriction);

Описание feature включает в себя декларацию функций или других связанных “полезностей”, которые адресованы пользователю продукта или другому продукту, взаимодействующему с нашим продуктом. Описание должно отвечать на вопросы: “что”, “для кого”, “зачем” должно быть сделано, но НЕ должно отвечать на вопрос “как”. По сути, features, является единой и формализованной формулировкой ВСЕХ требований, ранее выставленных stakeholder’ами. При описании feature следует разделять то, что мы напишем в списке features, и ту информацию, которая нам необходима самим об этой feature. Список features, входящий в документ vision является только общей декларацией, достаточно краткой, что бы её могли охватить все участники проекта, включая заказчиков и stakeholder’ов. При написании features полезны следующие приёмы:

• Декомпозиция;
• Активное обсуждение;

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

• Вначале четко ставится группа проблем, которые будут обсуждаться.
• Далее создается (не обсуждается!) набор features, который бы решал эти проблемы. Есть смысл записать каждую features на отдельном листке, указывая: какую проблему/запрос пользователя feature удовлетворяет, каким пользователям она адресована.
• Собранные решения обсуждаются, и выносится окончательная формулировка. Для оценки feature может использоваться метод голосования, когда каждый оценивает каждую feature и в дальнейшем features ранжируются по количеству поданных голосов.

Назначение атрибутов features

Когда определен список feature, следует назначить атрибуты. Атрибуты это важные характеристики, которые будут учтены в определение приоритетов и порядка разработки features. Минимальный рекомендованный набор атрибутов включает в себя:

• Важность для заказчика
  • Обязательно (obligatory) - "без этого продукт не имеет смысла, или эта feature принесет значительный экономический эффект";
  • Желательно (desired) - "без этого можно жить, но внедрение принесет дополнительную выгоду, стоящую упоминания";
  • Опционально (optional) - "жили без этого сто лет, и еще проживем, но если совсем нечего делать - то сделайте".
• Приоритет (скорость) для заказчика (насколько быстро необходима реализация?)
  • Срочно - "надо завтра, если завтра не будет - то уже и не надо";
  • Средне срочно - "ждем, но ожидание доставляет дискомфорт";
  • Не срочно - "жили без этого и еще проживем".

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

• Каков риск того, что исходные требования будут изменяться в дальнейшем?
• Какова сложность реализации (знаем ли мы как?)?
• Какова трудоемкость реализации (сколько нужно времени/ресурсов)?

Трассировка features

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

• Все ли исходные требования получили соответствующую feature в системе.
• Все ли features проистекают из какого-либо требования.

Базовый анализ Use Cases

Цель

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

Что есть use-case?

Поскольку мы определили use-case как процесс, сначала следует понять, что есть процесс. Процесс – это последовательность действий, направленная на получение результата, имеющего ощутимую ценность для того, по чьей инициативе процесс был исполнен. То есть:

• Процесс всегда инициатора – лицо, напрямую заинтересованное в результатах процесса;
• Процесс всегда имеет выход ¬– результат процесса, имеющий ценность для инициатора;
• Процесс всегда имеет как минимум одну последовательность действий (flow).

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

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

В терминах UML, инициатор процесса называется actor. Процесс, инициируемый в интересах actor’а, называется use case (вариант использования). Само называние предполагает, что продукт используется, т.е. работаем с ним в своих интересах и для достижения своих целей. Actor’ом являются как непосредственные пользователи системы, так и те (одушевленное) и то (неодушевленное), что вовлекается в работу в ходе процесса. Показать, как рисуется use case.

Каждый use case:

• Описывает действия, которые совершает продукт для предоставления результата, значимого для actor’а.
• Моделирует общение между пользователем и продуктом.
• Представляет собой полный и точный поток событий и действий с точки зрения пользователя.

Использование use-case позволяет:

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

Выделение актеров и вариантов использования

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

Не следует путать актёров с конкретными пользователями системы. Актёр – это роль, которую может исполнять по отношению к системе человек. В общем случае каждый пользователь может исполнять несколько ролей по отношению к системе, и наоборот – каждая роль может быть исполнена несколькими пользователями. Т.е. более правильным является исходить из того, ЗАЧЕМ используется продукт, а не кто его использует.

Вопросы, помогающие определить актёров:

• Кто/что использует продукт?
• Кто/что получает информацию от продукта?
• Кто/что предоставляет информацию для продукта?
• Где в бизнес-процессах заказчика продукт используется?
• Кто поддерживает продукт и управляет им?

Каждый актёр должен быть именован и вкратце описан:

• Каких пользователей представляет актёр;
• Какова ответственность этого актёра (зачем он введён в продукт?);
• Зачем актёр использует продукт.

Далее, для каждого актёра выделяются варианты использования. Вопросы, помогающие определить варианты использования:

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

При выделении use-case следует не забывать следующие правила:

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

При именовании use-case следует придерживаться следующих правило:

• Название должно отражать значимый результат для актёра;
• Название должно отражать действие (начинаться с глагола), совершаемое актёром для достижения результата.

При выделении use-case не следует забывать о вариантах использования, которые:

• Предназначены для поддержки продукта (запуск, остановка, настройка, управление).
• Выполняются по расписанию, а не по требованию.

Use case документируется в виде:

• Название use-case
• Краткое описание:
  • Для кого предназначен use case;
  • С какими целями используется use-case;
  • Какой результат достигается в use-case.

Более подробно каждый use-case описывается каждый в своём документе.

Замечание, для упрощения документирования системы, часто use-cases связанные с управлением данным объединяются в один CRUD use case (create, read, update, delete something…)

Flows

Для каждого use case описывается flow – поток действий (опять-таки наблюдаемых пользователем с точки зрения системы). Flow разделяется на шаги, шаги нумеруются. Шаги должны быть описаны с использованием терминов бизнес области, поскольку они так же предназначены для чтения заказчиком. Шаги не должны быть слишком подробными. Для изначального описания выбирается наиболее вероятный успешный путь получения результата. Далее, проводится поиск альтернатив:

• Шаг(и) может быть выполнен(ы) по другому;
• Шаг(и) может быть пропущен(ы);
• Сценарий может завершиться неуспешно.

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

Сценарии

Для use-cases так же создаются сценарии – конкретные варианты прохождения use-case в реальной ситуации (отношение use-case - сценарий аналогично класс-объект). Эти сценарии часто используются для:

• Определения приоритетов в разработке;
• Как исходный материал для test cases;

Пример: use-case flows и scenario