Слайды к докладу на Analyst Days

1. Нефункциональные
требования
Наталья Желнова
ЛАФ, Иваново, 2016

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

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

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

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

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

7. Примеры ограничений
• «Разработка должна вестись на платформе
вендора X»
• «При аутентификации пользователя
должны использоваться биометрические
методы идентификации»

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

9. Примеры бизнес-правил
• «При отгрузке заказа менеджер должен
запросить у бухгалтера товарно-
транспортную накладную и счет-фактуру»
• «Если оплата по счету не поступила в
течение 15 дней, заказ считается
отменённым»

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

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

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

13. Предложения по тестированию
Дополнения к требованиям, указывающие,
каким образом то или иное требование
должно быть протестировано

14. Юридические требования
Требования к лицензированию, патентной
чистоте, etc.

15. Определение нефункциональных
требований
• Использование шаблонов, в которых нужно
перечислить основные виды
нефункциональных требований
– Книга К. Вигерса «Разработка требований к
программному обеспечению»
– Модели качества ПО
– Материалы ГОСТ 34 серии
• Разработка сценариев, определяющих
нефункциональные требования

16. Пример сценария, определяющего
НФТ
Сценарий используется для определения
требований к производительности модуля
системы, рассылающего уведомления
пользователям сайта по электронной почте

17. Пример сценария, определяющего
НФТ
1. Система получает оповещение о событии,
инициирующем рассылку уведомлений.
2. Система осуществляет рассылку
оповещений по адресам из списка рассылки
X, используя шаблон Y. Для рассылки
сообщений используется сервис Z.
3. В случае невозможности завершения
рассылки, система предпринимает
повторные попытки рассылки.

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

19. Критерии качественных
нефункциональных требований
• Полнота (отдельного требования и системы
требований)
• Однозначность
• Корректность отдельного требования и
согласованность (непротиворечивость)
системы требований
• Необходимость
• Осуществимость
• Проверяемость

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

21. Однозначность требований
Однозначность — требование должно быть
внутренне непротиворечиво и все работающие с ним
должны понимать его одинаково. Требования следует
выражать просто, кратко и точно, используя известные
термины.
Обычно базовые знания читателей спецификации
требований к ПО различаются. Поэтому в ее состав
нужно включить раздел с определением понятий
прикладной области, используемых при определении
требований. Пример, неоднозначного требования.
«Период обновления экрана должен быть не менее 20
сек.»

22. Корректность требований
Корректность отдельного требования и
согласованность (непротиворечивость)
системы требований — требование не
должно содержать в себе неверной, неточной
информации, а отдельные требования в
системе требований не должны
противоречить друг другу.

23. Необходимость требований
Необходимость — требование должно
отражать возможность или характеристику
ПО, действительно необходимую
пользователям, или вытекающую из других
требований.

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

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