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

15.08.2021 alexxlab

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Про бизнес-требования — Личный опыт на vc.ru

В сухом остатке, концепция проекта содержит цель проекта, обычно очень верхнеуровневое описание шагов для её достижения и описание целевой аудитории. Если вы не знакомы с концепцией (scope) проекта и не знаете как её разрабатывать или ищите пример, от которого можете оттолкнуться для разработки концепции для своего продукта, то смело скачивайте документ «Scope проекта».

9918 просмотров

Если вы ознакомились с документом «Scope проекта», то увидели там раздел «Бизнес-требования».

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

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

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

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

Статья разработана автором нового канала «Product Architect Guide»

Какие бывают требования? — Сообщество Аналитиков

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

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

Системные требования (system requirements) — это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

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

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

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

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

Понравилось? Поделись с друзьями!

Формирование требований и классификация требований

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

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

Иными словами, нужно знать, какие требования заказчик предъявляет к продукту. Полный набор этих требований называют каталогом требований, или спецификацией.
Крупные и сложные проекты обычно насчитывают тысячи требований. Бизнес-анализ как раз и позволяет выявлять проблемы и определять, что требуется для их преодоления. В крупных проектах, таких, как разработка программного обеспечения, сбор требований является одним из важнейших этапов жизненного цикла проекта, котоорыый может занять несколько недель/месяцев.
Для выявления требований проводится серия структурированных интервью с заказчиками, которые позволяют точно определить их пожелания к готовому продукту. Попытка напрямую узнать у заказчика, какие результаты ему нужны, может закончится крахом: заказчик станет выдвигать все новые и новые требования, так что вы просто будете не в силах их удовлетворить. Помните, любое требование влияет на продолжительность и стоимость проекта. Соответственно, получая подробный список требований, вам нужно знать, являются ли они:

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

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

Функциональные требования — это требования к системе.
Бизнес-требования — эквивалентно бизнес-целям.
Между ними — Пользовательские требования, User Requirements.
Пользовательские требования формулируются в терминах предметной области, а функциональные требования — в терминах системы.

Бизнес-процессы — самое начало работы.

Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):
1. Бизнес-моделирование
2. Выявление требований
3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн
4. Реализация
5. Тестирование
6. Опытно-промышленная эксплуатация
7. Support и развитие системы

Совсем упрощенно:
1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования.
2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.
3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).
4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).

Типовая структура требований выглядит как «Система должна … /утверждение о необходимом функциональном поведении системы/» или «система должна позволять … /утверждение о возможности, предоставляемой пользователю или внешней системе/.

Например:
«Система должна вести журнал всех действий пользователя» или «Система должна позволять создавать новые Проекты».

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

Пользовательские и функциональные требования как правило связаны между собой. Это необходимо для отслеживания зависимостей требований друг от друга. В системах управления требованиями (например, Borland CaliberRM, TelelogicDoors, Rational RequisitePro) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.

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

Схема процесса разработки с уровнями требований

Формирование и анализ требований

Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.
Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.
Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.
Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода.
Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.
Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

Аттестация требований

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

Подготовка к интервью по сбору требований у заказчика

Компания — Бизнес-требования

Источники: Топ-менеджмент компании
Документ: Бизнес-требования (обоснование потребностей инициативы)
Ответственный: Менеджер проекта

Состав бизнес-требований может отличаться на практике. Обычно включаются следующие пункты:

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

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

Заказчик — Документ требований заинтересованных лиц

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

Бизнес-назначение
Бизнес-рамки
Обзор бизнеса
Заинтересованные лица
Организационная среда
Цели и результаты
Бизнес-модель
Информационная среда
Бизнес-процессы
Политики и правила
Ограничения деятельности
Организационная структура
Концепция использования системы
Сценарии эксплуатации
Проектные ограничения

Пользователь — Требования пользователя

Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё.
Источники: Пользователь
Документ: Пользовательские требования/Требования к ПО
Ответственный: Системный аналитик

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

Проблемы при формировании пользовательских требований

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

Системные требования

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

Функциональные требования

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

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

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

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

Нефункциональных требований

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

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

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

Требования предметной области

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

Требования к продукту

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

Организационные требования

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

Требования к интеграции

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

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

Интеграция через ESB

Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.
Основными функциями ESB являются:

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

Интеграция точка-точка

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

Интеграция данных

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

Задачи интеграции данных:

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

Интеграция ETL
Интеграция ETL характеризуется следующим сценарием:
На платформе ETL пишется процесс, который
1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные
2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы
3) Загружает данные в таблицы БД 2й системы.

Файловый обмен
Файловый обмен характеризуется следующим сценарием:
1) Приложение, которому требуется передать данные другому приложению, сохра¬няет их в файле.
2) Разрабатывается интеграционное решение, которое преобразует формат файла в формат, требуемый другим приложением. (В частном случае для этого дорабатывается одна из интегрируемых систем)
3) Приложение которому нужны данные, загружает подготовленный файл.

Требования к пользовательскому интерфейсу

Пользовательский интерфейс — часть программной системы. Требования к пользовательскому интерфейсу могут быть разбиты на две группы:

требования к внешнему виду пользовательского интерфейса и формам взаимодействия с пользователем;
требования по доступу к внутренней функциональности системы при помощи пользовательского интерфейса.

К первой группе можно отнести следующие типы требований:

Требования к размещению элементов управления на экранных формах
Требования к содержанию и оформлению выводимых сообщений
Требования к форматам ввода

Ко второй группе относятся следующие типы требований:

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

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

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

Классификация изменяемых требований

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

Процесс управления изменениями

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

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

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

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

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

Если вы выбрали реалистичные KPI для своих целей, но не видите признаков прогресса по истечении разумного времени, нужно провести расследование:

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

Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.

Документы процесса разработки требований

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

Документы процесса управления требованиями

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

Пример дорожной карты совершенствования процессов работы с требованиями

4.8 4 Голоса

Рейтинг статьи

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Зачем?

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

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

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

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

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

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

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

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

2. Что?

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

Например
Чтобы сократить процесс согласования счетов, мы можем:
А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.
Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.
В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.

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

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

3. Как?

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

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

Например
Анкета должна содержать файл с фото, так как фото необходимо при оформлении документов — это бизнес-требование. А возможно, и бизнес-правило.

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

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

Будем хранить все фото в формате base64 в отдельной таблице в БД. Это — нефункциональные требования.

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

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

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

4. Когда?

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

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

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

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

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

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

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

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

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

Виды требований к программному продукту

01.03.2018 18:48

Текстовая расшифровка третьего видеоурока курса Введение в профессию аналитика.

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

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

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

Самый первый вид требований: бизнес-требования. Что это такое, обобщённо? Описание высокоуровневых целей организации или заказчика, достигаемых посредством разрабатываемой системы.

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

Что дает описание бизнес требований? Описывает бизнес-идею, без реализации которой продукт не будет нужен потребителю. Это описание тех самых проблем и возможностей, для решения или реализации которых создается продукт.

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

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

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

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

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

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

