Бизнес-требования , также известные как спецификации требований заинтересованных сторон (StRS), описывают характеристики предлагаемой системы с точки зрения конечного пользователя системы, как CONOPS . Продукты, системы, программное обеспечение и процессы — это способы доставки , удовлетворения или соответствия бизнес-требованиям. Следовательно, бизнес-требования часто обсуждаются в контексте разработки или закупки программного обеспечения или других систем.
Три основные причины таких обсуждений:
По мнению Голдсмита, Робина Ф., таких путаниц можно избежать, осознав, что бизнес-требования не являются целями, а скорее соответствуют целям (т. е. предоставляют ценность) при удовлетворении. Бизнес-требования « что» не распадаются на требования к продукту/системе/программному обеспечению «как» . Скорее, продукты и их требования представляют собой ответ на бизнес-требования — предположительно, как удовлетворить что . Бизнес-требования существуют в бизнес-среде и должны быть обнаружены, тогда как требования к продукту определяются (указываются) человеком. Бизнес-требования не ограничиваются существованием высокого уровня, но должны быть доведены до деталей. Однако, независимо от их уровня детализации, бизнес-требования всегда являются бизнес-поставляемыми « что», которые предоставляют ценность при удовлетворении; доведение их до деталей никогда не превращает бизнес-требования в требования к продукту. [2]
В проектах по разработке систем или программного обеспечения бизнес-требования обычно требуют полномочий от заинтересованных сторон. Обычно это приводит к созданию или обновлению продукта, системы или программного обеспечения. Требования к продукту/системе/программному обеспечению обычно состоят как из функциональных требований , так и из нефункциональных требований . Хотя обычно они определяются в сочетании с функциональностью продукта/системы/программного обеспечения (функции и использование), нефункциональные требования часто фактически отражают форму бизнес-требований, которые иногда считаются ограничениями. Они могут включать необходимые аспекты производительности, безопасности или защиты, которые применяются на уровне бизнеса.
Бизнес-требования часто перечисляются в документе бизнес-требований или BRD. Акцент в BRD делается на процессе или деятельности по точному доступу к планированию и разработке требований, а не на том, как этого достичь; это обычно делегируется спецификации или документу системных требований (SRS или SRD) или другой вариации, такой как документ функциональной спецификации. Путаница между BRD и SRD может возникнуть, когда игнорируется различие между бизнес-требованиями и системными требованиями. Следовательно, многие BRD на самом деле описывают требования к продукту, системе или программному обеспечению.
Бизнес-требования в контексте разработки программного обеспечения или жизненного цикла разработки программного обеспечения — это концепция выявления и документирования бизнес-требований бизнес-пользователей, таких как клиенты, сотрудники и поставщики, на ранних этапах цикла разработки системы для руководства проектированием будущей системы. Бизнес-требования часто фиксируются бизнес-аналитиками , которые анализируют бизнес-деятельность и процессы и часто изучают процесс «как есть», чтобы определить целевой процесс «как будет».
Бизнес-требования часто включают в себя
Бизнес-требования обычно определяются бизнес-аналитиками в сотрудничестве с другими заинтересованными сторонами проекта .
Обе стороны могут нести ответственность за определение бизнес-требований и разработку технических решений. Бизнес-аналитики, как правило, участвуют в разработке подхода к внедрению и управлении влиянием на все сферы бизнеса, включая взаимодействие с заинтересованными сторонами и управление рисками.
Прототипирование с тестированием на ранней стадии может оценить полноту и точность зафиксированных бизнес-требований. Заинтересованные стороны приходят на раннем этапе, чтобы помочь определить требования, и результат отправляется группам разработки проекта, которые создают бизнес-систему; другие заинтересованные стороны тестируют и оценивают окончательную развернутую систему. Ясность требует отслеживания требований и их решения с формальным процессом для определения соответствующего использования шаблона . Область бизнес-требований не обязательно ограничивается стадией определения того, что должно быть построено как бизнес-система. Она выходит за рамки, чтобы предусмотреть, как управляется и поддерживается работающая бизнес-система, и обеспечить ее постоянное соответствие бизнес-целям или стратегии. Документ бизнес-требований должен постоянно пересматриваться контролируемым образом. Наличие стандартизированного формата или шаблонов, которые разработаны для определенных бизнес-функций и областей, может обеспечить полноту бизнес-требований, помимо сохранения области в фокусе.
Хотя прототипирование обычно считается средством оценки требований, на самом деле оно обычно переключает внимание с бизнес-требований на создаваемый продукт, систему или программное обеспечение. Прототипы — это работающее программное обеспечение, что означает, что они представляют собой три шага (требования к продукту/системе/программному обеспечению, инженерное/техническое проектирование указанного продукта/системы/программного обеспечения и реализация проекта в программном коде), удаленных от бизнес-требований. Прототипы — это предварительные версии программного обеспечения, которое разработчик намерен реализовать. Поскольку прототипы довольно конкретны, заинтересованные стороны, которые испытывают прототип, могут дать более содержательную обратную связь относительно некоторых аспектов того, что создает разработчик, что является интерпретацией разработчика способа удовлетворения бизнес-требований, а не бизнес-требований. Более того, чтобы создать прототип на ранней стадии и быстро, подчеркивается графический пользовательский интерфейс (GUI), а «внутренности» являются сокращенными. Внутренности — это основная часть логики программы, и именно там будет решаться большинство бизнес-требований. Другими словами, проблемы, которые раскрывают прототипы, вряд ли будут связаны с бизнес-требованиями.
Важно распознавать изменения в требованиях, документировать их и поддерживать определение требований в актуальном состоянии. Однако бизнес-требования, как правило, не меняются так сильно, как их осознание. Бизнес-требование может присутствовать, но не осознаваться или не пониматься заинтересованными сторонами, аналитиками и проектной группой. Изменения более очевидны в отношении того, что обычно называют «изменениями требований» — требованиями к продукту/системе/программному обеспечению. Они, как правило, отражают предполагаемые способы удовлетворения неадекватно определенных бизнес-требований. Большая часть трудностей, приписываемых достижению бизнес-требований, на самом деле отражает распространенную практику направления почти всех усилий по «требованиям» на то, что на самом деле является высокоуровневым проектированием продукта, системы или программного обеспечения. Это происходит из-за того, что сначала не удается адекватно определить бизнес-требования, которым продукт/система/программное обеспечение должны удовлетворять, чтобы обеспечить ценность. Методы разработки обычно продолжают пересматривать продукт/систему/программное обеспечение, пока они в конечном итоге не «возвращаются» к решению, которое, по-видимому, делает то, что нужно, т. е., по-видимому, удовлетворяет бизнес-требованию. Подобные дорогостоящие косвенные методы проб и ошибок для определения бизнес-требований являются основой для большей части «итеративной разработки», включая популярные методы разработки Agile, которые рекламируются как «лучшие практики».
Шаблоны помогают стимулировать запросы относительно конкретных тем, которые часто могут быть релевантны бизнес-требованиям. Они могут способствовать стандартизированной документации относительно бизнес-требований, что может облегчить понимание. Шаблоны не гарантируют точность или полноту бизнес-требований. Фактически, часто неправильно используемые шаблоны часто негативно влияют на исследование требований, поскольку они, как правило, способствуют поверхностности и в основном механическому определению без осмысленного анализа.
Бизнес-требования часто преждевременно ужесточаются из-за большой базы заинтересованных сторон, участвующих в определении требований, где существует потенциал для конфликта интересов. Процесс управления и достижения консенсуса может быть деликатным и даже политическим по своей природе. Менее сложной, хотя и распространенной, проблемой является распределенная команда с заинтересованными сторонами в нескольких географических точках. Естественно, что сотрудники отдела продаж находятся ближе к своим клиентам, в то время как производственный персонал находится ближе к производственным подразделениям; финансы и HR , включая высшее руководство, находятся ближе к зарегистрированному головному офису. Например, система, которая включает пользователей отдела продаж и производства, может столкнуться с конфликтом целей — одна сторона может быть заинтересована в предложении максимального количества функций, в то время как другая может сосредоточиться на минимальной стоимости производства . Подобные ситуации часто заканчиваются консенсусом с максимальным количеством функций за разумную, прибыльную стоимость производства и распространения.
Для решения этих проблем на ранней стадии заинтересованные стороны вовлекаются в процесс посредством демонстрации прототипов и совместной работы. Обычны семинары для заинтересованных сторон, как в виде фасилитируемых сессий, так и в виде простых групповых обсуждений, чтобы помочь достичь консенсуса, особенно в отношении деликатных бизнес-требований и там, где есть потенциальный конфликт интересов. Сложность бизнес-процесса является фактором. Это может повлечь за собой специальные знания, необходимые для понимания юридических или нормативных требований, внутренних общекорпоративных руководящих принципов, таких как брендинг или корпоративные обязательства по социальной ответственности. Анализ бизнес-требований заключается не только в том, чтобы зафиксировать «что» бизнес-процесса вместе с «как» для предоставления его контекста. Может потребоваться перевод в проектирование и создание работающей системы. На этом этапе бизнес-требования должны признавать технические детали и осуществимость.
Индивидуально разработанное решение не всегда требуется для каждого нового набора бизнес-требований. Часто существуют стандартизированные процессы и продукты, которые с некоторой доработкой или настройкой могут служить для удовлетворения бизнес-требований. Целевая бизнес-система часто ограничена определенным выбором технологий, бюджетом или уже развернутыми доступными продуктами.
Наконец, стандартизация формата может вызвать трудности. Несколько проектов с несколькими форматами, которые приводят к вариациям в структуре и содержании документа с требованиями, делают их неэффективными с точки зрения прослеживаемости и управляемости. Фактически, при создании шаблона для использования в кросс-функциональном упражнении по сбору требований, различные роли с дополнительными знаниями могут столкнуться с трудностями при работе в рамках общего формата. Поэтому крайне важно позволить заинтересованным сторонам, не являющимся специалистами или экспертами, предоставлять дополнительные требования в виде Приложений и дополнительных вложений, чтобы охватить свою область спецификации. Рассмотрение различных нюансов и достижение наилучшего соответствия остается единственной самой большой проблемой для эффективных требований.
Включает в себя следующие этапы:
{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )