Подходы к управлению требованиями в BABOK

Страница разрабатывается

Описание стандарта

Профессиональный стандарт/свод знаний по бизнес-анализу, разрабатываемая международным институтом бизнес-анализа IIBA в Канаде.

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

Требование — это:
1. Условие или возможность, необходимые заинтересованной стороне для решения проблемы или достижения цели.
2. Условие или возможность, которые должны быть выполнены или которыми должно обладать решение/компоненты решения для удовлетворения контракта, стандарта, спецификации или других официальных документов.
3. Документированное представление условий или возможностей, как в (1) или (2).

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

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

Требования к решению описывают характеристики к решению, которые соответствуют бизнес-требованиям и требованиям заинтересованных сторон. Они разработаны и определены на основе анализа требований. Их часто делят на подкатегории, особенно в случаях, когда требования описывают программное решение:

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

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

Методы сбора требований

Brainstorming — Мозговой штурм

Document Analysis — Анализ документов

Focus Groups — Фокус-группы

Interface Analysis — Анализ интерфейсов

Interviews — Интервью

Observation — Наблюдение

Prototyping — Прототипирование

Requirements Workshops — Семинары по сбору требований

Survey/Questionnaire — Анкетирование


Опубликовано в Обзор всех методик работы с требованиями.
Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>