Бизнес требования определяют для чего

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

Кунал Миттал, директор по IT,

SonyPictures Entertainment

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

Введение

В первой статье данной серии вы узнали о том, как определять технические требования для проекта SOA (Service-Oriented Architecture – сервис-ориентированная архитектура). Мы начали с обсуждения того, что надо определять раньше — технические требования или требования бизнеса. Хотя «правильного» ответа на этот вопрос нет, судя по моему опыту, часто, если не всегда, SOA-проекты возглавляются департаментами информационных технологий (ИТ), и обсуждения, как правило, начинаются с технологии. В предыдущей статье подробно рассматриваются различные типы технических требований и разнообразные возможные ловушки, которых нужно остерегаться при определении этих требований.

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

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

Эта статья охватывает процесс определения требований и построения первых нескольких сервисов в вашем SOA-проекте. В третьей и последней статье серии мы перейдем от рассмотрения этих нескольких сервисов к вопросам сбора, документирования и управления требованиями для внедрения SOA в корпоративном масштабе.

С чего начать?

В этой статье предполагается, что вы четко определились с технологией SOA. Вы определили начальный набор технических требований для вашей SOA и сейчас спрашиваете себя: «Какие сервисы SOA мне следует внедрить?» Различные ИТ-подразделения вашей организации могут говорить разные вещи: одни захотят внедрить технические сервисы, такие как сервис управления контентом, другие — сервисы, связанные с безопасностью (аутентификация/авторизация), или что-то еще. Однако ключевым в SOA-проекте является первоначальный набор бизнес-требований. Я не хочу вдаваться в полемику о том, с чего начать, я предполагаю, что вы начинаете с бизнес-сервисов. Давайте для начала рассмотрим способы определения требований для этих бизнес-сервисов.

Определение сервиса

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

Определение сервисов сверху вниз

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

2. Виды требований к программному обеспечению. Часть 1. (Курс бизнес-аналитик с нуля)

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

Рисунок 1. Нисходящий подход

Определение сервисов снизу вверх

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

На рисунке 2 показан пример восходящего подхода к определению сервисов. Он не сильно отличается от нисходящего подхода, однако начальные точки существенно различаются.

Рисунок 2. Восходящий подход

В разделе Ресурсы есть ссылка на полезную статью, в которой более подробно обсуждается концепция определения сервисов.

Сбор требований для одного сервиса

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

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

Итак, вы готовы определить требования для своего первого SOA-сервиса. В общем случае вам нужно собрать требования по следующим категориям. Заметьте, что в этой статье мы фокусируемся на бизнес-требованиях, в то время как в предыдущей статье мы обсуждали технические требования для сервиса (сервисов):

● Удобство использования. Как пользователь сервиса сможет найти его и получить к нему доступ? Это требование находится на границе между техническими и бизнес-требованиями. Поэтому подумайте о бизнес-процессе, при котором нужно будет искать и вызывать сервис, который вы создаете.

● Функциональность. Какой базовый бизнес-процесс или процедуру будет обеспечивать ваш сервис? Какие задачи бизнеса вы решаете? Это обсуждение может занять много времени. Вам необходимо определить соответствующий уровень детализации, на котором будут располагаться сервисы в вашей SOA-архитектуре. (См. статью, в которой этот материал обсуждается более подробно, в разделе Ресурсы в конце статьи.)

● Взаимодействие. Как сервис или приложение, которое вызывает сервис, взаимодействует с этим сервисом? Как сервис обрабатывает ошибки?

● Информация. Какие данные посылаются сервису и что он возвращает?

● Процесс. Каковы взаимоотношения между действиями и событиями в сервисе?

Процесс определения требований

Теперь, когда вы знаете, какого рода информацию нужно собрать для требований к сервису, давайте поговорим о самом процессе сбора. За пределами мира SOA вам, возможно, потребовалось бы, чтобы пользователи сервиса или приложения описали языком бизнеса, что должен делать сервис. В мире SOA вам не нужно учитывать мнение всех пользователей (или потенциальных клиентов) сервиса. В данном случае вам нужно, чтобы поставщик сервиса (заинтересованное лицо со стороны бизнеса, по инициативе которого вы создаете сервис) описал то, что он хочет, чтобы сервис выполнял. Потом вам следует проверить это описание с несколькими пользователями сервиса, однако вы не сможете учесть мнение всех потенциальных клиентов, и этого делать не нужно – более того, это невозможно.

Нужно четко понимать, что степень участия заказчиков со стороны бизнеса в вашем SOA-проекте является одним из главных факторов риска проекта. Вам нужно вовлечь менеджмент, показать им значение SOA и убедить их в том, что вы сделаете все «вовремя, быстрее и дешевле» (то, что их волнует).

