Разработка требований к ПО: этапы, основные проблемы и ошибки

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

Бизнес-анализ и системный анализ

Сущность требований при разработке ПО

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

Как правило, все многообразие требований, которые применяются в сфере разработки ПО, принято классифицировать на несколько основных категорий:

• business-требования — совокупность бизнес ожиданий и потребностей заказчика, которые полностью соотносятся с его главной стратегией и концепцией его будущего развития;

• требования заинтересованных лиц — включают исходные потребности отдельных групп пользователей ПО;

• функциональные требования — раскрывают рабочий функционал и поведение ПО при различных условиях его использования;

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

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

Обратите внимание! При составлении списка требований к ПО следует руководствоваться принципом SMART: требования должны быть конкретными (Specific), измеримыми (Measurable), достижимыми (Achievable), релевантными (Relevant) и ограниченными во времени (Time-bound). Еще один важный момент — сохранение баланса между гибкостью и детализацией. В конечном счете, чрезмерно детализированные требования могут тормозить и ограничивать фантазию разработчиков, а слишком расплывчатые и абстрактные приводят к непониманиям и ошибкам интепретациии. 

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

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

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

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

• Атомарность — одно базовое требование описывает одну функцию. 

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

• Консистентность — требования не могут противоречить друг другу. 

• Прослеживаемость — требование должно быть связано (прямо или косвенно) с практическими бизнес-целями и другими элементами системы/проекта. 

Для удобства при составлении стандартного перечня функциональных требований к ПО применяется следующая структура формулировки: «Программа должна [действие] для [кого/чего] при [условие]». 

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

1. Программа должна позволять пользователям проходить регистрацию, войти в ЛК сайта с помощью email и номера телефона.

2. ПО должно направлять уведомление по заданной форме администратору/службе поддержки в случае 3 (трех) неудачных попыток авторизации. 

3. Система должна хранить историю персональных переписок пользователей за последние 90 дней. 

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

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

Обратите внимание! Для составления перечня требований функционального типа могут использоваться разные методики моделирования: графики и диаграммы последовательностей (Sequence Diagrams), пользовательские истории (User Stories), диаграммы вариантов использования (Use Case), модели переходов состояний (State Transition Diagrams) и т.д.

Нефункциональные требования: качественные аспекты ПО

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

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

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

• Производительность — пропускная способность, время отклика, использование ресурсов. 

• Безопасность — целостность, аутентификация, конфиденциальность, авторизация. 

• Масштабируемость — способность системы расти и развиваться вместе с заказчиком. 

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

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

• Совместимость — соответствие стандартам, взаимодействие со сторонними открытыми приложениями.  

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

Гибкая архитектура данных: как избежать краха проекта через два года

Например: 

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

• Дизайн пользовательского интерфейса должен быть выполнен в соответствии со стандартом WCAG 2.1.

• Система должна поддерживать горизонтальное масштабирование для обслуживания до 100 000 одновременных пользователей без деградации времени отклика более чем на 10%. 

• Покрытие модульными тестами компонентов ПО должно составить не менее 80%. 

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

Ключевые отличия типов требований в системном анализе

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

Фундаментальные различия между функциональными и нефункциональными требованиями:

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

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

• Зависимость — реализация одного требования невозможно без выполнения другого.

• Конфликт — выполнение одного требования делает невозможным реализацию другого. 

• Перекрытие — требования частично дублируют друг друга. 

• Уточнение — более узкие и конкретные требования детализируют более широкие.  

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

До разработки: зачем нужна концепция IT-решения

Что такое процесс разработки требований?

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

1. Выявление потребностей и ожиданий

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

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

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

3. Спецификация требований

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

4. Проверка и верификация 

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

5. Контроль и управление требованиями. 

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

Анализ процессов крупной производственной компании

Методики разработки требований к ПО

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

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

Различия между традиционным и гибким Agile подходом к разработке требований к ПО:

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

• Гибкая Agile методология: данный способ обеспечивает адаптивность требований за счет их постоянного обновления.

• Итеративная природа подхода позволяет командам в кратчайшие сроки подстраиваться под происходящие изменения. 

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

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

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

Рассмотрим наиболее часто встречающиеся ошибки и проблемы при работе с требованиями к ПО. 

1. Недостаточное вовлечение в процесс заинтересованных пользователей. 

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

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

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

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

3. Постоянное разрастание требований. 

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

4. Использование двусмысленных формулировок

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

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

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

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

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

Проведение аналитики под ключ для финтех-сервиса оплаты товаров и заказов по частям

Подводим итоги 

Таким образом, качественный сбор и анализ требований — это стратегический актив и инвестиции в успешное завершение проекта, которое обеспечивает будущему программному продукту весомые конкурентные преимущества. Фактически, именно требования становятся своеобразным мостом между техническими решениями и стратегическими целями. Эффективное управление ими позволяет на 20-30% сократить стоимость разработки, сводит к минимуму переделки и задает прочный фундамент для успешного продукта. Силы и время, потраченные на систематизированную и структурированную работу с требованиями на начальных этапах работы с проектом обеспечивают многократную отдачу на последующих этапах его жизненного цикла. Если возникли вопросы, обращайтесь по телефону 8-800-200-99-24 или пишите на request@simbirsoft.com.

FAQ: частые вопросы

1. Кто участвует в процессе сбора и документирования требований?

В идеале, в этом процессе должны участвовать: заказчик/владелец продукта —  представляют интересы бизнеса и конечных пользователей. Они знают, что нужно; бизнес-аналитик (BA) — он выявляет, анализирует, документирует и управляет требованиями; команда разработки — программисты, архитекторы; тестировщики (QA) — помогают убедиться, что требования сформулированы так, чтобы их можно было проверить; UX/UI-дизайнеры — приводят требования в соответствии с пользовательским интерфейсом.

2. Как документируют требования? 

Документирование требований — не менее важный этап, чем их сбор. От качества документации зависит, насколько легко и точно команда разработки сможет реализовать задуманное. Для решения поставленной задачи составляются: спецификация требований (SRS — Software Requirements Specification) — файл, содержащий все типы требований, их описание, различные полезные ссылки, критерии приемки и другую важную информацию; пользовательские истории (User Stories) — короткие и очень простые описания функциональности с точки зрения пользователя, обычно в формате «Как [тип пользователя], я хочу [действие], чтобы [цель]». Часто используются в Agile-методологиях; сценарии использования — отражают детальные описания взаимодействия пользователя с системой для достижения конкретной цели. Включают в себя основной сценарий, альтернативные пути и возможные ошибки. 

3. Что такое «плохие» требования и как их избежать?

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