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

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

Две категории требований

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

Нравится:

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

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

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

Что относится к категории?

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

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

  • Предложения по реализации. В группу включены конкретные предложения, оценивающие возможность использования тех или иных архитектурных и технологических решений.
  • Правовые требования. Лицензия на продукт, наличие патента и т.д.
  • Предложения по верификации, тестирование разработанного программного обеспечения. Это серия дополнений к требованиям, в которых указано, как проверить конкретное требование на практике.
  • Внешние интерфейсы. Описание ключевых аспектов взаимодействия продукта с другими системами и операционной средой. В первую очередь, это требования к API системы или продукта, а также требования к API других систем, с которыми планируется интеграция разрабатываемого продукта.
  • Ограничения. То есть условия, ограничивающие выбор каких-либо решений по реализации отдельных требований (или набора требований). Они ограничивают разнообразие выбора инструментов, стратегий, инструментов при разработке как структуры (архитектуры), так и аспекта информации или программного продукта.
  • Бизнес правила. Сюда входят руководящие принципы, политики, принципы и нормативные акты, которые так или иначе ограничивают определенные аспекты бизнеса. Например, они могут определить состав и правила реализации любых бизнес-проектов. Что можно отнести к этой категории? Корпоративная политика, всевозможные государственные постановления и распоряжения, отраслевые стандарты, алгоритмы расчета. При работе над проектом используются все правила, так или иначе влияющие на развитие системы, продукта.

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

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

Примеры требований

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

  • Бизнес правила. «Когда продукт отгружен, менеджер должен запросить счет и накладные у бухгалтера компании». «Заказ будет считаться отмененным, если оплата счета не будет получена поставщиком в течение 14 дней».
  • Внешние интерфейсы. «Убедитесь, что в журнале операционной системы разработки зарегистрированы следующие события: сообщение о запуске и остановке службы X». «Убедитесь, что в журнале разрабатываемой программы записаны параметры данных ее модулей: ядро, сканер, антивирусные базы. Информация должна фиксироваться как при запуске приложения, так и при обновлении его модулей».
  • Ограничения. «Эта разработка выполняется только на платформе производителя X». «При аутентификации пользователя в информационной системе следует использовать только методы биометрической идентификации».

Как определять данные требования?

Мы рассмотрели конкретные примеры нефункциональных требований. А теперь еще один важный вопрос: «Как их определить применительно к конкретному товару?»

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

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

  • ГОСТ 34-я серия.
  • Книга «Разработка требований к программному обеспечению» (автор — К. Вигерс). В частности, стоит обратить внимание на раздел «Приложение D». Содержит конкретные примеры документации требований.

Теперь давайте посмотрим, кто именно выполняет эту работу.

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

Деятельность по определению требований к продукту

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

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

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

Роли участников рабочей группы

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

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

Сценарий для определения требований

Здесь мы приведем конкретный пример сценария, используемого для определения нефункциональных требований к производительности формы, предназначенной для уведомления пользователей Интернет-ресурса по электронной почте:

  1. Система получает сигнал о событии, которое запускает уведомление по электронной почте.
  2. Система отправляет сообщения пользователям из списка A с использованием шаблона B. Служба B используется для отправки сообщений.
  3. Если операция не может быть завершена, система пытается повторно отправить сообщения.

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

Формирование требований к продукту по сценарию

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

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

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

Важные критерии требований

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

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

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

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