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

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

История и развитие понятия

Понятие функциональных требований возникло в контексте системного анализа и проектирования, которые активно развивались с середины XX века. В 1950–1960-х годах, с появлением первых компьютеров и программного обеспечения, возникла необходимость формализовать, что именно должна делать вычислительная машина. Первые методы описания требований были неформальными и основывались на интуиции разработчиков. В 1970-х годах, с развитием структурного программирования и методологий, таких как SADT (Structured Analysis and Design Technique), функциональные требования стали выделять в отдельную категорию. В 1980-х годах, с появлением объектно-ориентированного подхода (например, методология UML), функциональные требования стали описывать через диаграммы вариантов использования и сценарии. В 1990-х годах, с развитием гибких методологий (Agile), функциональные требования стали формулировать в виде пользовательских историй (user stories) и критериев приёмки. В XXI веке, с распространением DevOps, микросервисной архитектуры и облачных технологий, функциональные требования стали более динамичными, часто изменяемыми и тесно связанными с непрерывной интеграцией и тестированием.

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

Функциональные требования можно классифицировать по нескольким основаниям.

По уровню детализации

• Бизнес-требования — описывают цели и задачи, которые система должна решать с точки зрения бизнеса (например, «система должна автоматически выставлять счета клиентам»).
• Пользовательские требования — описывают, что пользователь может делать с системой (например, «пользователь может войти в систему, используя логин и пароль»).
• Системные требования — описывают конкретные функции, которые система реализует на уровне программного или аппаратного обеспечения (например, «система должна проверять корректность введённого пароля»).

По источнику возникновения

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

По типу функциональности

• Транзакционные — связаны с обработкой данных (ввод, хранение, изменение, удаление, поиск).
• Вычислительные — выполняют расчёты, преобразования, анализ данных.
• Управляющие — управляют потоками данных, состоянием системы, доступом.
• Коммуникационные — обеспечивают взаимодействие с другими системами, пользователями, устройствами.

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

Качественные функциональные требования должны обладать следующими характеристиками:

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

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

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

• Интервью — опрос заинтересованных сторон (пользователей, заказчиков, экспертов).
• Анкетирование — сбор структурированных ответов от большого числа респондентов.
• Наблюдение — изучение текущих процессов и поведения пользователей.
• Анализ документов — изучение существующей документации, регламентов, стандартов.
• Мозговой штурм — коллективное обсуждение и генерация идей.
• Прототипирование — создание ранних версий системы для уточнения требований.
• Варианты использования (use cases) — описание последовательности действий пользователя и системы для достижения конкретной цели.

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

• Спецификация требований к программному обеспечению (SRS) — стандартный документ, описывающий все функциональные и нефункциональные требования.
• Пользовательские истории (user stories) — короткие описания функций от лица пользователя (например, «Как менеджер, я хочу просматривать отчёт по продажам, чтобы анализировать эффективность»).
• Диаграммы вариантов использования — визуальное представление взаимодействия пользователей с системой.
• Сценарии — детализированные описания последовательности действий, включая альтернативные и исключительные пути.
• Таблицы решений — матрицы, описывающие логику обработки данных в зависимости от условий.

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

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

Для интернет-магазина

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

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

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

Для банковской системы

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

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

Функциональные требования используются на всех этапах жизненного цикла разработки системы:

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

Критика и ограничения

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

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

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

Интересные факты

• Первая формальная спецификация функциональных требований была создана в 1960-х годах для проекта SAGE (Semi-Automatic Ground Environment) — системы ПВО США.
• В стандарте ISO/IEC 25010:2011 функциональные требования отнесены к категории «функциональная пригодность» (functional suitability), которая включает функциональную полноту, корректность и целесообразность.
• В России требования к функциональным требованиям регулируются ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

Источники

• ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».
• ISO/IEC 25010:2011 «Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models».
• IEEE Std 830-1998 «IEEE Recommended Practice for Software Requirements Specifications».
• Вигерс, К. «Разработка требований к программному обеспечению». — М.: Русская редакция, 2004.
• Леффингуэлл, Д., Уидриг, Д. «Принципы работы с требованиями к программному обеспечению». — М.: Вильямс, 2002.