В бизнес анализе выделяют следующие типы требований

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

Сбор требований

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

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

Выжимка по процессу формирования требований

Функциональные требования — это требования к системе.
Бизнес-требования — эквивалентно бизнес-целям.
Между ними — Пользовательские требования, 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) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• легкость и простота использования;
• легкость перемещения;
• целостность;
• эффективность и устойчивость к сбоям;
• внешние взаимодействия между системой и внешним миром;
• ограничения дизайна и реализации. Ограничения (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).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.

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

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

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

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

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

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

Рубрика: Качество
требований,Статья

Данная
статья является второй в серии статей,
которые я публикую в рамках темы
“Управление качеством требований”.
Введение к серии было представлено на
данном сайте в теме “Управление
качеством требований. Начало.”
от 12 декабря 2009 года.

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

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

На сегодняшний день существует множество
определений термина требование к
программному обеспечению (software
requirement). Наиболее подходящим, на мой
взгляд, является определение, приведенное
в [2]:

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

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

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

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

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

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

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

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

Для проектов, разрабатываемых в
соответствии с ГОСТ, «бизнес требования»
описывают цели и назначение разрабатываемой
системы, и могут размещаться в
соответствующем разделе технического
задания.

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

Ключевые возможности

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

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

Соседние файлы в папке 09.17.12

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Одна из основных профессиональных обязанностей системного и бизнес-аналитика – это управление требованиями при разработке программного обеспечения. Сегодня мы рассмотрим, какие виды требований выделяет BABOK®Guide и как это профессиональное руководство по бизнес-анализу рекомендует работать с ними.

Что такое требование и дизайн по BABOK

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

• Бизнес-требование (business requirement), которое отвечает на вопросы «Почему это нужно?» или «Зачем я этого хочу?» и представляет собой отображение целей, задач и результатов, объясняющих, для чего было инициировано изменение и каким образом будет оцениваться успех его реализации;
• Требование стейкхолдера (stakeholder requirement), которое отвечает на вопрос «Что нужно?» и описывает потребности отдельной заинтересованной стороны или целой группы стейкхолдеров, необходимые для выполнения бизнес-требований. Фактически, они могут играть роль проводника от бизнес-требований до требований к решению.
• Требование к решению (solution requirement), которое отвечает на вопрос «Что я хочу?» и описывает возможность или качество решения, удовлетворяющие требованиям стейкхолдера. Требования к решению делятся на функциональные требования и нефункциональные. Функциональное требование (functional requirement) означает поведенческую возможность, которую должно предоставлять решение. Нефункциональное требование (non-functional requirement) описывает особенности эксплуатации: производительность, информационную безопасность, удобство использования и выражается в измеримых показателях, которые являются своего рода ограничениями варианта реализации (дизайна) решения. Подробнее про нефункциональные требования читайте в нашей новой статье.
• Переходное требование (transition requirement), которое отвечает на вопрос «Каковы условия реализации перехода от бизнес-потребности к внедренному решению?», описывая возможности решения и условия, каким оно должно соответствовать для перехода из текущего состояния в целевое. В отличие от других видов требования, переходное требование является временным, т.к. становится не нужным после завершения изменения. Например, требование относительно форматов и процедур преобразования данных при переходе от одной системы к другой.

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

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

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

Задачи управления требованиями в BABOK®Guide

Из 6-ти областей знаний BABOK целых 2 посвящены непосредственной работе с требованиями: «Управление жизненным циклом требований» (Requirement Life Cycle Management) и «Анализ требований и определение дизайнов» (Requirements Analysis and Design Definition). Как видно из названия, область знаний «Анализ требований и определение дизайнов» носит инструментальный характер и сосредоточена на моделировании – именно здесь разрабатываются различные виды процессных и структурных диаграмм, например, UML, BPMN, IDEF0, EPC, DFD или ERD, чтобы описать поведение и строение проектируемого решения, а также процедуры работы с ним через решение следующих задач бизнес-анализа:

