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

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

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

кто работает с ПО теперь, понимают, что на самом деле необходимо,

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

от-

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

новой системой. Недавние пользователи могут запутаться в текущих

особенностях работы, да так, что не увидят возможности усовершен'

ствовать

бизнес-процессы посредством новой информационной

сие

темы. Еще одна опасность: бывший пользователь может запросто

ду

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

интер

фейса. Концентрация внимания на вариантах решения с самого

начала создает ненужные ограничения архитектуры и зачастую не

по

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

От специалиста по медицинской технике к аналитику требований

У старшего менеджера отдела медицинских устройств в большой компании возник-

ла проблема. «Два года назад я принял на работу в свой отдел трех специалистов по

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

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

медицинских технологий и

поэтому

не могут точно сказать, что же сегодня нужно

клиентам. Какую работу мы можем предложить этим специалистам теперь?»

Бывшие специалисты по медицинскому оборудованию, работающие под началом

этого менеджера могут стать кандидатами в аналитики требований. И хотя они не

знают о новинках медицинской техники, они смогут общаться на одном языке с дру-

гими специалистами в этой области. За два года они усвоили принципы работы от-

дела.

Возможно,

им потребуется пройти обучение способам документации требова-

ний, тем не менее они накопили ценный опыт, который позволит им эффективно вы-

полнять работу аналитиков.

Бывший разработчик

Менеджеры проекта, которым не хватает профессионального

знали

тика требований, зачастую ожидают, что его функции будет

выполнять,

разработчик. К сожалению, навыки и личные качества, необходимые!

разработчику, отличаются от тех, что необходимы аналитику. Шаблон

ный

«компьютерщик»

— не самый социально приятный из людей.

Мале

кто из разработчиков терпелив с

пользователями,

считая их необходи

мым

злом, с которым нужно разобраться как можно

быстрее,

чтобы

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

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

требова-

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

Глава 4. Аналитик требований 71

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

для специализации в области анализа требований.

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

дробно ознакомиться с предметной областью бизнеса. Однако разра-

ботчики легко переходят на техническое мышление и жаргон, концен-

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

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

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

владеют лучшие аналитики — умение эффективно слушать, вести пе-

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

Профильный специалист

Ralph Young

(2001)

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

пертом в предметной области или профильным специалистом, а не

обычным пользователем: «Спецификация требований к ПО может оп-

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

как

они расширяют суще-

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

тектуру и какое влияние они окажут на пользователей». Некоторые ор-

ганизации-разработчики

ПО нанимают опытных пользователей их

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

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

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

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

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

классов пользователей. Иногда профильные специалисты увлекаются

созданием универсальной,

всеобъемлющей

системы, когда на самом

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

сложное решение. Зачастую лучше, чтобы аналитик требований из ко-

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

стом, который кроме того выбран в качестве ключевого

представителя

пользователей (сторонника

продукта).

Подробнее о роли сторонников

продукта в разработке пректа — в главе 6.

Создание атмосферы тесного сотрудничества

Иногда в проектах по разработке ПО возникают напряженные отноше-

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

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

мотивации других участников и не ценят потребности и ограничения

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

72 Часть I. Требования к продукту: что, почему и кто

граммного

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

инфор

мационных

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

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

успеха

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

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

Аналитик

требований — основное лицо, отвечающее за обеспечение тесного

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

и прочими сторонами, заинтересованными в проекте.

Эффективный

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

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

рует коллегам свое уважение. Аналитик добивается от участников про

екта согласования требований, в результате чего выигрывают все:

клиенты довольны продуктом;

1 организация-разработчик получает прибыль;

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

екта.

Что теперь?

I Если вы - аналитик требований, сравните свои

знания

и навыки с описанными в

Этой главе. Если

вы

выявили какие-либо пробелы, выберите две темы и прора-

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

рованные курсы.

I Выберите

из

этой книги один

новый

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

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

вальном смысле! Выберите два или три дополнительных способа и начните ис-

пользовать их

через

месяц. Другие оставьте на потом, чтобы изучить и приме-

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

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

вам, а также какая помощь или дополнительная информация может потребовать-

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

новые способы. Выявите препятствия, которые могут помешать применять кон-

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

Глава 4. Аналитик требований 73

Определение образа

и границ проекта

Когда моя коллега Карен ввела в компании, где она работала, практику

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

многие проблемы, которые выявили проверяющие, касались объема

проекта. Часто у экспертов было разное представление о предпола-

гаемых границах и целях проекта. В результате им трудно было дого-

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

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

Как мы уже видели в главе

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

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

границы системы ПО. Пользовательские и функциональные требова-

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

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

Требования,

не содействую-

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

Проект, в котором нет четко определенного и согласованного на-

правления, можно смело

назвать

кандидатом на провал. Участники

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

ные задачи, если у

них

у них разные бизнес-цели и приоритеты.

Лица,

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

ве

требований,

если они не выработали общего понимания

бизнес-це-

лей. Четкое представление образа и границ проекта особенно важно

при разработке сложного, распределенного ПО, когда географическое

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

щающее коллективную работу.

Признаком того, что бизнес-требования недостаточно ясно опреде-

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

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

Проблемы, касающиеся образа и границ, необходимо разрешать до

спецификации детализированных функциональных требований. Поло-

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

жение о рамках и ограничениях проекта необычайно

полезно

при

обсу-

ждении предлагаемых функций и целевых выпусков. Кроме того, на

него можно ссылаться при принятии решений о изменении и расшире-

нии требований. В некоторых компаниях основные положения об об-

разе и границах помещают на схему, которую приносят на каждое про-

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

предложенное изменение за рамки проекта.

