Определение структуры

из "Разработка и управление требованиями "

Наличие хорошо организованной структуры играет исключительно важную роль в обеспечении управления и координации работ на всем протяжении жизненного цикла проекта. Сбор пользовательских требований обычно является итеративным процессом -требования одно за другим фиксируются, уточняются, очищаются и затем помещаются в общую структуру. [c.115]
Такие подходы не имеют ничего общего с качеством разработок, а являются всего лишь отражением временных интересов разработчиков. [c.115]
Мы утверждаем, что требования обязательно должны быть организованы и должна обязательно существовать хорошая структура для управления каждым индивидуальным требованием по мере его появления и внесения в эту структуру. Что характерно, аргументы в пользу необходимости структурирования уже описаны в Главе 4, поскольку являются теми же, на которые уже обращалось внимание при обсуждении проблем работы с требованиями, как в области проблем, так и в области решений. Лишний раз подчеркивая особую важность построения хорошей, понятной структуры, эта глава большее внимание уделяет именно тому, как получить такую структуру для пользовательских требований. [c.115]
Основной концепцией построения структуры требований является сценарий использования. Однако для сложных систем может существовать достаточно большое количество сценариев использования. В таком случае рекомендуется все-таки потратить время и усилия на то, чтобы попытаться соединить все имеющиеся сценарии в один всеобъемлющий, если такое возможно. Конечно же, это не всегда может удаться, но попробовать в любом случае стоит. Помимо достижения своей прямой цели этот процесс даст многим возможность задуматься о системе, как о некоем целом, представить ее общий функционал, и, возможно, выявить очень много проблем. [c.115]
Чтобы проиллюстрировать каким образом сценарии могут иногда объединяться, приведем пример из области ресторанного бизнеса. Для описания ресторана могут быть использованы три следующих сценария, которые отображены на рис. 5.6 - 5.8. [c.115]
Первый сценарий описывает жизнь ресторана - вначале ресторан приобретается владельцем, затем следует период владения рестораном и, в заключении, наступает момент его продажи. [c.116]
Второй сценарий описывает все состояния, в которых ресторан находиться в течение рабочего дня. [c.116]
Первой целью (состоянием) является пополнение запасов продуктов и напитков. В данном случае подразумевается, что у ресторана несколько поставщиков, но порядок доставки продуктов и напитков не имеет значения. Конечно, можно поспорить на тему, что пополнение запасов обязательно должно заканчиваться до момента открытия ресторана, но в нашем примере мы упростили себе жизнь, чтобы сделать пример более наглядным, и будем считать, что вся доставка осуществляется до момента открытия ресторана. В сценарии рабочего дня ресторана затем идут периоды, когда ресторан бывает открыт для посетителей и когда ресторан закрыт - завершен рабочий день, производится уборка и составляется список для пополнения запасов на следующий день. [c.116]
Сценарий посещения ресторана клиентом представляет собой просто последовательность состояний. [c.116]
На рис. 5.9 показана общая структура, объединяющая все три сценария. [c.117]
Этот объединенный сценарий может теперь рассматриваться как структура заголовков (структура разделов) для документа, содержащего требования. [c.117]
Конечно же, не всегда есть возможность объединить все сценарии в один. Тут не существует универсального подхода, который мог бы всегда срабатывать. Если объединение не удается, то нужно просто рассматривать один сценарий за другим. И тогда структура документа с требованиями будет повторять последовательность сценариев, в каждый из которых встроены свои собственные требования. [c.117]
По сути, структура в большой степени формируется в зависимости от списка заинтересованных сторон, участвующих в проекте. И хотя многие сценарии использования могут иметь различные ключевые цели (состояния), все равно следует предпринимать попытки включения сценариев один в другой. [c.117]

Вернуться к основной статье