Вигерс Карл. Разработка требований к программному обеспечению

Подождите немного. Документ загружается.

Что теперь?

I Сравните схему на рис. 6-1 с тем способом, посредством которого вы узнаете

мнение

клиентов.

Возникают ли у вас проблемы с распространением информа-

ции? Определите кратчайшие и наиболее подходящие пути распространения ин-

формации, которые пригодятся для сбора требований в будущем.

Определите для своего проекта

различные

классы пользователей. Какие них

привилегированные, а какие (если таковые имеются) - нет? Кто бы мог стать хо-

рошим сторонником продукта для каждого из важных классов пользователей?

Используя

табл. 6-2 в качестве отправной точки, определите обязанности сто-

ронника продукта. Обсудите конкретные пункты с каждым предполагаемым сто-

ронником продукта и его менеджером.

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

ниями к проекту. Насколько эффективен процесс принятия решений, используе-

мый в настоящее время? Где он дает сбой? Правильно ли выбраны лица, прини-

мающие

решения? Если нет, кто должен принимать решения? Предложите ли-

цам, принимающим решения, последовательность действий для достижения

согласия по вопросам требований.

Глава 6. Как отобрать пользователей для работы над проектом

113

Как услышать голос клиента

«Доброе

утро,

Мария. Я — Фил, аналитик требований к новой

информационной системе для сотрудников, которую мы соби-

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

стать сторонником продукта этого проекта. Ваша информация

нам очень пригодится. А теперь расскажите

мне,

что же вам

все - таки нужно

?»

«Гм,

что же мне нужно, — размышляет Мария. — Не представ-

ляю, с чего и начать. Ну, новая система должна работать на-

много быстрее предыдущей.

Потом,

вы же знаете, как старая

система зависает, если имя какого-либо сотрудника оказыва-

ется слишком длинным — нам приходится обращаться в служ-

бу поддержки, чтобы они ввели имя. В новой системе длинные

имена должны обрабатываться без сбоев. Да, согласно

ново-

му закону, нам нельзя использовать номера социального

страхования в качестве идентификаторов сотрудников, и с

вводом новой системы в эксплуатацию нам придется заме-

нить все эти данные. Новые идентификаторы предполагается

сделать шестизначными числами. Также пригодилась бы

функция отчета о времени, затраченном каждым сотрудников

в текущем году на обучение. А еще мне хотелось бы

получить

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

ное положение осталось прежним».

Фил добросовестно записал все пожелания Мария, но его го-

лова пошла кругом. Он не знал, что делать с этой информаци-

ей, и не имел ни малейшего представления, что же передать

разработчикам. «Ну что ж, — подумал он, — если Мария хочет,

чтобы мы это сделали,

полагаю,

нам

придется

это сделать».

114

Часть II. Разработка требований к ПО

Сердце процесса формулирования требований - - их выявление

felicitation),

когда потребности и ограничения высказывают лица, заин-

тересованные в проекте. Цель —

обозначить

требования

пользо-

вателей,

которые занимают средний уровень в трехступенчатой моде-

ли требований к ПО

(подробнее

об этом в главе

два других уровня —

бизнес-требования

и функциональные требования). Это

задачи,

кото-

рые пользователям необходимо выполнять средствами

системы,

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

простоте работы с системой и других атрибутах качества системы.

этой главе обсуждаются общие принципы эффективного выявления

требований.

Аналитику необходима структура для систематизации массива ин-

формации, полученной в процессе выявления требований. Просто за-

давая пользователям вопрос: «Чего вы

хотите?»,

вы получите массу не-

упорядоченной информации, в которой легко утонуть. Вопрос: «Чтс

вам требуется

делать?»

— гораздо лучше. В главе 8

рассказывается

как с помощью таких приемов, как варианты использования

продукте

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

для

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

Результат этапа формулирования требований --

согласованное:

представление о потребностях всех заинтересованных в проекте лиц

Теперь разработчикам гораздо легче предлагать альтернативные

спо-

собы удовлетворения этих потребностей. Те, кто занимается

выявле-

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

немедленно

приступить к проектированию системы — до того момента, как

про

блема станет абсолютно ясной. В противном случае готовьтесь к

зна

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

Концентрация на задачах пользователей, а не на интерфейсе, внима

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

не отвлекаться на детали архитектуры — сейчас это несколько

преж

девременно.

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

проекту. Даже простой план повышает шансы на успех и делает более

реалистичными ожидания всех заинтересованных лиц. Только четко

сформулировав потребности, касающиеся ресурсов, графика и

вы

