Одна из основных профессиональных обязанностей системного и бизнес-аналитика – это управление требованиями при разработке программного обеспечения. Сегодня мы рассмотрим, какие виды требований выделяет BABOK®Guide и как это профессиональное руководство по бизнес-анализу рекомендует работать с ними.

Что такое требование и дизайн по BABOK

Начнем с определений по BABOK®Guide: требование – это пригодное для практического использования представление потребности в виде условия или возможности, которые необходимы заинтересованной стороне (стейкхолдеру) для достижения цели. BABOK®Guide различает следующие виды требований:

• Бизнес-требование (business requirement), которое отвечает на вопросы «Почему это нужно?» или «Зачем я этого хочу?» и представляет собой отображение целей, задач и результатов, объясняющих, для чего было инициировано изменение и каким образом будет оцениваться успех его реализации;
• Требование стейкхолдера (stakeholder requirement), которое отвечает на вопрос «Что нужно?» и описывает потребности отдельной заинтересованной стороны или целой группы стейкхолдеров, необходимые для выполнения бизнес-требований. Фактически, они могут играть роль проводника от бизнес-требований до требований к решению.
• Требование к решению (solution requirement), которое отвечает на вопрос «Что я хочу?» и описывает возможность или качество решения, удовлетворяющие требованиям стейкхолдера. Требования к решению делятся на функциональные требования и нефункциональные. Функциональное требование (functional requirement) означает поведенческую возможность, которую должно предоставлять решение. Нефункциональное требование (non-functional requirement) описывает особенности эксплуатации: производительность, информационную безопасность, удобство использования и выражается в измеримых показателях, которые являются своего рода ограничениями варианта реализации (дизайна) решения.
• Переходное требование (transition requirement), которое отвечает на вопрос «Каковы условия реализации перехода от бизнес-потребности к внедренному решению?», описывая возможности решения и условия, каким оно должно соответствовать для перехода из текущего состояния в целевое. В отличие от других видов требования, переходное требование является временным, т.к. становится не нужным после завершения изменения. Например, требование относительно форматов и процедур преобразования данных при переходе от одной системы к другой.

Итак, потребность трансформируется в требование, которое, в свою очередь, в дальнейшем преобразуется в дизайн – пригодное для практического использования представление решения. Требования и дизайны очень близки друг другу: в частности, при работе с ними часто используются одни и те же техники выявления, моделирования и анализа. Требование является входом для разработки дизайна, который может повлечь дополнительное выявление и анализ требований. Тем не менее, BABOK®Guide дифференцирует требования и дизайны по следующему принципу:

• если фокус лежит на понимании потребности, речь идет о требовании;
• когда речь идет о конкретном варианте реализации, т.е. решении, аналитик имеет дело с дизайном.

При этом руководство BABOK отмечает, что в ИТ-сфере термин “дизайн” обычно используется именно для технических вариантов решения, которые создаются непосредственно специалистами по реализации: разработчиками программного обеспечения, ИТ-архитекторами и т.д. А требование означает выдвигаемые бизнесом условия или ожидаемые возможности.

Задачи управления требованиями в BABOK®Guide

Из 6-ти областей знаний BABOK 2 посвящены непосредственной работе с требованиями: «Управление жизненным циклом требований» (Requirement Life Cycle Management) и «Анализ требований и определение дизайнов» (Requirements Analysis and Design Definition). Как видно из названия, область знаний «Анализ требований и определение дизайнов» носит инструментальный характер и сосредоточена на моделировании – именно здесь разрабатываются различные виды процессных и структурных диаграмм, например, UML, BPMN, IDEF0, EPC, DFD или ERD, чтобы описать поведение и строение проектируемого решения, а также процедуры работы с ним через решение следующих задач бизнес-анализа:

• Спецификация и моделирование требований (Specify and Model Requirements)
• Верификация требований (Verify Requirements)
• Валидация требований (Validate Requirements)
• Определение архитектуры требований (Define Requirements Architecture)
• Определение вариантов дизайна (Define Design Options)
• Анализ потенциальной ценности и рекомендация решения (Analyze Potential Value and Recommend Solution)

А непосредственное управление требованиями выполняется в рамках области знаний «Управление жизненным циклом требований» и включает следующие задачи работы с требованиями:

• Трассировка (Trace Requirements)
• Поддержание (Maintain Requirements)
• Приоритизация (Prioritize Requirements)
• Оценка изменений (Assess Requirements Changes)
• Утверждение (Approve Requirements)

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

Практическое управление требованиями реализуется с помощью соответствующих программных инструментов, например, Archi для моделирования диаграмм, и Jira для трассировки, приоритезации и поддержания требований. В следующей статье мы рассмотрим, как организовать управление требованиями в Agile-проектах с учетом особенностей гибких методологий и строгих предписаний ГОСТов на разработку ТЗ. А освоить техники и рекомендации BABOK®Guide по управлению требованиями и другим задачам бизнес-анализа, а также подготовиться к сертификационному экзамену IIBA® на уровни ECBA, CCBA и CBAP вам помогут авторизованные курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации аналитиков, менеджеров и ИТ-специалистов в Москве:

• Штурм BABOK®Guide за 5 дней: подготовка к экзамену CBAP/CCBA
• Экспресс-тренинг по BABOK®Guide: подготовка к экзамену ECBA за 3 дня