Бизнес-требования. Назначение и форма

Оглавление

Оглавление

Георгий Савельев

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

Зачем нужны и как их применять

Зачем нужны бизнес-требования?

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

1. Бизнес-требования определяют смысл проекта и обосновывают его необходимость. Если мы в какой-то момент теряем фокус, то всегда можем возвращаться к бизнес-требованиям, как к исходной точке, и опираться на них.
2. Бизнес-требования – это удобный инструмент договоренности: они объективны, компактны и понятны стейкхолдерам. Если бизнес-требования хорошо определены, на них просто и эффективно строить контрактные отношения.
3. Из бизнес-требований вытекают критерии приемки проекта. К ним применяются те же критерии качества, что и к другим типам требований, включая тестируемость. Критерии выполнения бизнес-требований фактически являются готовыми критериями приемки и оценки результатов проекта.
4. Бизнес-требования используются для определения рамок проекта. В различных стандартах, либо определение рамок является частью бизнес-требований, либо наоборот.
5. Бизнес-требования помогают принимать решения о приоритетах. Например, как решить, какую особенность системы важно реализовать раньше, а какую – позже? Если мы понимаем, как функции связаны с теми или иными бизнес-требованиями, такое решение принять легко: при известном приоритете бизнес-требования будет понятен и приоритет связанных с ними функции. А если не понимаем, то спорить можно до бесконечности, и никогда так и не договориться.
6. И, наконец, в Scrum бизнес-требования являются (во всяком случае, так должно быть) основным инструментом владельца продукта для управления продуктовым бэклогом и для согласования его с другими стейкхолдерами.

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

Понятие требований в инженерных стандартах

Стандарт IEEE 610.12−1990 определяет требования как

1. «Условие или возможность, необходимые причастному лицу для решения проблемы или достижения цели»
2. «Подлежащее выполнению условие или способность, которой должно обладать решение или его компонент для соответствия контракту, стандарту, спецификации или другому формальному документу».
3. «Документированное представление условия или возможности в соответствии с п.п. 1 или 2».

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

Второе определение, напротив, говорит о требовании как о том, что требуется от чего-то (т. е. от решения).

Первое определение охватывает понятия «бизнес-требований» и «требований стейкхолдеров», а второе «требований к решению» (функциональных и нефункциональных).

Инженерный стандарт ISO/IEC/IEEE 29 148:2018 упоминает, но не определяет понятия бизнес-требований. Он использует понятие «требования стейкхолдеров» (Stakeholder Requirements) и считает бизнес-требования разновидностью требований стейкхолдеров.

Российский ГОСТ 34.601−90 (тоже очень технический, а не бизнес-ориентированный) вообще не использует понятие бизнес-требований, а упоминает только «требования пользователя».

Six Sigma — не инженерный стандарт, а организационно-управленческий подход, но на него ссылается стандарт ISO. Здесь появляется понятие бизнес-требований, которые определяются как «Критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от [конкретного] решения». В этом определении особо подчеркивается, что эти активности не должны быть привязаны к какому-то конкретному решению, то есть подразумевается, что решения, могут быть разными.

Six Sigma также вводит понятие Business Requirement Definition (BRD) — документа спецификации бизнес-требований, в который, в том числе, включаются потребности и ожидания клиента.

Понятие требований в бизнес-анализе

Руководство к своду знаний по бизнес-анализу (BABOK Guide) в предыдущих версиях использовал определение стандарта ISO, однако за несколько лет практики его применения стали очевидны проблемы, связанные с недостаточной бизнес-ориентированностью этого определения. Версия 3 BABOK Guide определяет требования с другого ракурса. Вот три самых важных момента в этом новом определении:

1. Если в инженерном стандарте требования — это «то, что нужно кому-то или что требуется от чего-то», то BABOK Guide определяет требование как «пригодное для использования представление потребности», то есть фокусируется на том, что нужно.
2. BABOK Guide подчеркивает, что требование любого уровня должно фокусироваться на понимании приносимой пользы: зачем нужно.
3. BABOK Guide уточняет, что форма представления может значительно варьироваться в зависимости от обстоятельств (не предписывает какую-либо форму представления или шаблон).

