О чем пишут наши эксперты...

Требования и управление требованиями

Forrester заключает,
что лучшие бизнес-аналитики сочетают в себе темперамент и коммуникативную изобретательность дипломата с аналитическими способностями разведчика.
  
Я бы добавил, что другие бизнес-аналитики нам не нужны.

В.Рудь

Согласно определению BABOK, «бизнес-аналитик выполняет роль посредника (мостика) между всеми заинтересованными сторонами, выявляя, анализируя и утверждая требования к изменениям бизнес-процессов, корпоративных политик и информационных систем». Таким образом, бизнес-аналитик должен понять цели и задачи, стоящие перед организацией  и рекомендовать решение (solution), которое позволит организации достичь поставленных бизнес-целей или создать «механизм» их достижения. Каким образом организация формулирует свои задачи и цели перед аналитиком? Возможно, она выражает их в виде определенных требований, возможно – в виде собственно целей или KPI, а возможно и не выражает их четко (в таких случаях требуются обследование организации/предприятия - enterprise analysis - и четкая локализация ее проблем). Наш опыт показывает, что четко сформулировать цель, проблему или задачу, а тем более требование организации (в особенности – большие организации) не могут и таким образом цикл инжиниринга бизнес-системы в большинстве случаев начинается с обследования организации, на выходе которого появляется либо набор четко сформулированных требований, либо ясное описание проблем/задач, стоящих перед предприятием. Таким образом, требования не являются отправной точкой в цикле дизайна автоматизированной системы или инжиниринга процесса, но занимают центральное место в процессе управления изменением бизнес-системы: требования определяют границы изменения, способы изменения, параметры, показатели, условия, рамки контракта, скоуп проекта, основу для управления качеством и т.п. Так что же такое «требование»? BABOK и я вместе с ним определяем «требование» следующим образом:

  • условие или характеристика, необходимые заинтересованному лицу (stakeholder) для решения задачи или достижения цели;
  • условие или свойство/способность, которые должны быть созданы/достигнуты системой или компонентом системы, чтобы соответствовать контракту, стандарту, спецификации или другому формальному документу;
  • условия, характеристики, допущения и ограничения к отдельным требованиям, ко всем требованиям или группам требований, а также замечания по реализации требований.

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

Требования разделяют на несколько типов. Бизнес-аналитики не были бы бизнес-аналитиками, если бы не сделали это :)   В любом проекте приходится оперировать со следующими типами   требований (привожу типизацию согласно BABOK, но согласен с ней на 100%):

  • Бизнес-требования. Представляют собой высокоуровневые описания целей, задач и потребностей организации, описывают крупные блоки функций будущей системы, описывают контуры новых или изменяющихся бизнес-процессов, описают бизнес-метрики (KPI), общие условия реализации проекта. Не всегда бизнес-требования указывают сразу на решение (solution). 
  • Требования ключевых заинтересованных лиц (stakeholders). Описывают потребности отдельного заинтересованного лица или группы лиц. Очевидно, что такие требования описывают потребности более узко и специфично чем бизнес-требования, сосредотачивая внимание на производственных интересах отдельной группы или даже отдельных индивидов. Babok утверждает, что эти требования являются мостиком между бизнес-требованиями и функциональными/системными требованиями. И это так и есть: требования бизнеса должны всегда выражаться через призму тех, кто этот бизнес осуществляет.
  • Требования, описывающие свойства/параметры/характеристики проектируемого Решения (Solution). Не всегда известно заранее, каким именно будет Решение. Чаще всего Решением будет либо автоматизированная системы, либо организационное/процессное изменение. Поэтому требования этого типа часто называют «Функциональные требования» или «Системные требования». Они описывают поведение системы и способы работы с информацией, которой система будет управлять. Функциональные требования описывают возможности, которые реализует бизнес-система, в терминах выполняемых ею операций. Требования к проектируемому решению делят на три подтипа:

а) Собственно функциональные требования, описывающие поведение системы, ее информационную модель, функции и т.п.

б) Условия функционирования. Определяют внешние условия и ту среду, в которой должно работать Решение. Сюда же относятся требования производительности, безопасности, доступности и т.п..

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

Примечание: хорошее структурирование нефункциональных требований дают ГОСТы 34-й серии.

  • Трансформационные требования – требования переходного периода или Требования реализации. Представляют собой временные требования, описывающие всё, что необходимо для запуска Решения в работу или эксплуатацию. Те аналитики, которые принимали участие в проектах по управлению изменениями (change management) понимают, о чем здесь идет речь. Эти требования описывают возможности, которые решение должно иметь, чтобы упростить переход организации из текущего состояния в задуманное (ToBe). Однако эти возможности перестанут быть актуальными, когда такой переход будет завершен.

Работа с бизнес-изменениями требует от аналитика профессиональных знаний в различных областях. Очевидно, что эти области (в том виде, как они определены в BABOK), представляют собой сплав хорошо сформировавшихся дисциплин, как например, проектное управление, разработка программного обеспечения, change management, так и soft skills– навыков межличностного общения. Вот эти области:

  • Business analysis planning and monitoring: планирование работ по бизнес-анализу и отслеживание хода этих работ;
  • Enterprise analysis: анализ предприятия - это и есть собственно бизнес-анализ в чистом виде;
  • Requirement selicitation: выявление требований (примечание: выявление требований, как активность в проекте, может происходить и в ходе анализа требований. В этом смысле все изложенные здесь области представляют собой перекрывающиеся области знаний);
  • Requirements analysis: анализ требований и сопоставление ожиданий/требований бизнеса со свойствами/требованиями к проектируемому Решению (системе или какому-то виду бизнес-изменений);
  • Solution assessment and validation: оценка и утверждение готового решения, т.е. оценка того, на сколько созданное/проектируемое решение удовлетворяет сформулированным в начале дизайна требованиям.

Описание каждой из этих областей, описание используемых техник, приемов и особенностей вы можете получить на нашем семинаре по управлению требованиями >>>

Услуги компании «Марк Аврелий» в области управления  требованиями >>>

Услуги компании «Марк Аврелий» в области управления проектами >>>

ПРОГРАММА СЕМИНАРА  «Управление требованиями» как базовая составляющая «Бизнес-анализа» для трансформации бизнеса»

Автор: В.Рудь
Дата публикации 05.01.2013



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

Реализованные проекты

все проекты

Наши контакты

Офис компании

105082, г.Москва, Спартаковский переулок, дом 2, строение 1

(495) 922-1240

info@consulo.ru