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