Обратите внимание на формулировку «пригодное для использования представление потребности». А чем плохи сами потребности? Почему нужно использовать какое-то отдельное их представление и почему оно может быть (а может и не быть) «пригодным для использования» (usable)?

Дело в том, что формулировки потребностей как таковых звучат обычно очень тривиально. При виде формулировки потребности возникает вопрос: «Ну и что? Да, это так, это очевидно, но что с этим делать?»

Вот пример формулировки потребности:

«Люди испытывают ежедневную потребность в пище»

Но ведь это очевидно, верно? Казалось бы, с этим ничего невозможно сделать, так зачем об этом вообще говорить?

Всё изменится, если эту потребность поместить в какой-нибудь конкретный контекст. Например, предположим, что наш контекст — это морские путешествия во времена Колумба и Магеллана.

Потребность людей в пище, конечно, очевидна всем.

Но в контексте морских путешествий эту потребность уже можно сформулировать в виде требования, например, такого:

«Продукты питания, используемые в рационе моряков, должны сохранять пригодность для употребления в пищу в течение, как минимум, 30 дней при температуре до +30оС и высокой влажности, поскольку моряки длительное время вынуждены обходиться без поставок продовольствия».

Можно поразмышлять для тренировки над тем, в какие требования могла бы преобразоваться потребность в пище, если бы мы поместили её в другие контексты: школьного питания; работы на заводе или в офисе; постовой службы; пограничной службы; космических полетов. Очевидно, что требования будут совершенно разные, хотя потребность — одна и та же. Различие только в контексте.

Вернемся к нашему примеру с требованием о продуктах питания для моряков. Это требование уже можно выполнить, и его выполнение можно проверить.

Выполнить это требование можно разными способами. Можно, например:

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

Способы выполнения требований называются решениями.

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

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

При этом, бизнес-требование — не обязательно нечто глобальное: оно может относиться «к предприятию в целом, области бизнеса или конкретной инициативе». То есть масштаб бизнес-требований может быть очень разным.

Есть ещё одно важное свойство бизнес-требований, о котором BABOK Guide не говорит явно, но которое нужно читать между строк и понимать: бизнес-требования не зависят ни от каких стейкхолдеров.

Иногда у аналитиков возникают трудности с различением того, является ли требование бизнес-требованием или нет. Встречается также упрощенное понимание, что всё, что сообщают представители бизнеса — это и есть бизнес-требования. Это не так.

Для проверки того, является ли некое требование бизнес-требованием, нужно задать себе такие вопросы: Может ли требование измениться, если завтра на месте того, кто сообщил это требование будет работать другой человек? Изменится ли требование если изменится бизнес-процесс? Если вы ответили «нет» на оба вопроса, то проверка пройдена успешно.

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

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

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

Взаимосвязь понятий: потребности, требования, решения, контекст

Следующая диаграмма иллюстрирует связь потребностей, требований, решений и контекста.

• Голубой блок обозначает контекст проекта и его элементы.
• Красный блок в левой части — потребности бизнеса и стейкхолдеров.
• Желтый блок в центре — бизнес-требования, требования стейкхолдеров и требования к решению.
• Зеленый блок справа — решения, удовлетворяющие требования (бизнес-процессы и информационные системы).

Потребности бизнеса, подлежащие удовлетворению в конкретном контексте, отражаются в бизнес-требованиях.

Решением для бизнес-требования обычно является бизнес-процесс или организация, выполняющая множество бизнес-процессов.

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

Полное решение состоит из бизнес-процессов и [информационных] систем, поддерживающих и обеспечивающих эти процессы. Системы реализуют требования к решению.

Какие бывают потребности

Большинство людей имеют одни и те же основные потребности, отраженные в распространенной модели — пирамиде Маслоу.

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

У любой организации тоже есть ограниченный набор типовых потребностей, например, безопасность, непрерывность, эффективность, конкурентоспособность. Архитектор предприятий Даг Макдэвид предлагает рассматривать любую организацию не как механическую конструкцию, а как живой организм, имеющий естественные потребности связанные с его выживанием и развитием: саморегуляция, адаптация, восстановление, производство, воспроизводство, коммуникация и т. п. (Doug McDavid, Sustaining the life of your business, LinkedIn, January 25, 2015).