Часто бизнес-требования путают с бизнес-правилами, потому что они начинаются со слова «бизнес». Что понимается под бизнес-правилом? Положение, определяющее или ограничивающее какие-либо стороны бизнеса. Я не буду перечитывать то, что написано у Вигерса, а лучше сразу покажу на примерах, что за этим стоит.

За этим стоят, во-первых, какие-то документы, регламентирующие на уровне законов или отраслевых стандартов (или ещё каких-то стандартов) то, как должен работать наш продукт. Если, например, мы разрабатываем банковскую систему, то там есть огромное количество правил, которые генерируют Центробанки. Если говорить о России, то это наш Центральный Банк, который выпускает различные инструкции, и банковская система должны обязательно им следовать.

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

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

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

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

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

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

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

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

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

Как я уже сказал, основная масса существующих методов разработки требований относится именно к этому уровню. Use Cases, User Stories, «персоны» и ещё некоторые методы, не так часто используемые. Лучше всего проработанные, концептуально завершенные, они как раз относятся к уровню взаимодействия людей с продуктом. Но это естественно, потому что продукты, в основном, до сих пор создаются для людей.

Здесь может быть очень много разных примеров. Я даже не стал их детализировать.

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

Мы можем описать требования в виде набора user stories, например, для интернет-магазина. Если я хочу выполнить покупку на сайте интернет-магазина, то мне нужно будет реализовать user stories для сравнения товаров, для добавления в корзину, для управления корзиной и оформления заказа, для онлайн-оплаты. Каждая user story имеет определенный формат, который не представлен на этом слайде.

Каждая user story — это такой единичный кусок, unit при разработке требований, обладающий своими собственными характеристиками, и разработанный по определённому методу.

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

Атрибуты качества. Более детально мы атрибуты качества рассмотрим ещё сегодня на этом вебинаре.

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

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

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

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

Например, время загрузки главной страницы и карточки товара не должно превышать 3 секунд при нагрузке до 20 посетителей в минуту. Это требование отражает атрибуты качества «производительность» и «надёжность». Производительность — это время загрузки страницы, а надёжность — это какую нагрузку должен держать сайт.

База данных сайта должна устанавливаться на сервера mysql или MS SQL Server или Oracle без необходимости внесения изменений в установочные скрипты. Это, опять же, конкретное представление требования, которое отражает такой атрибут качества как «переносимость». Мы можем наш разработанный сайт устанавливать в разном окружении, и при этом должны быть реализованы эти требования, чтобы мы могли использовать разные системы баз данных.

Сайт должен быть адаптирован для мобильных устройств. Это может вам показаться спорным, но это требования тоже отражают атрибут качества. Удобство использования тоже является атрибутом качества. Сейчас он больше известен под словом «юзабилити», которое в стандарте последнем так и переведено: «удобство использования».

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

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

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

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

Например: сервер приложений сайта должен разрабатываться на языке Java. Почему? А потому что, например, у заказчика есть множество специалистов, которые могут эту джаву сопровождать, и все другие его сервера приложений тоже работают в этом окружении.

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

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

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

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

Ну например, что это может быть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предыдущий урок: Уровни требований к программному продукту

Следующий урок: Функциональная и нефункциональная стороны программного продукта

Бизнес требования к системе — Бизнес Гид

Contents

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

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

Функциональные требования — это требования к системе.Бизнес-требования — эквивалентно бизнес-целям.Между ними — Пользовательские требования, User Requirements.Пользовательские требования формулируются в терминах предметной области, а функциональные требования — в терминах системы.

Бизнес-процессы — самое начало работы. Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность): 1. Бизнес-моделирование 2. Выявление требований 3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн 4. Реализация 5. Тестирование 6. Опытно-промышленная эксплуатация 7. Support и развитие системы

Совсем упрощенно: 1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования. 2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации. 3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования). 4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).

Например:«Система должна вести журнал всех действий пользователя» или «Система должна позволять создавать новые Проекты».

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

Схема процесса разработки с уровнями требований

Формирование и анализ требований

Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода.Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

Аттестация требований

Подготовка к интервью по сбору требований у заказчика

Компания — Бизнес-требования

Источники: Топ-менеджмент компанииДокумент: Бизнес-требования (обоснование потребностей инициативы)Ответственный: Менеджер проекта

Состав бизнес-требований может отличаться на практике. Обычно включаются следующие пункты:

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

Заказчик — Документ требований заинтересованных лиц

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

Бизнес-назначение
Бизнес-рамки
Обзор бизнеса
Заинтересованные лица
Организационная среда
Цели и результаты
Бизнес-модель
Информационная среда
Бизнес-процессы
Политики и правила
Ограничения деятельности
Организационная структура
Концепция использования системы
Сценарии эксплуатации
Проектные ограничения

Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё.Источники: ПользовательДокумент: Пользовательские требования/Требования к ПООтветственный: Системный аналитик

Проблемы при формировании пользовательских требований

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

Системные требования

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

Функциональные требования

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

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

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

Нефункциональных требований

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

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

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

Требования к продукту

Организационные требования

Требования к интеграции

Интеграция через ESB

Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.Основными функциями ESB являются:

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

Интеграция данных

Задачи интеграции данных:

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

Файловый обмен Файловый обмен характеризуется следующим сценарием: 1) Приложение, которому требуется передать данные другому приложению, сохра¬няет их в файле. 2) Разрабатывается интеграционное решение, которое преобразует формат файла в формат, требуемый другим приложением. (В частном случае для этого дорабатывается одна из интегрируемых систем) 3) Приложение которому нужны данные, загружает подготовленный файл.

Требования к пользовательскому интерфейсу

требования к внешнему виду пользовательского интерфейса и формам взаимодействия с пользователем;
требования по доступу к внутренней функциональности системы при помощи пользовательского интерфейса.

Требования к размещению элементов управления на экранных формах
Требования к содержанию и оформлению выводимых сообщений
Требования к форматам ввода

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

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

Классификация изменяемых требований

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

Процесс управления изменениями

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

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

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

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

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

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

Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets). Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.

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

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

Документ о бизнес-требованиях: обзор высокого уровня

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

У инструментов, используемых в этом процессе, есть много разных названий: спецификация бизнес-потребностей, спецификация требований или просто бизнес-требования.

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

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

Процесс BRD может быть включен в культуру Six Sigma DMAIC (определение, измерение, анализ, улучшение, контроль).

Наиболее распространенные цели BRD:

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

BRD важен, потому что он является основой для всех последующих результатов проекта, описывая, какие входы и выходы связаны с каждой функцией процесса.Функция процесса предоставляет CTQ (критически важные для качества). CTQ передают голос клиента (VOC). BRD описывает, как система будет выглядеть с точки зрения бизнеса.

