В этой статье рассмотрим, что такое бизнес-правила, какие они бывают, зачем их определять, анализировать и документировать при описании процессов, а также спецификации требований. Анализ бизнес-правил как техника BABOK®Guide и полезный метод фиксации особенностей предметной области при разработке технического задания (ТЗ) на ПО.
Что такое бизнес-правила: определение BABOK®Guide и примеры
Анализ бизнес-правил является одной из 50 техник BABOK®Guide и используется для выявления, определения, описания, проверки и организации ежедневных операций, а также условий принятия операционных решений. Если бизнес-правила являются основанием для принятия решений, с ними можно дальше работать в технике «Анализ решений», структурировав в виде таблицы или дерева, что мы рассмотрим в следующий раз. А сегодня сфокусируемся именно на технике «Анализ бизнес-правил» (Business Rules Analysis).
Бизнес-правила не стоит путать с организационными (деловыми) политиками, область действия которых шире чем у правил и направлена больше на предприятие в целом, чем на отдельные процессы и управленческие решения. Бизнес-правило — это конкретная проверяемая директива как условие или критерий управления поведением/процессом или принятия рутинных (операционных) решений. Оно всегда практически осуществимо, контролируемо и не требует дополнительной интерпретации для применения в бизнесе. BABOK выделяет 2 категории бизнес-правил:
1. Кто такой бизнес-аналитик и что такое требование? (Курс бизнес-аналитик с нуля)
— определительные, которые относятся не к людям, а отражают операционные знания организации. Например, обращения привилегированных клиентов получают наивысший приоритет. Определительные бизнес-правила невозможно нарушить, но можно неправильно применить. При разработке функциональных требований и их спецификации в ТЗ или SRS такие правила являются основанием для вычислений и изменения поведения/состояний объектов в ходе бизнес-процессов. Например, атрибуту «Статус» объекта «Клиент» задать значение «Привилегированный», если значение атрибута «Сумма заказа» больше 1 млн.
— поведенческие, которые относятся к людям, даже если их поведение автоматизировано. Они используются для организации и регулирования ежедневной деятельности в качестве обязательств или запретов на способы выполнения операций, действия, практики или процедуры.
Часто поведенческие бизнес-правила закреплены в политики организации для снижения рисков или повышения продуктивности. Они могут использовать информацию из определительных правил, чтобы направлять действия людей, обязывая их решать рабочие задачи определённым образом, запрещать какие-то действия или описывать условия корректного выполнения процессов и процедур. Поскольку поведенческие бизнес-правила относятся к людям, они могут быть нарушены. Например, обращение привилегированного клиента должно быть обработано оператором в течение 1-го часа после его поступления независимо от дня недели и времени суток.
Бизнес-правила напрямую связаны с бизнес-требованиями. Например, есть бизнес-требование «Выиграть войну (стать победителем)». Связанные с ним определительные бизнес-правила могут звучать так: «Выигрывает в войне, т.е. становится победителем тот, кто захватил всю территорию противника» и «Дата окончания войны фиксируется в акте капитуляции от проигравшей стороны». А поведенческое бизнес-правило в этом кейсе может быть таким: «Проигравший должен выплатить денежную контрибуцию победителю в течение месяца после окончания войны».
2. Виды требований к программному обеспечению. Часть 1. (Курс бизнес-аналитик с нуля)
Как анализировать бизнес-правила: рекомендации BABOK®Guide
BABOK отмечает, что техника анализа бизнес-правил включает следующие действия:
— сбор из явных и неявных источников (организационные регламенты и другие внутренние документы, договоры, контракты, деловые политики, отраслевые стандарты, эксперты предметной области и другие стейкхолдеры, а также негласные, но общепринятые практики и нормы корпоративной культуры);
— описание в виде текстовых определений (для определительных бизнес-правил) или наглядных схем бизнес-процессов в формальных нотаций моделирования (IDEF0, BPMN, EPC или UML) для поведенческих бизнес-правил;
— валидация описанных бизнес-правил, т.е. их проверка на соответствие реальности со стейкхолдерами, которые могут это подтвердить или опровергнуть;
— уточнение описанных и проверенных бизнес-правил, чтобы они лучше соответствовали реальности и бизнес-целям;
— организация описанных и проверенных бизнес-правил так, чтобы их было удобно использовать и администрировать по мере необходимости, т.е. изменять, создавать их новые версии, выводить из эксплуатации (объявлять устаревшими).
Все эти действия направлены на то, чтобы сделать бизнес-правила явными, конкретными, ясными, доступными и централизованными. Если по результатам сбора информации из явных и неявных источников бизнес-аналитику необходимо сформулировать правило самостоятельно, BABOK®Guide рекомендует придерживаться следующих принципов:
— говорить на языке стейкхолдеров в терминах профессионального жаргона или глоссария организации/отрасли, чтобы эксперты предметной области смогли быстро их понять и подтвердить или опровергнуть;
— формулировать атомарно и декларативно, отделяя их от точек применения (бизнес-процессы или принятие решений), чтобы обеспечить возможность повторного использования. Однако, ссылку на процессы или управленческие решения, которые бизнес-правила поддерживают или ограничивают, поставить следует.
— предусмотреть способы их хранения и поддержки так, чтобы по мере развития бизнеса и влияния внешних обстоятельств правила была возможность отслеживать и менять правила.
Таким образом, можно сказать, что бизнес-правила являются своеобразной структурой регулирования поведения, а их ясное определение и администрирование позволяет организации корректировать свои деловые политики без изменения процессов или систем. Однако, если бизнес-правил слишком много, они описаны некорректно, сформулированы непонятно, не соответствуют действительности или противоречат друг другу, то ценность этого артефакта невелика. Впрочем, одной из рабочих обязанностей бизнес-аналитика является как раз наведение порядка в бизнес-правилах. Однако, разработка и улучшение организационных регламентов с помощью анализа бизнес-правил — не единственное приложение этой техники BABOK. BABOK®Guide рекомендует применять ее для решения следующих задач:
— планирование вовлечения стейкхолдеров из области знаний «Планирование и мониторинг бизнес-анализа»;
— проведение выявления из области знаний «Выявление и сотрудничество»;
— поддержание требований из «Управление жизненным циклом требований»;
— оценка изменений требований из «Управление жизненным циклом требований»;
— спецификация и моделирование требований из области знаний «Анализ требований и определение дизайна»;
Как именно бизнес-правила связаны со спецификацией требований в ТЗ и SRS мы рассмотрим далее.
Анализ бизнес-правил в спецификации требований
Популярный сегодня международный стандарт по инженерии требований ISO IEEE 29148–2011/2018 рекомендует описывать бизнес-правила в пункте SRS «рамки, ограничения, правила и стандарты», раздел «Общее описание». А поскольку помимо спецификации требований к системе и к ПО, стандарт ISO IEEE 29148–2011/2018 включает еще документ спецификации требований стейкхолдеров (StRS, Stakeholders Requirements Specification), неудивительно, что в нем также есть раздел, посвященный бизнес-правилам и политикам. В частности, именно в нем в качестве бизнес-правил рекомендуется описывать:
— операционные аспекты логики выполнения бизнес-процессов;
— критерии оценки бизнес-процессов или формулы количественной/качественной оценки показателей, которые влияют на функциональные требования к ПО (в SRS).
При этом все перечисленные бизнес-политики и правила должны иметь однозначные имена и номера со ссылками на описание бизнес-процессов. Подробнее о структуре и назначении ISO IEEE 29148–2011/2018, а также других стандартов спецификации требований и разработки ТЗ читайте здесь. Также предлагаю вам открытый интерактивный тест на знание стандартов разработки ТЗ и спецификации требований к ПО.
Освоить все практические приемы разработки требований и их спецификации в виде ТЗ и SRS вам поможет мой авторский курс «Разработка ТЗ на информационную систему» в нашей Школе прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве.
А проверить уровень своего знакомства с BABOK вы можете самостоятельно, выпонив бесплатные интерактивные тесты по содержанию этого руководства к своду знаний по бизнес-анализу, включая кейсы, похожие на вопросы сертификационных экзаменов ECBA, CCBA и CBAP:
Источник: medium.com
Анализ требований и бизнес-анализ.
Анализ требований — один из основных рабочих потоков (workflow) программной инженерии, наряду, допустим, с такими, как проектирование интерфейса пользователя, либо программирование.
Для его обозначения в англоязычной литературе, как правило, используется понятие «Requirement Process». В отечественной практике, наряду с обобщающим термином «анализ требований», принятым, в частности, в ГОСТ Р ИСО/МЭК 12207-99, встречаются также такие термины, как «поток работ», «требования», «работа с требованиями», «определение требований» и т.д., что вносит изрядную путаницу. Для того, чтобы внести некоторую ясность, рассмотрим декомпозицию рабочего потока Requirement Process на составляющие, принятую в SWEBOK, и введем терминологию, которой будем придерживаться на протяжении лекционного курса.
SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:
Requirements Elicitation (Извлечение требований),
Requirements Analysis (Анализ требований в узком смысле),
Requirements Specification (Специфицирование требований),
Requirements Validation (Проверка требований).
В качестве примера альтернативной декомпозиции потока работ можно рассмотреть взгляд, предложенный в RUP. RUP предлагает выделить в основном потоке анализа требований такие компоненты, как:
Analyze the Problem (Анализ проблемы),
Understand Stakeholder Needs (Понимание потребностей совладельцев),
Define the System (Определение системы),
Manage the Scope of the System (Управление контекстом системы),
Refine the System Definition (Уточнение определения системы).
Обобщая указанные выше декомпозиции, а также подходы, далее будем придерживаться следующей, более удобной в методическом плане схемой декомпозиции потока работ «Работа с требованиями»:
Классификация и спецификация требований;
Расширенный анализ требований (моделирование и прототипирование);
Совершенствование процесса работы с требованиями.
Первые 6 работ в лекционном курсе рассматриваются, как компоненты процесса анализа требований.
Для того, чтобы успешно создать автоматизированную информационную систему (или шире, программную систему), необходимо, во-первых, определить компоненты потока работ, которые будут использоваться командой разработчиков и, во-вторых, правильно их организовать. В вопросы организации входит упорядочение работ во времени, интерфейсы между ними, параллелизм, работа с рисками и многое другое.
Найти ответ на первый вопрос может помочь общая классификация задач, работ и операций программной инженерии, представленная в ГОСТ Р ИСО/МЭК 12207-99. Другая, более поздняя по времени классификация, присутствует в SWEBOK. Однако нужно отметить, что данные руководящие документы рассматривают общий случай, а в частном проекте может быть задействован далеко не весь арсенал работ.
Сложнее — с решением второго вопроса. На сегодня существуют и имеют примеры успешного применения десятки и сотни различных методологий (процессов), среди наиболее известных — MSF, RUP, Oracle PJM, XP, FDD, SCRUM, PSP, Crystal, DSDM. Методологии подразделяются на 3 «волны»: каскадные (исторически первые), прогнозирующие (например, RUP) и «гибкие» (agile), вошедшие в широкую практику на рубеже тысячелетий.
Описания методологий существенно разнятся объемом (от десятков до тысяч страниц текста), наборами базовых работ и рабочих квалификаций, акцентами (работа с моделями, управление рисками, построение команды и пр.). Но авторы их описаний обычно сходятся в одном: лучшая из методологий, которой нужно следовать, чтобы добиться успеха — именно та, которую предлагает (описывает, рекламирует) автор. Редким исключением являются работы А. Коберна, автора группы методологий Crystal, где он предлагает брать за основу не «самый лучший» из процессов, а тот, который, во-первых, наилучшим образом соответствует проектной задаче, а во вторых — команде, которая будет его реализовывать. Вводится несколько метрик, позволяющих частично формализовать процесс подбора методологии.
Почему нужно анализировать требования?
Из сказанного выше следует, что не все работы и операции, известные в программной инженерии, используются в той или иной методологии и, тем более, конкретном проекте. Возникает вопрос: является ли рабочий поток АТ необходимым в цепочке рабочих потоков создания информационной системы, стоит ли тратить на него время? Каков требуемый объем результатов, ожидаемых от АТ?
Со всей очевидностью можно утверждать: да, АТ, как этап разработки ИС, невозможно пропустить: этот этап закладывает фундамент всего процесса проектирования и реализации системы. Степень проработки АТ может быть различной: от совершенно неформальной записки, представленной на одной странице, до развернутой системы документов, моделей и прототипов, построенной в соответствии с принципами одной из прогнозирующих методологий, например, RUP. Она зависит от следующих основных факторов: размеров проекта, величины имеющихся ресурсов и степени рисков. Невысокая глубина проработки приемлема для небольших проектов, характеризующихся небольшим ресурсом и невысокими рисками. Хорошо проработанные требования позволяют:
выработать общее понимание между Заказчиком и Разработчиком;
определить рамки проекта;
более точно определить финансовые и временные характеристики проекта;
обезопасить Заказчика от риска получить продукт, в котором он не сможет работать,
обезопасить Разработчика от риска попасть в ситуацию «неконтролируемого размытия границ», которое может привести к непредвиденным затратам ресурсов сверх начальных ожиданий.
Анализ требований — это процесс (бизнес-процесс) и, следовательно, к нему подходят методы и средства процессного подхода к управлению.
Один из ключевых вопросов, позволяющих оценить результативность процесса — что является выходом (результатом) процесса. В чем результат АТ? Результатом рабочего потока «анализ требований» является набор артефактов. Это могут быть текстовые документы, модели UML, либо других языков моделирования, прототипы программного обеспечения.
Другой важный вопрос — какие цели преследует процесс.
RUP предлагает следующие цели для потока работ АТ:
добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система;
дать разработчикам наилучшее понимание требований к системе;
определить границы системы;
определить интерфейс пользователя и системы.
19. Акторы и варианты использования
Результатом выявления требований, является реестр требований. Требования совладельцев обычно оформляются в простой письменной форме, без какой-либо особой регламентации. Типовой пример оформления требования к программе электронной почты — «Система должна позволять набирать текст сообщения с возможностью форматирования текста и вставки смайликов». Данные требования далеко не во всем могут удовлетворять критериям: они могут противоречить друг другу, быть неясными, неточными и т.д. Тем не менее, документ «Требования совладельцев», несмотря на невысокий уровень формализации, играет очень важную роль: в нем собраны мнения всех заинтересованных сторон и главная цель сбора начальных требований заключалась в том, чтобы получить по возможности как можно более полный набор требований, не пропустив чего-то важного.
Для того, чтобы повысить уровень информативности требований, устранить взаимные противоречия и добиться выполнения их других основных характеристик, осуществляется переход от полностью неформализованных текстов к частично регламентированным (например, шаблонам MS Word) текстам, классификация, присвоение наборов атрибутов, построение моделей, прототипирование.
Самым популярным и весьма эффективным способом повышения информативности требований является оформление их в виде вариантов использования (use case), предложенный И.Якобсоном
Прежде, чем приступить собственно к специфицированию требований в форме вариантов использования, RUP рекомендует выявить реестр акторов (actors) и вариантов использования.
Актор — это некто или нечто, обладающее активностью по отношению к программной системе. Если вы разрабатываете простой текстовый редактор, то, скорее всего, выбор актора не составит особого труда: это будет пользователь, набирающий текст. Однако не всегда все так просто.
Помимо пользователя в качестве актора может рассматриваться другая программная система, аппаратное устройство, в ряде случаев — активная компонента самой системы. Поиск акторовкорпоративной информационной системы обычно сводится к анализу ролей различных пользователей. Менеджер по продажам, старший менеджер и начальник отдела продаж — один актор, два или три?
Это зависит от их функциональных обязанностей, разграничения доступа, способов использования информационной системы. Поиск акторов может осуществляться, например методом мозгового штурма. В дальнейшем при необходимости найденные акторы могут обобщаться, пересматриваться и объединяться.
Вариант использования в первом приближении можно рассматривать, просто, как функцию, реализуемую системой. Однако, современный взгляд на организацию бизнеса говорит о том, что всякая функция должна иметь ценность для конечного потребителя продукта или услуги.
Философия варианта использования предполагает выделение среди всего функционала системы подмножества, полезного конкретному конечному пользователю (точнее говоря, типу конечного пользователя). Другая сторона — вариант использования должен не только быть полезен, а еще и позволять получать КП конкретные законченные результаты.
Так, одной из функций текстового редактора, очевидно, является создание пустого файла. Но вряд ли КП будет использовать редактор с целью изготовления пустых файлов. Следовательно, создание пустого файла — функция, но не вариант использования системы. Вариантом использования может быть, например, подготовка в текстовом редакторе служебной записки. Вариант использования реализуется через функции системы.
Use Case Diagram
Диаграмма вариантов использования
Диаграмма вариантов использования UML, Use Case Diagram — одно из самых простых представлений системы. Ее базовые «строительные элементы» — акторы и варианты использования. Диаграмма задумана так, чтобы дать наиболее общее представление о функциональности системы (ее компоненты), не вдаваясь в детали взаимосвязей функций. Поэтому основной вид отношения, используемый в диаграмме — ассоциация между актором и вариантом использования.
Другие виды отношений — отношение включения (include), расширения (extend) и обобщения/генерализации.
Включение служит для обозначения подчиненных вариантов использования (когда один или более вариантов использования содержат вызовы одной и той же функциональности).
Расширение в точности соответствует точке расширения, используемой при описании варианта использования.
Отношение обобщения может применяться как к акторам, так и к вариантам использования, с целью указания специализации одних относительно других.
Источник: megalektsii.ru
Описание статусов и атрибутов требования в соответствии с BABOK 3.0
Сегодня я предлагаю рассмотреть такую важную вещь, как статусы требований.
Начнём с определения термина «статус». Вот что говорит про статус Википедия:
Статус (лат. Status — состояние, положение) — абстрактное многозначное слово (термин), в общем смысле обозначающий совокупность стабильных значений параметров объекта или субъекта. С упрощённой точки зрения статус объекта или субъекта — это его состояние либо позиция, ранг в любой иерархии, структуре, системе, времени и ином.
В принципе, понятно что имеется ввиду, но интересует статус именно требования. Глоссарий BABOK 3.0 не содержит определения термина «статус требования», но в задаче по бизнес-анализу 3.4 «Планирование управления информацией по бизнес-анализу» приводится пример определения термина «статус требования» (здесь и далее синим шрифтом выделен переведенный на русский язык текст BABOK 3.0):
Статус (требования): указывает состояние требования, независимо от того, предлагается оно, принято, проверено, отложено, отменено или выполнено.
Вообще, в своде знаний уделяется значительное место обсуждению требований, в том числе их статусам, но, к сожалению, внятной и однозначной схемы статусов требований не приводится.
В подготовительных материалах к экзамену CBAP в соответствии с требованиями BABOK 2.0 содержалась вот такая схема статусов требований:
С выходом новой версии BABOK 3.0 данная схема потеряла свою актуальность и чтобы понять новую систему статусов (и атрибутов) требования, которую предлагает BABOK 3.0, придётся проштудировать весь свод знаний, и особенно области знаний «Описание анализа требований и дизайна» и «Управление жизненным циклом требований».
Специфицировано и смоделировано
И специфицировано, и смоделировано (specified and modelled). Да, да, именно так. Практически два статуса в одном.
Специфицированные и смоделированные требования получаются в результате выполнения задачи по бизнес-анализу 7.1 «Спецификация и моделирование требований», входом для которой являются любые результаты выявления (elicatation), а выходом – любая комбинация требований иили дизайна требований в форме текста, матриц и диаграмм. Свод знаний весьма широко трактует «результаты выявления» – фактически это может быть любая информация, полученная аналитиком. С точки зрения жизненного цикла требования – это, фактически, рождение требования.
Однако, в своде знаний содержится и некоторая непоследовательность. В глоссарии приводится ещё один статус требования, который должен был бы находиться ещё раньше по жизненному циклу:
Заявленное (stated) требование: требование, сформулированное заинтересованной стороной, которое не было проанализировано, проверено или подтверждено. Заявленные требования зачастую отражают желания заинтересованной стороны, а не фактические потребности.
Очевидно, что заявленное требование появляется раньше, чем специфицированноесмоделированное. Но, в BABOK 3.0 нет задачи, входом или выходом которой является требование с пометкой «заявленное».
Верифицировано (проверено)
После того, как требование специфицировано, его надо проверить (верифицировать). Про верифицированное требование глоссарий BABOK утверждает следующее:
Верифицированное (verified) требование: требование, которое было рассмотрено и определено как правильное, соответствует стандартам или руководящим принципам и находится на приемлемом уровне детализации.
Верифицированные требования получаются в результате выполнения задачи по бизнес-анализу 7.2 «Верификация требований», входом для которой являются специфицированные и смоделированные требования (результаты задачи 7.1).
Валидировано (подтверждено)
После того, как требование проверено на корректностьправильность, его надо подтвердить. Про валидированное требование глоссарий BABOK говорит следующее:
Подтвержденное (validated) требование: требование, которое было рассмотрено и определено для поддержки предоставления ожидаемых выгод и находится в пределах скоупа (области решения).
Валидированные требования получаются в результате выполнения задачи по бизнес-анализу 7.3 «Валидация требований», входом для которой являются верифицированные требования (результаты задачи 7.2).
Утверждено (approved)
Утверждению требований в BABOK 3.0 посвящена отдельная задача по бизнес-анализу 5.5 «Утверждение требований». И в этом вопросе BABOK однозначен – утверждено может быть только проверенное (verified) требование.
Промежуточный итог
Подведём промежуточный итог. По результатам анализа областей знания, связанных с требованиями, получилось четыре возможных состояния, в которых может находиться статус требования:
- Специфицировано и смоделировано (specified and modelled)
- Верифицировано (verified)
- Валидировано (validated)
- Утверждено (approved)
Переход между этими статусами чётко определён в BABOK, получается небольшая, но вполне логичная схема. Кому-то может и её хватить для работы. Но давайте посмотрим, какие ещё состояния требования описывает BABOK.
Для этого необходимо чуть глубже проанализировать задачи по бизнес-анализу, которые включены в свод знаний.
Приоритет
Входом для задачи по бизнес-анализу 5.3 «Приоритизация требований» являются любые требования в виде текста, матриц или диаграмм, готовые к приоритезации. Но является ли «приоритет» требования статусом или же это отдельный, самостоятельный атрибут?
Ответ на это можно найти в описании задачи по бизнес-анализу 3.4 «Планирование управления информацией по бизнес-анализу». На странице 45 приведен примерный перечень атрибутов требования:
Таким образом, согласно BABOK, приоритет требования – это отдельный от статуса атрибут требования. Приоритет можно присвоить требованию с любым статусом, главное, чтобы оно было готово для приоритезации. Подтверждением того, что приоритет является самостоятельным атрибутом, согласно BABOK 3.0 является то, что одним из входов задачи по бизнес-анализу 7.5 «Определение параметров дизайна» (Define Design Options) являются подтвержденные (validated) и проиритизированные (prioritiezed) требования.
Трассировано
Что же такое – «трассировка требований»? BABOK утверждает следующее:
Трассировка требований включает в себя анализ и поддержание отношений между требованиями, дизайном требований, компонентами решения, и другими результатами работ. Цель трассировки требований заключается в обеспечении соответствия требований и дизайна на различных уровнях друг с другом, а также в управлении последствиями изменения связанных требований.
Трассированы могут быть любые виды требований, BABOK не накладывает никаких ограничений: цели, задачи, бизнес-требования, требования заинтересованных сторон, требования решения и требования перехода, компоненты решения, визуальные элементы, бизнес-правила и другие рабочие продукты.
В общем, практически все результаты бизнес-анализа могут быть трассированы. Трассировке требований посвящена отдельная задача по бизнес-анализу 5.1 «Трассировка требований».
Аллоцировано (распределено)
В BABOK 3.0 появилась новая задача по бизнес-анализу 7.5 «Определение параметров дизайна» (Define Design Options), которая вобрала в себя несколько задач, существовавших в BABOK 2.0, в том числе задачу 7.2 «Аллокация требований» (Allocate Requirements).
Требования могут быть распределены (аллоцированы) между подразделениями, должностными функциями, компонентами или релизами решения. Распределение требований обычно начинается с определения подхода к решению и продолжается до тех пор, пока не будут распределены все допустимые требования. Распределение обычно продолжается в процессе разработки и внедрения решения.
Глоссарий BABOK содержит следующее определение аллокации:
Распределение (allocation) требований: процесс назначения требований, которые должны быть реализованы конкретными компонентами решения.
Однако ни на входе, ни на выходе какой-либо задачи по бизнес-анализу нет требований с пометкой «аллоцировано» (allocated).
Из всего вышесказанного можно сделать вывод, что «аллоцировано» является отдельным, самостоятельным атрибутом требования, по аналогии с атрибутом «приоритет».
Поддержано в актуальности (maintained)
Цель поддержки требований в актуальном состоянии – сохранить точность и цельность требования во время и после его изменения, в течение всего жизненного цикла требования, и чтобы поддержать повторное пользование требований в других решениях.
Результатом выполнения задачи 5.2 «Поддержка требований в актуальности» по бизнес-анализу являются требования, которые:
определены один раз и доступны для долгосрочного использования организацией. Они могут стать активами организационного процесса или использоваться в будущих инициативах. В некоторых случаях требование, которое не было утверждено или выполнено, может быть сохранено для возможной будущей инициативы.
Прожуточный итог
В дополнение к описанным выше статусам требования, свод знаний содержит описания ещё как минимум четырёх атрибутов требования:
- Приоритезировано (prioritiezed)
- Трассировано (traced)
- Поддержано в актальности (maintained)
- Аллоцировано (allocated)
Выводы
Статья получилась немаленькая, пора подвести окончательные выводы. В своде знаний по бизнес-анализу содержатся начальные сведения по статусной схеме требований. Их можно взять за основу при проектировании жизненного цикла требований:
- Специфицировано и смоделировано (specified and modelled)
- Верифицировано (verified)
- Валидировано (validated)
- Утверждено (approved)
Помимо статусов, свод знаний содержит набор важных атрибутов требования, связанных со статусами:
- Приоритезировано (prioritiezed)
- Трассировано (traced)
- Поддержано в актальности (maintained)
- Аллоцировано (allocated)
Можно, конечно, воплотить приведенную схему статусов и атрибутов требования «как есть» и работать по ней, но лучше будет всё-таки адаптировать схему под нужды вашей организации.
Успехов в бизнес-анализе в общем, и в управлении требованиями в частности!
Статусы и атрибуты требования в BABOK 3.0
- ← Бесплатная книга по основам стандарта BABOK 3.0
- BABOK 3.0 Метод “Прототипирование” →
Подписка на рассылку
Если Вы хотите первыми узнавать о новых статьях и анонсах мероприятий — подписывайтесь на рассылку с сайта!
Онлайн-тренинг «Моделирование бизнес-процессов в BPMN 2.0»
Тренинг состоится в онлайн-формате 22.05.2023 — 25.05.2023 с 14.00 до 17.30 по московскому времени
Популярные тренинги
- Моделирование на BPMN 2.0
- Моделирование в Archimate 3.1
- Управление требованиями в AGILE
- Лучшие методы бизнес-анализа
- Тренинг “Основы AGILE и SCRUM”
Лучшее по стандарту BABOK 3.0
- Бесплатная книга по основам стандарта BABOK 3.0
- BABOK 3.0 Метод “Прототипирование”
- 50 методов BABOK 3.0
- Область знания “Оценка решения” BABOK 3.0. Введение
- Статусы и атрибуты требования в BABOK 3.0
- BABOK 3.0 Метод «Интервью»
- BABOK 3.0 и Sparx Architect
- BABOK 3.0. Метод «Lessons learned»
- BABOK 3.0 Метод “Collaborative Games”
Лучшее по КорпАрхитектуре
- Опубликована новая версия TOGAF 9.2
- Gartner Magic Quadrant for EA Tools 2017
- Отчёт Forrester по корпоративной архитектуре Q2 2017
- Таблица Захмана (Zachman) в Sparx Enterprise Architect 13
- Пример моделирования на Sparx Enterprise Architect 13
- Эволюция фреймворка Захмана (Zachman)
- Архитектура федеральной организации 2.0 (FEAF)
Рубрики
- Бизнес-анализ (23)
- Книги (3)
- Корпоративная архитектура (12)
- Обучение (8)
- Тренинги по бизнес-анализу (3)
Теги
Новое в блоге
- BPMN: что почитать на английском языке 24.03.2023
- BPMN: что почитать на русском языке 23.03.2023
- BPMN: как работает неэксклюзивный шлюз 21.03.2023
- Чем может быть полезен свод знаний BABOK? 22.05.2022
- Сколько заработали аналитики в 2019 году 12.05.2020
- Паттерны требований к программному обеспечению 17.08.2018
- Подход к бизнес-анализу (BABOK V3.0) 15.08.2018
- Опубликована новая версия TOGAF 9.2 23.05.2018
- BABOK 3.0 Метод “Прототипирование” 31.01.2018
- Статусы и атрибуты требования в BABOK 3.0 29.01.2018
Источник: olegburko.ru