Вы можете предложить свою классификацию — в практической работе важен не конкретный «идеальный» перечень потребностей, а понимание того, что у организации любого вида существуют объективные потребности, имеющие важное значение в конкретном контексте.

Что такое контекст

Контекст — важная часть бизнес-требований. Лингвисты говорят «Контекст — это король».

Применительно к предприятию в общем, контекст — это все обстоятельства и факторы, которые не являются частью предприятия, но влияют на него, затрагиваются им или определяют его смысл.

К контексту относятся:

1. Рыночная среда
2. Спрос
3. Конкуренция
4. Структура подразделений компании
5. Физическое воплощение подразделений (здания, оборудование, и т. п.)
6. То, как в компании организовано управление, какие существуют бизнес-процессы. Любое изменение, любое решение реализуются не в вакууме, а в конкретных условиях, на конкретном предприятии. Мы не можем поменять всё, и мы не собираемся это делать. Мы меняем лишь какую-то часть деятельности предприятия, а всё остальное остается неизменным и, следовательно, является для нас контекстом. Важно зафиксировать, какая часть деятельности предприятия остается неизменной и образует контекст для нашей работы.
7. Люди, которые участвуют в деятельности предприятия, и технологии, которые на нем используются. Решение, прекрасно работающее в одной компании, может совсем не работать в другой. Часто заказчик отвечает на предлагаемое решение: «Да, решение прекрасное, но наши люди не смогут так работать, чтобы оно приносило пользу». И мы не можем поменять всех людей, это нереально. В этом случае сотрудники предприятия для нас являются элементами контекста.
8. Информационные системы и данные. Например, для внедрения системы могут быть нужны определенные данные, а если их нет, то для того чтобы их собрать в нужном формате, может потребоваться внедрить ещё несколько систем и поменять множество бизнес-процессов. Следовательно, отсутствие или наличие данных — это тоже контекст.

Как получается, что информационные системы в некоторых случаях являются решением, а в других — контекстом?

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

Пример определения бизнес-требования на основе анализа потребности

Предположим, наш заказчик — торговая компания.

Потребность бизнеса очевидна: чтобы продавать товары, компании нужно их где-то брать — либо оперативно получать от поставщиков, либо поддерживать на складе нужный запас. Эту потребность можно сформулировать так:

«Торговой компании необходимо постоянно иметь в наличии или оперативно получать нужные товары в нужном количестве.»

Это проекция базовой потребности бизнеса в непрерывности деятельности на бизнес-модель конкретной компании.

Потребность в непрерывности бизнеса: Для большинства организаций непрерывность деятельности — критический фактор существования. Например, банк не может nbsp;полностью прекратить свою деятельность, а через месяц, как ни в чем ни бывало, ее продолжить — у него есть требующие поддержания активы и обязательства.

Если бизнес-модель компании предполагает поддержание товарных запасов на складе, то бизнес-требование можно сформулировать так:

«Для поддержания нужных товарных запасов на складах компании, их необходимо регулярно (BR-INV-01) пополнять через формирование заказов поставщикам.

Размер поддерживаемого запаса каждого товара должен определяться, исходя из оптимизации затрат и минимизации рисков упущенной прибыли (BR-INV-02).»

В тексте этого требования есть две ссылки: BR-INV-01 и BR-INV-02. Здесь BR означает «бизнес-правило» (Business Rule), а INV — Inventory (запас). Это ссылки на бизнес-правила, определяющие то, с какой именно регулярностью нужно пополнять запасы, и каков алгоритм расчета оптимального товарного запаса. Бизнес-правило — один из типичных артефактов, сопровождающих бизнес-требования.

Артефакты бизнес-анализа, сопровождающие бизнес-требования

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

По мере определения бизнес-требований появляются:

1. Доменные модели — высокоуровневые информационные модели предметной области.
2. Глоссарий предметной области.
3. Модели состояния объектов управления: на этом этапе мы определяем, какими объектами мы хотим управлять, и какие состояния нас интересуют (или какие состояния мы хотим отслеживать).
4. Метрики и показатели этой деятельности, которые говорят нам о том, что важно для бизнеса и как мы оцениваем то, насколько хорошо или плохо, лучше или хуже выполняется его деятельность.
5. Бизнес-правила: описания применяемых в данной компании алгоритмов, нормативов, ограничений, проверок, и политик.

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