BRD проводит различие между бизнес-решением и техническим решением. При изучении бизнес-решения BRD должен ответить на вопрос: «Что хочет сделать бизнес?» Например, предприятие хочет подавать 100 бутылок красного вина каждую ночь в течение трехдневной конференции, и при розливе вино должно иметь температуру 57 градусов по Фаренгейту.Техническое решение должно поддерживать бизнес-решение. Например, компании потребуется винный грот или холодильная установка, способная вместить более 300 бутылок с температурой от 48 до 52 градусов по Фаренгейту.

Кто должен участвовать в создании BRD?

Ряд команд и партнеров должны создать BRD:

Основная команда проекта
Деловой партнер (ы)
Владелец или представители процесса
Специалисты в предметной области
Управление изменениями / проектами / продуктами, отделом качества и / или управление ИТ по мере необходимости или доступности

Предварительные требования для BRD

Предварительным условием для BRD является устав проекта, созданный на этапе определения проекта DMAIC.BRD предоставляет возможность пересмотреть устав проекта, чтобы убедиться, что цель, цели, объем, проектная группа и утверждающие точно отражены.

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

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

Третье предварительное условие — это CTQ, определенные на этапах определения или измерения и подтвержденные базовыми измерениями, целями и спецификациями.

Текущие показатели: данные, которые определяют и описывают текущую производительность — сигма-уровень CTQ включает определение того, как характеристики продукта / услуги должны быть определены количественно.
Целевая / номинальная стоимость: Какова цель продукта / услуги? Если бы в продукте / услуге никогда не было изменений, это было бы постоянное значение.
Пределы спецификации: Какие отклонения клиент готов допустить в доставке продукта или услуги? Определите верхний и нижний пределы спецификации в соответствии с требованиями заказчика.
Допустимый процент брака: как часто производители готовы производить продукт / услугу, выходящие за пределы спецификации?

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

Люди: люди обрабатывают информацию и принимают решения [основная команда разрабатывает дизайн высокого уровня / дизайн низкого уровня (HLD / LLD)]
Системы: Системы обрабатывают информацию и принимают решения
Системы / люди: Система обрабатывает информацию, и люди принимают решения.
- Различать сотрудника и клиента
- Выделить требования к руководству для сотрудника в случае, если полномочия по принятию решений должны быть повышены
Fishbone: для каждой технологической функции для оценки воздействия

Общая информация о проекте и передовой опыт

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

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

Лучшие Лрактики

Подтвердить область действия: проанализировать и уточнить область действия по мере необходимости на основе таблицы деталей процесса, идентифицируя любые изменения того, что входит или выходит за рамки области сейчас, когда требования были разработаны.Завершите это до получения согласия делового партнера (ов) и зафиксируйте объем проекта. Любые изменения в проекте после этого этапа будут обрабатываться через процесс управления изменениями.
Создание документа, затронутого системой: Создайте схему элементов дизайна для каждой функции процесса второго или третьего уровня для оценки воздействия на:
- Люди
- Процесс
- Технологии
- Материалы и принадлежности
- Удобства
- Товар
- Машины и оборудование
- Другое по мере необходимости (в зависимости от организации)
Определения и сокращения: Определите любые термины, которые не всем понятны.

Упаковка BRD

Упакуйте BRD так, чтобы он имел логическую последовательность и простоту выполнения. Пример высокоуровневого списка разделов:

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

Деловой партнер Выход из системы

Деловые партнеры должны быть активными участниками разработки BRD, но окончательная проверка и одобрение также важны.

Дополнительная информация

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

Примеры вопросов для текущей оценки окружающей среды и обзора систем:

Кто предполагаемый пользователь?
Сколько у вас пользователей? Они одного типа пользователей или разные?
Какой уровень опыта работы с компьютером будет у пользователей (или необходим)?
Какая необходимая безопасность?
Есть ли аппаратные ограничения — сетевые или автономные?
Какое приблизительное количество записей требуется на начальном этапе плюс ожидаемый рост?
Какая техническая поддержка необходима и доступна внутри компании?
Какие еще системы необходимо интегрировать / обмениваться данными?
Резервное копирование.Опишите текущий режим резервного копирования (например, однодневное резервное копирование на магнитную ленту). Как с этим согласуется новая система? Если это в настоящее время не определено, подумайте, сколько данных может быть случайно потеряно. Например, будет ли потеря последних 30 минут работы серьезной катастрофой или данные за вчерашнюю / прошлую неделю будут сохранены?
Результаты. Каковы ожидания — система, файлы справки, документация, полный исходный код, обучение, поддержка и т. Д.? Детализируйте, что важно и что приятно. Не просите автоматически все, если в этом нет необходимости.Если менеджер проекта должен поддерживать систему, убедитесь, что он заявляет, что ему требуется полный исходный код — в качестве альтернативы, если разработчик должен поддерживать систему, рассмотрите возможность заключения соглашения об условном депонировании (где источник находится у независимой третьей стороны). Рассказывайте об инструментах, необходимых для помощи. Если разработчик не желает оказывать необходимую поддержку, найдите кого-нибудь, кто это сделает.

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

Подробное описание требования, включая цели (например, создание отчета о расходах / отделе / году по запросу, при котором пользователь выбирает отдел и требуемый финансовый год), необходимо знать, как компания определяет финансовый год.
Насколько важно это требование (существенно, желательно, приятно иметь, не обязательно и т. Д.)?
Есть ли какие-либо известные проблемы проектирования / реализации, связанные с этим требованием?
Взаимодействует ли это требование с другими требованиями?

Данные для хранения: образец извещения

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

Обычно нет необходимости определять таблицы в терминах базы данных (например, номер клиента — длинное целое число), но примеры данных, которые должны храниться в полях, полезны (например, типичный номер задания может быть FH / 1234, где FH указывает на отдел, выполняющий задание, а 1234 — это уникальный номер. На практике хороший разработчик базы данных тогда распознает, что «реальный» номер задания на самом деле является частью 1234, а FH — просто ассоциированным полем).Если известен максимальный размер любого поля — например, поле «Название компании» составляет 100 символов — включите это. Если есть какие-либо определения таблиц из существующих систем, укажите в них любые требуемые изменения.

Сводка

Как и любой другой инструмент, BRD может иметь как преимущества, так и режимы отказа. Преимущества, полученные от хорошего BRD, включают меньшее количество изменений на этапах улучшения и контроля DMAIC, а также сокращение времени до развертывания. Режимы отказа из-за плохого BRD означают, что разработанная система не будет соответствовать бизнес-требованиям.Создание успешного BRD требует планирования и координации. Есть несколько передовых методов, которым следует следовать в этом процессе. Команда должна провести специальный выездной сеанс, чтобы завершить BRD со 100-процентной доступностью всех необходимых ресурсов. Планирование — ключ к успеху здесь. По мере того, как каждый инструмент / результат завершается в рамках методологии, создайте BRD. Выделите недельный крайний срок для завершения элементов действий из внеофисного сеанса и проведите заключительную сессию обзора через два-три часа после завершения действий.

Вам также может понравиться

бизнес-требований против функциональных требований? Какая разница?