пуска, можно избежать того, что лиц, участвующих в выявлении

требо

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

рабо

ты. План должен отражать:

I цели выявления требований

(например,

проверка рыночных дан-

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

робного набора функциональных требований к системе);

Глава 7. Как услышать голос клиента

115

3-4776

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

опросов, семинаров, встреч с клиентами, интервью и других прие-

мов с возможным использованием различных подходов для разных

групп заинтересованных лиц);

результаты

выявления

требований (например, перечень вариантов

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

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

спе-

цификация атрибутов качества и производительности);

график и смету ресурсов (определите, кто из разработчиков и

кли-

ентов будет участвовать в различных операциях по выявлению тре-

бований; примерно оцените усилия и время на выявление требова-

ний};

риски, связанные с выявлением требований (укажите факторы, ко-

торые могут нарушить график работ по выявлению требований,

оцените опасность каждого фактора и решите, как смягчить его или

управлять им).

Выявление требований

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

женный ошибкам и требующий интенсивного общения этап разработ-

ки ПО. Как вы уже знаете из главы 2, эта процедура может оказаться

успешной только при условии сотрудничества клиентов и

разработчи-

ков. Аналитик должен создать атмосферу, благоприятную для тща-

тельного исследования обусловленного продукта. Чтобы облегчить

общение, используйте лексику предметной области, а не

прессингуй-

те клиентов компьютерным жаргоном. Не полагайтесь на то, что все

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

- создайте словарь. Однако объясните клиентам, что обсуждение

возможной функциональности — это еще не обязательство включить

ее в продукт. Этот этап обособлен от анализа приоритетов, осущест-

вимости и

ограничений,

налагаемых реальностью. Заинтересованным

в проекте лицам необходимо расставить приоритеты в списке «голу-

бых

грез»,

чтобы проект не стал рыхлым и бесполезным.

Мастерство управления дискуссией по выявлению требований при-

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

учатся брать интервью, общаться в группах, разрешать конфликтные

ситуации и т.д. Как аналитику, вам придется «нырнуть» в поток требо-

ваний клиента и, «опустившись поглубже», разобраться в его истинных

потребностях. Просто задав несколько раз вопрос типа

«Почему?»,

вы

116

Часть II. Разработка требований к ПО

сможете перейти от обсуждения уже существующего решения к

выяв

лению проблемы. Вопросы, допускающие несколько вариантов

отвв'

та, помогут вам разобраться в бизнес-процессах и понять, как

новая

система повысит их эффективность. Поинтересуйтесь, какие задачи

собираются выполнять пользователи и

как

они будут работать с

систе-

мой. Вообразите, что вы обучаетесь служебным обязанностям

пользо-

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

Ка

кие задачи вам придется решить? Какие вопросы у вас

возникают"'

Другой подход — влезть в «шкуру» новичка, которого обучает

опытный

пользователь. Вы задаете массу вопросов, а он управляет

беседой,

выбирая важную, с его/ее точки зрения,

тему

для обсуждения.

Попробуйте метод исключений. Что мешает пользователю успешно

выполнить задачу? Как система должна реагировать на

различные;

ошибочные условия? Задавайте вопросы, начинающиеся со слов: «Л

что еще могло

бы...»,

«Что произойдет,

когда...»,

«Вам когда-нибудь

требовались...»,

«Где вы

получаете...»,

«Почему вы делаете (или не де-

лаете}...»

и «А кто-нибудь

когда-либо...».

Задокументируйте

источник

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

проследить, на каких же потребностях клиентов основываются те

или

иные направления разработки.

Когда вы разрабатываете следующую версию системы,

попросите

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

сейчас

больше всего. Этот вопрос поможет вам

понять,

почему же систему

следует менять. При этом также становится ясно, чего же ждут пользо-

ватели от новой системы. Как и при любой модификации, неудовле-

творение настоящим дает отличную пищу для принятия нового.

Попытайтесь вытащить на «свет

божий»

все предположения клиен-

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

те возможности или характеристики, которые клиенты полагают

само

собой разумеющимися и даже не считают нужным обрисовать. Gause и

Weinberg (1989) предлагают использовать бесконтекстные вопросы

(context-free

questions),

узкоспециализированные

вопросы и вопросы,

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

нес-проблемах и их возможных решениях. Реакция клиентов на

такие

вопросы, как «Какой уровень точности необходим в продукте?» или

«Почему вы не согласны с ответом

Мигеля?»,

иногда более действен-

ны, чем вопросы с ответами типа «да/нет» или

«А/В/С».

В процессе сбора информации работающий творчески аналитик не

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