Требования стейкхолдеров

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

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

“

Как специалисту, отвечающему за поддержание запасов, мне нужно иметь возможность:

1. Автоматически рассчитывать заказ по каждому товару с использованием определенного алгоритма (здесь прозвучит то же самое бизнес-правило, которое упоминалось в бизнес-требовании). Почему автоматически? Потому что мне надо на 4 складах поддерживать 3000 товарных позиций, поступающих от 100 поставщиков — это невозможно или крайне сложно обрабатывать вручную.
2. По любой позиции автоматически рассчитанного заказа видеть то, как именно была посчитано это значение и почему оно именно такое — алгоритм может не учитывает какие-то известные мне нюансы. Например, ожидаемое значительное повышение или снижение продаж.
3. Менять количество в автоматически рассчитанном заказе — в конечном счете за заказ отвечаю я, а не система. Система не может учесть всё, и если я считаю нужным поменять заказанное количество, у меня должна быть возможность это сделать.
4. Смотреть для проверки не на все 3000 позиций, а только на те, где расчеты системы могут быть вызвать сомнения. Например, недостаточная история продаж, высокая волатильность продаж или другие подобные факторы.

Примерно так будет рассказывать нам живой человек. «Пользовательская история» (User Story) — естественная форма представления требований стейкхолдеров, имеющая формат <роль> <задача> <нужная возможность>.

Например:

Как специалисту, отвечающему за поддержание запасов, для формирования заказов поставщикам мне нужно:

1. Автоматически рассчитывать заказ по каждому товару с использованием BR-INV-02;
2. по любой позиции заказа иметь возможность посмотреть детали расчета и
3. вручную изменить заказываемое количество,
4. видеть отдельно те позиции заказа, по которым, возможно, требуется моя корректировка (BR-INV-03)

Обычно требованиям стейкхолдеров сопутствуют дополнительные артефакты:

• Карты стейкхолдеров (показывают, кто участвует в процессах)
• Модели и другие описания процессов
• Варианты использования (Use Cases)
• Образцы данных, с которыми работают стейкхолдеры (помогают понять ситуацию и потребности стейкхолдеров)

В рамках Scrum-подхода команда разработки работает именно с требованиями стейкхолдеров, представляемыми в виде пользовательских историй, из которых образуется бэклог продукта (product backlog).

Отсутствие понятия бизнес-требований — один из недостатков Scrum-подхода. Между тем, именно бизнес-требования обеспечивают понимание смысла требований стейкхолдеров и дают возможность их приоритизировать. Работа с бизнес-требованиями — область (неявной) ответственности Владельца продукта (Product Owner), определяющего приоритеты для команды разработки. В этом подходе предполагается, что команде разработки не нужно заботиться о том, как и из каких соображений владелец продукта определяет приоритеты. Однако, для бизнес-аналитика, зачастую выступающего в роли владельца продукта, чрезвычайно важно понимать бизнес-требования как источник требований стейкхолдеров и критерий их важности.

Требования к решению

«Требования к решению» (solution requirements) — понятие, применяемое в бизнес-анализе для определения требований к продукту, позволяющему выполнить требования стейкхолдеров.

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

Требования к решению описываются как способности решения, нужные для выполнения требований бизнеса и стейкхолдеров.

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

«Система управления запасами должна обеспечивать:

Возможность автоматического формирования предлагаемых заказов поставщикам по всем товарам, выбранным закупщиком. Формирование заказов должно выполняться в соответствии с алгоритмом BR-INV-01. …»

(Обратите внимание: здесь опять появляется ссылка на то бизнес-правило, которое мы определили в бизнес-требовании.)

Мы можем далее уточнить требование:

«Отображение позиции сформированного заказа должно содержать информацию о…»

Перечисление отображаемой информации должно ссылаться на модель данных предметной области.

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

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

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

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

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

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