Каковы бизнес-требования? Типичный ответ, который я получаю, когда спрашиваю пример бизнес-требования, — это предложение вроде: «Система должна облегчить автоматизацию электронной почты для клиента». Это бизнес-требование? Ну конечно должно быть. Бизнес сказал мне это конкретно и такими словами! Это должно быть бизнес-требование, ведь оно исходит от бизнеса, верно !?

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

Чем не является бизнес-требование: функциональное требование

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

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

Заявление типа: «Система должна отображать приветственное сообщение для пользователя на домашней странице».
Прототип
Схема рабочего процесса
Описание варианта использования (текстовое описание шагов для выполнения функции)
Карта-история

Итак, что такое бизнес-требование?

Бизнес-требование — это не то, что должна выполнять система .Это то, что бизнес должен делать или иметь, чтобы оставаться в бизнесе. Например, бизнес-требование может быть:

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

Ваши бизнес-требования меняются меньше (в большинстве случаев), чем ваши функциональные требования, и, как правило, они более объективны. «Если мы не найдем лучший способ связаться с нашим клиентом, мы можем выйти из бизнеса!» Итак, бизнес-требование будет выглядеть примерно так: «Нам нужно связаться с клиентом с информацией xyz», а не «система….».

Помните, что «Система должна делать то или это…» описывает , как (или функциональные возможности). Это проявление бизнес-требований в системе.

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

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

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

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

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

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

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

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

Повысьте эффективность сбора информации с помощью нашей быстрой подсказки по методам сбора требований.

Например, при обсуждении того, почему вы хотите общаться со своими клиентами, когда они покупают определенные продукты, основное внимание уделяется решению и направлению. Это для узнаваемости бренда или, может быть, для продажи дополнительных товаров или услуг? Ответы на эти вопросы и мозговой штурм о том, как вы могли бы достичь этих целей, создают моменты «ага».Это создает инновации. Это способствует совершенству в бизнесе. Когда все хорошо разбираются в бизнесе, легче понять, в каких новых направлениях следует двигаться, чтобы добиться успеха.

Как нам достичь истинных бизнес-требований?

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

Когда я не преподаю, я управляю ИТ в компании по управлению расходами на телекоммуникации, поэтому я живу и дышу данными.Без правильных и полных данных мой бизнес быстро потерял бы клиентов! Это означает, что я неравнодушен к данным и обычно начинаю с них. Если вы более «ориентированы на процесс», вы можете начать с этого. Неважно, с чего вы начнете, если вы хорошо разбираетесь в бизнесе.

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

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

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

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

Я обычно вижу озадаченные лица, когда говорю людям, что утверждения «система должна» не являются бизнес-требованиями, а скорее функциональны. Но потом я получаю ага! момент, когда они начинают понимать, почему им нужно понимать и сообщать истинные бизнес-требования. Именно тогда в дело вступают инновации, реальные изменения, творчество, нестандартное мышление! Если вы действительно понимаете, ЧТО делает бизнес, вы можете найти лучшее решение для этого бизнеса.

Я надеюсь, что мы в ИТ-индустрии не станем жертвой старого образа мышления «просто начни строить, и это будет здорово». Я делал это раньше; это не здорово. Это приводит к дорогостоящему редизайну и переделке, и даже это делается не очень хорошо, потому что теперь мы отстаем, а бизнес разочарован. Как насчет того, чтобы сделать это правильно с первого раза? Я говорю да!

Спасибо,

— Али

Примечание редактора. Эта запись в блоге была первоначально опубликована в феврале 2014 года. В связи с ее популярностью, Али полностью переработал и обновил свое содержание, сделав его более полным и точным для современного состояния среды.

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

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

Чтобы проиллюстрировать это, одна вики определяет бизнес-требования как «выраженные в терминах общих результатов, которые требуются бизнесу, а не конкретных функций, которые система может выполнять. Конкретные элементы дизайна обычно выходят за рамки этого документа ». ¹ Другой отмечает, что бизнес-требования «описывают в бизнес-терминах, что должно быть выполнено или выполнено, чтобы обеспечить ценность [выделено ими]». ² BABOK 2.0 ( A Guide to the Business Analysis Body of Knowledge , полное руководство по всем вопросам, связанным с бизнес-анализом ³) просто заявляет, что «Бизнес-требования — это заявления более высокого уровня о целях, задачах или потребности предприятия. Ключевым термином здесь является высшего уровня. Бизнес-требования — это то, что аналитик может показать руководителю, чтобы помочь ему понять необходимость проекта, а не то, что она покажет инженеру, чтобы помочь ему построить проект. BABOK продолжает: «Они описывают причины, по которым проект был инициирован, цели, которые проект будет достигать, и показатели, которые будут использоваться для измерения его успеха». Короче говоря, это диаграмма бизнес-требований, в которой будет развиваться проект, а не то, как он будет реализован.

Чтобы составить бизнес-требования, аналитик должен сначала определить ключевые заинтересованные стороны, которые всегда будут включать владельцев бизнеса или спонсоров проекта. Очень часто в их состав также входят эксперты в предметной области и конечный пользователь / заказчик. BABOK 2.0 описывает другие заинтересованные стороны, от которых аналитик может запросить требования, включая регулирующих органов (которые могут вводить новые нормативные требования в результате проекта) и экспертов по вопросам реализации (которые могут быть осведомлены о возможностях, которые в настоящее время присутствуют в существующих системах или легко добавляются к ним. ).Эти заинтересованные стороны должны быть тщательно проверены и проинтервьюированы, чтобы завершить подробное исследование бизнес-требований. Любая существующая документация, относящаяся к проекту, также должна быть тщательно проверена.

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

Бизнес-требования, которые аналитик создает для этого проекта, будут включать (но не ограничиваться ими):

Выявление бизнес-проблемы (ключевые задачи проекта), т.е.е., «Снижение продаж билетов требует стратегии увеличения количества посетителей в наших кинотеатрах».
Почему было предложено решение (его преимущества; почему оно приведет к желаемому результату — возврату продаж билетов на более высокий уровень), т. Е. «Клиенты в подавляющем большинстве назвали неудобство стоять в очереди как главную причину, по которой они больше не посещают наш театр. . Мы устраним это препятствие, позволив клиентам покупать и распечатывать билеты в театр дома всего за несколько кликов.”
Объем проекта. Вот несколько примеров: «1. Планируется, что в конечном итоге этот проект будет реализован во всех 400 театрах, но мы начнем с 50 театров в самых густонаселенных мегаполисах ».
Правила, политика и положения. Например: «Мы будем спроектировать наш веб-сайт и торговлю так, чтобы все правила FCC, SEC и другие соответствующие правительственные постановления соблюдались».
Ключевые особенности услуги (без подробностей о том, как они будут реализованы).Вот несколько примеров: «1. Мы обеспечим безопасный сайт, на котором пользователь сможет выбрать количество билетов и их желаемое, а также ввести свою платежную информацию. 2. Мы дадим пользователю возможность сохранить информацию о своей карте в нашей системе, чтобы им не приходилось повторно вводить ее в более позднем сеансе. 3. Система поддерживает только кредитные, дебетовые и платежные методы PayPal ».
Ключевые характеристики производительности (без подробностей о том, как они будут реализованы), т.е.е., «1. Система будет спроектирована таким образом, чтобы она могла восстанавливаться в течение 30 секунд после любого простоя. 2. Поскольку наша пиковая аудитория составляла 25 000 посетителей во всех наших кинотеатрах за одну ночь, система сможет обслуживать как минимум в 10 раз больше пользователей в любой момент времени без какого-либо влияния на производительность системы ».
Ключевые функции безопасности (опять же без подробностей), например: «Мы разработаем уникальный идентификатор для каждого билета, который будет запрещать ксерокопии или подделки».
Критерии для измерения успеха проекта, такие как: «Этот проект будет считаться успешным, если продажи билетов вернутся к уровню 2008 года в течение 12 месяцев после его запуска.”

