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

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

Три основные причины таких дискуссий:

Общепринятой практикой является называть цели или ожидаемые выгоды «бизнес-требованиями». ^[1]
Люди обычно используют термин «требования» для описания особенностей продукта, системы или программного обеспечения, которые, как ожидается, будут созданы.
Широко распространенная модель утверждает, что эти два типа требований различаются только уровнем детализации или абстракции, при этом «бизнес-требования» являются высокоуровневыми, часто расплывчатыми и распадаются на подробные требования к продукту, системе или программному обеспечению.

По мнению Голдсмита, Робина Ф., это путаница, которой можно избежать, признав, что бизнес-требования не являются целями, а скорее соответствуют целям (т. е. обеспечивают ценность), когда они удовлетворены. Бизнес-требования «что» не разлагаются на требования к продукту/системе/программному обеспечению « как» . Скорее, продукты и требования к ним представляют собой ответ на требования бизнеса — предположительно, как удовлетворить и что . Бизнес-требования существуют в бизнес-среде и должны быть обнаружены, тогда как требования к продукту определяются (задаются) человеком. Бизнес-требования не ограничиваются существованием на высоком уровне, их необходимо детализировать. Однако, независимо от уровня детализации, бизнес-требования всегда представляют собой то , что обеспечивает бизнес-результат, если его удовлетворение приносит пользу; их детальное рассмотрение никогда не превращает бизнес-требования в требования к продукту. ^[2]

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

Бизнес-требования часто перечислены в Документе бизнес-требований или BRD. Акцент в BRD делается на процессе или деятельности по точному доступу к планированию и разработке требований, а не на том, как этого достичь; это обычно делегируется спецификации или документу системных требований (SRS или SRD) или другому варианту, например документу функциональной спецификации. Путаница между BRD и SRD может возникнуть, если игнорировать различие между бизнес-требованиями и системными требованиями. Следовательно, многие BRD фактически описывают требования к продукту, системе или программному обеспечению.

Обзор [ править ]

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

Бизнес-требования часто включают в себя

Бизнес-контекст, объем и предыстория, включая причины ^[3] для перемен
Ключевые заинтересованные стороны бизнеса, у которых есть требования
Факторы успеха для будущего/целевого состояния
Ограничения, налагаемые бизнесом или другими системами
Модели и анализ бизнес-процессов, часто с использованием обозначений блок-схем для изображения бизнес-процессов «как есть» и «будущих».
Концептуальные модели данных и словари данных ссылки на
Глоссарии деловых терминов и местного жаргона
Диаграммы потоков данных , иллюстрирующие, как данные проходят через информационные системы (отличаются от блок-схем, изображающих алгоритмический поток бизнес-деятельности).

Темы бизнес-требований [ править ]

Преимущества [ править ]

Описание
Уменьшить провал проекта	Структурированное объяснение бизнес-процесса или метода, определенного на ранних стадиях жизненного цикла, помогает уменьшить количество неудач проекта, которые происходят из-за несогласованных или неверно представленных требований, приводящих к несоответствию ожиданиям пользователей.
Связано с более широкими бизнес-целями	Четко определенные бизнес-требования помогают составить устав проекта. ^[3] критический шаг в реализации бизнес-стратегии или бизнес-целей, а также перейти к следующему логическому этапу превращения в ИТ-систему. Это помогает контролировать общее состояние проекта и обеспечивает положительную динамику среди ключевых заинтересованных сторон проекта, включая спонсоров.
Достижение консенсуса и сотрудничество	Преимущество структурированного формата, типичного для документации бизнес-требований, помогает достичь позитивного консенсуса и улучшить сотрудничество, когда группа заинтересованных сторон может представлять собой большую межфункциональную команду, распределенную географически.
Экономия затрат	Хорошее качество бизнес-требований, если они зафиксированы на ранней стадии, не только повышает успех проекта, но и экономит общие затраты , связанные с запросами на изменения и соответствующими инвестициями в обучение, инфраструктуру и т. д.

Роли [ править ]

Бизнес-требования обычно определяются бизнес-аналитиками в сотрудничестве с другими участниками проекта .

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

Формат [ править ]

Традиционная структура BRD - ^[4]
Заголовок Версия Описание изменения Автор Дата Содержание Введение Цель Объем Фон Ссылки Предположения и ограничения Обзор документа Методология Функциональные требования Контекст Требования пользователя Диаграммы потоков данных Логическая модель данных/словарь данных Другие требования Требования к интерфейсу Требования к преобразованию данных Требования к аппаратному/программному обеспечению Эксплуатационные требования Приложение А -