Определение образа продукта

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

Образ продукта (product vision) выстраивает работу всех заинтересо-

ванных лиц в одном направлении. Он

описывает,

что продукт

пред-

ставляет собой сейчас и каким он станет впоследствии. Границы про-

екта (project scope) показывают, к какой области конечного

долгосро

ного образа продукта будет направлен текущий проект. В положении о

границах определена черта между тем, что входит в проект и тем, что

остается вовне. То есть указанные рамки также определяют

ограниче-

ния проекта. Более детально эти сведения изложены в базовой версии

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

Говоря об образе, мы подразумеваем весь продукт. Он будет

изме-

няться относительно медленно при определении со временем

страте-

гии продукта или развитии бизнес-целей. Границы же относятся к оп-

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

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

5-1.

Границы бо-

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

жимое каждой версии в соответствии с графиком, бюджетом, ресурса-

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

управлении границами определенного проекта (разрабатываемого или

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

страте-

гического образа. Положение об объеме для каждого проекта или ках-

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

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

доку-

мент об образе и границах. Для крупных новых проектов необходимо

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

специ-

фикацию требований. О шаблоне спецификации требований

рассказа-

но в главе

10.

Например, федеральное правительственное агентство получило дол-

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

Глаеа

5. Определение образа и границ проекта 77

информационной системы. Команда определила бизнес-цели и образ

системы еще на начальной стадии и за несколько следующих лет никак

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

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

ем его собственных границ. Последние должны были соответствовать

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

других проектов — это позволяло гарантировать, что ничего не будет

пропущено.

Нереальные требования

Менеджер компании, специализирующейся на разработке ПО, сильно переживаю-

щая из-за почти катастрофического расползания

границ

проекта, с сожалением ска-

зала мне; «Мы создали слишком нереальные требования*. Она имела в виду, что

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

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

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

ленно поздней) версии. Наконец, после четырех лет разработки, черезмерно

пере-

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

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

раньше.

Версия

1.0

оговоренного

объема

Версия

1.1

оговоренного объема

Рис.

5-1.

Образ продукта содержит запланированные версии оговоренного

объема

Конфликтующие бизнес-требования

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

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

товать. Представьте себе компьютер со встроенным ПО, подсоеди-

ненный к Интернету и предназначенный для покупателей магазина

(киоск). При его разработке следует удовлетворить следующие биз-

нес-цели:

1 получение дохода путем сдачи в аренду или продажи киоска про-

давцу;

I продажу потребительских товаров покупателям;

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

привлечение внимания покупателей к торговой марке;

1 предоставление широкого ассортимента товаров.

Бизнес-интересы розничного продавца таковы:

I максимальное увеличение дохода с доступного пространства;

I привлечение большего количества покупателей в магазин;

i увеличение объема продаж и уровня прибыли, если киоск

замени-'

операции, выполняемые вручную.

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

увлекательным для покупателей. Продавцу же нужна простая и

полно

стью готовая к эксплуатации система, а для покупателя важны

удобст

во и функциональные возможности. Напряженность между этими

тре-

мя сторонами с их различными целями, ограничениями и бюджетом

может привести к несогласованности бизнес-требований. Тот, кто

фи-

нансирует проект, должен разрешить эти конфликты до того, как

ана-

литик детализирует системные требования и требования к ПО киоска

Основное внимание следует уделять фундаментальным задачам,

суля-

щим наибольшую коммерческую выгоду

(«увеличатся

продажи,

буду!

привлечены новые

покупатели»)-

При этом можно легко отвлечься

не

внешние характеристики продукта

{«инновационный

пользователь-

ский интерфейс, привлекающий клиентов»), которые не отражают

ре-

альные бизнес-цели.

Кроме того, тот (или те), кто финансирует проект, проекта

должеь

разрешать конфликты различных заинтересованных в проекте лиц —

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

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

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

ется риск увеличения обьема проекта. Неконтролируемый рост объе-

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

удовлетворить

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

ственным весом, так и не дав каких-либо ценных результатов. Разре-

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

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

этой книге.

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

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

определяют и набор бизнес-задач

(вариантов

ис-

пользования), которые позволяет выполнять приложение

(ширина

приложения],

и глубину

уровня,

до которого реализуется каждый вари-

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

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

проекта,

Глава 5. Определение образа и границ проекта 79

4—2437

значит, что вы принимаете решение о ширине проекта. Глубина про-

стирается от простой реализации до полной автоматизации с множе-

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

позволяяют

по-

нять,

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

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

реализации, по крайней мере на первое время.

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

использования и связанные с ними функциональные требования. На-

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

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

щих за продажу большего количества продуктов или предоставляю-

щих услуги покупателям. Экзотичные, эффектные функции,

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

ентов и не способствующие выполнению основной бизнес-задачи, не

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

Бизнес-требования также существенно влияют на способ реализа-

ции требований. Например, одна из причин создания Chemical Track-

ing System — уменьшить закупку новых бутылей с химикатами, исполь-

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

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

момент это не делается. В свою очередь, на основе этой информации

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

облегчают отслеживание химикатов в каждой лаборатории и помогают

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

ближе,

Документ об образе и границах проекта

Документ об образе и границах

{vision

and scope document) собирает

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

документ,

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

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

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

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

{mar-

ket requirements document,

MRD).

В нем более детально, чем в доку-

менте об образе и границах, рассматриваются целевые сегменты рын-

ка и проблемы, касающиеся коммерческого успеха продукта.

Владельцем документа об образе и границах считается

тот,

кто фи-

нансирует проект или несет аналогичную ответственность. Аналитик

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

об образе и границах проекта. Информация, касающаяся бизнес-тре-

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