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