• Два основных подхода к документированию БТ
• Шаблоны для описания БТ
• Классификация и примеры БТ
• Направления поиска БТ
• Типовые ошибки в БТ
• Типовые ловушки при разработке БТ
• Что делать с «магическими числами» в БТ
• Как восстанавливать БТ, если они отсутствуют в уже идущем проекте

Георгий Савельев

Эксперт по бизнес-анализу, член Международного института бизнес-анализа (IIBA), первый CBAP в России. Соавтор BABOK v.3.
Вице-президент IIBA Russian Chapter.

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

Участвовал в реализации более 50 проектов по разработке, внедрению и совершенствованию программного обеспечения.

С 1990 года занимается проведением тренингов и деловых игр для руководителей и специалистов. Автор статей по бизнес-анализу.

Создатель авторских аналитических методик и моделей оперативного планирования. Участвовал более чем в 20 консалтинговых проектах по увеличению прибыльности и совершенствованию операционной эффективности компаний.

Участник профессиональных ассоциаций IASA, ABPMP Russian Chapter.

Подписаться на новые статьи

Научиться создавать эффективные бизнес-требования в Agile

Научиться создавать эффективные бизнес-требования в стиле Agile под руководством опытного наставника с использованием формата User Story, техник Impact Map и Story Map можно на нашем онлайн-курсе «Основы бизнес-анализа и Разработки требований в Agile»

Другие статьи:

Контекстная диаграмма

Зачем нужна, как создавать и как тестировать контекстную диаграмму при разработке системных требований и проектировании систем

Что мы создаём в ИТ-проектах?

Программное обеспечение, информационная система, автоматизированная система — в чём разница?

Книги

Рекомендации литературы по инженерии требований и прикладному системному анализу

Стандарты

Международные и российские стандарты в области прикладного системного анализа и инженерии требований

Remote Analyst. Первые шаги и частые вопросы

Как начать дистанционную работу независимым ИТ-аналитиком

Как выполнить тестовое задание на вакансию ИТ-аналитика

Рекомендации с примерами

Постановка задачи на реализацию

Разберёмся, что это такое, зачем нужна, как создавать

Как разработать бизнес-требования?

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

Требования к ПО на пальцах / Хабр

Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.

Если коротко, то основные этапы разработки требований — это:

1. Зачем нам что-то делать? (нужно больше золота)
2. Что мы будем делать? (все как у людей, но дешевле)
3. Как мы это сделаем? (с блокчейном и датасаентистами, естественно)
4. Когда мы это сделаем? (вчера, а отрефакторим «потом»)

А теперь подробнее.

Если вы когда-либо просили что-то сделать — значит вы создавали требования. Они могли быть в форме устного пожелания, письма, технического задания, таски или чего угодно.

Так что требования — они повсюду.

Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,

либо вы некорректно поставили задачу.

Как известно, неверная задача может обойтись довольно дорого. Например, если полгода команда из 5 программистов разрабатывала систему, которая никому не была нужна.

В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь. Поэтому, даже если у вас нет аналитика на проекте, даже если вы вообще не IT — не забывайте про здравый смысл и берите из лучших практик то, что нужно в данный момент.

Так что же такое требования и почему важно уметь их разрабатывать?

Итак, обратимся к истокам:

То есть о требованиях можно говорить, как о будущих свойствах. Как о том, каким будет продукт, удовлетворяющий целям разработки.

С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.

1. Зачем?

Как бы “ASAP!!!!” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.

Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.

Например

Заказчик попросит срочно показывать ему все заказы, которые были сделаны в системе. Допустим, мы напряглись и впихнули посреди спринта задачу на отображение всех заказов для администратора. После этого заказчик просит выводить в отдельном окне список всех компаний, чьи заказы он видит. Сделали и это. Потом заказчик просит выводить дополнительно вообще все компании-партнеры. Окей… Через какое-то время мы встречаемся с заказчиком и видим, как он выгружает оба списка в эксель, ВПРит разницу и начинает обзванивать компании, у которых нет заказов, чтобы напомнить им, что нужно делать заказы через нашу систему.

Если бы мы с самого начала спросили у заказчика, какую цель он хочет достичь, просматривая все заказы — мы бы сэкономили кучу времени и сил, сразу сделав отчет с компаниями, которые не делали пока заказы.

Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.

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

