Сбор требований

из "Разработка и управление требованиями "

Интервью это очень непростая задача. Для того чтобы суметь вытянуть из представителей заинтересованных сторон реальные требования, специалист, проводящий интервью, должен, в первую очередь, быть коммуникабельным и уметь правильно общаться. Интервью это исключительно психологическая задача, не имеющая ничего общего с организационными или техническими аспектами разработки систем. Необходимо помнить, что получение пользовательских требований от заинтересованных сторон это человеческая, а не техническая проблема. Однако несмотря на это, специалист, проводящий интервью, должен хорошо разбираться и в проблемной (предметной) области, чтобы не испытывать трудности при общении, и понимать все, что ему будут говорить представители заинтересованных сторон. [c.118]
Очень важно разговаривать с людьми на их языке , об их мире и не заводить разговор в область конкретных решений или обсуждения технических проблем. В течение интервью желательно попросить человека описать по шагам процесс его работы. Все беспорядочные заметки, сделанные в процессе интервью, должны быть затем аккуратно структурированы в наборы требований и переданы представителю заинтересованной стороны для рецензирования. Интервью это интерактивный (диалоговый) процесс и очень важно, чтобы специалист, проводящий интервью, не выполнял свою работу поверхностно, а как можно чаще задавал вопрос Почему , докапываясь до сути (при этом не выступая в роли судьи, сразу оценивая, что важно, а что нет). [c.118]
Существует множество способов сформулировать этот простой вопрос по-разному, например С какой целью вы делаете... или Расскажите мне немного подробнее о... . Несмотря на предварительную подготовку, интервьюер может не быть экспертом в предметной области и, следовательно, в ходе интервью всегда будут необходимы дальнейшие уточнения и подробные разъяснения. Поэтому не бойтесь задавать глупые (на первый взгляд) вопросы. Существует только единственный глупый вопрос - это тот, который не задан Поэтому важно осознавать, что, в конечном итоге, именно пользователь (представитель заинтересованной стороны) несет ответственность за пользовательские требования - вы лишь помогаете им формулировать требования. [c.119]
Не забывайте, что обсуждение сценариев использования с будущими пользователями системы является ключом к успеху. [c.119]
Лучше всего обсуждение строить на принципе от общего к частному . Очень важно быть уверенным в том, что все, что намечалось обсудить, было проговорено, и что при этом четко выделены области, не относящееся к делу. [c.119]
Опыт проведения интервью подсказывает, что конкретные формы и содержание вопросов должны всегда зависеть от собеседников и ситуации. [c.119]
После того, как был создан объединенный сценарий, становится возможным извлекать пользовательские требования непосредственно из него. [c.120]
В некоторых случаях это делается простым перефразированием состояний (или целей) сценария использования. Например, состояние готовность к отплытию можно перефразировать и сформулировать возможность следующим образом пользователь должен иметь возможность подготовить парусную лодку к отплытию. В других случаях для этого требуется гораздо больше усилий. Рис. 5.10 поможет нам продемонстрировать вышесказанное. [c.120]
Два человека должны иметь возможность погрузить лодку на крышу легкового автомобиля среднего размера. [c.121]
Более подробную информацию о том, как правильно формулировать требования можно найти в главе 4. [c.121]
Одним из путей сбора пользовательских требований является проведение семинаров. [c.121]
Как только будет получен предварительный набор требований, его нужно тут же выносить на обсуждение всех участников семинара. Необходимо поощрять критику и дискуссии. Возможность общения между различными группами заинтересованных сторон привносит весьма ощутимую пользу в процессе формирования требований. Часто случается, что эти люди, даже работая в одной компании, впервые видят друг друга на вашем семинаре. Поэтому и вам и им самим будет всегда интересно наблюдать, как взаимодействие между различными группами порождает требования, которые находятся на стыке интересов, - как желание иметь возможность делать что-то для одной группы пересекается с соответствующими желаниями и потребностями других групп. [c.122]
Ключевыми элементами семинара являются формирование позитивного рабочего настроя, достижение нужного темпа работы и последующее поддержание его на протяжении всего семинара. [c.123]
Следует заметить, что организация такого семинара потребует определенных усилий, однако полученный результат перекроет все затраты на его проведение. [c.123]
Очень важно также, чтобы представители всех категорий заинтересованных сторон, присутствующих на семинаре, были уполномочены принимать решения. [c.123]
Проблемы, обнаруженные непосредственными пользователями системы, - это просто золотая жила для дальнейшей работы, - однако очень часто эта информация даже не принимается к рассмотрению. Складывается некое негативное отношение к информации такого рода, поскольку она ассоциируется с проблемами, однако эта информация может принести очень большую пользу. [c.123]
Несомненно, что чем раньше обнаружена проблема, тем дешевле стоит ее устранение -иногда для этого достаточно просто изменить формулировку требования или требований. Но с другой стороны, - если позволить легко, бесконтрольно и постоянно вносить изменения в проект, любой проект будет похоронен в самом начале. Поэтому если разработка системы предусматривает ее пошаговую реализацию (функционал внедряется не весь сразу, а постепенно), то становится возможным отложить внесение изменений до следующих версий. [c.123]
Если вы разрабатываете совершенно новую систему, аналогов которой не существует, в этом случае прототипы, макеты просто незаменимы. Прототипы дают представление о том, как система будет выглядеть. Так в области разработки программного обеспечения прототипы очень часто применяются для моделирования пользовательского интерфейса, поскольку будущим пользователям системы без наглядного примера бывает очень трудно представить себе как будет выглядеть этот интерфейс. [c.123]
Главная проблема при разработке прототипов это то, что разработчики очень часто увлекаются и тратят на разработку макета очень много времени и сил. Разработка прототипов должна каждый раз позиционироваться как выделенный подпроект со своими собственными требованиями. Цель разработки прототипа должна быть четко определена, поскольку она нужна не только для разработки прототипа как такового, но она может оказать неоценимую помощь в формировании самих пользовательских требований. [c.123]

Вернуться к основной статье