Преграды на пути выявления требований

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

Задача выявления требований

Выявление требований осложняется тремя эндемическими синдромами

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

Поиск требований сродни археологическим раскопкам (поиск "ненайденных руин"); чем больше вы находите, тем больше вы знаете о том, что еще осталось ненайденным.

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

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

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

Синдром "да, но • • •"

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

1 Иногда для их обозначения мы будем использовать понятие пользователь в обобщенном смысле. Методы применяются для выявления требований всех заинтересованных лиц.

· “О, это действительно здорово, мы можем реально использовать это, классная работа, молодцы мальчики, ” и т.д.

· "Да, но, как насчет...? Нельзя ли было бы...? А что будет, если...?"

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

Реакция пользователей является следствием человеческой природы. Подобную реакцию можно часто наблюдать и при других повседневных обстоятельствах. Пользователи никогда ранее не видели новую систему или что-либо подобное; они не понимают, что вы подразумеваете, когда описываете ее. И вот теперь она перед ними — впервые после стольких месяцев (или лет) ожидания они имеют возможность взаимодействовать с системой. И оказывается, что это не совсем то, чего они ожидали!

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

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

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

• Синдром "да, но..." является следствием человеческой природы и неотъемлемой частью разработки любого приложения.

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

Синдром "неоткрытых руин"

Один из наших друзей однажды был экскурсоводом на автобусном маршруте в районе Four Corners, области, определенной общими границами штатов Колорадо, Нью- Мексико, Юта и Аризона. Экскурсия проходила по живописным вершинам горной цепи Ла-Плата, античным руинам Анасази в Меса-Верде и окрестностям. Вопросы туристов являются постоянным источником развлечения для экскурсоводов и создают определенный фольклор туристического бизнеса. У нашего друга самым любимым "дурацким" вопросом был "А сколько здесь неоткрытых руин?".

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

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

Синдром "пользователя и разработчика"

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

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

Иногда мы должны учиться более эффективно общаться с этими '"пользователями из другого мира". В своей статье Лора Шерер (Laura Scharer, 1981) описывает эту проблему и предлагает некие рекомендации по ее смягчению. В табл. 7.1 представлены некоторые аспекты данной проблемы и предлагаемые решения.

Таблица 7.1. Синдром "пользователь и разработчик"

Проблема Решение
Пользователи не знают, чего хотят, а если и знают, то не могут это выразить Признавать пользователя экспертом в предметной области и ценить его в этом качестве; пытаться использовать альтернативные методы общения н выявления требований
Пользователи думают, что они знают, чего хотят. до тех пор, пока разработчики не предоставят им то, что они якобы хотели Как можно раньше предлагать альтернативные методы выявления: раскадровку, ролевые игры. прототипы и т.п.
Аналитики думают, что они понимают проблемы пользователя лучше его самого Поставить аналитика на место пользователя. Провести ролевую игру в течение часа или всего дня
Все считают, что другие руководствуются политическими мотивами Такова человеческая натура, поэтому пусть все остается как есть

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


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: