Организация информации требованиях

Основные положения

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

• В зависимости от типа приложения необходимо применять различные методы организации требований.

• В сложных системах создаются спецификации требований для каждой подсистемы.

Требования необходимо записывать и документировать. Если вы в одиночку разрабатываете систему, в которой будете единственным пользователем и ответственным за сопровождение, можно попытаться приступить к ее проектированию и кодированию непосредственно после выявления своих потребностей. Однако разработка систем редко 6ывает столь простой. Как правило, разработчики не являются пользователями, а в процесс разработки вовлечены заинтересованные лица. пользователи, разработчики, аналитики, специалисты по архитектуре и другие члены команды. Все участники должны прийти к соглашению о том, какая система должна быть создана.

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

Такой документ называется спецификацией требований. Спецификация требовааний к системе (или приложению) описывает ее внешнее поведение.

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

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

• Система может быть очень сложной.

• Потребности заказчиков могут быть документированы до того, как производится документирование подробных требований.

• Система может быть членом семейства родственных продуктов.

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

• Цели маркетинга и бизнеса следует отделить от подробных требований к продукту.

В любой из этих ситуаций приходится вести множество документов. Рассмотрим не сколько специальных случаев.

• Некий "родительский" документ определяет требования ко всей системе в целом: к аппаратному и программному обеспечению, персоналу и процедурам; а другой документ — только к программному обеспечению. Первый документ называется спецификацией требований к системе (system requirement specification), а второй — спецификацией требований к программному обеспечению (software requirement specification).

• Один документ содержит общие определения функций системы, а другой — более конкретные. Первый документ часто называется документом-концепцией (Vision document), а второй— спецификацией требований к программному обеспечению (software requirement specification).

• Один документ содержит полный набор требований к семейству продуктов, а в другом представлены требования к конкретному приложению и конкретной версии. Первый из них именуется документом требовании к семейству продуктов (product family requirements), или концепцией семейства продуктов (product family Vision document), а второй— спецификацией требований к программному обеспечению (software requirement specification) определенной реализации некоего конкретного приложения из семейства продуктов.

• Один документ описывает общие бизнес - требования и бизнес-окружение, в котором будет существовать система, а другой определяет ее внешнее поведение. Первый называется документом бизнес -требований (business requirements document), или документом требований маркетинга (marketing requirements document), а второй - спецификацией требований к программному обеспечению (software requirement specification).

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