Итоговые бизнес-требования этого проекта не включают:

Описание того, как соблюдать правительственные или нормативные требования.
Описание того, как будут реализованы требования к производительности, например: «Сервер XYZ, на котором хранится информация о клиентах, будет архивироваться каждые пять минут с помощью программы XYZ».
Любое описание того, как будет реализован уникальный идентификатор билета.
Любые подробности или особенности, относящиеся к функциям службы, например: «1. Текстовое поле номера кредитной карты будет состоять из 20 символов и содержать простой текст. 2. Если пользователь выберет «Да» (01), информация будет загружена на наш вызываемый сервер хранения XYZ ».

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

Как и все требования, бизнес-требования должны быть:

Поддается проверке. Тот факт, что бизнес-требования формулируют бизнес-потребности, а не технические спецификации, не означает, что они не должны быть продемонстрированы. Поддающиеся проверке требования конкретны и объективны. Эксперт по контролю качества должен иметь возможность, например, проверить, поддерживает ли система методы дебета, кредита и PayPal, указанные в бизнес-требованиях.(S) он не смог бы этого сделать, если бы требования были более расплывчатыми, например: «Система будет поддерживать соответствующие способы оплаты». ( Соответствующий подлежит интерпретации.)
Однозначно, точно указывающая, какая проблема решается. Например, фраза «Этот проект будет считаться успешным, если продажи билетов значительно увеличатся», вероятно, слишком расплывчата, чтобы все заинтересованные стороны могли согласиться с ее смыслом в конце проекта.
Комплексный, охватывающий все аспекты бизнес-потребностей.Бизнес-требования — это действительно большая картина, но это очень полная картина. В вышеупомянутом примере, если бы аналитик предположил, что разработчики будут знать, как спроектировать систему, которая могла бы обслуживать во много раз больше клиентов, которых сеть кинотеатров видела за один раз в прошлом, но не указал это явно в требованиях, разработчики могут спроектировать систему, способную одновременно обслуживать только 10 000 посетителей без проблем с производительностью.

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

¹ http://en.wikipedia.org/wiki/Business_analyst

² http://en.wikipedia.org/wiki/Requirement

³ Руководство к Своду знаний по бизнес-анализу (BABOK)

2018-10-18 Requirements.com Все о требованиях 2020-09-20 Требования.com Персонал Каковы бизнес-требования?

Советы по написанию документов бизнес-требований

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

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

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

Что такое документ с бизнес-требованиями?

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

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

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

Бизнес-требования vs.функциональные требования

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

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

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

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

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

Анатомия великого BRD

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

Структура может отличаться, но базовая BRD будет включать следующие разделы и компоненты:

Обзор проекта (включая видение, цели и контекст)
Факторы успеха
Объем проекта
Идентификация заинтересованных сторон
Бизнес-требования
Объем решения
Ограничения проекта (например, график и бюджет)
Меры контроля качества

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

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

5 лучших советов по написанию идеального BRD

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

1. Практикуйте эффективное выявление требований

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

В Руководстве по своду знаний по бизнес-анализу (более известному как Руководство BABOK) перечислены девять основных методов выявления:

Мозговой штурм
Анализ документов
Анализ интерфейса
Фокус-группы
Создание прототипов
Семинары по требованиям
Интервью
Наблюдение
Опросы

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

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

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

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

Познакомьтесь со своими заинтересованными сторонами

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

Всегда будьте готовы

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

2. Используйте понятный язык без жаргона.

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

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

3. Изучите прошлые проекты

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

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

4. Подтвердите документацию

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

Этот шаг имеет решающее значение для создания успешного BRD. Без него вы рискуете пропустить ключевые требования или оставить критические ошибки, которые могут сбить ваш проект с пути.

5. Включите визуальные элементы

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

Бизнес-требования: как создать документ с бизнес-требованиями (бесплатный шаблон) | Процессная улица

Том : « Мне нужен новый теплый пуховик для следующей поездки .”
Me : « Отлично, я бы выбрал Patagonia или Arcteryx ».

Почему я рекомендовал Тому эти марки, а эти марки только ?

Это связано с доверием к бренду. Я знаю, что эти бренды поставляют точно, то, что я хочу постоянно.

Как потребители, мы с Томом являемся акционерами Patagonia и Arcteryx. У нас есть ожидания, которые эти два бренда должны удовлетворить, чтобы сохранить наши традиции. Эти ожидания переводятся в требования .В этом сценарии наши требования были:

Соотношение цена / качество
Прочные, долговечные изделия
Функциональные товары
Продукты, которые реализуют их намерения

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

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

Например, исследование Pulse of the Profession показало, что 37% программных проектов терпят неудачу из-за плохо определенных требований.

Поскольку мы не хотим, чтобы вы потерпели неудачу, в этой статье на Process Street мы подробно объясняем, что такое бизнес-требования и как вы можете определить их для своего бизнеса или направления работы. Мы объясняем преимущества правильного определения бизнес-требований.Затем мы разъясняем, как вы можете задокументировать бизнес-требования в документе с бизнес-требованиями, используя шаблон бизнес-требований Process Street.

Похоже на статью, которая вам нужна от до прочитать от до получится … верно? 😉

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

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

Готовы?

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

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

Используя этот шаблон, вы:

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

Щелкните здесь, чтобы получить доступ к нашему шаблону бизнес-требований!

Нет учетной записи Process Street? Не волнуйтесь! Подпишитесь на бесплатную пробную версию сегодня, чтобы получить доступ к сотням готовых шаблонов, подобных этому.

Каковы бизнес-требования и почему вам это нужно

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

При установлении бизнес-требований — также называемых спецификациями требований заинтересованных сторон (Stakeholder Requirement Specification, StRS) — бизнес-процесс, система, программное обеспечение, продукт или услуга анализируются с учетом приоритета конечного пользователя. Решение для удовлетворения потребностей конечных пользователей / заинтересованных сторон подробно описано как бизнес-требование в BRD. На BRD можно сослаться в любой момент.

