Способы получения требований от конечных пользователей включают

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

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

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

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

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

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

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

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

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

Источник

Методы сбора требований или «Как понять, что хочет заказчик?»

Данная статья будет полезна как аналитикам, так и менеджерам, занимающимся сбором и анализом требований. В ней описаны основные методики сбора требований, а также их плюсы и минусы. Возможно, что-то вы уже применяли на практике, а о чем-то, возможно, не знали. В общем, эта статья для всех тех, кто уже занимается бизнес — анализом или только планирует пополнить ряды аналитиков.

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

Стейкхолдерами могут быть любые физические лица и/или организации, которые активно участвуют в нашем проекте, и чьи интересы могут быть затронуты не только в процессе создания системы, но и непосредственно по завершению самого проекта. Ими могут быть менеджеры, начальники отделов, директора, любые сотрудники организации, которые будут хоть как-то взаимодействовать с готовым решением, и чьи требования (пожелания, идеи, потребности, проблемы) будем собирать.

Существует множество различных техник сбора требований, которые помогут лучше понять, что же хочет заказчик.
Рассмотрим основные из них чуть подробнее:

Анкетирование

Данный способ подразумевает под собой составление листа-опросника (анкеты, брифа), который может содержать открытые (требуют от опрашиваемого сформулировать его ответ) и закрытые (требуют от опрашиваемого выбрать ответ из предложенных вариантов) вопросы.

Анкетирование используется для того, чтобы подтвердить или детализировать ранее известные требования, выбрать параметры для решений.

Самым известным примером анкетирования может быть “Бриф на разработку сайта” — анкета содержащая список основных требований и информацию о будущем сайте.

1. Высокая скорость получения результатов.
2. Сравнительно небольшие материальные затраты.

Недостатки:

1. Данный метод не подходит для выявления неявных требований.
2. При составлении опросника физически невозможно учесть все необходимые вопросы.

Интервью

Этот метод известен многим, своего рода беседа “по душам” с заинтересованным лицом, тет-а-тет.
Необходимо задавать открытые вопросы для получения информации и закрытые для того, чтобы подтвердить или опровергнуть конкретные варианты требований.

Данный способ применяется, в основном, для получения информации по какой-либо конкретной теме и/или для уточнения требований.

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

1. Возможность задавать вопросы в произвольной последовательности.
2. Возможность использовать вспомогательный материал.
3. Анализ невербальной реакции опрашиваемого человека, позволит сделать дополнительный вывод о достоверности его ответов.

Из минусов:

1. Интервью отнимает достаточно много времени и сил.
2. Дополнительной сложностью является получение одинаковых ответов от интервьюируемых.

Автозапись

Данный метод подразумевает под собой работу с записями, письмами (электронными письмами), а также с любым другим документом, автором которого является Заказчик или конечный пользователь (т.е. стейкхолдер).

В действительности это может быть и документ и наговоренная на диктофон последовательность действий или самая обычная салфетка, на которой заказчик набросал свои идеи / проблемы /хотелки, которые необходимо превратить в полноценные требования, согласовать и передать в разработку.

Примером такого метода может быть работа с концепцией или видением проекта (сам Заказчик любит называть это — «ТЗ»), которую он прислал вам на момент начала работ по аналитике.

• Помогает лучше понять сложные процедуры или процессы.

Недостаток:

• Данный метод сильно зависит от опыта Заказчика, а также от его умения формулировать и выражать свои мысли.

Изучение существующей документации

Данная методика может быть использована при наличии в организации документации, которая может помочь в определении потребностей Заказчика. Примеры документации включают в себя: регламенты,
описания процессов, структура организации, спецификации продукта, различные процедуры, стандарты и инструкции, шаблоны документов и т.д.

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

• Данный способ не применим при наличии в компании только базовых документов (или при их полном отсутствии) или, если в компании Заказчика не поддерживается актуальность документации.

Повторное использование спецификации

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

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

В большинстве случаев только часть документации актуальна для нового проекта, поэтому потребуется тщательная проверка требований на соответствие текущим целям и задачам Заказчика.

• Сокращение времени на разработку документации.

Недостатки:

• Высокая стоимость первого проекта.
• Излишняя детализация требований, может привести к их дорогостоящим изменениям в будущем.

Представитель заказчика в компании разработчика