С точки зрения процесса вам нужно получить от «поставщика» сервисов описание того, какая функциональность будет присутствовать в сервисе и какая отсутствовать. Сначала вы собираете различную информацию, описанную в предыдущей части статьи, используя любую методологию или инструментарий сбора требований: IBM® Rational® Unified Process и IBM Rational RequisitePro® или обычный текстовый документ по итогам импровизированного совещания по требованиям. На этом этапе я бы не рекомендовал слишком формализовать процесс. Идея в том, чтобы быстро реализовать несколько сервисов для демонстрации значимости вашего SOA-проекта. Однако вам все равно нужно как-то задокументировать эти требования.

Документирование требований для одного сервиса

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

Возможно, вам уже приходилось иметь дело со сценариями использования. Это превосходный способ определения требований для SOA-проекта. На рисунке 3 показан пример шаблона сценария использования, который вы можете использовать для документирования своих требований. В Rational RequisitePro и других средствах Rational имеется много других полезных шаблонов.

Дело не в том, какой шаблон использовать. Если вы собираете типы требований, описанные ранее, все будет в порядке.

Рисунок 3. Шаблон сценария использования

Заключение

Итак, после прочтения данной статьи у вас должно сложиться представление о том, как определить несколько первоначальных сервисов для своего SOA-проекта. Вы также узнали о том, как собирать требования для этих сервисов и документировать эти требования с использованием существующих процессов и средств определения требований. В статье «Создание идеальной команды для SOA-проекта» (см. Ресурсы) объясняется, как эффективно организовать вашу команду, а также раскрыта роль бизнес-аналитика в SOA-проекте.

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

Источник: ecm-journal.ru

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

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

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

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

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

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

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

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

Обзор

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

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

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

Темы о бизнес-требованиях

Преимущества

Описание

Роли

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

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

Формат

• Название
• Версия
• Описание изменения
• Автор
• Дата
• Содержание
• Введение
• Цель
• Область применения
• Предпосылки
• Ссылки
• Допущения и ограничения
• Обзор документа
• Методология
• Функциональные требования
• Контекст
• Требования пользователя
• Диаграммы потоков данных
• Логические модель данных / словарь данных
• Другие требования
• Требования к интерфейсу
• Требования к преобразованию данных
• Требования к аппаратному и программному обеспечению
• Рабочие требования
• Приложение A —

Полнота

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

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

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

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

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

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

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

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

Трудности

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

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

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

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

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

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

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

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

1. Определение бизнеса
2. Понимание бизнес-домена (-ов)
3. Цели организации
4. Основная компетенция

См. Также

• Жизненный цикл разработки систем
• Системная инженерия
• Процесс разработки программного обеспечения
• Бизнес-аналитик
• Спецификация требований к программному обеспечению
• Анализ требований
• Требование
• Прототипирование
• Создание прототипов программного обеспечения
• Бизнес-анализ

Библиография

• Бил, Адринана. Требование — это то, что мы должны сделать для достижения цели www.bealprojects.com, 2012
• Голдсмит, Робин Ф. Определение требований реального бизнеса для успеха программных проектов. Artech House, 2004.
• Робертсон, Сюзанна и Джеймс С. Робертсон. Освоение процесса требований. 2nd Edition, Addison-Wesley, 2006.

Источники

1. ^Бил, 2012. стр. 1
2. ^Goldsmith, 2004. стр. 2-6
3. ^https://it.toolbox.com/question/brd- шаблон-документ-функциональный-клиент-требования-040208

Источник: alphapedia.ru

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

Эта статья нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью к добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален
Найдите источники: «Бизнес-требования» – Новости · газеты · книги · ученый · JSTOR ( Февраль 2012 г. ) (Узнайте, как и когда удалить этот шаблон сообщения)

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

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

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

Подобной путаницы можно избежать, если признать, что бизнес-требования не являются целями, а скорее соответствуют целям (т. Е. Обеспечивают ценность) при выполнении. Бизнес-требования что не разлагать на требования к продукту / системе / программному обеспечению как.

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

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

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

• 1 Обзор
• 2 Темы бизнес-требований

• 2.1 Преимущества
• 2.2 Роли
• 2.3 Формат
• 2.4 Полнота

Обзор

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

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

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

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

Преимущества

Описание

Роли

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

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

Формат

Полнота

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

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

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

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

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

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

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

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

Трудности

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

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

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

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

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

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

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

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

1. Определение бизнеса
2. Понять бизнес-домен (-ы)
3. Цели организации
4. Основная компетенция

Источник: wikidea.ru