Бизнес-требования: разработка и примеры оформления

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

Определение

Путаница в терминологии возникает по трем основным причинам:

Обычной практикой является обозначение целей или ожидаемых выгод как бизнес-требований.

Люди, как правило, используют данный термин для обозначения характеристик продукта, системы, программного обеспечения, которые предполагается создать.

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

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

Обновление продукта

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

Акценты процесса

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

Обзор

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

Состав заявок

Требования бизнес-процесса часто включают в себя:

Контекст, область и фон, в том числе и причины изменений.

Ключевые заинтересованные стороны, у которых есть требования.

Факторы успеха для будущего или целевого состояния.

Ограничения, налагаемые бизнесом или другими системами.

Модели и анализ процессов, часто использующие блок-схемы для представления всего «как есть».

Логическая модель данных и ссылки на словарь.

Глоссарии деловых терминов и местный жаргон.

Диаграммы потоков данных для иллюстрации того, как они проходят через информационные системы (в отличие от блок-схем, изображающих алгоритмический поток бизнес-операций).

Роли

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

Полнота

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

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

Прообраз

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

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

Разработка

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

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

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

Примеры оформления

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

Трудности

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

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

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