Презентация на тему Методы сбора требований

во внимание такие характеристики интервьюируемого как предрасположенность, опыт и

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

Интервью

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

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

Интервьюирование

или описать потенциальное решение. Вопросы, направленные в первую очередь

на получение реального понимания проблемы и какие решения уже предусмотрены.
Пример контекстно-свободных вопросов:
Кто является пользователем?
Кто является заказчиком?
Их потребности отличаются?
Где еще можно найти решение этой проблемы?

Контекстно-независимых вопросы

версии желаемой системы или части этой системы.
Прототип демонстрирует

возможности системы пользователям и дизайнерам.
Прототип представляет механизм связи, позволяющий рецензентам, понять взаимодействие внутри системы.

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

Прототипирование

излагается последовательность событий, описывающих использование пользователем системы для достижения

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

Анализ вариантов использования

который сдвигает фокус с формального документирования требований к разговору,

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

Пользовательские истории

выявления требований.
Участники семинаром могут уйти с более глубоким

пониманием вопросов, и в результате чего могут  почувствовать сильное чувство приверженности и заинтересованности в проекте.

Главное чтобы семинар не перерос в симпозиум ☺

Семинары

требований к системе за очень короткий промежуток времени;
Быстро принять

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

Совещание

(ЗЛ) получают возможность высказаться;
Формирует соглашение между ЗЛ и разработчиком

по поводу того, что должна делать система;
Может осветить/разрешить политические вопросы, которые влияют на успех проекта;
Результат – предварительное определение системы на уровне функций – становится известен немедленно.

Преимущества совещаний

когда участники проекта собираются вместе.
Любой мозговой штурм (МШ) состоит

из 2 основных этапов:
Генерация идей;
Отбор идей.

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

больше идей, не обязательно глубоких, но как можно более

различных. При отборе идей осуществляется с целью анализа всех возникших идей. При этом производятся отсечение, группировка, развитие и уточнение идей, расстановка приоритетов.
Перед началом штурма следует четко поставить его цель, например, «получить ответы на один из следующих вопросов»:
Какими свойствами должна обладать система?
Какие услуги должна предоставлять система?
Какие параметры должна отслеживать система?
По достижении поставленной цели МШ стоит завершить.

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

не обсуждаются;
Не допускается никакая критика/дебаты, кроме замечания «Отличная идея»!
Дайте

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

Правила МШ

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

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

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

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

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

Сценарии и ролевые игры спасибо, мистер Грей

заинтересованных лиц в одной комнате на день-два для интенсивной

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

Совместная разработка приложений

самое лучшее правило «Лучше один раз увидеть, чем сто

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

Наблюдение

возможной нормативной базы и других документов, и на базе

которых мы и проектируем функционал системы

Изучение документов

вопросах «что делаете», а не что «хотите»
Какие сейчас есть

проблемы и как сейчас решаются?
Какие претензии к старой системе?
Выяснить входную и выходную информацию
Придерживаться позитивного настроя при интервьюировании
Бесконечно мило улыбаться =))

Интервью

«по максимуму»
 
Очень важно правильно сформулировать вопросы в анкетах, т.к.

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

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

времени  не самый быстрый способ сбора данных)
Придерживаться позитивного настроя

при обсуждении
Бесконечно мило улыбаться =))

Наблюдение

не участвуем, в основном все делают технические специалисты (архитекторы

и программисты)
В случае, если мы все же нужны, то с нас «копирование функционала» в текстовой интерпретации..

Прототипирование