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