План управления требованиями · Конспекты по бизнес-анализу

Главные идеи#

Место плана#

В RUP план управления требованиями описывает, как собирают требования, как контролируют изменения и как команда работает с заказчиком. В Руководстве BABOK® эти решения относятся к двум задачам планирования: «Планирование руководства бизнес-анализом» (3.3) и «Планирование управления информацией бизнес-анализа» (3.4).

Вигерс и Битти делят управление требованиями на четыре вида деятельности: управление версиями, управление изменениями, отслеживание статусов и трассировку. Их предупреждение звучит жёстко: если никто не назначен за это ответственным, этого не будет, а если ответственны «все», этого тоже не будет.

Что решает план#

Роли: кто владеет требованиями, кто общается с заказчиком, кто входит в совет по управлению изменениями (CCB).
Идентификация: как именуют и нумеруют артефакты и требования.
Трассировка (traceability): какие типы артефактов с какими связаны, с правилом для каждой связи. В шаблоне RUP используется цепочка от запросов заинтересованных сторон (STR) к потребностям заинтересованных сторон (NEED) и функциям (FEAT) в документе «Видение», а затем к вариантам использования (UC) и дополнительным требованиям (SUPP). Типичное правило: каждая утверждённая функция трассируется хотя бы к одному варианту использования.
Атрибуты: набор RUP — статус, выгода, трудоёмкость, риск, стабильность, целевой релиз, исполнитель и причина. Вигерс перечисляет больше, например происхождение, обоснование, метод проверки и приоритет. Маглинец передаёт совет Вигерса: начинать не более чем примерно с пяти атрибутов и добавлять другие, когда появится реальная потребность.
Базовые версии (baselines): согласованный набор требований, который команда обязуется выполнить в релизе или итерации. В RUP их обычно фиксируют на границах фаз.
Управление изменениями: как запросы подают, анализируют и решают и кто принимает решение.

Статусы, которые что-то сообщают#

Вигерс и Битти предлагают набор статусов: «Предложено», «В работе», «Черновик готов», «Утверждено», «Реализовано», «Проверено», «Отложено», «Удалено» и «Отклонено». Используйте только нужные. Число требований в каждом статусе говорит больше, чем «процент выполнения», который неделями держится на отметке 90%.

Для гибких команд они приводят статусы историй по Леффингуэллу (в бэклоге, определена, в работе, завершена, принята, заблокирована) и диаграмму сгорания (burndown) оставшихся очков историй: её подъём говорит о росте объёма работ, а не об ошибке.

Изменения: оцените влияние, прежде чем сказать «да»#

Анализ влияния, как его излагает Маглинец по Вигерсу, охватывает побочные эффекты (новые функции могут недопустимо замедлить систему), документы, модели и код, которые придётся изменить, а также задачи и трудоёмкость. Проведите его до того, как кто-то скажет «конечно, без проблем». Вигерс предлагает «не сейчас» (в одном из следующих релизов) как более мягкое «нет»; Маглинец добавляет вопрос «зачем?», чтобы инициатор взвесил реальную выгоду.

Леффингуэлл и Уидриг различают внешние причины изменений (меняется проблема, представления пользователей или среда; новая система порождает новые потребности) и внутренние (не опросили нужных людей; не было процесса изменений). Требования, которые проникают через неофициальные каналы, — «просочившиеся» требования, — по их словам, могут составлять до половины объёма проекта. Их средство: принять изменения как данность, зафиксировать базовую версию, пропускать каждое изменение через один канал и записывать каждый запрос.

Практические детали#

Ручное управление версиями: без инструмента Вигерс и Битти предлагают схему «1.0 черновик 1, черновик 2…», затем «1.0 утверждённая», затем «1.1 черновик 1» для небольшого изменения или «2.0 черновик 1» для крупного. Иначе тестировщики в итоге регистрируют утверждённые изменения как дефекты, потому что тестировали по старой спецификации.
Проблемы с требованиями — в трекер: вопросы, пропущенные, ошибочные или дублирующиеся требования. Заметку на доске сотрут.
Явные и неявные связи: Леффингуэлл и Уидриг отмечают, что некоторые связи следуют из структуры (63.1 входит в 63). Пустая строка или столбец в матрице трассировки указывает на что-то лишнее, пропущенное или неправильно понятое.
Два вида запросов на изменение: пример плана из учебных материалов отделяет новые функции от улучшений существующих и связывает детальные требования с функциями из документа «Видение».

Как применять#

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

Шаблон#

Шаблон

# План управления требованиями: <проект>

## 1. Введение — цель, область применения, термины, ссылки
## 2. Роли — владелец требований, аналитик(и), контактные лица заказчика, члены совета по изменениям
## 3. Инструменты и репозиторий — где хранятся требования, у кого есть доступ
## 4. Идентификация — типы артефактов, форматы ID, правила именования
## 5. Трассировка — цепочка артефактов, правила связей («каждая функция трассируется хотя бы к одному варианту использования»)
## 6. Атрибуты — для начала не больше пяти: название, допустимые значения, кто задаёт каждый
## 7. Статусы — выбранный набор и разрешённые переходы между статусами
## 8. Базовые версии — когда фиксируются, кто утверждает, как помечаются
## 9. Управление изменениями — канал подачи запросов, чек-лист анализа влияния, орган принятия решений, оповещение
## 10. Проблемы с требованиями — где регистрируют вопросы, пробелы, ошибки и дубликаты
## 11. Отчётность — число требований по статусам, диаграмма сгорания, статистика изменений
## 12. Отступления и обучение — согласованные исключения; кому нужно освоить процесс
## История изменений

Источники и что почитать#

Шаблоны документов IBM Rational Unified Process (RUP): Requirements Management Plan.
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 27 (виды деятельности по управлению требованиями, набор статусов, управление версиями, отслеживание в гибких проектах).
Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекция 7 (атрибуты, анализ влияния, разрастание границ).
D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. Рус. изд.: Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002. Гл. 31 и 34 (явная и неявная трассировка, просочившиеся требования, процесс изменений).
IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Задачи 3.3 и 3.4.
Учебные материалы по бизнес-анализу (практические примеры и шаблоны): заполненный пример плана.