Самым популярным форматом записи бизнес-требований является документ бизнес-требований (BRD). Целью BRD является определение того, каких результатов следует ожидать от системы, однако в конечном итоге она может быть спроектирована. Таким образом, документы BRD дополняются системным справочным документом (SRD) ИЛИ документом технического проектирования (TDD), в котором подробно описываются проектирование, производительность технологии и ожидания от инфраструктуры, включая любые технологические требования (нефункциональные), относящиеся к качеству обслуживания, такие как производительность. , ремонтопригодность, адаптируемость, надежность, доступность, безопасность и масштабируемость.

Полнота [ править ]

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

Хотя прототипирование обычно считается средством оценки требований, на самом деле оно обычно переключает внимание с бизнес-требований на создаваемый продукт, систему или программное обеспечение. Прототипы — это работающее программное обеспечение, что означает, что они представляют собой три этапа (требования к продукту/системе/программному обеспечению, инженерное/техническое проектирование указанного продукта/системы/программного обеспечения и реализация проекта в программном коде), удаленные от бизнес-требований. Прототипы — это предварительные версии программного обеспечения, которое разработчик собирается реализовать. Поскольку прототипы достаточно конкретны, заинтересованные стороны, которые опробуют прототип, могут дать более содержательную обратную связь относительно некоторых аспектов того, что создает разработчик, что является интерпретацией разработчиком способа удовлетворения бизнес-требований, а не бизнес-требований. Более того, чтобы создать прототип как можно раньше и быстрее, упор делается на графический интерфейс пользователя (GUI), а «внутренности» сокращаются. Внутренности — это основная часть логики программы, и именно здесь будет решаться большинство бизнес-требований. Другими словами, проблемы, выявляемые прототипами, вряд ли связаны с бизнес-требованиями.

Важно распознавать изменения в требованиях, документировать их и поддерживать определения требований в актуальном состоянии. Однако бизнес-требования, как правило, меняются не так сильно, как осведомленность о них. Бизнес-требования могут присутствовать, но не распознаваться и не пониматься заинтересованными сторонами, аналитиками и командой проекта. Изменения более очевидны в отношении того, что обычно называют «изменениями требований» — требований к продукту/системе/программному обеспечению. Они, как правило, отражают предполагаемые способы удовлетворения неадекватно выявленных бизнес-требований. Большая часть трудностей, приписываемых достижению бизнес-требований, на самом деле отражает общепринятую практику, когда почти все усилия по «требованиям» посвящаются тому, что на самом деле является высокоуровневым проектированием продукта, системы или программного обеспечения. Это происходит из-за неспособности сначала адекватно определить бизнес-требования, которым должен удовлетворять продукт/система/программное обеспечение, чтобы обеспечить ценность. Практики разработки обычно продолжают пересматривать продукт/систему/программное обеспечение до тех пор, пока они в конечном итоге не «вернутся» к решению, которое, по-видимому, делает то, что необходимо, т. е. явно соответствует бизнес-требованиям. Такие дорогостоящие Косвенные способы определения бизнес-требований методом проб и ошибок лежат в основе большей части «итеративной разработки», включая популярные методы гибкой разработки, которые рекламируются как «лучшие практики».

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

Трудности [ править ]

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

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

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

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

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

Включает следующие шаги:

Определение бизнеса
Понимание бизнес-доменов
Цели организации
Основная компетенция

См. также [ править ]

Цитаты [ править ]

^ Бил, 2012. стр. 1.
^ Голдсмит, 2004. страницы 2–6.
↑ Перейти обратно: Перейти обратно: ^а ^б Институт управления проектами 2021 , §3.4 Фокус на ценности.
^ «Шаблон BRD для документирования функциональных требований клиента» .

Ссылки [ править ]

Бил, Адриана. Требование – это то, что мы должны сделать для достижения цели www.bealprojects.com , 2012 г.
Голдсмит, Робин Ф. Выявление реальных бизнес-требований для успеха программного проекта . Артех Хаус, 2004.
Институт управления проектами (2021). Руководство по совокупности знаний по управлению проектами (руководство PMBOK) . Институт управления проектами (7-е изд.). Ньютаун-сквер, Пенсильвания. ISBN 978-1-62825-664-2 . {{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )
Робертсон, Сюзанна и Джеймс С. Робертсон. Освоение процесса требований . 2-е издание, Аддисон-Уэсли, 2006 г.

[1] Бил, 2012. стр. 1.

[2] Голдсмит, 2004. страницы 2–6.

[FOOTNOTEProject_Management_Institute2021§3.4_Focus_on_Value-3] Перейти обратно: Перейти обратно: ^а ^б Институт управления проектами 2021 , §3.4 Фокус на ценности.

[4] «Шаблон BRD для документирования функциональных требований клиента» .

[1]

[2]

[3]

[4]