Типы требований к системе и их качество

Понятно, что перед тем, как начать проектировать, необходимо понять, что нужно проектировать. Тут появляется понятие требования. С требованиями вы уже сталкиваетесь, когда пытаетесь сообразить, что должна уметь делать рассматриваемая система и для кого это делается.

Требования и их типы

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

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

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

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

Источники требований и их связь с требованиями

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

Пользовательская потребность описывает проблему или цель пользователя на его языке. Она может породить несколько требований.

Системная возможность описывает, что система должна уметь делать, чтобы закрыть потребность.

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

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

Проще проследить на примере, как эти источники формируют требования.

Представим, что мы проектируем службу курьерской доставки.

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

Ещё одно функциональное требование: система должна оповестить внешние системы об изменении статуса заказа. Вполне логичное ограничение в связке с этим функциональным требованием: оповещать внешние системы нужно через существующие API.

Качество требований

Для грамотного моделирования требования должны быть достаточно качественными. Минимальный набор критериев качества таков:

атомарность: одно требование описывает одну возможность или одно ограничение;
проверяемость: можно понять, выполнено требование или нет;
непротиворечивость: требование не конфликтует с другими требованиями и бизнес-правилами;
полнота: требование содержит достаточно контекста для проектирования;
реализуемость: требование не противоречит известным ограничениям;
трассируемость: понятно, из какого источника оно появилось и какими артефактами покрывается.

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

Управление требованиями — отдельное искусство, поэтому оно вынесено в свою дисциплину, которая будет в следующем семестре.