Цитирую из книги Карла Вигерса "Рапзработка требований к ПО"

Цитата

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

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

Можно чуть-чуть не согласиться?

Цитата

Обязанность № 3. Точно и конкретно описать требования к системе

Зачастую клиент сам не знает, чего он хочет. Вот здесь аналитик обязан объяснить клиенту, что же он (клиент) хочет.
И ведь требования в виде ТЗ (не просто точно и конкретно, а исчерпывающе!) будет оформлять не клиент.

ida
А почему не здесь разместила?

Цитата

Зачастую клиент сам не знает, чего он хочет. Вот здесь аналитик обязан объяснить клиенту, что же он (клиент) хочет.

podval, а вот вся моя работа это и есть борьба за 8-й пункт!!!
Помимо прочего, разумеется. Ты не прав - клиент знает, чего он хочет, он просто не может объяснить это всем остальным. Задача аналитика понять, чего клиент хочет, и сделать так, чтобы его желания не испугали разработчиков.

В каждом продукте есть вещи, о которых разработчики даже не подозревают, и есть вещи, о которых совсем не обязательно знать клиенту. Но аналитик и руководитель проекта обязаны знать ВСЕ. Иначе ничего не получится. Такие вот они коварные...

Это сообщение отредактировал(а) ida - 18.2.2005, 17:37

Цитата(ida @ 18.2.2005, 17:32)

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

Понмю, мы угрохали год на промышленные эксперименты с попутными расчетами, чтобы математически получить то, что технологи давно использовали как эмпирически накопленный опыт, не имеющий до сих пор строгого доказательства.
И ведь они гады молчали, не давали нам свои цифры
Наверное, сами хотели, чтобы мы независимо пришли к тем же результатам.