Права
Право № 1. Иметь дело с аналитиком, который разговаривает на вашем языке
При обсуждении требований следует выяснить потребности и задачи вашего бизнеса, используя при этом принятую в вашем бизнесе терминологию.
Заставьте аналитиков говорить с вами на вашем языке (возможно, для этого
им следует предоставить небольшой словарь). При разговоре с аналитиками
не надо переходить на технический жаргон.
Право № 2. Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для которых создается система
Выявляя требования, аналитики смогут лучше понять задачи вашего бизнеса
и осознать, какое место уготовано создаваемому ПО в вашем бизнесе. Это
поможет им удовлетворить ваши ожидания. Пригласите разработчиков и
аналитиков посмотреть на вашу работу. Если заказанная система заменит существующее приложение, предложите аналитикам поработать с ним. Таким образом, им будет легче понять его сильные и слабые стороны и то, как его можно усовершенствовать. Не надо предполагать, что аналитик уже знает все ваши бизнес-операции и терминологию (см. Обязанность №1).
Право № 3. Потребовать, чтобы аналитик зафиксировал требования в надлежащей форме
Аналитик разберется со всей информацией, предоставленной заинтересованными лицами, и задаст дополнительные вопросы, чтобы пользовательские требования на основе бизнес-требований, бизнес-правил, функциональных требований, целей качества и прочих элементов. Конечный итог этого анализа — выверенный набор требований, хранящийся в одной из надлежащих форм, например спецификация требований к программному обеспечению (SRS) или средство управления требованиями. Этот набор требований является соглашением заинтересованных лиц относительно функций, качеств и ограничений продукта, который планируется построить. Требования должны быть написаны и организованы так, чтобы их было легко понимать. Ваша проверка этих спецификаций и других представлений требований, например моделей визуального анализа, помогает обеспечить точное представление ваших потребностей.
Право № 4. Получить подробный отчет о будущих процедурах и результатах процесса формулирования требований
Различные процедуры могут сделать процесс формулирования и управления
требованиями эффективным и продуктивным, а знание требований может
представляться в самых разных формах. Аналитик должен объяснить рекомендуемые процедуры, а также определить какую информацию будет содержать каждый полученный в результате документ. Например, для иллюстрации текста аналитик может создать ряд диаграмм. Эти диаграммы могут показаться непривычными или сложными, но они просты. Аналитик должен объяснить назначение каждой из них, смысл обозначений и процедуру проверки диаграмм на предмет ошибок. Если он не предоставляет таких объяснений, попросите его представить их.
Право № 5. Изменить свои требования
Со стороны аналитиков или разработчиков не реалистично ожидать, что вы
сразу сможете предоставить все требования или что эти требования останутся неизменными на протяжении всего цикла разработки. У вас есть право вносить изменения в требования по мере развития бизнеса, в процессе получения членами команды больше информации от заинтересованных лиц или когда вы лучше обдумаете, что на самом деле вам нужно. Тем не менее, у изменений всегда есть цена. Иногда при добавлении новой функции приходится приносить в жертву другие функции или вносить коррективы в график или бюджет проекта. Важная часть ответственности аналитика заключается в оценке, управлении или изменении последствий подобных действий. Совместно с аналитиком выработайте простой, но эффективный процесс работы с изменениями в своем проекте.
Право № 6. На взаимное уважение
Отношения между клиентами и разработчиками могут становиться конфликтными. Если клиенты и разработчики не понимают друг друга, обсуждение требований может обернуться большим разочарованием. Совместная работа позволяет открыть друг другу глаза на проблемы, с которыми сталкивается каждая из этих групп. Клиенты, участвующие в процессе выработки требований, имеют полное право требовать от аналитиков и разработчиков уважительного отношения к себе и бережного отношения к затраченному времени. В свою очередь, и клиентам следует оказывать уважение разработчикам, ведь они все вместе сотрудничают для достижения общей цели —успешного проекта. Все находятся по одну сторону баррикад.
Право № 7. Знать о вариантах и альтернативах требований и их решении
Чтобы гарантировать, что новая система не будет автоматизировать неэффективные или устаревшие процессы, аналитик должен знать, почему существующие системы не годятся для ваших бизнес-процессов. Аналитики часто предлагают те или иные усовершенствования ваших бизнес-процессов. Полезен и аналитик, творчески подходящий к делу: он предлагает
Право № 8. Описать характеристики, упрощающие работу с продуктом
Вполне вероятно, что аналитики спросят вас о характеристиках ПО, выходящих за рамки функциональных потребностей пользователей. Благодаря им программный продукт становится более удобным в работе, что позволяет клиентам эффективнее выполнять свои задачи. Иногда пользователи просят, чтобы продукт был дружественным или надежным, однако эти термины слишком субъективны, чтобы помочь разработчикам. Поэтому аналитик должен выяснить конкретные характеристики, означающие для вас дружественность или надежность. Расскажите аналитику о том, какие стороны ваших текущих приложений кажутся вам «дружественными», а какие нет. Если вы не обсудите эти характеристики с аналитиком, вам должно сильно повезти, чтобы продукт получился именно таким, как вы надеялись.
Право № 9. Узнать о способах корректировки требований для ускорения разработки за счет повторного использования
Отношение к требованиям должны быть гибкими. Аналитику могут быть
известны готовые программные компоненты или требования, которые практически полностью удовлетворят некоторые названные вами потребности. В таком случае аналитику следует предложить скорректировать ваши требования, чтобы разработчики могли использовать имеющееся ПО. Разумные возможности применения существующих модулей сэкономит ваши время и деньги. Если вы посчитаете разумным включить в свой продукт готовые коммерческие компоненты, будьте готовы проявить гибкость, поскольку характеристики таких компонентов вряд ли будут точно соответствовать вашим потребностям.
Право № 10. Получить систему, функциональность и качество которой соответствует вашим ожиданиям
Это самое главное право клиента, но оно осуществимо, только если вы сумеете донести до разработчиков всю информацию, которая поможет им создать подходящий продукт, если разработчики четко изложат вам все варианты и ограничения и если все участники достигнут соглашения. Убедитесь, что вы высказали все свои ожидания и предположения; в противном случае программисты, скорее всего, не смогут реализовать их. Иногда клиенты не формулируют определенные вещи, считая их общеизвестными фактами. Однако проверка правильности понимания всеми членами команды так же важна, как выражение чего-то нового.
Источник: Разработка требований к ПО. Карл Вигерс и Джой Битти