• Спецификация и моделирование требований (Specify and Model Requirements)
• Верификация требований (Verify Requirements)
• Валидация требований (Validate Requirements)
• Определение архитектуры требований (Define Requirements Architecture)
• Определение вариантов дизайна (Define Design Options)
• Анализ потенциальной ценности и рекомендация решения (Analyze Potential Value and Recommend Solution)

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

• Трассировка (Trace Requirements)
• Поддержание (Maintain Requirements)
• Приоритизация (Prioritize Requirements)
• Оценка изменений (Assess Requirements Changes)
• Утверждение (Approve Requirements)

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

Практическое управление требованиями реализуется с помощью соответствующих программных инструментов, например, Archi для моделирования диаграмм, и Jira для трассировки, приоритезации и поддержания требований. В следующей статье мы рассмотрим, как организовать управление требованиями в Agile-проектах с учетом особенностей гибких методологий и строгих предписаний ГОСТов на разработку ТЗ. А процессы и стадии жизненного цикла требований разбираются в этом материале.

А освоить техники и рекомендации BABOK®Guide по управлению требованиями и другим задачам бизнес-анализа вам помогут курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации аналитиков, менеджеров и ИТ-специалистов в Москве:

• Управление бизнес-анализом – курс для руководителей
• Разработка ТЗ на информационную систему по ГОСТ и SRS

Данная статья – продолжение нашей большой статьи по бизнес-анализу. Чтобы читать сначала, пожалуйста, перейдите по этой ссылке.

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

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

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

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

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

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

Хорошая практика – использовать единый язык во всех сборах требований. Требования заинтересованных сторон должны начинаться с «Пользователь запрашивает …». Функциональные и нефункциональные требования должны начинаться с «Решение должно …» или «Система должна …».

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

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

Виды сбора требований в бизнес-анализе

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

Готовясь к взаимодействию с заинтересованными сторонами, сначала соберите письменный материал в виде анализа процессов и вариантов использования:

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

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

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

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

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

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

1. Необходимое?
2. В рамках проекта?
3. Конкретное?
4. Измеримое?
5. Достижимое?
6. Реалистичное?
7. Отслеживаемое?
8. Грамматически правильное?
9. Правильно определенно и организованно?
10. Отвечает ли оно на вопрос «Что», а не «Как»?

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

Сбор требований через собеседование

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

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

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

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

• Начинайте с открытых вопросов (Кто? Что? Когда? Где? Почему? Как?). Используйте их для того, чтобы люди говорили и предоставляли информацию. Например, «В чем основная причина вашего желания внести это изменение?», «Кто еще в этом будет участвовать?».
• Затем переходите к закрытым вопросам. Используйте эти вопросы, уточняя информацию и спрашивая о предпочтениях. Например, «вы бы предпочли вариант А или Б, если …?».
• Фактические вопросы используются для получения конкретной информации, например, «сколько товара создается в час?» или «сколько требуется одновременных входов в систему?».
• Эмоциональные вопросы используются для выявления болевых точек, опасений и воздействий. Например, «Расскажите мне, когда в последний раз вас разочаровывал текущий процесс?».

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

В процессе собеседования требования бывают двух форм: явные и предполагаемые. Явные требования легче всего услышать. Пользователь очень четко описывает свои потребности или предложения по улучшению: «Мне нужна пропускная способность 50 упаковок в минуту» или «Наша служба должна соответствовать стандарту ISO …, раздел 15, пункт 4.2».

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

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

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

Сбор требований через мозговой штурм

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

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

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

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

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

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

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

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

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

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

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

Сбор требований через наблюдение за работой

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

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

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

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

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

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

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

Сбор требований с помощью опросов

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

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

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

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

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

При подготовке опроса рассмотрите следующие шаги:

• Начните анкету с простых вопросов. Используйте краткие заявления. Делайте вопросы как можно короче, но обеспечивайте достаточный контекст, чтобы респонденты могли понять вопрос.
• Используйте слова и язык, который понятен респондентам.
• Включите вариант ответа «Неизвестно», «Ни один из вариантов». Респонденты, которые не знают или не имеют опыта работы с темой вопроса, не должны оценивать или комментировать ее.
• Создайте категории, охватывающие все возможные ответы.
• Оставьте достаточно места для письменных комментариев. Поощряйте респондентов писать больше, предоставляя достаточное количество строк для ответов.
• Анкета должна быть как можно короче. Уменьшение длины анкеты увеличивает количество откликов.
• Укажите дату, до которой должны быть отправлены ответы.

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

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