Например

Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.

Это облегчает понимание задач и в то же время развязывает руки в выборе средств достижения цели.

И да, не забывайте согласовывать эту красоту с заказчиками. Вообще не забывайте согласовывать требования со всеми заинтересованными сторонами.

2. Что?

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

Например

Чтобы сократить процесс согласования счетов, мы можем:

А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.

Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.

В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.

Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.

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

3. Как?

Итак, мы поняли нашу цель и что мы будем делать, чтобы ее достичь. Осталось разобраться с тем — как мы это реализуем: какие страницы будем показывать пользователям, в каком виде отобразим отчет для заказчика, как получим данные из другой системы, как будем хранить их у себя и так далее.

Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще.

Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса и других умных людей. Если для вас какой-то тип требований сейчас не актуален — окей, не описываем. Но важно не забыть и проверять себя.

Например

• Анкета должна содержать файл с фото, так как фото необходимо при оформлении документов — это бизнес-требование. А возможно, и бизнес-правило.
• Из бизнес-требования следует, что у пользователя должна быть возможность прикрепить фото к анкете — это пользовательское требование. То есть требование, описывающее действия пользователя.
• Получается, что система должна иметь функционал прикрепления фото к анкете — это уже функциональное требование, описывающее поведение системы. Или как должна работать система, чтобы выполнять исходное пользовательское требование.
• Будем хранить все фото в формате base64 в отдельной таблице в БД. Это — нефункциональные требования.
• Фото в очень хорошем качестве нам не нужно, а также мы не хотим покупать много памяти для сервера. Поэтому сделаем ограничение на размер загружаемого фото: не более 10Мб.

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

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

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

4. Когда?

В “лесу” ваших требований скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно всю эту красоту документировать и представлять в виде таблиц и диаграмм.

Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.

Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.

Однако, как правило, «пятенный» уровень детализации не позволяет увидеть подводные камни и продумать все возможные сценарии. Ведь вроде и так все понятно, а нарисовал схемку — и вот тебе и бесконечный вызов, и забытая ветка процесса, и кратчайший путь к золоту.

Поэтому полезно знать, какие есть инструменты для обращения хаоса в порядок.

В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).

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

Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.

Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.

Спасибо за внимание и удачного проектирования.

Определение требований к процессу – База знаний BriefBuilder

Важно: для определения требований к процессу необходимо активировать модуль процесса в меню модулей.

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

Кроме того, возможны требования, касающиеся результаты , которые необходимо произвести в ходе проекта (например, модели BIM, сертификаты, гарантии, отчеты об испытаниях).

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

В BriefBuilder есть два «дерева» (декомпозиции), доступные для сбора таких требований:

• процесс дерево (что должно быть сделано ?)
• результаты дерево (что должно быть поставлено ?).

Декомпозицию процесса и результатов можно найти в разделе «Требования / процесс» в меню навигации

Оба будут обсуждаться ниже.

Процессы и действия

В дереве процессов можно определить, какие процессы и действия должны выполняться стороной договора. Он состоит из двух типов объектов:

	Процесс	Общий процесс, которым должен заниматься подрядчик/команда дизайнеров (например, ландшафтный дизайн или дизайн интерьера). Можно разделить на подпроцессы или действия.
	Деятельность	Конкретная деятельность или задание, которое должно быть выполнено подрядчиком/группой проектировщиков, обычно с определенным конечным результатом (например, запрос разрешений или проведение конкретного испытания). Нижний уровень дерева. Не подлежит дальнейшему подразделению.

В дереве процессы и действия могут быть структурированы в соответствии с фазами или дисциплиной или их комбинацией. Это можно сделать с помощью папок ( ). См. ниже простой пример.

Пример того, как можно использовать «дерево процессов» для определения того, какие действия ожидаются в отношении дизайна интерьера. Вы можете использовать функцию метки BriefBuilder, чтобы указать, являются ли действия необязательными.

Обратите внимание: процессы иногда путают с вызываемыми сервисами в BriefBuilder. Разница заключается в следующем:

Процессы — это действия/задачи, которые необходимо выполнить для реализации и завершения проект (например, проектная деятельность, строительные работы).

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

