При разработке новой информационной системы (или при внедрении существующей) специалистам обязательно придется столкнуться в своей работе с необходимостью определения этого типа требований. Имеет смысл рассмотреть их подробно. Что такое нефункциональные требования, что это такое, как их определяют профессионалы.
Две категории требований
Есть много требований к характеристикам, качеству программных продуктов, информационных систем. Однако их можно разделить только на две широкие категории: функциональные и нефункциональные требования. Важно в начале статьи указать разницу между ними.
Нравится:
- Функциональные запросы. Точно опишите, что необходимо реализовать в конкретной системе или продукте, какие действия следует предпринять пользователям в отношении этой разработки.
- Нефункциональные требования. Они описывают, как именно работает созданная система или программный продукт, какими свойствами и характеристиками обладает конкретная разработка.
Шаг 1. Сформировали понятие функциональных и нефункциональных требований. Теперь перейдем ко второму пункту: рассмотрим, что именно можно отнести к последнему.
Что относится к категории?
Фактически, различные атрибуты качества продукции в основном относятся к нефункциональным требованиям. То есть требования, определяющие качественные характеристики разработки (ПО, информационной системы). Это, конечно, надежность, масштабируемость, производительность продукта.
Однако большое значение имеют также следующие нефункциональные требования:
- Предложения по реализации. В группу включены конкретные предложения, оценивающие возможность использования тех или иных архитектурных и технологических решений.
- Правовые требования. Лицензия на продукт, наличие патента и т.д.
- Предложения по верификации, тестирование разработанного программного обеспечения. Это серия дополнений к требованиям, в которых указано, как проверить конкретное требование на практике.
- Внешние интерфейсы. Описание ключевых аспектов взаимодействия продукта с другими системами и операционной средой. В первую очередь, это требования к API системы или продукта, а также требования к API других систем, с которыми планируется интеграция разрабатываемого продукта.
- Ограничения. То есть условия, ограничивающие выбор каких-либо решений по реализации отдельных требований (или набора требований). Они ограничивают разнообразие выбора инструментов, стратегий, инструментов при разработке как структуры (архитектуры), так и аспекта информации или программного продукта.
- Бизнес правила. Сюда входят руководящие принципы, политики, принципы и нормативные акты, которые так или иначе ограничивают определенные аспекты бизнеса. Например, они могут определить состав и правила реализации любых бизнес-проектов. Что можно отнести к этой категории? Корпоративная политика, всевозможные государственные постановления и распоряжения, отраслевые стандарты, алгоритмы расчета. При работе над проектом используются все правила, так или иначе влияющие на развитие системы, продукта.
важно отметить, что нефункциональные системные требования предопределены и фиксированы. Только после этого специалист может приступить к разработке продукта.
Примеры требований
Чтобы получить более четкое представление о нефункциональных требованиях информационной системы, давайте рассмотрим несколько примеров:
- Бизнес правила. «Когда продукт отгружен, менеджер должен запросить счет и накладные у бухгалтера компании». «Заказ будет считаться отмененным, если оплата счета не будет получена поставщиком в течение 14 дней».
- Внешние интерфейсы. «Убедитесь, что в журнале операционной системы разработки зарегистрированы следующие события: сообщение о запуске и остановке службы X». «Убедитесь, что в журнале разрабатываемой программы записаны параметры данных ее модулей: ядро, сканер, антивирусные базы. Информация должна фиксироваться как при запуске приложения, так и при обновлении его модулей».
- Ограничения. «Эта разработка выполняется только на платформе производителя X». «При аутентификации пользователя в информационной системе следует использовать только методы биометрической идентификации».
Как определять данные требования?
Мы рассмотрели конкретные примеры нефункциональных требований. А теперь еще один важный вопрос: «Как их определить применительно к конкретному товару?»
Первым шагом является создание шаблона, в котором перечислены основные типы нефункциональных требований к продукту. Прежде всего, это необходимо для того, чтобы не потерять ни одной позиции из этого списка.
Для составления таких моделей разработчики обычно выбирают следующие источники:
- ГОСТ 34-я серия.
- Книга «Разработка требований к программному обеспечению» (автор — К. Вигерс). В частности, стоит обратить внимание на раздел «Приложение D». Содержит конкретные примеры документации требований.
Теперь давайте посмотрим, кто именно выполняет эту работу.
Деятельность по определению требований к продукту
Функциональные и нефункциональные требования к системе разрабатываются конкретными рабочими группами. Их члены не только определяют, но и контролируют и утверждают эти предписания.
Что касается нефункциональной категории, для ее определения важно привлечь не только пользователей и аналитиков, но и ключевых разработчиков продуктов, системных архитекторов и группу тестировщиков. Почему это важно? Например, архитектор будет использовать нефункциональные требования в качестве входных данных для выбора и разработки архитектуры программы. И команда тестирования будет использовать их для планирования подходящих сценариев нагрузочного тестирования. Именно с помощью последнего будет проверяться соответствие нефункциональным требованиям. В общем, это атрибуты качества.
Роли участников рабочей группы
Теперь давайте посмотрим, какие роли назначены членам экспертной группы, которые определяют и утверждают нефункциональные требования к продукту:
- Системный аналитик. Этот участник собирает, анализирует, систематизирует и документирует нефункциональные требования.
- Тестовая группа. Также участвуйте в определении, анализе перечня нефункциональных требований к программе. Он также разрабатывает тестовые сценарии для этих рецептов.
- Ключевые разработчики и системные архитекторы. Какую роль играет эта группа? Они участвуют как в определении, так и в анализе нефункциональных требований и контролируют степень их выполнения.
- Пользователи. Эти участники оценивают значения тех параметров, которые определяют нефункциональные требования.
Сценарий для определения требований
Здесь мы приведем конкретный пример сценария, используемого для определения нефункциональных требований к производительности формы, предназначенной для уведомления пользователей Интернет-ресурса по электронной почте:
- Система получает сигнал о событии, которое запускает уведомление по электронной почте.
- Система отправляет сообщения пользователям из списка A с использованием шаблона B. Служба B используется для отправки сообщений.
- Если операция не может быть завершена, система пытается повторно отправить сообщения.
Формирование требований к продукту по сценарию
А теперь давайте более подробно остановимся на требованиях к сценарию, сформированному в предыдущем подзаголовке:
- Требования к времени отправки сообщений: уведомления должны быть отправлены системой не позднее, чем через X секунд после получения отчета о событии.
- Требования к повторной отправке уведомлений в случае неудачных попыток: количество повторных попыток должно быть равно X. Интервал — X минут с каждого случая неудачной отправки сообщения.
- Требования к времени уведомления о событии, инициирующем рассылку уведомлений: система должна получить сообщение о событии, инициирующем рассылку, не позднее, чем через X минут с момента его возникновения.
Важные критерии требований
Сами нефункциональные требования должны строго соответствовать ряду критериев качества их содержания:
- Правильность индивидуального требования для обеспечения согласованности системы.
- Проверяемость. Он должен обеспечивать однозначную проверку его выполнения.
- Осуществимость. Выполнение этого требования реально.
- Необходимость. Пользователям действительно необходимо реализовать это требование.
- Полнота (как отдельное требование, так и их полный список). Что это значит? Требование должно содержать всю информацию, необходимую для его выполнения.
- Уникальность. Требование не должно противоречить самому себе или другим пунктам в списке. Все профессионалы, которые с ним работают, должны понимать это одинаково.
Мы познакомились с таким понятием, как нефункциональные требования к программному продукту, информационной системе. Также они проанализировали свои конкретные примеры, отличие от функциональной категории, критерии качества категории. Вы знаете, какие команды экспертов создают и каким образом утверждают эти рецепты.