Один из наиболее эффективных методов сбора требований, поскольку позволяет получать от представителя Заказчика своевременную оценку прогресса, корректности реализации, в короткие сроки получать обратную связь (фидбек) и дополнительную информацию для корректировки и разработки требований.

Метод часто применяется для сбора и управления требованиями при итерационной разработке, позволяет оперативно собирать, согласовывать и дорабатывать требования.

В дополнение можно сказать, что наличие представителя заказчика в компании разработчика является одним из главных правил Agile.

• Быстрое получение обратной связи и информации от Заказчика.

Недостатки:

• Достаточно высокая цена для Заказчика.
• Затраты по времени на адаптацию сотрудника.

Работа «в поле»

Работа «в поле» состоит из наблюдения за деятельностью и процессами будущих пользователей системы, и в определении требований, основанных на этом наблюдении. Если говорить проще, то это наблюдение за тем, как работают пользователи, и документирование процесса, задач и результатов их деятельности.

Метод позволяет избежать проблем, связанных с трудностями стейкхолдеров в описании и выражении своих потребностей. В некоторых случаях процесс наблюдения может сопровождаться «интервьюированием» пользователей для уточнения особенностей и деталей их работы и задач. В процессе наблюдения можно так же выявить пути оптимизации бизнес процессов Заказчика.

1. Позволяет наглядно увидеть проблему и разработать наиболее оптимальный вариант ее решения.
2. Помогает наиболее точно собрать требования, наблюдая за работой сотрудников.

Недостатки:

1. В процессе наблюдения могут быть упущены некоторые альтернативные сценарии бизнес процесса.
2. Трудно применим на секретных предприятиях или опасных (вредных) производствах.

Обучение

Обучение — это процесс, в котором Заказчик или любой другой человек из организации Заказчика, знающий процесс, обучает аналитика по принципу учитель — ученик.

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

Обучение позволяет лучше понять сложные бизнес-процессы, а также преодолеть трудности, связанные с нехваткой абстрактного мышления и самовыражения у будущих пользователей системы.

• Позволяет понять сложный бизнес процесс, что позволяет предложить наилучшее решение.

Недостатки:

• Высокая стоимость и длительность.
• Метод неприменим на опасных (вредных) производствах.

Мозговой штурм

Мозговой штурм — наиболее часто используемый метод получения требований, которые связанны с новыми или плохо изученными направлениями деятельности организации Заказчика или функциями системы.

Он позволяет собрать множество идей от различных заинтересованных лиц (стейкхолдеров) в кратчайшие сроки и практически бесплатно.

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

• Позволяет генерировать множество (в том числе и нестандартных) вариантов решений, а также позволяет участникам развивать идеи друг друга.

Минусы:

• Участники мозгового штурма должны быть мотивированы на идеи.
• Трудно применим в распределенных командах.

Совещание

Совещание — встреча, ориентированная на обсуждение конкретных вопросов, которые были определены и озвучены участникам заранее.

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

Совещания являются одной из ключевых практик в Agile, т.к. в них участвуют все стороны, заинтересованные в развитии проекта и решении проблемы.

• Позволяет развить и детализировать требования, определить приоритеты.

Недостатки:

• Сложности в организации встречи, если команда географически разделена, могут возникнуть трудности с присутствием всех необходимых людей на совещании.
• Консенсус необязательно будет достигнут.

Use case

Use cases или варианты использования позволяют собрать и сформировать функциональные требования от лица участников Диаграммы вариантов использования определяют границы решения и показывают связи с внешними системами и участниками.

Метод позволяет детализировать требования с точки зрения пользователей, а также помогает уточнить и систематизировать функционал, который требуется реализовать.

• Позволяет проработать все варианты развития сценария (основной и альтернативные сценарии)

Минусы:

• Метод не применим для сбора нефункциональных требований.

Эпилог

Комбинирование методик позволяет повысить эффективность сбора требований, а так же избежать их «потери».
При сборе требований необходимо помнить, что важны не только функциональные требования (ЧТО делает система), но и нефункциональные (КАК система это делает).

Тщательно собранные требования минимизируют риски проекта, т.к. позволяют сформировать четкий и понятный базис для разработки системы.

Информация для статьи взята из учебного пособия по подготовке к сертификации REQB Certified Professional for Requirements Engineering (Базовый уровень).

Источник