Требования к процессу

Для каждого процесса и действия вы можете определить требования относительно того, как и когда они должны выполняться.

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

См. ниже простой пример того, какие требования клиент может сформулировать в отношении деятельности Семинары с конечными пользователями .

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

Более технический пример можно увидеть ниже. Это пример тестовой деятельности («тест на выдерживание»), которая является частью процесса ввода в эксплуатацию.

Обратите внимание, что действия можно связать с конкретными пространствами, системами или элементами, к которым они относятся. В этом примере испытания на вымачивание это делается в таблице 9.0003 Соответствующие системы/элементы . В этой таблице указано, для каких систем должен выполняться тест.

Чтобы связать действие с определенной технической системой или элементом, нажмите Выбрать.

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

Чтобы связать действие с конкретным результатом, нажмите «Выбрать».

Обратите внимание, : с помощью0003 результаты «дерево» имеет значение только в том случае, если у вас есть подробные требования к результатам (см. примеры выше). Если нет, вы можете вместо этого просто добавить стандартное свойство под названием «доставляемый» к вышеупомянутым действиям.

Результаты

Дерево результатов можно использовать для определения того, какая документация должна быть предоставлена ​​на различных этапах проекта. Подумайте о документах (чертежах, гарантиях, разрешениях, документах по планированию), а также о моделях BIM, макетах или образцах продукции.

Дерево состоит только из объектов одного типа («доставляемые»). Вы можете использовать папки ( ) для организации результатов в соответствии с типом, этапом или дисциплиной. См. ниже простой пример.

Пример набора результатов для конкретного этапа проектирования.

Для некоторых результатов вы можете добавить особые требования, касающиеся их содержания или формата. Это можно сделать, создав свойства в подробном представлении результата (просто нажмите Добавить свойство ) или задав стандартные свойства (через меню настроек требований). Типичные примеры таких свойств:

См. ниже простой пример требований к отчету об окончании этапа .

Краткое описание было использовано для объяснения того, что требуется в общем смысле. Свойства использовались для объяснения специфики.

Процесс требований — статьи бизнес-аналитиков, вебинары, шаблоны, вакансии

Хотя это является второй натурой для многих из нас, я подумал, что было бы полезно изложить это здесь — различные шаги, связанные с выявлением, документированием и определением требований.

Не перегружайтесь количеством шагов, со временем все они будут сливаться в одну бесшовную последовательность.

1. Определите заинтересованные стороны

Кто является заинтересованными сторонами? Человек или лица, заинтересованные или обеспокоенные чем-либо. Погуглите, и вы найдете от 4 до 14 типов заинтересованных сторон. Я рассматриваю стейкхолдеров как стейкхолдеров проекта, стейкхолдеров требований и т. д. Могут быть некоторые совпадения, но не всегда. Например, вице-президент может быть участником проекта, но не участником требований. Заинтересованные стороны проекта обычно перечислены в уставе/концептуальном документе проекта. Заинтересованные стороны требований будут перечислены в BRD или любом его варианте. Имейте в виду следующее:

• Это люди, которые будут использовать систему или затронуты системой
• Определите любые текущие проекты или вышестоящие/нижние системы, которые могут быть затронуты
• Включите всех людей в свой список заинтересованных сторон требований.

2. Есть ли у вас техническое задание (SOW)?

В случае, если вы покупаете продукт COTS и выпустили RFP, очень вероятно, что RFP содержит SOW, определяющий общий объем проекта. Если их нет, начните с определения области действия высокого уровня. Почему? Легко определить масштаб высокого уровня, а затем перейти к подробным требованиям. Наоборот, вероятность застрять в сорняках слишком высока.

3. Организовать стартовое заседание по требованиям

Вот что нужно сделать:

1. Пригласить всех заинтересованных лиц, проект, требования и т. д.
2. Установите повестку дня и придерживайтесь ее
3. Возглавить сеанс
4. Объясните требования 5W и 1H – кто, что, где, когда, почему и как.
5. Уточнение качества требований – правильное, однозначное, полное, необходимое, выполнимое, проверяемое и отслеживаемое
6. Настаивайте на том, что «вы» понимаете требования. Документирование невозможно без хорошего понимания требований.
7. Запись сеанса (Объявите об этом в начале, не все организации относятся к этому благосклонно)
8. Распространение резюме обсуждения и получение отзывов на основе отсутствия возражений