вые идеи и предлагает альтернативы. Иногда пользователи не пред-

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

Глава 7. Как услышать голос клиента 117

страшно обрадуются, если вы предложите функциональность, которая

сделает систему особенно удобной. В тех случаях, когда пользователи

не способны ясно

выразить

свои потребности, аналитику стоит пона-

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

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

за рамки, ограничивающие мышление людей слишком тесно связан-

ных с конкретной предметной областью. Ищите удобные случаи

по-

вторно использовать функциональность, которая уже реализована в

другой системе,

Интервью с отдельными потенциальными пользователями или с

группами — традиционный источник информации при сборе требова-

ний, касающихся как коммерческих продуктов, так и информационных

систем. [О проведении интервью с пользователями см. Beyer и Holtzb-

latt

(1998), Wood и

Silver

(1995), а также

McGraw

и Harbison

(1997).]

Во-

влечение пользователей в процесс сбора информации — это способ

получить

поддержку

в том числе и финансовую, проекта. Попытайтесь

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

этапно рассмотрите работу пользователей и постарайтесь понять ее

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

ские пути принятия решений. Убедитесь, что все понимают, почему

система должна выполнять конкретные функции. Иногда предложен-

ные требования отражают устаревшие или неэффективные бизнес-

процессы, которые не следует встраивать в новую систему,

После каждого интервью документируйте элементы, обсуждавшие-

ся группой, и попросите интервьюируемых просмотреть список и вне-

сти исправления. Просмотр на ранних

стадиях.необходим

для успеш-

ного сбора

требований,

поскольку только те люди, которые эти требо-

вания

предоставили,

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

В дальнейшем также не отказывайтесь от обсуждений — это позволит

разрешить все противоречия и заполнить пробелы.

Польза семинаров

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

щающие сбор информации о требованиях. Это позволяет весьма эф-

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

(Keil

Carmel,

1995). Основная задача ответственного за мероприятие

сотрудника — создать условия для успешного выполнения задачи;

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

обсуждение проводилось продуктивно. Если вы собираетесь приме-

118

Часть II. Разработка требований к ПО

нять новые технологии сбора требований, ответственным за первый

семинар следует назначить стороннего сотрудника — не из вашей

ко-

манды. В этом случае аналитик сможет полностью сосредоточиться

нп

обсуждении. Пригласите также секретаря, чтобы он фиксировал

вес;

идеи, возникающие в ходе обсуждения.

Согласно одному из

источников,

"Организация

какого-либо

меро-

приятия — искусство управления людьми в ходе этого

мероприятия,

которое позволяет достичь согласованных решений в

атмосфер*.:

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

заинтересованно-

сти в результатах своей работы» (Sibbet, 1994). О семинарах,

упро-

щающих сбор требований, подробно рассказано в труде Ellen

Gottesdi-

ener

(2002)

«Requirements by

Collaboration»

(Выявление требований

•;;

помощью сотрудничества). Gottesdiener описывает спектр приемов 1

средств для облегчения семинаров. Вот некоторые из них.

Определите основные правила. Участники должны договориться об

основных правилах проведения семинаров (Gottesdiener, 2002). На-

пример, таких:

i своевременно начинать и заканчивать семинар;

I не опаздывать после перерывов;

не проводить несколько обсуждений одновременно;

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

комментировать и критиковать решение, а не личность.

Придерживайтесь границ проекта. Чтобы удостовериться, что

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

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

проек-

та.

Следите, чтоб на каждом семинаре уровень обобщения соответст-

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

обсуждения несущественных деталей. На это уходит масса времени,

которое на начальном этапе работы следует потратить на

прояснение

пользовательских требований — время деталей наступит позже. Зада-

ча организатора — по мере необходимости возвращать участников к

теме

обсуждения,

Ловушка Избегайте преждевременного углубления в детали. Фиксируя мель-

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

щиеся

из-за размытости требований,

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

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

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

Глава 7. Как услышать голос клиента

119

данные детали в требования, то в некоторой степени ограничите про-

цесс разработки. К разработке пользовательского интерфейса следует

приступать

позднее,

хотя предварительные наброски интерфейса по-

лезны на любом этапе при иллюстрации

возможных

способов

реализа-

ции требований. Проверка осуществимости на ранних стадиях,

требую-

щая определенной разработки, значительно снижает риски.

Фиксируйте темы для дальнейшего обсуждения. На семинаре

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

бизнес-правила, идеи по разработке пользовательского интерфейса,

ограничения и т.п. Запишите их на плакатах простейшим

