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