Нефункциональные требования в черновиках Recovery Mode Перевод

Вступление к переводу

Мы все с вами ежедневно сталкиваемся с нефункциональными требованиями. Мы приходим в мебельный магазин, садимся на кресло и говорим «не удобно» или «это долго не проживет». Мы приходим выбирать автомобиль и не спрашиваем может ли машина разгоняться (функциональное требование), мы спрашиваем за сколько она может разогнаться до 100 км (нефункциональное требование)?

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

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

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

Перевод публикуется с разрешения 3SL

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

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

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

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

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

NFRs включают такие характеристики как:
— Эргономичность.
— Надежность.
— Ремонтопригодность.
— Доступность.
— Жизнеспособность (для военных систем).
— Гибкость.
— Адаптируемость.

Функциональные требования будут в центре внимания в начале проектирования и разработки. Существуют техники моделирования (нотации), такие как UML Use Case и Activity Diagrams, extended Function Flow Block Diagrams (eFFBDs) или Behaviour Diagrams которые предлагают методы отображения того, какие операции должны быть выполнены во времени и логику управления, которая будет определять ход выполнения.

Работа с нефункциональными требованиями может оказаться не столь простой. Сначала мы должны посмотреть на базовые типы NFRs:
— Окружение — требования, определяющие физическую среду (природную или созданную) в которой будет работать система. В некоторых случаях, это также может отражать политическую или экономическую обстановку, в которой выполняется работа или система будет функционировать.
— Физические — требования, определяющие форму продукта или системы. Например, указание размера, формы, окраски, веса или других аналогичных свойств продуктов или систем.
— Интерфейсные — требования, определяющие данные, структуру и физическую форму интерфейсов между компонентами (аппаратными средствами, программным обеспечением и людьми). Здесь также могут указываться требования по взаимодействию с существующими системами или использованию некоторых стандартных интерфейсов. Некоторые аналитики выделяют интерфейсные требования в отдельную группу, не включая их в NFR.
— Ограничения — требования, предписывающие условия или ограничения на то, как система может быть построена или как и в каком контексте должны применяться другие требования. Нетехнические аспекты, такие как сроки или бюджет могут также органичивать проекты по разработке.
— Факторы качества (эмерджетные свойства) — требования, которые касаются других качественных факторов продукта или процесса, так называемые «ильности», упомянутые выше.

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

Другие нефункциональные «ильности» включают тестируемость, переносимость/мобильность, эргономичность, масштабируемость, гибкость, поддерживаемость.

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

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

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

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

Ключевой деятельностью при реализации NFRs является определение физической архитектуры.
Архитектура системы разрабатывается посредством:
— Определения структуры продукта (то есть составных частей).
— Выделение требуемых характеристик конкретных компонентов (например, цвета, размера, веса и др.), т.е. определение нефункциональных требований к каждому компоненту.
— Определение интерфейсов между составными частями.



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

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

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