На изображении ниже вы можете увидеть каркасную структуру BRD.

Понимание бизнес-требований путем понимания того, какие бизнес-требования не соответствуют

Найдите минутку, чтобы подумать о следующем:

Цель или ожидаемая выгода от продукта / услуги / программного обеспечения / процесса или системы,
Описание продукта / услуги / программного обеспечения / процесса или системы,

❓ Вопрос : Что из вышеперечисленного подробно описывает бизнес-требование ? ❓

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

Если вы нашли время записать свой ответ, я благодарю вас 🙇‍♀️. Но я также хочу извиниться за то, что был немного обманщиком.

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

Почему?

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

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

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

Цель : Повышение эффективности сотрудников
Ожидания : Повышение производительности, предоставление заинтересованным сторонам быстрого и оперативного обслуживания
Бизнес-требование : Учет рабочего времени сотрудников в офисе

На основании вышеизложенного можно ли различить цели , , ожидания , и требования , ?

Эту информацию можно добавить в ваш BRD, как показано на изображении ниже.

За счет правильного изображения и последующей идентификации бизнес-требования будут:

Уменьшите частоту отказов проекта : Несогласованные или неверно истолкованные требования могут привести к провалу проекта, поскольку ожидания заинтересованных сторон не оправдываются. Определение бизнес-требований создает прочную основу, на которой создается структурированный процесс или метод для удовлетворения потребностей заинтересованных сторон.
Участвовать в разработке бизнес-обоснования : Четко определенные бизнес-требования помогают описать проект в целом.Это критически важно для выполнения бизнес-стратегии и достижения конкретных целей. Реализация проектов будет продолжаться, что снизит частоту отказов и обеспечит положительную поддержку ключевым заинтересованным сторонам проекта.
Экономия затрат : Установление бизнес-требований на раннем этапе не только повышает вероятность успеха проекта, но и снижает затраты в долгосрочной перспективе. Подумайте об этом: отслеживание хода реализации проекта позволяет сократить количество запросов на изменение и связанных с этим затрат. Кроме того, ценность достигается за счет точного удовлетворения потребностей заинтересованных сторон.
Создает ориентацию на пользователя : эффективный BRD использует интеграцию и анализ воздействия во всех отделах, уделяя приоритетное внимание потребностям заинтересованных сторон. Цель состоит в том, чтобы уравновесить ожидания конечного пользователя и то, что реально осуществить.

Бизнес-требования и функциональные требования

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

Как видно из приведенного выше примера BRD ⬆ — см. 3.1 Функциональные требования — бизнес-требования идут в паре вместе с функциональными требованиями — еще несколько жаргонов, которые можно добавить в свой словарный запас.

Функциональные требования — это детальная разбивка, объясняющая, как результат проекта будет работать в соответствии с указанными бизнес-требованиями.

Это немного сбивает с толку, не правда ли? 😕

Для дальнейшего объяснения рассмотрим пример.

Как автор контента в Process Street, я работаю удаленно вместе с другими членами команды по созданию контента Process Street.Наша команда прилагает все усилия, чтобы удовлетворить бизнес-требования, предъявляемые к нашему отделу.

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

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

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

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

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

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

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

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

Создание BRD с использованием Process Street, шаг № 1: Определение потребностей заинтересованных сторон

После того, как вы соберете свою команду, определите, как вы будете определять потребности своих заинтересованных сторон.Будете ли вы проводить фокус-группы? Раздаточные опросы? Создать прототип продукта?

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

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

Создание BRD с использованием Process Street, шаг 2: определение целей, ожиданий и требований организации

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

Создание BRD с использованием Process Street, шаг № 3: определение рабочих операций, соответствующих определенному требованию

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

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

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

Создание BRD с использованием Process Street, шаг 4: Подробная информация об ответственности, приоритетах, показателях и критериях приемки

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

Чтобы проиллюстрировать последнее, в Process Street мы следуем системе обзора BAMM, оценивая качество производимого контента.На основании этой системы дается процентная оценка , чтобы определить, насколько хорош фрагмент контента, с подробным описанием необходимых поправок для обеспечения требуемого качества контента.

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

Создание BRD с использованием Process Street, шаг 5: Создание контрольного списка бизнес-требований

С BRD обеспечивается четкость, сохраняется фокус и устраняется двусмысленность.

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

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

Для получения дополнительной информации о том, как создавать и редактировать контрольные списки в Process Street, посмотрите видео ниже: Основы создания и редактирования шаблонов .

Создание BRD с использованием Process Street, шаг № 6: Эффективное управление изменениями в вашей организации

По мере того, как вы представляете новый продукт / процесс / систему / услугу или программное обеспечение, вы вносите изменения в свою организацию.

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

Чтобы помочь вам, команда разработчиков контента Process Street упорно трудилась, чтобы предоставить лучшие бесплатные ресурсы по шаблонам, которые помогут вам правильно спланировать изменения и управлять ими.

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

Создание BRD с использованием Process Street, шаг № 7: Непрерывное управление бизнес-требованиями

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

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

Управляйте изменениями надлежащим образом с помощью модели управления изменениями

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

Для успешного управления изменениями ознакомьтесь с контрольными списками модели управления изменениями Process Street.Доступ к этим контрольным спискам предоставляется ниже вместе с соответствующими деталями контрольного списка.

Контрольный список процессов модели управления изменениями Левина

В модели управления изменениями Левина изменение делится на три этапа:

Этап 1 : Размораживание статус-кво
Этап 2 : Внести изменения
Этап 3 : Повторное замораживание для фиксации изменений для нового статус-кво

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

Щелкните здесь, чтобы получить доступ к контрольному списку процесса модели управления изменениями Lewin!

Контрольный список процесса для модели перехода

Bridges

Модель перехода

Bridges рассматривает изменения как путешествие, а не как резкий сдвиг. Подробно описаны три этапа этого путешествия:

Этап 1 — Конец, проигрыш и отпуск
2 этап — Нейтральная зона
3 этап — Новое начало

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

Щелкните здесь, чтобы получить доступ к контрольному списку процесса модели перехода Bridges!

Контрольный список процесса управления изменениями модели ADKAR

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

A : Осознание необходимости изменений
D : Желание участвовать и поддержать изменение
K : Знание о том, как изменить
A : Способность реализовать необходимые навыки и поведение для изменений
R : усиление для поддержания изменений

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

Щелкните здесь, чтобы получить доступ к контрольному списку процесса управления изменениями модели ADKAR!

Контрольный список процессов для модели McKinsey 7-S

Модель McKinsey 7-S выделяет 7 элементов компании, подробно описывая, как одно будет влиять на другое. Эти элементы разделены на 2 категории: жесткий и мягкий . Жесткие элементы управляются менеджментом и более осязаемы. Мягкие элементы обусловлены культурой и менее осязаемы.

Жесткие элементы включают :

Стратегия
Строение
Системы

Мягкие элементы включают :

