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

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

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

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

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

— Система отправляет запрос на утверждение после того, как пользователь вводит личную информацию;

— Функция поиска позволяет пользователю искать среди различных счетов-фактур, если он хочет зачислить выставленный счет;

— Система отправляет электронное письмо с подтверждением при создании новой учетной записи пользователя.

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

— Страницы веб-сайта должны загружаться за 3 секунды при общем количестве одновременных пользователей <5 тысяч;

— Система должна быть способна обслуживать 20 миллионов пользователей без снижения производительности.

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

— Идентификация;
— Уровни авторизации;
— Соответствие законам или нормативным актам;
— Внешние интерфейсы;
— Обработка транзакций;
— Отчет;
— Бизнес-правила и т. д.

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

— Документ спецификации требований к программному обеспечению;
— Варианты использования;
— Истории пользователей;
— Структура разбивки работы (WBS), или функциональная декомпозиция;
— Прототипы;
— Модели и диаграммы.

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

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

— Эффективность использования;
— Интуитивность;
— Низкая воспринимаемая рабочая нагрузка.

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

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

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

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

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