Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство
Шрифт:
Рис. 5–6. Контекстные диаграммы
5.2.2.8. Прототипы
Прототипирование представляет собой метод получения предварительных отзывов относительно требований путем предоставления модели ожидаемого продукта, прежде чем создавать продукт в действительности. Примерами прототипов являются продукты небольшого размера, модели, выполненные с помощью компьютерной двух- или трехмерной графики, макеты или имитации. Прототипы позволяют заинтересованным сторонам экспериментировать с моделью конечного продукта, а не ограничиваться обсуждением абстрактных представлений своих требований. Прототипы поддерживают концепцию последовательного уточнения в итеративных циклах создания макетов, проведения экспериментов пользователем, формирования отзывов и пересмотра прототипа. После проведения достаточного числа циклов обратной связи требования, полученные с помощью прототипа, оказываются в достаточной мере полными для перехода к фазе проектирования или создания.
Раскадровка (storyboarding) – это метод прототипирования, использующий последовательность или навигацию в рамках серии изображений или иллюстраций. Раскадровка используется в различных проектах во многих отраслях, например, при создании фильмов, в рекламе, педагогическом проектировании, в проектах гибкой разработки и других проектах разработки программного обеспечения. При разработке программного обеспечения в раскадровке используются макеты, чтобы продемонстрировать возможности навигации по веб-страницам, экранам или другим интерфейсам пользователей.
5.2.3. Сбор требований: выходы
5.2.3.1. Документация по требованиям
Документация по требованиям описывает, каким образом отдельные требования соответствуют бизнес-потребности в проекте. Требования могут быть сначала описаны высокоуровнево, а затем постепенно детализироваться по мере поступления новой информации о них. До включения в базовый план требования должны стать однозначными (измеримыми и проверяемыми), отслеживаемыми, полными, непротиворечивыми и приемлемыми для ключевых заинтересованных сторон. Формат документа по требованиям может варьироваться от простого документа, перечисляющего все требования, разделенные на категории по заинтересованным сторонам и приоритетам, до более тщательно проработанных форм, содержащих резюме для руководства, подробные описания и приложения.
Многие организации подразделяют требования на различные типы, например, бизнес-решения и технические решения, причем первые относятся к потребностям заинтересованных сторон, а последние – к способу реализации этих потребностей. Требования могут быть сгруппированы в классы, что обеспечивает их дальнейшее уточнение и детализацию в процессе их выработки. Данные классы включают в себя:
Бизнес-требования. Бизнес-требования описывают высокоуровневые потребности организации в целом, например, проблемы или благоприятные возможности организации, а также причины, по которым проект был инициирован.
Требования заинтересованных сторон. Требования заинтересованных сторон описывают потребности заинтересованной стороны или группы заинтересованных сторон.
Требования к решению. Требования к решению описывают свойства, функции и характеристики продукта, услуги или результата, который удовлетворяет бизнес-требованиям и требованиям заинтересованных сторон. Требования к решению, в свою очередь, группируются в функциональные и нефункциональные требования:
• Функциональные требования. Функциональные требования описывают поведение продукта. Примеры включают в себя операции, процессы, данные и взаимодействия, которые должен исполнять продукт.
• Нефункциональные требования. Нефункциональные требования дополняют функциональные и описывают условия или качества среды, необходимые для обеспечения эффективности продукта. Примеры включают в себя: надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность поддержки, требования к хранению/уничтожению и т. д.
Требования на переходный период и по обеспечению готовности. Требования к переходу описывают временные возможности, такие как требования к преобразованию данных и обучению, необходимые для перехода из текущего состояния «как есть» в желаемое состояние в будущем.
Требования к проекту. Требования к проекту описывают действия, процессы или другие условия, которым должен соответствовать проект. В качестве примеров можно назвать даты контрольных событий, договорные обязательства, ограничения и т. п.
Требования к качеству. Требования к качеству, включающие в себя любое состояние или критерии, необходимые для подтверждения успешного получения поставляемого результата проекта или выполнения других требований к проекту. В качестве примеров можно назвать тестирование, сертификацию, подтверждения и т. п.
5.2.3.2. Матрица отслеживания требований
Матрица отслеживания требований – это таблица, связывающая требования к продукту, начиная от их создания и заканчивая предоставлением соответствующих им поставляемых результатов. Применение матрицы отслеживания требований помогает удостовериться, что каждое требование добавляет бизнес-ценность, связывая требование с целями организации и проекта. Это позволяет отслеживать требования на протяжении жизненного цикла проекта, что помогает удостовериться в том, что требования, одобренные в документации по требованиям, выполнены в конце проекта. Наконец, матрица отслеживания требований обеспечивает структуру для управления изменениями содержания продукта.
Требования к отслеживанию включают в себя, среди прочего:
бизнес-потребности, а также благоприятные возможности, цели и задачи организации;
цели проекта;
содержание проекта и поставляемые результаты ИСР;
проектирование продукта;
разработку продукта;
стратегию и сценарии тестирования;
детализацию от высокоуровневых до более детальных требований.
Параметры, связанные с каждым требованием, могут быть зафиксированы в матрице отслеживания требований. Данные параметры помогают определить ключевую информацию относительно требований. Типичные параметры, используемые в матрице отслеживания требований, могут включать в себя: уникальный идентификатор, текстовое описание требования, обоснование включения в список требований, владельца требования, источник, приоритет, версию, текущий статус (например, активно, отменено, отложено, добавлено, одобрено, назначено, выполнено) и дату статуса. Дополнительные параметры, позволяющие удостовериться, что требование удовлетворяет заинтересованные стороны проекта, могут включать в себя также стабильность, сложность и критерии приемки. На рис. 5–7 представлен пример матрицы отслеживания требований с включенными в нее параметрами требований.
Рис. 5–7. Пример матрицы отслеживания требований
5.3. Определение содержания
Определение содержания – процесс разработки подробного описания проекта и продукта. Ключевая выгода данного процесса состоит в том, что он позволяет описать границы и критерии приемки продукта, услуги или результата. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–8. На рис. 5–9 показана диаграмма потоков данных процесса.