Общие значения
Стиль
Персонал
Навыки

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

Щелкните здесь, чтобы получить доступ к контрольному списку процесса моделирования McKinsey 7-S!

Контрольный список процессов модели управления изменениями цикла PDCA

Цикл PDCA рассматривает изменения как непрерывный процесс улучшения.

Есть четыре этапа:

1 этап : план
Этап 2 : До
Этап 3 : Проверка
Этап 4 : Закон

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

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

Рекомендуется использовать цикл PDCA, когда вы подойдете к концу нашего шаблона бизнес-требований, в разделе «Управление текущими требованиями» .

Щелкните здесь, чтобы получить доступ к Контрольному списку процесса модели управления изменениями цикла PDCA!

Контрольный список процесса модели управления изменениями Коттера

Основная цель модели управления изменениями

Коттера — создать ощущение срочности изменений. Модель заявляет, с этой срочностью, импульс для изменений получен.

Модель разбивает заявку на изменение на 8 этапов:

Этап 1 — Создание ощущения срочности
Этап 2 — Создание основной коалиции
Этап 3 — Формирование стратегического видения
Этап 4 — Привлечение всех на борт
Этап 5 — Удаление барьеров и снижение трения
Этап 6 — Краткосрочные победы
7 ступень — Поддерживающее ускорение
Этап 8 — Закрепление изменений в камне

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

Нажмите здесь, чтобы получить доступ к контрольному списку процесса модели управления изменениями Kotter!

Контрольный список процесса изменения кривой Кюблера-Росс

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

Кривая изменений Кюблера-Росса описывает пять этапов горя в процессе изменений:

Этап 1 : Отказ
Этап 2 : Гнев
3 этап : торг
4 этап : Депрессия
Этап 5 : Приемка

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

Щелкните здесь, чтобы получить доступ к контрольному списку процесса изменения кривой Кюблера-Росса!

Контрольный список процесса модели управления изменениями теории подталкивания

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

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

Щелкните здесь, чтобы получить доступ к контрольному списку процесса модели управления изменениями теории подталкивания!

Для получения дополнительной информации о теории подталкивания и архитектуре выбора, читайте : Разъяснение архитектуры выбора: как избавиться от человеческих предубеждений в вашем бизнесе сегодня!

Контрольный список процесса модели управления изменениями Satir

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

Эти этапы горя:

Этап 1 : Позднее статус-кво
Этап 2 : Сопротивление
Этап 3 : Хаос
Этап 4 : Интеграция
Этап 5 : Новый статус-кво

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

Щелкните здесь, чтобы получить доступ к контрольному списку процесса модели управления изменениями Satir!

Впервые на Process Street? Краткий обзор, который поможет вам начать работу

Process Street — это сверхмощных контрольных списков.

Как наши контрольные списки наделены сверхспособностями?

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

Остановить задачи, чтобы обеспечить порядок задач.
Динамические сроки выполнения, поэтому ни один крайний срок не пропущен.
Условная логика, создание динамического шаблона, который удовлетворяет вашим потребностям.
Назначение ролей, чтобы упростить делегирование задач в вашей команде.
Утверждения, позволяющие лицам, принимающим решения, давать добро (или отклонять) важные вопросы. Также могут быть предоставлены необходимые комментарии.
Webhooks, чтобы приложения могли отправлять автоматические сообщения или информацию напрямую другим приложениям.Отличная функция, позволяющая уведомлять другие инструменты о статусе контрольных списков и задач в Process Street.
Назначения задач, чтобы назначать пользователей и группы для отдельных задач в ваших контрольных списках, что позволяет легко увидеть, кто за что отвечает.
Embed Widget, позволяющий просматривать и взаимодействовать с другими приложениями, не покидая контрольный список.

Готов поспорить, вам не терпится начать! Зарегистрируйтесь на Process Street бесплатно уже сегодня!

Начните определять бизнес-требования уже сегодня и последовательно удовлетворяйте потребности заинтересованных сторон

Установление бизнес-требований на раннем этапе жизненно важно для успеха нового продукта / проекта / услуги / программного обеспечения или системы.Четко определенные бизнес-требования будут:

Сэкономьте деньги,
Экономьте ваше время,
Значительно снизить вероятность отказа,
Внесите вклад в развитие вашего бизнес-кейса,
Помогите вам сосредоточиться на удовлетворении потребностей заинтересованных сторон.

Что терять?

С шаблоном бизнес-требований Process Street устанавливать бизнес-требования еще никогда не было так просто. Используйте наш шаблон бизнес-требований, чтобы создать BRD.Используйте свой BRD вместе с нашими контрольными списками модели управления изменениями для успешного внедрения вашего нового продукта / проекта / услуги / программного обеспечения или системы.

Как вы определяете и документируете бизнес-требования в своем бизнесе или сфере деятельности? С какими успехами и проблемами вы столкнулись? Мы будем рады услышать от вас, пожалуйста, оставьте комментарий ниже. Кто знает, возможно, вы даже попадете в грядущую статью !

Краткое руководство по бизнес-требованиям

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

Какие они?

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

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

Понимание бизнес-требований на примере

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

Итак, бизнес-требование здесь будет:

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

Отметим здесь кое-что, это бизнес-требование Скотта:

Определяет высокоуровневые потребности организации, не вдаваясь в подробности. По сути, он отвечает на вопрос «Чего хочет» организация?
В нем указаны преимущества, которые будут достигнуты, когда требование будет выполнено. Он отвечает: «Зачем» это нужно организации?
Написано с точки зрения организации, а не с точки зрения какой-либо заинтересованной стороны.

Что они включают?

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

- История проекта — является ли проект результатом смены правительства. политики, либо движется изменением технологий или рынка
- Причина инициирования бизнес-требований
- Бизнес-цели и задачи
- Контекст требований, их описание (включая как функциональные, так и нефункциональные требования) и, если доступно, включение любой связанной исходной информации / данных
- Влияние требований и затронутые стороны
- Список всех основных заинтересованных сторон
- Видение и особенности бизнес-решения
- Факторы / индикаторы, определяющие выполнение бизнес-требований
- Любые ограничения или ограничения (для e.грамм. график, объем или бюджет), обеспечиваемый бизнес-средой или системой
- Любые допущения, которые необходимо учитывать в отношении бизнес-требований.
- Терминология и соответствующее объяснение делового языка
- Любые риски, выявленные против выполнения предложенных требований
- Технологические потоки, модели и блок-схемы для изображения системы «как есть» или «как будет»

Где они задокументированы?

Документом, в котором четко и точно представлена вся вышеперечисленная информация, является BRD (Business Requirements Document) .Основным мотивом BRD является перечисление того, что должно достичь решение, без учета того, как это должно быть достигнуто.

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

Связанная статья: 9 важных документов, создаваемых каждым бизнес-аналитиком

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

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

Самые популярные статьи

В поисках хороших требований

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

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

Определение требования