Часто заинтересованные стороны не знают об аспектах и ​​стандартах качества требований. У них также сложилось впечатление, что вы, БА, и они на одной волне и в понимании. Лучше очистить воздух заранее.

4. Проверка и подтверждение процесса «КАК ЕСТЬ»

Если организация поддерживает обновленный процесс AS-IS, я рекомендую купить лотерейный билет! Возможно, вам действительно повезло. Заинтересованные стороны должны подтвердить процесс AS-IS, чтобы убедиться, что он актуален. Если вам не повезло, задокументируйте процесс КАК ЕСТЬ. Одновременно подготовьте карту взаимодействия с заинтересованными сторонами, которая представляет то, что происходит между всеми без исключения заинтересованными сторонами. Это важно, поскольку позволяет выявить заинтересованные стороны, которые были упущены на первом этапе.

Реклама

5. Задокументируйте болевые точки

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

6. Определение требований высокого уровня

ТЗ/высокоуровневый объем и болевые точки должны служить хорошей отправной точкой для определения высокоуровневых требований. Поделитесь списком с заинтересованными сторонами и определите недостающие. В идеале должно быть не более 8-10 высокоуровневых требований. Предоставьте не более нескольких описаний предложений для каждого из требований высокого уровня.

7. Выбрать методы извлечения информации

В BABOK их насчитывается более 50. Не все релевантны для выявления требований. Кроме того, каждая ситуация может потребовать использования различных техник или комбинации техник. Например, если требований не существует, используйте мозговой штурм. Если они туманны, используйте анкету.

8. Организуйте сессии по сбору информации

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

9. Выберите правильный шаблон

Не переусердствуйте с шаблоном. Они просто обеспечивают структуру документа с требованиями. Содержание очень важно. Сосредоточьтесь на этом. Стандартные шаблоны BRD содержат множество разделов для заполнения. Обсудите с вашей организацией, можно ли исключить некоторые из этих разделов. Конечно, некоторые разделы, такие как обзор, по предмету и предметам, не относящимся к предмету, являются обязательными. Процесс AS-IS и процессы TO-BE могут быть задокументированы отдельно и указаны в BRD.

10. Требования к документам

Пришло время документировать требования. Имейте это в виду:

1. Стандарты качества
2. Не объединяйте два требования в одном предложении
3. Используйте простой активный голос
4. Обеспечьте логическую последовательность требований. Например, проверка подлинности пользователя должна предшествовать всем остальным требованиям

.

5. Перечитайте требования, убедитесь, что они имеют смысл и что в них нет противоречащих друг другу требований
6. Избегайте деталей реализации как части бизнес-требований. Например, система должна поддерживать многопоточность или параллельную обработку, JSP или что-то подобное.
7. Не позволяйте существующей системе затуманивать ваши мысли
8. По возможности приведите примеры и образцы. Это обеспечивает большую ясность

11. Определение тестовых сценариев

V-модель предполагает, что тестовые сценарии должны создаваться вместе с бизнес-требованиями. Необходимо учитывать не только положительные, но и отрицательные сценарии испытаний. Это один из способов выявления отсутствующих требований. Сценарии будут преобразованы в тестовые примеры на более позднем этапе. Имейте в виду следующее:

1. Для каждого требования укажите один или несколько сценариев
2. Всегда включать негативные сценарии
3. Сценарии тестирования на основе ролей следует учитывать, если они важны
4. Нисходящие и/или восходящие сценарии тестирования важны, если системы будут затронуты

12. Рецензирование артефактов

Это абсолютно необходимо. Поделитесь BRD; Потоки AS-IS, болевые точки, тестовые сценарии и все другие артефакты с коллегой или старшим БА. Это обеспечит соответствие требований качеству и учет всех требований. Это также гарантирует, что тестовые сценарии обеспечивают полное покрытие всех требований.

13. Запросить отзыв

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

This entry was posted in Популярное