Использование бизнес-правил и матрицы отслеживания требований

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

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

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

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

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

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

1. Она документирует источник всех требований. С помощью этой информации разъяснение или проверка требований по мере раскрытия дополнительной информации помогает обеспечить эффективное и действенное создание вашего пакета требований. Это помогает обеспечить выполнение всех требований.
2. В случаях, когда временные или финансовые ограничения сокращают проект, понимание требований помогает поддерживать сбалансированные решения и приоритизаровать определенные направления проекта.
3. Помогает отследить доставку того, что заказчик просил и за что заплатил. Согласование объема/цели – это когда мы не обеспечиваем недостаточное или избыточное выполнение, обеспечивая соответствие требований достижению одного или многих пунктов объема проекта.
4. Матрица отслеживания помогает в тестировании и контроле качества. Она фиксирует, как будет проверяться каждое бизнес-требование, и кто будет проводить это тестирование.

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

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

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

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

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

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

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

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

Как понять, что у вас достаточно требований перед началом проекта

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

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

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

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

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

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

Чтобы продолжить чтение, переходите в статью «Проверка и контроль требований в бизнес-анализе. Часть 4»

So, what makes a good requirement? A good requirement should be valuable and actionable; it should define a need as well as provide a pathway to a solution. Everyone on the team should understand what it means. Requirements vary in complexity.

• A good Requirements Document can be part of a group with high-level requirements broken down into subrequirements.

• They may also include very detailed specifications that include a set of functional requirements describing the behavior or components of the endproduct.

• Good requirements need to be concise and specific, and should answer the question, “what do we need?” Rather than, “how do we fulfil a need?”

• Good requirements ensure that all stakeholders understand their part of the plan; if parts are unclear or misinterpreted the final product could be defective or fail.

Preventing failure or misinterpretation of requirements can be aided by receiving feedback from the team continuously throughout the process as requirements evolve. Continuous collaboration and buy-in with everyone is a key to success.

Requirement Gathering and Analysis

A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an organizational objective; a condition or capability that must be met or possessed by a system.

Requirement analysis in software engineering covers those tasks that go into determining the needs or conditions to meet for a new or altered product taking account of the possible conflicting requirements of various stakeholders, analyzing, documenting, validating and managing software or system requirements.

The requirements should be −

• Documented
• Actionable
• Measurable
• Testable
• Traceable

Requirements should be related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

A Business analyst gathers information through observing the existing systems, studying the existing procedures, discussions with the customers and the end users. The analyst should also have imaginative and creative skills in absence of a working System. Analyzing the gathered requirement to find the missing links is requirement analysis.

Eliciting Approach

To elicit the objectives, ask the business expert, the development manager, and the project sponsor the following questions −

• What business objectives of the company will this project help achieve?

• Why are we doing this project now?

• What will happen if we do it later?

• What if we do not do it at all?

• Who will benefit from this project?

• Do the people who will benefit from it consider it the most important improvement that can possibly be made at this time?

• Should we be doing a different project instead?

Possible objectives might be reducing costs, improving the customer service, simplifying the work flow, replacing obsolete technology, piloting a new technology, and many others. Also, make sure you understand exactly how the proposed project will help accomplish the stated objective.

Different Types of Requirements

The most common types of requirement which a Business analyst is interested would be the following −

Business Requirements

Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objectives while remaining solution independent. A business requirements document (BRD) details the business solution for a project including the documentation of customer needs and expectations.

User Requirements

User requirements should specify the specific requirements which the user expects/wants from software to be constructed from the software project. A user requirement should be Verifiable, Clear and concise, Complete, Consistent, Traceable, Viable.

The user requirements document (URD) or user requirements specification is a document usually used in software engineering that specifies what the user expects the software to be able to do.

System Requirements

System requirements deal with defining software resources requirements and prerequisites that needs to be installed on a computer to provide optimal functioning of an application.

Functional Requirements

Functional requirements capture and specify specific intended behavior of the system being developed. They define things such as system calculations, data manipulation and processing, user interface and interaction with the application, and other specific functionality that show how user requirements are satisfied. Assign a unique ID number to each requirement.

Non-Functional Requirements

Non-functional requirement is the one which specifies criteria that can be used to judge the operation of a system rather than specific behaviors. System architecture speaks on the plan for implementing non-functional requirements.

Non-functional requirements speak on how the system should look like or it can be mentioned like “system shall be”. Non-functional requirements are called as qualities of the system.

Transition Requirements

Transition Requirements describe capabilities that the solution must fulfill in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete.

They are differentiated from other requirements types, because they are always temporary in nature and because they cannot be developed until both an existing and new solution is defined. They typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state. They are developed and defined through solution assessment and validation.

Traceability and Change Management

Requirements traceability is a way to organize, document and keep track of all your requirements from initial idea generation through to the testing phase.

The requirements trace ability matrix (RTM) provides a method for tracking the functional requirements and their implementation through the development process. Each requirement is included in the matrix along with its associated section number.

As the project progresses, the RIM is updated to reflect each requirement’s status. When the product is ready for system testing, the matrix lists each requirement, what product component addresses it, and what test verifies that it is correctly implemented

Include columns for each of the following in the RTM −

• Requirement description
• Requirement reference in FRD
• Verification Method
• Requirement reference in Test Plan

Example − Connecting the dots to identify the relationships between items within your project. It is a connector of common downstream flow.

Idea Requirements Design Test Business Objectives

You should be able to trace each of your requirements back to its original business objective.

By tracing requirements, you are able to identify the ripple effect changes have, see if a requirement has been completed and whether it’s being tested properly. Traceability and change management provides managers peace of mind and the visibility needed to anticipate issues and ensure continuous quality.

Quality Assurance

Getting requirements delivered right the first time can mean better quality, faster development cycles and higher customer satisfaction with the product. Requirements management not only helps you get it right, but also helps your team save money and many headaches throughout the development process.

Concise, specific requirements can help you detect and fix problems early, rather than later when it is much more expensive to fix. In addition, it can cost up to 100 times more to correct a defect later in the development process after it’s been coded, than it is to correct early on while a requirement.

By integrating requirements management into your quality assurance process, you can help your team increase efficiency and eliminate rework. Moreover, rework is where most of the cost issues occur.

In other words, development teams are wasting majority of their budgets on efforts that are not performed correctly the first time. For example, a developer codes a feature based on an old specification document, only to learn later, that the requirements for that feature changed. These types of issues can be avoided with effective requirements management best practices.

In summary, requirements management can sound like a complex discipline, but when you boil it down to a simple concept – it’s about helping teams answer the question, “Does everyone understand what we’re building and why?” From the business analysts, product managers and project leaders to the developers, QA managers and testers, along with the stakeholders and customers involved – so often the root cause of project failure is a misunderstanding of the scope of the project.

When everyone is collaborating, and has full context and visibility to the discussions, decisions and changes involved with the requirements throughout the lifecycle of the project, that is when success happens consistently and you maintain continuous quality. In addition, the process is smoother with less friction and frustration along the way for everyone involved.

Note − Research has shown that project teams can eliminate 50-80% of project defects by effectively managing requirements. According to the Carnegie Mellon software engineering institute, “60-80 percent of the cost of software development is in rework.”

Obtaining Requirements Signoff

Requirements signoff formalizes agreement by project stakeholders that the content and presentation of the requirements, as documented, are accurate and complete. Formal agreement reduces the risk that, during or subsequent to implementation, a stakeholder will introduce a new (previously unencountered) requirement.

Obtaining requirements signoff typically involves a face-to-face final review of requirements, as documented, with each project stakeholder. At the end each review, the stakeholder is asked to formally approve the reviewed requirements document. This approval may be recorded either physically or electronically.

Obtaining requirements signoff is typically the final task within Requirements Communication. The Business Analyst will require the output from the Formal Requirements Review(s), including accommodation of any comments or objections which were raised during the review process.