Более точное определение дается в Глоссарии терминологии программной инженерии IEEE и в Сводах знаний по бизнес-анализу (BABOK®).Оба определяют требование как

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

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

BABOK® определяет следующие типы требований: бизнес, пользователь (заинтересованное лицо), функциональный (решение), нефункциональный (качество обслуживания), ограничение и реализация (переход).

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

Примеры различных типов требований

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

Таблица 1. Примеры требований

Область применения

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

Заинтересованные стороны

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

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

Выявление требований — это на удивление тяжелая работа. Заинтересованные стороны часто не знают точно, что им нужно, и выявление требований может быть довольно сложной задачей. Как резко заявил Фред Брукс в своем основополагающем эссе «Нет серебряной пули: сущность и случайности разработки программного обеспечения»

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

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

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

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

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

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

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

Рисунок 1.Деятельность по управлению требованиями

Деятельность по управлению требованиями

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

Процесс обработки требований

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

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

Рисунок 2.Процесс управления требованиями

Обязательства заинтересованных сторон

Чтобы ИТ-проект был успешным, у заинтересованных сторон есть определенные обязанности:

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

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

Выявление и обнаружение требований

Для выявления требований аналитик применяет различные методы. Этапы сбора требований обычно следующие:

Спланируйте процесс выявления требований и то, как группа будет документировать и проверять требования. Этот план называется Планом управления требованиями (RMP) и считается ключевым документом для планирования проекта.
Напишите Устав проекта или Заявление о миссии проекта, содержащее бизнес-требования и общий объем проекта. Часто контекстная диаграмма используется для пояснения объема работ по разработке системы. Все заинтересованные стороны должны согласиться с видением проекта. Некоторые организации называют этот документ Документом бизнес-требований (BRD). Используйте мозговой штурм и собеседование, чтобы определить ключевые бизнес-требования.
Определите ключевых пользователей и их характеристики использования и выберите прокси для каждого пользователя, который может представить требования для этого класса пользователей.С этими «представителями пользователей» будут проводиться консультации во время сбора требований.
Сотрудничайте с представителями пользователей, чтобы определить варианты использования, а затем проанализировать эти варианты использования, чтобы получить подробные функциональные требования для продукта.
Проанализируйте любые события, на которые должна реагировать система, например, ввод от аппаратных устройств или сообщения от других систем.
Укажите другие заинтересованные стороны, которые могут предоставить требования или ограничения.
Проведение семинаров по требованиям, на которых пользователи в течение нескольких дней работают вместе, чтобы изучить потребности пользователей и согласовать требования.Семинары по требованиям — это способ сократить время, необходимое для поиска всех требований, за счет одновременного объединения всех участников. Совместное планирование требований (JRP) и Совместная разработка приложений (JAD) являются примерами упрощенных семинаров по требованиям.
Тень пользователей, выполняющих рабочие задачи, и использование результатов наблюдений для определения потребностей и понимания бизнес-процессов. Задокументируйте эти идеи в виде блок-схем или диаграмм действий UML.
Проводите сеансы обратной связи, во время которых пользователи могут оставлять отзывы о проблемах или проблемах с текущей системой.Результаты могут быть использованы для формулирования требований по улучшению системы. Просмотр отчетов о проблемах из службы поддержки может быть особенно полезным.
Создайте прототип, демонстрирующий требования и обеспечивающий реалистичную обратную связь с пользователями.
Выявить, задокументировать и устранить любые риски, которые могут негативно повлиять на проект, , то есть , которые могут вызвать задержку в доставке, увеличение бюджета или сокращение объема.
Подтвердите требования с помощью пошаговых инструкций и других официальных или неофициальных встреч с заинтересованными сторонами, чтобы убедиться, что правильные требования были обнаружены.

Анализ требований

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

Артефакты анализа

В ходе анализа аналитик конструирует ряд текстовых, цифровых и визуальных артефактов, в том числе:

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

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

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

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

Проверка требований

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

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

Написание эффективных требований

Документирование требований — важная часть процесса требований. За прошедшие годы было разработано множество подходов к документированию требований.Среди наиболее важных рекомендаций — стандарт IEEE Standard 830, содержащий рекомендуемые методы написания спецификаций требований к программному обеспечению (SRS).

Полезные требования обладают несколькими важными характеристиками:

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

Форматы документации

Требования обычно записываются в виде простых повествовательных утверждений.Требования пользователей лучше всего выражать в виде более подробных документов. Распространенным форматом документирования требований пользователей являются варианты использования. Кроме того, создание визуальных моделей упрощает передачу сложных требований. Визуальная модель, такая как диаграмма UML, может более точно описать требования, чем письменный абзац. Также легче обнаружить ошибки в диаграмме, чем в длинном повествовании. Спецификация требований обычно включает комбинацию описаний, вариантов использования и визуальных моделей.

Идентификация требований

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

Требования пользователя выражаются как варианты использования и используют префикс UC, , например , UC1.
используются префиксы R или FR, , например. , R92, FR876
Business Requirements использует префикс O (для цели), e.грамм. , О2
используют префикс BR, , например , BR12
Нефункциональные требования (или требования к качеству обслуживания) также используют префикс R, хотя некоторые предпочитают использовать NFR, например R14 или NFR23

Прослеживаемость требований

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

Утверждение требований

Многие организации имеют формальный процесс «подписания» или утверждения, когда заказчик или спонсор проекта формально соглашаются с зафиксированными требованиями. Хотя это в некоторой степени формально, утверждение следует рассматривать как веху проекта, а не как формальный контракт.Скорее всего, после подписания требования все равно изменятся. В конце концов, бизнес не остается статичным; в деловом мире все постоянно меняется. Команды проекта должны принять процедуру изменения требований, к которой заинтересованные стороны могут прибегнуть, когда требование действительно изменится. Естественно, руководитель проекта должен объяснить заинтересованным сторонам, что изменение требований (путем добавления, изменения или удаления требования из спецификации), вероятно, повлияет на график, бюджет и этапы реализации проекта.

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

Заключение

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

Не забудьте оставить свои комментарии ниже.

Доктор Мартин Шедлбауэр, консультант и инструктор Группы корпоративного обучения, является опытным экспертом в предметной области бизнес-анализа. Более двадцати лет он руководит и создает семинары и практикумы по бизнес-анализу, разработке программного обеспечения и управлению проектами.Помимо этого, он обучает своих клиентов методам бизнес-анализа, моделированию процессов и бережливому управлению проектами. Когда он не работает со своими клиентами или не проводит семинары для CEG, он читает лекции в Северо-Восточном университете в Бостоне в качестве клинического профессора.

[1] Брукс, Ф., «Серебряной пули нет: сущность и случайности разработки программного обеспечения». IEEE Computer, 20 (4), апрель 1987 г., стр. 10–19.

[2] Mashup — это повторная комбинация доступных веб-компонентов для обеспечения новых мощных функций с использованием простых визуальных редакторов и небольшого программирования.В качестве примеров см. Каналы Yahoo и гибридные приложения Google.