Больше внимания требованиям, а не проектированию

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

• Разработка требований предшествует проектированию,

• Пользователи и заказчики принимают решения относительно требований,

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

Это удачная модель, от которой можно отталкиваться при решении задач управления требованиями. Дэвис (Devis, 1993) назвал ее парадигмой "что вместо как", где "что" — это требования ("что" система должна делать), а "как" представляет собой проектное решение, которое следует реализовать для достижения этой цели.

Для такого представления есть причины. Действительно, лучше понять требования перед тем, как приступать к проектированию, а большинство ограничений (“использовать XYZ-библиотеку классов для доступа к базе данных”) являются важными проектными решениями, записанными в активы требований с тем, чтобы мы знали, что они получены по условиям контракта или по достаточно веским техническим причинам.

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

Однако существует пока невидимая, но достаточно серьезная проблема, которая противоречит представленной нами простой парадигме. Вернемся к нашему рабочему при меру. Если команда принимает проектное решение использовать ПК-технологию для подсистемы "Центральный блок управления" (ЦБУ) системы HOLIS, это, вероятно, окажет некое внешнее воздействие на пользователя (он будет видеть подсказку или экран - приглашение). Если мы захотим воспользоваться некоторыми возможностями ОС, то соответствующие библиотеки классов будут, конечно же, демонстрировать внешнее поведение пользователю. (Заметим, что его можно скрыть, но это не нужно.)

Если воспользоваться предложенным в данной главе определением, возникает вопрос: если проектное решение воздействует на внешнее поведение, заметное пользователю, становится ли такое решение (явно воздействующее на ввод или вывод системы) требованием. Ответ ("да", "нет" или "не имеет значения") будет зависеть от вашей интерпретации определения и проведенного нами анализа. Но это проливает свет на очень важный аспект, так как его понимание жизненно необходимо для уяснения природы итеративного процесса в целом. Давайте рассмотрим его более подробно.