способом, — так вы не потеряете их и продемонстрируете уважение

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

не относящихся к теме дискуссии, если только они не окажутся важны-

ми, например бизнес-правилом, которое ограничивает варианты ис-

пользования.

Ограничивайте некоторые дискуссии по времени. Организатор

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

скажем, первоначально — 30 минут на каждый вариант использова-

ния. Возможно, некоторые дискуссии придется завершить позднее, но

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

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

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

Не увеличивайте размер команды и тщательно отбирайте участ-

ников. Небольшие группы работают намного быстрее. Семинары, чис-

ло активных участников которых превышает пять или шесть человек,

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

Попробуйте одновременного проводить несколько семинаров — это

позволит

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

В обсуждении должны участвовать сторонник продукта и другие пред-

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

ласти, аналитик требований и разработчик. Допуском к участию в се-

минарах по сбору информации являются знания, опыт и право прини-

мать решения.

Ловушка Не допускайте в процессе сбора информации обсуждения посторон-

них тем, например подробностей дизайна.

Вовлекайте в обсуждение каждого. Иногда участники самоустраня-

ются от обсуждения, например, расстроившись из-за того, что не

представляют себе ценность системы. Возможно, их идеи не воспри-

120

Часть II. Разработка требований к ПО

нимают

серьезно, поскольку

другим

участникам их концепции кажутся

неинтересными или группа не хочет отвлекаться от текущей

дискус

сии. Возможно, аутсайдер не уверен в себе и уступил право голоса бо

лее активным сотрудникам или главному аналитику. Организатору

се

минара

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

разо

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

попытаться снова вовлечь его в работу. Ведь интуитивное

представле

ние каждого может оказаться очень ценным.

У семи нянек...

Работа семинаров по сбору информации о требованиях большим количеством уча-

стников может продвигаться слишком медленно. Так, моя коллега Дебби, занимав-

шаяся организацией

семинара,

где разбирались варианты использования Web-про-

дукта, была расстроена именно этим. Двенадцать участников длинно обсуждали

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

сократила группу до шести человек, в число которых вошли аналитик,

клиент,

сис-

темный архитектор, разработчик и дизайнер. Объем обсуждаемой информации стал

меньше,

но темпы работы более чем компенсировали эту потерю. Участникам семи-

нара следует по его окончании обменяться информацией с коллегами, не пригла-

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

Не следует ожидать, что ваши клиенты представят краткий, полный и хорошо орга-

низованный список своих потребностей. Аналитикам придется классифицировать

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

вать и использовать соответствующим образом. На рис. 7-1 показано девять таких

категорий требований.

Некоторая информация не попадает ни в одну из этих категорий, в

том

числе:

требования,

не относящиеся к разработке ПО, например необходи-

мость обучения пользователей работе с новой системой;

I ограничения проекта, например затраты или ограничения, налагае-

мые графиком (в отличие от ограничений, касающихся дизайна или

реализации);

R предположения;

1 требования, касающиеся данных, которые зачастую связаны с оп-

ределенной функциональностью системы (вы сохраняете данные на

компьютере только для того, чтобы позднее извлечь их);

дополнительная информация хронологического или

описательно!

характера, а также относящаяся к управлению контекстом.

Глава?.

Как услышать голос клиента

121

Бизнес-требования

Идеи,

Варианты использования

касающиеся решений или сценарии

Определения

___—у

Бизнес-правила

данных

Ограничения

Функциональные

требования

Требования к интерфейсу Атрибуты качества

Рис.

7-1.

Классификация требований клиента

Далее в этом разделе я привожу некоторые типичные для дискус-

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

данных.

Бизнес-требования.

Вся информация, описывающая финансовые,

рыночные или другие отношения коммерческого характера, которые

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

продукта, относится к

бизнес-требованиям.

Обращайте внимание в

разговоре на такие высказывания о преимуществах, которые покупа-

тели или пользователи ПО хотят получить:

1 «Увеличить рыночную долю

наХ%»;

I «Сэкономить Y$ в год за счет сокращения использования электро-

энергии, которая сейчас расходуется неэффективно»;

i «Сэкономить Z$ за счет

сокращения

расходов на поддержание ус-

таревшей

системы

W».

Варианты использования или сценарии. Основные утверждения

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

(ком-

мерческих задачах) называются вариантами использования; единст-

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

тайте с пользователями, чтобы свести сценарии в более общие вари-

анты использования.

Часто

удается выявить варианты использования,

попросив клиентов описать их рабочий процесс. Другой способ — вы-

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

122 Часть II. Разработка требований к ПО