Разработка требований к ПО: основные понятия, уровни и типы требований

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

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

Что внутри:

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

Очень часто при внедрениях от клиента можно услышать фразы типа: «А как этого нет. Это же есть в ….. Я думал, что это само собой понятно. Я без этого не смогу нормально работать. Ваша система …..» Ну и дальше в таком роде. Справедливо ли это? Наверное нет. Каждая система (в данном случае я говорю про ERP) содержит определенный функционал и может в себе не содержать некоторые «фичи» которые есть в других.

И когда начинается разработка или внедрение клиент должен озвучить все свои «хотелки» иначе существует риск, что что-то не будет реализовано и тогда пиши пропало.

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

Стадия сбора требований как правило предшествует стадии разработки и внедрения. И именно на ней формируется scope проекта.

Содержание проекта (Project Scope) Работы, которые необходимо выполнить, чтобы получить продукт, услуги или результат с указанными характеристиками и функциями.

Содержание

1 Что же такое требование? Уровни и типы требований

2 Разработка и управление требованиями2.1 Выявление и сбор требований (elecitation)

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

2.3 Документирование

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

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

3 Основные проблемы при работе с требованиями3.1 Недостаточное вовлечение пользователей

3.2 Небрежное планирование

3.3 «Разрастание» требований пользователей

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

3.5 Требования -«бантики»

3.6 Противоречивые требования

4 Выводы

Что же такое требование? Уровни и типы требований

Здесь и далее я буду опираться на определения из книги Карла Вигерса и Джоя Битти «Разработка требований к программному обеспечению»

Существует много определений данного понятия мы же остановимся на таком:

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

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

Словарик бизнес-аналитика

Бизнес-требование — высокоуровневая бизнес-цель организации или заказчиков системы. Оно должно отвечать на вопрос «Что?» и «Зачем?».

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

Ограничение — ограничение на выбор вариантов, доступных разработчику при проектировании и разработке продукта.

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

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

Функциональное требование — описание требуемого поведения системы в определенных условиях.

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

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

Системное требование — требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования

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

Требования к ПО состоят из трех уровней:

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

Вдобавок к этому выделяют еще нефункциональные требования.

Давайте рассмотрим каждый уровень чуть более детальней.

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

Пользовательские требования (user requirements) описывают цели и задачи, которые пользователь должен иметь возможность выполнять с помощью продукта. Они описывают то, что пользователь должен иметь возможность делать с системой. Это по сути user stories и сценарии. Например: «Я как пользователь системы хочу иметь возможность быстро посмотреть остатки конкретного товара на складе и посмотреть историю его перемещений»

Функциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях. Такие требования описывают в форме традиционных утверждений со словами должен или должна. Например — «система должна в момент проведения в системе документов по взаиморасчетам с контрагентами (инвойс, банковская выписка) дать возможность указать договор по которому ведутся взаиморасчеты» или «система должна давать возможность пользователю выбрать место хранения при закупке товара, куда он будет оприходован» или «должна быть возможность указать в карточке сотрудника дату его рождения и система за 2 дня до его наступления должна высылать директору по персоналу об этом уведомление».

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

Системные требования (system requirements) описывают требования к продукту, которые содержит многие компоненты или подсистемы (например рабочее место кассира, которое оборудовано сканером считывания штрих-кодов, весами, принтером и т.д.).

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

Примеры бизнес-правил: «При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру», «Если оплата по счету не поступила в течение 15 дней, заказ считается отменённым»

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

«API метод должен возвращать список ресторанов в короткой форме: id, название, адрес»

Это функциональное требование, оно описывает поведение системы.

«API метод должен отдавать данные не более чем за 200ms на 95 перцентиле и не более чем за 500ms на 99 перцентиле.»

А это уже нефункциональное требование, которое описывает определённый атрибут качества – performance.

Разработка и управление требованиями

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

Выявление и сбор требований (elecitation)

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

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

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

Этот этап подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде. Основными действиями на этом этапе будут:

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

Документирование

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

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

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

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

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

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

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

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

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

Основные проблемы при работе с требованиями

Выявление требований непростой процесс. Проблему усугубляет то, что заказчик может говорить о чем угодно, но только не о том, что ему действительно нужно. Основное следствие проблем с требованиями — переделка того, что вы думаете что уже готово (на это расходуется от 30 до 50% общего бюджета разработки). С ростом объема переделок растет и растрата ресурсов и разочарования.

Создание более качественных требований это инвестиции, а не затраты.

Недостаточное вовлечение пользователей

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

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

Небрежное планирование

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

«Разрастание» требований пользователей

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

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

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

Требования -«бантики»

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

Противоречивые требования

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

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

Выводы

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

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

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

Вопрос: Что такое требование к ПО?

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

Вопрос: Зачем нужен сбор требований?

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

Вопрос: Какие бывают типы требований?

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

Вопрос: Что такое scope проекта?

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

Вопрос: Какие ошибки чаще всего возникают при работе с требованиями?

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

← Предыдущая статья

Новая парадигма «унифицированной схемы звезды» в обзоре моделирования данных Google Analytics

Следующая статья →

Как установить на Ubuntu Apache Superset