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

• А что такое «требования»?
• Функциональные
• Нефункциональные
• SRS
• Use Case диаграмма
• Пользовательские истории
• Таблицы для ленивых
• Примеры и советы

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

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

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

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

• Портативность (переносимость между системами/платформами/типами девайсов)
• Безопасность
• Легкость обслуживания в дальнейшем, «ремонтопригодность» продукта
• Надежность и устойчивость
• Масштабируемость/расширяемость
• Производительность/продуктивность
• Реюзабельность/возможность применять в других условиях/окружениях
• Гибкость/настраиваемость
  

А что такое «требования»?

Согласно известному Своду знаний по бизнес-анализу (BABOK), требование — это представление потребности. Таким образом, в контексте разработки программного обеспечения мы рассматриваем слово «требования» как набор требований, которые должен выполнять программный продукт. 

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

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

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

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

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

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

Существует несколько категорий функциональных требований. Среди них уместно выделить следующие:

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

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

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

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

Определение нефункциональных требований не является обязательной задачей. Мы можем разрабатывать продукт, руководствуясь только набором функциональных требований. Однако, при этом продукт будет работать по модели best-effort, например не соответствуя ожиданиям по параметрам производительности или презентабельности. 

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

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

Наконец, мы создаем дополнительные нефункциональные требования по требованию (on-demand). 

Стратегии спецификации требований и документ SRS

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

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

Документ SRS должен состоять как минимум из трех разделов:

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

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

Диаграммы вариантов использования

Диаграмма вариантов (примеров) использования предназначена для определения взаимодействия программного решения с его операторами (пользователями) и администраторами. На этих диаграммах мы имеем три основные сущности: 

• Актор: представление операторов и администраторов программного решения
• Система: характеристика функциональных требований как ожидаемого поведения программного решения 
• Цель: описание целей агента, взаимодействующего с системой 

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

Пользовательские истории

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

История пользователя состоит из обычного текста, но обычно в них учитывается форматирование, представленное следующим образом: 

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

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

Функциональные и Нефункциональные

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

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

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

В таблицах сопоставлены некоторые важные характеристики функциональных и нефункциональных требований:

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

Примеры и советы

Сбор правильных и полных требований — один из самых важных моментов в разработке. Неправильные и неполные требования могут быть причиной провала проекта.
Если вы задаетесь вопросом, почему на создание прототипа уходит 2 недели, а на разработку реального приложения — 3-4 месяца, вспомните о нефункциональных требованиях. Когда кто-то говорит, что нужно создать приложение, он имеет в виду, что это приложение должно делать, и это функциональные требования. Например, давать возможность торговать на определенном рынке товаров или услуг; но он не говорит вам о безопасности, производительности, нагрузке и других вещах; это то, что называется нефункциональными требованиями.
Очевидное различие между функциональными и нефункциональными требованиями заключается в том, что функциональные задаются пользователями и бизнес-аналитиками и являются частью списка возможностей программного обеспечения.
Например, функциональное требование типичного приложения — получить заказ, обработать его и отправить данные на площадку; но нефункциональные требования не создаются пользователем, его создают архитектор программного обеспечения, эксперты предметной области, техлид и сотрудники службы поддержки.
Например, для этого приложения нефункциональными требованиями могут быть: отказоустойчивость и восстановление, ведение логов, аудит, показатели задержек и другие характеристики производительности: приложение должно работать непрерывно, обрабатывать не менее 5 тысяч заказов в секунду и т.д. Специалисты службы поддержки также могут задать требования по добавлению пользователей, предоставлению доступа, отзыву доступа, мониторингу и т. д.
Каждое приложение при разработке программного обеспечения имеет тот или иной вид нефункциональных требований.

1. Функциональные требования задаются пользователем, в то время как нефункциональные требования задаются техническими специалистами, такими как архитектор, техлид и разработчики.
2. Функциональные требования — это действия, которые должна выполнять система; с другой стороны, нефункциональные зависят от критичности приложения. Например, если приложение не критично и можно смириться с его простоем какое-то время, команде не потребуется разрабатывать сложный код восстановления после сбоев и аварий, что сократит общее время разработки.
3. Функциональные требования определяют функциональность программного обеспечения, то есть то, что оно может делать, в то время как нефункциональные требования определяют другие вещи, которые не нужны пользователю в любой момент времени, но требуются поставщику услуг или самому приложению; например, ведение журнала — нефункциональное требование для поддержки приложения, которое не используется непосредственно пользователем, но необходимо для устранения неполадок в продакшен-окружении.
4. Нефункциональные требования иногда определяются в терминах метрик (то, что можно измерить в системе), чтобы сделать их более наглядными.
5. Нефункциональные требования могут также описывать аспекты системы, которые относятся не к ее исполнению, а скорее к ее развитию во времени (например, сопровождаемость, расширяемость, документирование и т. д.).
   

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

Baeldung, JavaRevisited, DZone