Классификация требований

Требования к ПО состоят из трех уровней – бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на Рис. 1‑1 иллюстрирует способ представления этих типов требований. Как и все модели, она не полная, но схематично показывает организацию требований. Овалы обозначают исходные типы информации для требований, а прямоугольники – средства консолидации и хранения результирующей информации.

Рис. 1‑1. Взаимосвязи разных типов информации для требований   По существу каждое требование пользователя должно быть сопоставлено бизнес-требованию. На основе требований пользователя аналитики определяют функции, которые позволят пользователям выполнять их задачи. Разработчикам же необходимы функциональные и нефункциональные требования, чтобы создавать решения с желаемой функциональностью, определенным качеством и требуемыми рабочими характеристиками, не выходя за рамки налагаемых ограничений. Хотя в модели на Рис. 1‑1 показан поток требований в направлении сверху вниз, следует ожидать и циклов, и итераций между бизнес-требованиями, требованиями пользователей и функциональными требованиями. 1.2.1. Бизнес-требования Бизнес-требования содержат высокоуровневые задачи и цели организации-разработчика или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей или отдел маркетинга. Эти требования объясняют, почему организации нужна такая система, или, иначе говоря, описывают цели, которые организация намерена достичь с ее помощью. Бизнес-требования записываются в соответствующем разделе Спецификации требований к ПО, хотя могут записываться и в форме документа об образе (концепции) и границах проекта, который еще иногда называют уставом проекта или документом рыночных требований.

Бизнес-правила

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