Методы сбора требований к программному обеспечению

В статье описываются методы сбора требований к программному обеспечению, которые часто применяются на этапе определения требований RUP.

Интервьюирование – заключается в беседе представителя разработчика и заинтересованного лица. Применяется в случае, когда большим объемом знаний обладает ограниченных круг людей. Обычно используется для беседы с одним человеком с глазу на глаз. Метод используется в том случае, когда нереально собрать насколько ключевых пользователей одновременно в одном месте. Опасность применения метода заключается в том, что могут быть опрошены не все заинтересованные лица, и разработчики могут упустить ключевую информацию.

Анкетирование – заключается в составлении списка вопросов и предоставлении их заинтересованным лицам. Метод удобен в случае, когда имеется большая база респондентов, а разработчики могут квалифицированно сформулировать список вопросов. Опасность метода заключается в том, что вопросы могут быть неоднозначно поняты пользователями и соответственно даны неточные ответы. Возможно, что пользователи вообще не смогут ответить на некоторые вопросы, которые потребуют дополнительного пояснения или просто забудут ответить на анкету.

Мозговой штурм – заключается в обсуждении требований и записи всего, что придет в голову с последующей сортировкой и обработкой полученных требований и установкой приоритетов. Метод удобен, когда обсуждаются нестандартные решения незнакомой проблемы. Большинство хороших идей часто бывают результатом комбинации нескольких, на первый взгляд не связанных. В самом процессе генерации идей не нужно критиковать и устанавливать ограничения. Главная задача мозгового штурма – выработка как можно большего количества требований анализ требований нужно производить позднее.

Сценарии и ролевые игры – метод заключается в создании легко модифицируемого схематичного сценария работы системы (не прототипа), который обсуждается с пользователем. Метод направлен на поиск актеров, участвующих в работе системы и получения от будущих пользователей обратной связи, например по вопросам интерфейса или по вопросам «что будет если...». Для ролевых игр могут использоваться доски, простые листы бумаги или даже интерактивные сценарии, главное, чтобы пользователь понимал, как происходит взаимодействие с системой. Сценарии особенно полезны в случае когда в систему включены новые функции, плохо поняты требования, не определены актеры и варианты использования. Они также позволяют обсудить пользовательский интерфейс, не прибегая к трудоемкому созданию прототипов.

Создание прототипов – метод заключается в создании скелета системы – прототипа, который позволяет предметно обсуждать с пользователем требования к системе, демонстрировать принятые решения, внешний вид системы и порядок работы. Прототип – не является рабочей версией программы, поскольку в нем не реализуются многие возможности необходимые для нормальной работы. Такие возможности как проверка входных параметров, обработка ошибок, резервное копирование обычно в прототип не включаются. Также при создании прототипа не уделяется внимание вопросам производительности и масштабируемости. Прототипы могут служить доказательством того, что команда проекта работает над системой, однако при их использовании может возникнуть опасность, что прототипы будут приняты руководством за рабочий вариант со всеми вытекающими из этого последствиями. В частности до требований, которые не реализованы в прототипах, могут вообще не дойти руки.

Совместная разработка приложений (joint application design [JAD-совещание]) – метод заключается в том, чтобы собрать всех заинтересованных лиц в одной комнате на день-два для интенсивной работы по идентификации требований их документированием и назначением приоритетов. Метод позволяет значительно сократить время опроса пользователей по отдельности, но требует высокой квалификации того, кто ведет JAD-совещание. Ведущий должен быть политически нейтральным, достаточно хорошо знакомым с областью деятельности, на которую рассчитан проект. Успех во многом зависит от позиции заинтересованных сторон и тех, кто принимает решения и их готовности к сотрудничеству. Этот метод хорошо сочетается с моделированием и, с некоторыми ограничениями, – созданием прототипов.

Моделирование - метод заключается в создании и обсуждении моделей автоматизируемых процессов, информационных потоков, отношений между объектами и т.д. Модели могут готовиться при помощи различных программных средств, таких как BPwin, Rational Rose, Visio и различных нотациях, которые понятны заинтересованным лицам. Нужно определять в каких случаях дешевле и проще создать модели, а в каких прототипы, поскольку прототип можно назвать моделью предварительного варианта использования. Обычно моделирование дешевле и гибче прототипирования, поскольку модель может иметь различные уровни абстракции от высокоуровневых до подробного и весьма детализированного описания системы. К недостаткам этого метода можно отнести высокие требования к квалификации как разработчиков, которые создают модели и обсуждают их с заинтересованными лицами так тех, кто эти модели рассматривает. Нельзя забывать и то, что слишком детализированное моделирование системы может занимать столько же времени, сколько заняло бы создание прототипа, и в то же время прототип можно «пощупать» и использовать его части в дальнейшем создании системы, тогда как модель – только иллюстрация.