Требования и их виды
Смысл требования
Заголовок раздела «Смысл требования»Первое, с чего начнём — попробуем дать определение понятию требования. Определение в разных источниках разное, поэтому дадим вольный перевод определения из SWEBOK.
Требования нужны не для того, чтобы “собрать пожелания”. Они задают основание для проектирования: что система должна делать, какие свойства иметь, в каких условиях работать и какие правила учитывать. Если требования сформулированы плохо, все последующие решения становятся догадками.
Функциональные и нефункциональные требования
Заголовок раздела «Функциональные и нефункциональные требования»Сами требования часто делятся на две категории, функциональные и нефункциональные.
Например: “система должна позволять студенту выбрать свободный интервал консультации” или “система должна отправлять уведомление преподавателю после создания записи”.
Например: “список свободных интервалов должен открываться не дольше двух секунд при 200 одновременных пользователях”. Функция здесь та же — просмотр интервалов, но требование говорит о качестве её выполнения.
Связанные виды утверждений
Заголовок раздела «Связанные виды утверждений»Кроме требований полезно выделить ещё несколько понятий, которые тесно с ними переплетены, но являются самостоятельными.
Ограничения задают рамки решения. Они могут быть техническими, организационными, правовыми или ресурсными: использовать корпоративную систему авторизации, хранить данные только на серверах организации, поддерживать определённые браузеры, уложиться в заданный срок. Ограничение не всегда описывает поведение системы, но влияет на архитектуру.
Пользовательская потребность обычно формулируется с точки зрения человека: “студенту нужно быстро найти подходящее время консультации”. Системная возможность переводит потребность в способность системы: “система показывает свободные интервалы и позволяет фильтровать их по преподавателю и дате”. Из одной потребности может появиться несколько требований.
Бизнес-правило описывает норму предметной области: “студент не может иметь две активные записи на одно и то же время”, “заявка после утверждения не редактируется исполнителем”, “оплаченный заказ нельзя отменить после передачи в доставку”. Правило может быть реализовано в программе, но существует не потому, что так устроен код, а потому что так устроена предметная область.
Разложение формулировок
Заголовок раздела «Разложение формулировок»Одну фразу часто приходится раскладывать на несколько типов утверждений:
| Исходная формулировка | Что в ней смешано |
|---|---|
| “Сделать удобную и безопасную запись на консультации” | потребность, функциональность, безопасность, UX |
| “Студент должен быстро записываться” | потребность, производительность, сценарий записи |
| “Система должна работать через университетский аккаунт” | функциональность входа и ограничение на способ авторизации |
| “Преподаватель не должен получать лишние заявки” | потребность, бизнес-правило, уведомления |
После разложения формулировка становится проектируемой:
- студент должен видеть список свободных интервалов консультации;
- студент должен создавать запись на выбранный свободный интервал;
- система должна запрещать создание двух активных записей на одно и то же время;
- система должна использовать университетскую систему единого входа;
- уведомление о новой записи должно отправляться преподавателю не позднее одной минуты после создания записи.
Такое разделение важно для дальнейших материалов. Функциональные требования обычно переходят в пользовательские цели и варианты использования. Нефункциональные требования влияют на архитектуру и развёртывание. Бизнес-правила проявляются в сценариях, процессах, состояниях и ограничениях модели. Ограничения задают границы допустимых решений.
Если требование трудно отнести к одному типу, это сигнал к уточнению. Например, “система должна безопасно хранить заявки” можно разложить на функциональную часть “хранить заявки”, нефункциональную часть “обеспечивать защиту данных”, ограничение “использовать корпоративный контур хранения” и бизнес-правило “доступ к заявке имеют только участники обработки”.
Функциональные требования станут входом для пользовательских целей и возможностей, а затем — для спецификации варианта использования и диаграммы использования. Нефункциональные требования и ограничения будут проверяться при выборе программной архитектуры и развёртывания.