ОСНОВЫ
Потребности и требования
Дадим определения и расскажем зачем столько разных типов
Что такое потребности и требования
!
Потребность бизнеса это утверждение, описывающее необходимое изменение для поддержания стратегии организации.
Обычно потребность бизнеса конкретизирует стратегию организации в одном из аспектов или направлений.
В России редко пользуются термином «потребность» и редко разделяют «потребность» и «требование». В большинстве случаев имея в виду «Business need» в России говорят бизнес-требование (или жаргонно — хотелка), а процесс преобразования хотелок в бизнес-требования называют как «конкретизацией бизнес-требований» так и бизнес-анализом.
С точки зрения бизнес-анализа, важно выделить потребность, не имеющую достаточную степень детализации и для которой ещё не выполняются строгие условия формулирования так, чтобы считать её требованием, однако, которая несёт фундамент требований, стартовую точку на пути их выявления и контекст всего требуемого изменения.
В России редко пользуются термином «потребность» и редко разделяют «потребность» и «требование». В большинстве случаев имея в виду «Business need» в России говорят бизнес-требование (или жаргонно — хотелка), а процесс преобразования хотелок в бизнес-требования называют как «конкретизацией бизнес-требований» так и бизнес-анализом.
С точки зрения бизнес-анализа, важно выделить потребность, не имеющую достаточную степень детализации и для которой ещё не выполняются строгие условия формулирования так, чтобы считать её требованием, однако, которая несёт фундамент требований, стартовую точку на пути их выявления и контекст всего требуемого изменения.
!
PMI определяет требование как свойство или способность, которая должна присутствовать в продукте или сервисе для удовлетворения потребности бизнеса.
Инжиниринг систем определяет требование намного более конкретно и ссылается на стандарт ISO/IEC 42010:2007:
!
Требование — утверждение однозначно идентифицирующее операционную, функциональную или конструкционную характеристику или ограничение продукта или процесса, которое должно быть проверяемым или измеримым и необходимым для приёмки.
По типам требований PMI и инжиниринг систем полностью тождественны:
- Бизнес-требования;
- Требования заинтересованных сторон;
- Системные требования. PMI называет их Solution requirement, то есть требования к решению, и делит их на 2 стандартные категории: функциональные требования и нефункциональные требования. Системная инженерия отдельно выделяет требования к элементам системы или требования к субсистеме;
- Переходные требования.
Насколько аналитик участвует в выявлении и формулировании требований каждого типа сильно зависит от организации. Я видел и участвовал в обоих экстремальных случая: когда один аналитик (независимо от названия роли) занимается всеми типами требований; когда один аналитик занимается строго одним типом требований.
У каждого из этих подходов свои недостатки и достоинства: один аналитик, занимающийся всеми типами требований, не тратит время на транспортировку информации; когда у каждого типа требований свой аналитик осуществляется дополнительный контроль при каждой транспортировке, трансформации и декомпозиции требований, что может быть критически важно, например, при учёте регуляторных требований или угрозе жизни.
У каждого из этих подходов свои недостатки и достоинства: один аналитик, занимающийся всеми типами требований, не тратит время на транспортировку информации; когда у каждого типа требований свой аналитик осуществляется дополнительный контроль при каждой транспортировке, трансформации и декомпозиции требований, что может быть критически важно, например, при учёте регуляторных требований или угрозе жизни.
Типы требований
- ТипБизнес-требованиеОписаниеВысокоуровневое описание потребностей организации, например, проблемы бизнеса или возможности для развития или роста.
Хорошие бизнес-требования включают контекст: откуда и почему такие требования появились; как требования удовлетворяют целям и стратегии организации; ограничения, учтённые при формулировании требований.
Часто такие требования составляются на предпроектной стадии. На основе бизнес-требований могут приниматься решения о старте разработки/доработки продукта и запуске проекта или нескольких проектов. - ТипТребования заинтересованных сторонОписаниеОписывают требования конкретной заинтересованной стороны, которая определяется PMI следующим образом — лицо, группа лиц или организация, которые оказывают или могут оказывать влияние на проект или продукт или, на которых проект или продукт оказывает или может оказывать влияние.
Например, заказчик, пользователи продукта, поставщик компоненты продукта, регуляторный орган.
В крупных организациях часто находится заинтересованная сторона в каждом департаменте, вовлечённом в продуктовый бизнес-процесс: заказчик, фронт-офис, риски, мидл-офис, бек-офис и поддержка. При этом у каждой заинтересованной стороны могут быть требования соответствующего регуляторного или надзирающего органа. - ТипТребования к продукту / системные требованияОписаниеОписывают характеристики и функции продукта, которые необходимо иметь, чтобы удовлетворять бизнес-требованиям и требованиям заинтересованных сторон.
Основа продукта, кульминация процесса выявления и структуризации требований. Делятся на функциональные и нефункциональные.
- ПодтипФункциональные требования к продуктуОписаниеОписывают поведение продукта, то есть что, как, почему и в каких ситуациях продукт должен выполнять
Включают текстовое описание, модели, процессы и диаграммы, use cases и т. д. - ПодтипНефункциональные требования к продуктуОписаниеОписывают условия и качества, необходимые для эффективного функционирования продукта.
Включают требования к надёжности, безопасности, обеспечению поддержки т.д.
- ТипТребования переходного периодаОписаниеОписывают временные, но необходимые качества для перехода к эффективной операционной деятельности.
Например, миграция данных или обучение персонала.
Зачем требованиям типы и жизненный цикл
“
Почему бизнес-анализ и инжиниринг систем выделяет такое количество разных типов требований и ещё и разделяет на потребности и требования?
Разве это не искусственное усложнение?
Разве это не создаёт искусственный жизненный цикл, без которого рождение продукта проходило бы быстрее?
Почему ничего не меняется в зависимости от типа жизненного цикла проекта? Почему как в гибком, так и в негибком жизненном цикле не разные типы требований и потребностей?
Разве это не искусственное усложнение?
Разве это не создаёт искусственный жизненный цикл, без которого рождение продукта проходило бы быстрее?
Почему ничего не меняется в зависимости от типа жизненного цикла проекта? Почему как в гибком, так и в негибком жизненном цикле не разные типы требований и потребностей?
В организациях ограничен бюджет (за редким исключением суперкорпораций, которые могут себе позволить выделять миллиарды долларов на исследования, не приносящие прямой выгоды) и ресурсы: как человеческие, так и материальные.
Кроме бюджета и ресурсов, что возможно ещё важнее — у организаций существует конкуренция, а значит время играет важную роль. Организации физически неспособны использовать все предоставляющиеся благоприятные возможности и решать все выявленные проблемы — свои или клиента.
Обладая такими ограничениями, нужно тщательно относиться к выбору активностей, в которые будут инвестироваться время и ресурсы. В высококонкурентной среде несколько неверно выявленных или проанализированных потребностей могут привести к гибели компании из-за реализации провальных продуктов.
Даже в низкоконкуретной среде всегда есть риск непринятия продукта рынком или принятия не в том объёме, чтобы поддерживать в организации жизнь. Нельзя забывать, что причиной низкой конкурентности может быть специфика данной индустрии или отрасли, или просто-напросто крохотный размер рынка и низкая маржинальность.
Контринтуитивная часть бизнес-анализа в том, что дешевле и быстрее потратить время (часто немаленькое) на выявление и анализ требований, чем нести высокие риски через разработку и производство, причём ситуация инвариантна к типу жизненного цикла проекта, потому, что жизненный цикл продукта независим от него.
Работа с требованиями может и должна выполняться не только при старте нового продукта, но и при изменении уже эксплуатируемого. Эти изменения, хоть они и не несут переход от несуществующего продукта к существующему, подвержены тем же самым рискам, и вдобавок дополнительным, связанным с непринятием изменений в полюбившихся и привычных механизмах продукта. Некорректное изменение продукта может так же, как и создание непродуманного продукта привести к тяжёлым финансовым потерям или даже банкротству.
Кроме бюджета и ресурсов, что возможно ещё важнее — у организаций существует конкуренция, а значит время играет важную роль. Организации физически неспособны использовать все предоставляющиеся благоприятные возможности и решать все выявленные проблемы — свои или клиента.
Обладая такими ограничениями, нужно тщательно относиться к выбору активностей, в которые будут инвестироваться время и ресурсы. В высококонкурентной среде несколько неверно выявленных или проанализированных потребностей могут привести к гибели компании из-за реализации провальных продуктов.
Даже в низкоконкуретной среде всегда есть риск непринятия продукта рынком или принятия не в том объёме, чтобы поддерживать в организации жизнь. Нельзя забывать, что причиной низкой конкурентности может быть специфика данной индустрии или отрасли, или просто-напросто крохотный размер рынка и низкая маржинальность.
Контринтуитивная часть бизнес-анализа в том, что дешевле и быстрее потратить время (часто немаленькое) на выявление и анализ требований, чем нести высокие риски через разработку и производство, причём ситуация инвариантна к типу жизненного цикла проекта, потому, что жизненный цикл продукта независим от него.
Работа с требованиями может и должна выполняться не только при старте нового продукта, но и при изменении уже эксплуатируемого. Эти изменения, хоть они и не несут переход от несуществующего продукта к существующему, подвержены тем же самым рискам, и вдобавок дополнительным, связанным с непринятием изменений в полюбившихся и привычных механизмах продукта. Некорректное изменение продукта может так же, как и создание непродуманного продукта привести к тяжёлым финансовым потерям или даже банкротству.
Каждый тип требования оперирует на своём информационном уровне: системные требования редко требуют анализа рынка, тогда как оценка потребностей бизнеса редко диктует низкоуровневые требования к системе (а если диктует, то имеет для этого конкретное обоснование, связанное с контекстом проблемы или благоприятной возможности).
В рамках выявления потребностей анализируется информация не только о проблемах организации, но и о её окружающем мире — конкуренты, рынок, регуляторы и так далее. Этот этап наименее конкретен с точки зрения описания конечного продукта и, более того, по результатам такого выявления может быть принято решение о том, что никакой продукт запускать нет потребности. Это этап определения контекста для продукта, его обоснования, а результат анализа также диктует глобальные ограничения и допущения.
Бизнес-требования конкретизируют потребности бизнеса. Очерчивают границы продукта: что должно быть включено, а что нет и почему; какие конкретные проблемы решает продукт или какие конкретные возможности обязан реализовать, а что остаётся за рамками состава продукта и почему.
Требования заинтересованных сторон формулируют все возможные допущения, ограничения и детализируют бизнес-требования, обычно с точки зрения компетенции и функциональных обязанностей стороны, у которой соответствующие требования выявляются. Например, требования к безопасности — от службы безопасности, требования к бухучёту — со стороны бэк-офиса, требования к отчётности — со стороны регулирующего органа.
Требования к решению / системные требования вбирают в себя все выявленные ранее требования, которые были согласованы для реализации в текущей версии продукта, при этом они формулируются и детализируются так, чтобы передать в разработку.
Уровень детализации и требования к формулировке зависит от отрасли и внутренних норм организации. Внутри одной организации у разных команд разработки могут быть разные требования к формулировке и детализации требований, а значит важно получить их заранее.
На этапе выявления требований к системе почти никогда не решается вопрос о запуске продукта и вместо этого ищется способ реализации согласованного состава функций, которыми обязан обладать продукт.
Уровень детализации и требования к формулировке зависит от отрасли и внутренних норм организации. Внутри одной организации у разных команд разработки могут быть разные требования к формулировке и детализации требований, а значит важно получить их заранее.
На этапе выявления требований к системе почти никогда не решается вопрос о запуске продукта и вместо этого ищется способ реализации согласованного состава функций, которыми обязан обладать продукт.
Прослеживаемость требований
Грамотный подход к управлению жизненным циклом требований обеспечивает одну из самых важных функций бизнес-анализа — прослеживаемость требований. Подробно будет описано множество раз в статьях этого ресурса.
Прямая прослеживаемость — возможность увидеть какими требованиями к системе закрывается каждое конкретное бизнес-требование.
Обратная прослеживаемость — возможность увидеть какое именно бизнес требование породило то или иное требование к системе или её элементу.
Прямая прослеживаемость — возможность увидеть какими требованиями к системе закрывается каждое конкретное бизнес-требование.
Обратная прослеживаемость — возможность увидеть какое именно бизнес требование породило то или иное требование к системе или её элементу.
Прослеживаемость требований это гарантия того, что все бизнес-требования учтены в продукте и только бизнес-требования учтены в продукте (нет паразитных элементов системы или функций, которые не решают поставленную задачу).
Карта статьи
