Почему трудно определять требования

К требованиям

От концепции

Определение

Как ее описать?

Описание архитектуры — это представление моделей системы, представления моделей

вариантов использования, анализа, проектирования, реализации и развертывания.

Описание архитектуры представляет те части системы, которые необходимо

понимать всем разработчикам и другим заинтересованным лицам.__

требований —

Поколение за поколением некоторые племена американских индейцев строили

каноэ из выдолбленных стволов деревьев. Строители каноэ начинали с поисков

дерева диаметром в несколько футов, лежащего неподалеку от воды. Около него

они разводили костер и клали горящие угли на бревно. Обугленную древесину было

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

После того как через несколько дней выдалбливания каноэ, казалось

бы, было полностью готово, строители выталкивали его на мелководье. Более чем

вероятно, что первый вариант каноэ просто переворачивался. Каноэ не было сбалансировано.

Следовало проделать еще много работы этими ужасными каменными

инструментами, пока у строителей не получалась лодка, которая не опрокидывалась,

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

она считалась законченной. Это умение передавалось из поколения в поколение

и врастало в кровь и плоть строителей.

Когда «племя» разработчиков программного обеспечения получает заказ на

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

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

немедленной и полной информации относительно того, как работает их «каноэ».

Во вторых, они не занимались непрерывным изготовлением таких продуктов

с раннего детства, и требования к системе и ограничения не вросли в их кровь

и плоть. Вместо этого они должны понять, что от них требуется.

Мы называем этот акт постижения определением требований. Это процесс выяснения,

что же должно быть создано. Этот процесс затруднителен. Фактически

это настолько трудно, что для разработчиков все еще является обычным делом

начать писать код (что довольно просто) раньше, чем они поймут, что этот код

должен делать (что значительно сложнее).

Профессиональные разработчики программного обеспечения обычно создают программы

не для себя, а для других людей — пользователей программного обеспече-

иия. «Так, — говорят разработчики, — пользователи должны знать, что им нужно».

Однако даже небольшой опыт получения требований от пользователей показывает,

что они — не идеальный источник информации. Прежде всего, у любой системы

обычно множество пользователей (или категорий пользователей), и в то время

как каждый пользователь знает свою работу, никто не может увидеть картину

в целом. Пользователи не знают, как работа в целом может быть сделана более

эффективной. Большинство пользователей не знает, какие аспекты их работы могут

быть переложены на программу. На самом деле пользователи часто не знают

даже, что такое требова1П1Я и как их точно изложить.

Традицио1И1ым подходом к этой проблеме было поручение выявления списка

требований каждого пользователя посредникам — аналитикам ~ в надежде на то,

что аналитик будет способен увидеть картину в целом и разработать полное, правильное

и непротиворечивое техническое задание. Аналитики обычно записывают

требования в документах размером в сотни, а иногда и тысячи страниц. Но абсурдно

полагать, что человеческий"! мозг может создать полный, верный и непротиворечивый

список из тысяч заявлен1и1 «система должна...». Что более важно, эти

спецификации требований невозможно быстро преобразовать в проектные и рабочие

спецификации.

Даже с помощью аналитиков пользователи не до конца понимали, что должна

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

пользователи, посредники и сами разработчики начинали видеть, на что

будет похожа система, и лучше понимать реальные потребности пользователей.

Поступало множество предложений об изменениях. Многие из них действительно

следовало бы сделать, но их выполнение обычно влекло за собой серьезное на-

рушери!е сроков и рост затрат.

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

и что все, что мы должны сделать, ~ это расспросить их. Действительно,

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

изучать взаимодействие пользователя с программой, глядя на то, что делают

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

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

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

которые ее используют. Часто трудно понять, каким должен быть этот результат,

а иногда невозможно создать систему, дающую такой результат. Более того, отражая

меняющийся реальный мир, ценность этого результата сама может изменяться

в ходе проекта: может измениться сам бизнес, могут изменяться технологии,

при помощи которых формируется система, могут изменяться ресурсы (люди, деньги),

при помощи которых формируется система и т. п.

Даже после этого озарения определение требований остается нелегким делом.

В промышленности происходили длительные поиски хорошего, систематического

процесса определения требований. Рассмотрением такого процесса мы и займемся

в этой и следующей главах.