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

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

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

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

Итак:

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

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

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

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

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

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

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

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

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

• Ограничения. "Данная разработка ведется только на платформе вендора Х". "При аутентификации пользователя в информационной системе должны использоваться только биометрические методики идентификации".
• Бизнес-правила. "При отгрузке продукта менеджер обязан запросить у бухгалтера предприятия счет-фактуру и транспортно-товарные накладные". "Заказ будет считаться отмененным, если оплата по счету не поступила поставщику в течение 14-ти дней".
• Внешние интерфейсы. "Обеспечить запись в журнал разрабатываемой операционной системы таких событий: сообщение о старте и остановке сервиса Х". "Обеспечить запись в журнал разрабатываемой программы параметров данных ее модулей: ядра, сканера, антивирусной базы. Информация должна быть занесена в журнал как при запуске приложения, так и при обновлении его модулей".

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

Мы разобрали конкретные примеры нефункциональных требований. А теперь другой важный вопрос: : "Как их определять в отношении конкретного продукта?"

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

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

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

Давайте рассмотрим теперь, кто конкретно занимается этой работой.

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

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

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

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

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

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

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

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

1. Система получает сигнал о событии, инициирующем рассылку электронных уведомлений.
2. Система осуществляет рассылку сообщений пользователям из списка А, используя для этого шаблон Б. Для отправления посланий используется сервис В.
3. В случае невозможности завершения операции система предпринимает повторную попытку рассылки сообщений.

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

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

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

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

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

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

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