Материал: 1 Бизнес требования

Уровни и типы требований

В этом разделе приводятся определения, которые будут использоваться для терминов, наиболее часто применяемых в такой сфере, как разработка требований (см. табл. 1-1).

Табл. 1-1. Информация о некоторых типах требований

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

Рис. 1-1. Взаимосвязи нескольких типов информации для требований. Сплошные линии означают «содержатся в», а пунктирные — «являются отправной точкой» или «влияют на»

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

Бизнес-требования (business requirements) описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью. Основное их содержание — бизнес-цели организации или клиента, заказывающих систему. Обычно бизнес-требования существуют в форме документа о концепции и границах (vision and scope document). К другим руководящим документам, которые еще иногда используют в этом качестве, относят устав проекта (project charter), вариант использования (business case) или документ рыночных требований (market requirements document).

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

Определение бизнес-требований

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

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

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

Формулировка бизнес-требований

Термин бизнес-требования (business requirements) относится к информации, которая в совокупности описывает потребность, которая инициирует один или больше проектов, призванных предоставить решение и получить требуемый конечный бизнес-результат. В основе бизнес-требований лежат бизнес-возможности, бизнес-цели, критерии успеха и положение о концепции.

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

Определение требуемых бизнес-преимуществ

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

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

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

Концепция продукта и границы проекта

Концепция и границы — два базовых элемента бизнес-требований.

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

Границы проекта (project scope) показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация. В положении о границах определена черта между тем, что входит в проект и тем, что остается вовне.

Документ о концепции и границах

Документ о концепции и границах (vision and scope document) собирает бизнес-требования в единый документ, который подготавливает основу для последующей разработки продукта. В некоторых организациях с этой же целью создают устав проекта или положение о бизнес-задачах. В организациях, создающих ПО на продажу часто создают документ основных рыночных требований (market requirements document, MRD). В нем более детально, чем в документе о концепции и границах, рассматриваются целевые сегменты рынка и вопросы коммерческого успеха продукта.

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

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

Рис. 1-2. Рекомендуемый шаблон документа о концепции и границах

1. Бизнес-требования

Проекты запускаются с полным убеждением, что новый продукт сделает мир для кого-то лучше и обеспечит прибыль. Бизнес-требования описывают основные преимущества, которые новая система даст ее заказчикам, покупателям и пользователям. Бизнес-требования непосредственно влияют на то, какие пользовательские требования будут реализованы и в какой последовательности.

1.1 Исходные данные

Они суммируют обоснование и содержание нового продукта или изменения, которые нужно внести в существующий продукт. Здесь помещают общее описание предыстории или ситуации, в результате чего было принято решение о создании продукта.

1.2 Возможности бизнеса

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

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