Сбор требований — это итеративный процесс, который включает в себя взаимодействие с клиентами для согласования деталей требований. Не существует идеальной методики для сбора и анализа требований. Наиболее подходящие методики варьируются от проекта к проекту.
Наиболее часто используемые техники:
- Интервьюирование;
- Прототипирование;
- Анализ вариантов использования;
- Пользовательские истории;
- Семинары.
Рассмотрим чуть подробнее каждый из приведенных методов.
1. Интервью
Интервью используются для сбора информации. Однако, необходимо принять во внимание такие характеристики интервьюируемого как предрасположенность, опыт и мастерство, поскольку данные особенности могут повлиять на качество полученной во время интервью информации. Одним из подходов для снижения риска потери информации является использование контекстно-независимых вопросов.
2. Прототипирование
Прототипирование это техника для построения быстрой и приблизительной версию желаемой системы или части этой системы. Прототип демонстрирует возможности системы пользователям и дизайнерам. Прототип представляет механизм связи, позволяющий рецензентам, понять взаимодействие внутри системы. В некоторых случаях, создание прототипов может создать впечатление, что разработчики зашли дальше в развитии проекта, чем есть на самом деле, что может предоставить пользователям нереалистичные ожидания окончания проекта.
Эффективные техники для выявления требований / Экспертный стол Дениса Гобова
3. Анализ вариантов использования
Анализ вариантов использования это описательный документ, в котором излагается последовательность событий, описывающих использование пользователем системы для достижения определенных целей. Варианты использования описывают поведение системы, предназначенное для разработки, без описания того как это поведение должно быть разработано. Диаграмма вариантов использования может быть использована для описания высокоуровневых бизнес требований, которые должна поддерживать система.
4. Пользовательские истории
Пользовательские истории это простой подход к сбору требований, который сдвигает фокус с формального документирования требований к разговору, который позволяет проекту быть более восприимчивыми с момента его создания. Пользовательские истории отличаются от вариантов использования тем, что они написаны клиентами. Клиенты описывают функций, которые система должна выполнять. Пользовательские истории состоят всего из несколько предложений.
5. Семинары
Семинары по сбору требований предоставляют возможность для совместного выявления требований. Участники семинаром могут уйти с более глубоким пониманием вопросов, и в результате чего могут почувствовать сильное чувство приверженности и заинтересованности в проекте.
Источник: sysana.wordpress.com
Мастер-класс по сбору и анализу требований
Презентация на тему СБОР ТРЕБОВАНИЙ -ИНСТРУКЦИЯДЛЯ МЕНЕДЖЕРА
ОПРЕДЕЛЕНИЕ Сбор требований — это процесс выявления и документирования реальных потребностей клиента к программному продукту.
- Главная
- Разное
- СБОР ТРЕБОВАНИЙ -ИНСТРУКЦИЯДЛЯ МЕНЕДЖЕРА
Слайды и текст этой презентации
Слайд 1СБОР ТРЕБОВАНИЙ — ИНСТРУКЦИЯ ДЛЯ МЕНЕДЖЕРА
Дмитрий РУЗАНОВ
Сергей СТРУЖКОВ
Слайд 2
ОПРЕДЕЛЕНИЕ
Сбор требований — это процесс выявления и
документирования реальных потребностей клиента к программному продукту.
Слайд 3
ОГРАНИЧЕНИЕ
Сбор требований в том виде, в котором
мы будем о нем рассказывать, – это
не инструмент аналитика-проектировщика, это инструмент менеджера для первой встречи с клиентом и инструмент менеджера для детальной проработки несложного проекта
Слайд 4
ВОПРОС
У многих ли из вас существуют проблемы
с обучением новичков?
Проблема следующего рода –
когда вы должны передать свой опыт и знания начинающему, а он просто не понимает то, что для вас является давно уже понятным и ясным – и вам становиться сложно найти общий язык
Слайд 5
ОСНОВНАЯ НАША ПРОБЛЕМА
«Как за несколько месяцев испытательного
срока научить менеджера эффективно собирать требования с
Слайд 6
ОСНОВНАЯ ПРОБЛЕМА МЕНЕДЖЕРА
Как не потеряться и
не
пойти на поводу у клиента
И как в итоге выявить
максимальное количество требований?
Слайд 7
ИТОГИ ОБУЧЕНИЯ
За 3-4 недели менеджер обучается собирать
основные требования к программному продукту:
устанавливать цели
и задачи создания сайта,
обговаривать основной функционал,
выявлять основные сценарии поведения пользователей на сайте
давать впоследствии денежную оценку проекта
Слайд 8
ПРОЦЕСС СОЗДАНИЯ САЙТА
Первый контакт, ценовые ожидания,
встреча
Анализ действующего сайта и конкурентов
Очная встреча: сбор
бизнес-требований и требований участников проекта
Оценка на полноту и непротиворечивость
Трансформация требований в функциональные модули
Согласование функционала
Описание сценариев использования сайта посетителями
Написание технического задание
Договор, оплата, начало работы
Слайд 9
БИЗНЕС-ТРЕБОВАНИЯ
Слайд 10
БИЗНЕС-ТРЕБОВАНИЯ
Сбор требований – это не допрос
с пристрастием!
Это диалог, построенных на открытых
Слайд 11
М: Часто ли вы нанимаете сотрудников? Есть
ли у вас с этим проблема? В
этом случае я рекомендовал бы размещение раздела с вакансиями и возможно даже создание отдельной промо-страницы, где можно было бы описать преимущества работы с вами, истории успеха ваших сотрудников, выложить видео, инфографику и т.п. – то, чего не сделаешь на сайтах с вакансиями
М: Какого рода у вас есть партнеры? Наверняка, у вас партнерские отношения с поставщиками пива? Давайте подумаем, что можно предложить им?
М: Как часто вы печатаетесь в СМИ типа «Афиши» и подобных? Какую информацию они обычно у вас запрашивают? Может ее стоит разместить на сайте?
М: Как мы учтем наличие ваших конкурентов? В любом случае мой совет – не стоит раскрывать полную информацию о сотрудниках – могут схантить.
Слайд 12
Требования участников проекта — это требования
сотрудников компании к сайту (пожелания с точки
зрения того, как сайт может быть полезен им в качестве рабочего инструмента)
Как правило, сайт больше всего нужен:
менеджеру по работе с клиентами
директору по персоналу (HR-менеджеру)
директору по рекламе, маркетологу
пиар-менеджеру
бухгалтеру
курьеры
логисты
ТРЕБОВАНИЯ УЧАСТНИКОВ ПРОЕКТА
Слайд 13
ТРЕБОВАНИЯ УЧАСТНИКОВ ПРОЕКТА
Варианты использования сайта менеджером по
продажам:
Сайт может помогать менеджеру при непосредственном общении
с клиентом – например, менеджер с экрана компьютера демонстрирует клиенту продукцию или услуги компании.
Менеджер «конструирует» что-то на сайте, например, выбирает для клиента тур в Турцию или рассчитывает стоимость полиса ОСАГО.
Менеджер часто выезжает на встречу с клиентом на места и с планшетника демонстрирует продукцию, представленную на сайте – (для себя мы сразу делаем пометку, что будет важна мобильная версия сайта и интерфейс работы с устройствами с сенсорным экраном).
Слайд 14
ТРЕБОВАНИЯ УЧАСТНИКОВ ПРОЕКТА
Варианты вопросов для выявления требований
участников проекта (Паб):
Какую активность проявляет ваш маркетинговый
отдел? Возможно вам нужен функционал для размещения акций, конкурсов?
В каком виде происходит обработка входящих обращений менеджером? –предлагаем создать функционал бронирования столиков через сайт (с возможностью выбора столика на схеме). Сам же менеджер сможет оперативно отлеживать данную информацию в ходе поступающих телефонных звонков
PR-менеджер – для того, чтобы произвести впечатление на потенциальных посетителей можно сделать на сайте виртуальный тур, показав интерьеры паба
Слайд 15
ТРЕБОВАНИЯ ВНЕШНИХ ПОЛЬЗОВАТЕЛЕЙ
Сбор требований внешних пользователей системы
– это подробная проработка сценариев поведения всех
потенциальных групп посетителей сайта: начиная с покупателей товаров/услуг компании и заканчивая представителями СМИ, соискателями работы и т.п.
Фактически, это более подробно расписанные бизнес-требования, к которым добавляются требования 2 основных бизнес-групп – клиентов и потенциальных покупателей.
Слайд 16
ТРЕБОВАНИЯ ВНЕШНИХ ПОЛЬЗОВАТЕЛЕЙ
Виды сценариев поведения покупателей:
a.
Для первичных: покупка товара, ознакомление с ценами,
сравнение товара, получений консультаций.
b. Для вторичных: повторный заказ товара, получение скидки.
c. Для не определившихся: поиск товара, участие в акциях, связь с компанией.
d. Для постоянных: покупка одних и тех же товаров, использование скидок, техподдержка.
Слайд 17
ТРЕБОВАНИЯ ВНЕШНИХ ПОЛЬЗОВАТЕЛЕЙ
Пример для сценария «повторный заказ
товара»:
При заходе на сайт авторизованный пользователь
может зайти в раздел «история заказов», выделить с помощью чекбокса ранее сделанный заказ и нажать на кнопку «повторить заказ». После этого пользователь перенаправляется на страницу совершения покупок, где он может отредактировать свой «повторный заказ», удалив ненужные ему товары или добавив новые. В последнем случае пользователь должен будет перейти в каталог товаров и доложить в корзину требуемые.
Слайд 18
ДОМАШНЕЕ ЗАДАНИЕ
Проанализируйте ваши текущие инструкции по сбору
требований как с точки зрения их непосредственных
пользователей (если вы менеджеры), так и с точки зрения наставников, которые обучают сбору требований подчиненных и улучшите их с учетом полученных знаний!
Слайд 19
Спасибо!
Дмитрий РУЗАНОВ
Источник: thepresentation.ru
Планирование хороших требований
Итак, что делает хорошее требование? Хорошее требование должно быть ценным и действенным; это должно определить потребность, а также обеспечить путь к решению. Все в команде должны понимать, что это значит. Требования различаются по сложности.
- Хороший документ с требованиями может быть частью группы с требованиями высокого уровня, разбитыми на подусловия.
- Они могут также включать очень подробные спецификации, которые включают набор функциональных требований, описывающих поведение или компоненты конечного продукта.
- Хорошие требования должны быть краткими и конкретными и должны отвечать на вопрос «что нам нужно?», А не «как мы удовлетворяем потребность?»
- Хорошие требования гарантируют, что все заинтересованные стороны понимают свою часть плана; если детали неясны или неверно истолкованы, конечный продукт может быть неисправен или неисправен.
Хороший документ с требованиями может быть частью группы с требованиями высокого уровня, разбитыми на подусловия.
Они могут также включать очень подробные спецификации, которые включают набор функциональных требований, описывающих поведение или компоненты конечного продукта.
Хорошие требования должны быть краткими и конкретными и должны отвечать на вопрос «что нам нужно?», А не «как мы удовлетворяем потребность?»
Хорошие требования гарантируют, что все заинтересованные стороны понимают свою часть плана; если детали неясны или неверно истолкованы, конечный продукт может быть неисправен или неисправен.
Предотвращению сбоев или неправильного толкования требований может помочь постоянное получение обратной связи от группы в течение всего процесса по мере развития требований. Непрерывное сотрудничество и участие со всеми – ключ к успеху.
Сбор и анализ требований
Требование – это условие или способность, необходимые заинтересованному лицу для решения проблемы или достижения организационной цели; состояние или способность, которой должна соответствовать система.
Анализ требований в разработке программного обеспечения охватывает те задачи, которые входят в определение потребностей или условий для нового или измененного продукта с учетом возможных противоречивых требований различных заинтересованных сторон, анализа, документирования, проверки и управления требованиями к программному обеспечению или системе.
Требования должны быть –
- документированный
- Осуществимое
- измеримый
- Тестируемые
- прослеживаемый
Требования должны быть связаны с определенными бизнес-потребностями или возможностями и определены с уровнем детализации, достаточным для проектирования системы.
Бизнес-аналитик собирает информацию, наблюдая за существующими системами, изучая существующие процедуры, обсуждая с клиентами и конечными пользователями. Аналитик также должен обладать творческими и творческими навыками в отсутствие работающей Системы. Анализ собранных требований для поиска недостающих ссылок – это анализ требований.
Выявление Подхода
Чтобы определить цели, задайте бизнес-эксперту, менеджеру по развитию и спонсору проекта следующие вопросы:
- Каких бизнес-целей компании поможет этот проект?
- Почему мы делаем этот проект сейчас?
- Что будет, если мы сделаем это позже?
- Что делать, если мы не делаем это вообще?
- Кто выиграет от этого проекта?
- Считают ли люди, которые извлекут из этого пользу, самым важным улучшением, которое может быть сделано в это время?
- Должны ли мы делать другой проект вместо этого?
Каких бизнес-целей компании поможет этот проект?
Почему мы делаем этот проект сейчас?
Что будет, если мы сделаем это позже?
Что делать, если мы не делаем это вообще?
Кто выиграет от этого проекта?
Считают ли люди, которые извлекут из этого пользу, самым важным улучшением, которое может быть сделано в это время?
Должны ли мы делать другой проект вместо этого?
Возможными целями могут быть сокращение затрат, улучшение обслуживания клиентов, упрощение рабочего процесса, замена устаревшей технологии, пилотирование новой технологии и многие другие. Также убедитесь, что вы точно понимаете, как предлагаемый проект поможет достичь поставленной цели.
Различные типы требований
Наиболее распространенные типы требований, которые интересуют бизнес-аналитика, следующие:
Бизнес-требования
Бизнес-требования – это критически важные действия предприятия, которые должны выполняться для достижения целей организации, оставаясь при этом независимым от решения. Документ бизнес-требований (BRD) детализирует бизнес-решение для проекта, включая документацию о потребностях и ожиданиях клиента.
Требования к пользователю
Пользовательские требования должны указывать конкретные требования, которые пользователь ожидает / хочет от программного обеспечения, которое будет создано из программного проекта. Требование пользователя должно быть Проверяемым, Четким и кратким, Полным, Последовательным, Прослеживаемым, Жизнеспособным.
Документ с требованиями пользователя (URD) или спецификация требований пользователя – это документ, обычно используемый в разработке программного обеспечения, в котором указывается, что пользователь ожидает от программного обеспечения.
Системные Требования
Системные требования касаются определения требований к программным ресурсам и предварительных условий, которые необходимо установить на компьютер для обеспечения оптимального функционирования приложения.
Функциональные требования
Функциональные требования фиксируют и определяют конкретное предполагаемое поведение разрабатываемой системы. Они определяют такие вещи, как системные вычисления, манипулирование и обработка данных, пользовательский интерфейс и взаимодействие с приложением, а также другие специфические функции, которые показывают, как удовлетворяются пользовательские требования. Присвойте уникальный идентификационный номер каждому требованию.
Нефункциональные требования
Нефункциональное требование – это то, которое определяет критерии, которые могут использоваться для оценки работы системы, а не для конкретного поведения. Архитектура системы говорит о плане реализации нефункциональных требований.
Нефункциональные требования говорят о том, как должна выглядеть система, или ее можно назвать «система должна быть». Нефункциональные требования называются качествами системы.
Требования к переходу
Требования перехода описывают возможности, которые решение должно выполнять, чтобы облегчить переход от текущего состояния предприятия к желаемому будущему состоянию, но это не потребуется после завершения этого перехода.
Они отличаются от других типов требований, поскольку они всегда носят временный характер и не могут быть разработаны до тех пор, пока не будет определено как существующее, так и новое решение. Как правило, они охватывают преобразование данных из существующих систем, пробелы в навыках, которые необходимо устранить, и другие связанные изменения, чтобы достичь желаемого будущего состояния. Они разрабатываются и определяются путем оценки и подтверждения решения.
Отслеживание и управление изменениями
Отслеживание требований – это способ организации, документирования и отслеживания всех ваших требований от начальной генерации идеи до фазы тестирования.
Матрица возможностей трассировки требований (RTM) предоставляет метод для отслеживания функциональных требований и их реализации в процессе разработки. Каждое требование включено в матрицу вместе с соответствующим номером раздела.
По мере выполнения проекта RIM обновляется, чтобы отражать статус каждого требования. Когда продукт готов к тестированию системы, в матрице перечисляются все требования, какой компонент продукта отвечает на них, и какой тест проверяет, правильно ли он реализован.
Включить столбцы для каждого из следующих в RTM –
- Описание требования
- Требование ссылки в FRD
- Метод проверки
- Ссылка на требование в плане испытаний
Пример – подключение точек для определения взаимосвязей между элементами в вашем проекте. Это соединитель общего нисходящего потока.
Идея Требования Дизайн Тест Бизнес Цели
Вы должны быть в состоянии проследить каждое из ваших требований до их первоначальной бизнес-цели.
Отслеживая требования, вы можете определить, какие изменения имели волновой эффект, посмотреть, выполнено ли требование и проходит ли оно надлежащее тестирование. Отслеживание и управление изменениями обеспечивают менеджерам душевное спокойствие и видимость, необходимые для прогнозирования проблем и обеспечения постоянного качества.
Гарантия качества
Правильное выполнение требований с первого раза может означать лучшее качество, более быстрые циклы разработки и более высокое удовлетворение потребителя продуктом. Управление требованиями не только помогает вам сделать все правильно, но и помогает вашей команде сэкономить деньги и избавиться от множества головных болей на протяжении всего процесса разработки.
Вкратце, конкретные требования могут помочь вам обнаружить и исправить проблемы раньше, а не позже, когда их решение намного дороже. Кроме того, исправление дефекта в процессе разработки после его кодирования может стоить в 100 раз дороже, чем исправление на раннем этапе, когда это требуется.
Интегрируя управление требованиями в свой процесс обеспечения качества, вы можете помочь своей команде повысить эффективность и устранить доработки. Кроме того, на переделках возникает большинство проблем с расходами.
Другими словами, команды разработчиков тратят большую часть своего бюджета на усилия, которые не выполняются правильно с первого раза. Например, разработчик кодирует функцию, основанную на старом документе спецификации, только чтобы потом узнать, что требования к этой функции изменились. Таких проблем можно избежать с помощью эффективных методов управления требованиями.
Таким образом, управление требованиями может показаться сложной дисциплиной, но когда вы сводите его к простой концепции – речь идет о том, чтобы помочь командам ответить на вопрос: «Все ли понимают, что мы строим и почему?» От бизнес-аналитиков, продукта менеджеры и руководители проектов разработчикам, менеджерам по обеспечению качества и тестировщикам, а также заинтересованным сторонам и заказчикам – поэтому зачастую причиной провала проекта является неправильное понимание масштабов проекта.
Когда все сотрудничают и имеют полный контекст и видимость для обсуждений, решений и изменений, связанных с требованиями на протяжении всего жизненного цикла проекта, то есть когда успех происходит последовательно и вы сохраняете постоянное качество. Кроме того, процесс более плавный, с меньшим количеством трений и разочарований по пути для всех участников.
Примечание. Исследования показали, что проектные группы могут устранить 50-80% дефектов проекта, эффективно управляя требованиями. По данным Института разработки программного обеспечения Карнеги-Меллона, «60–80 процентов затрат на разработку программного обеспечения находятся в процессе доработки».
Получение требований Signoff
Получение требований к подписке обычно включает в себя итоговый обзор требований, как это задокументировано, с каждым участником проекта. В конце каждой проверки заинтересованному лицу предлагается официально утвердить пересмотренный документ с требованиями. Это одобрение может быть зарегистрировано либо физически, либо электронно.
Получение подписи требований, как правило, является конечной задачей в рамках взаимодействия требований. Бизнес-аналитику потребуются результаты анализа (-ов) формальных требований, включая размещение любых комментариев или возражений, которые были высказаны в процессе проверки.
Источник: coderlessons.com
