Как собирать требования аналитику
Перейти к содержимому

Как собирать требования аналитику

  • автор:

Методы сбора требований

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

Мой учитель

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

Ну, а теперь к теме статьи!

Сегодня мы тобой поговорим про методы сбора требований, которые может применять как аналитик, так и менеджер.

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

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

  • анализ данных;
  • интервьюирование;
  • анкетирование;
  • работа в “полях”;
  • мозговой штурм;
  • бенчмаркинг.

Анализ данных

Анализ данных может в себя включать:

  • изучение технической и нормативной информации;
  • работа с приложением/продуктом;
  • работа с набором данных (например отчет в excel, который необходимо автоматизировать);
  • работа с программным кодом.

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

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

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

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

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

Интервьюирование, как по мне, один из самых эффективных методов сбора требований. Если ты провел интервью качественно, то, скорее всего, ты сможешь составить 80% требований на основе этой информации. Хоть данный метод и является в большей степени устный, не стоит пренебрегать протоколированием и согласованием результатов интервью.

Виды интевьюирования

По стадии исследования:

  • предварительное — на данной стадии мы знакомимся с проблемой и ее источником. Уточняем перечень стейкхолдеров, которых необходимо включить в основную стадию и сроки начала основной стадии;
  • основное — для начала этой стадии важно начать проработку требований и проблемы, которую обозначил бизнес на предварительной стадии. Это необходимо, чтобы сформировать “правильные” вопросы к основной стадии интервью. Не жди, что с тобой охотно поделятся информацией, ее придется доставать со слезами на глазах;
  • контрольное — на этой стадии фиксируем результат, записываем новые хотелки бизнеса и, если они есть, фиксируем отклонения от исходных требований.

По количеству участников:

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

По степени формализации:

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

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

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

Анкетирование может быть:

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

Работа в «полях»

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

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

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

Работа в “полях” тесно переплетена с основной и контрольной стадией интервью.

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

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

Любой мозговой штурм состоит из двух этапов:

  • генерация идей;
  • отбор идей.

Среднее время генерации идей составляет один час.

Правила генерации идей:

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

Бенчмаркинг

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

  • оценивание;
  • сопоставление.

Обычно за образец принимают «лучшую» продукцию или и маркетинговый процесс прямых конкурентов, используемые прямыми конкурентами, работающими в подобных областях, для выявления фирмой возможных способов совершенствования её собственных продуктов и методов работы.
Ну, а если по-простому, то мы берем существующие решения, стандарты, методики и примеряем это на себя. Если после примерки выглядим хорошо и нигде не трет, а результативность наша выросла, то надо брать.
Этот метод позволяет наиболее точно составить требования, т.к. все уже реализовано, а тебе остается только переиспользовать имеющиеся наработки, с учетом собственных бизнес-процессов, нормативных документов и пожеланий бизнеса.

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

Сбор требований для чайников и технарей

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

Как собирать требования

Я хочу поделиться своим опытом сбора требований в области внедрения CRM систем, но думаю принципы, которые будут здесь описаны, подойдут и для других продуктов. Итак, с чего же начинается сбор требований. Естественно, с общения с заказчиком. Тут у нас есть два пути: непосредственное общение и анкетирование. Разберем оба варианта, с их плюсами и минусами.

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

• Экономия времени
• Все ответы строго зафиксированы на бумаге
• Возможность собрать запросы с большого количества сотрудников

• На самом деле минус здесь глобальный один, но он нивелирует все плюсы. При заполнении анкеты, без установления личного контакта, без наводящих вопросов, без возможности посмотреть где и как работают сотрудники мы в 90% случаев не сможем определить все проблемы заказчика. Соответственно не сможем предложить наиболее подходящее решение. И как итог получим негатив на выходе, будем требования пересобирать, заново анализировать и т.д. (опыт есть)

• Максимально полный разбор (при умении) проблем заказчика
• Возможность побеседовать со всеми сотрудниками и посмотреть за их работой

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

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

Первое общение

На самом деле с заказчиком уже скорее всего общались и менеджер по продажам и менеджер проекта, но вот настало наше время. Тут опять же есть два пути: общение посредством средств связи (Skype, What`s Up, мобильная связь и т.д.) или же личная встреча. Не буду разбирать здесь плюсы и минусы, мне кажется они очевидны. Однако, если вы не хотите, чтобы во время разбора проходило следующее: «Мне… ы… лось чт…… ы… о.к…», «Вас не слышно» — «А СЕЙЧАС. », то я бы настоял на личной встрече. Опять же ситуации бывают разные, заказчик может быть из другого города, в таком случае выбора у нас нет. Но сейчас нас интересует

Личная встреча

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

Время и место разбора назначены, заказчик ждет вас, как же подготовиться ко встрече? Сейчас я скажу довольно банальные вещи, однако, многие не знают о них, а многие игнорируют, чего делать не стоит. Во-первых, выспитесь перед встречей и поешьте, если вы будете зевать, заказчик ответит вам тем же, поешьте, урчание вашего желудка может и вызовет жалость, но не поспособствует качественному разбору (про одежду и дезодорант писать не буду, думаю и так поня… Хотя нет! Люди, пользуйтесь дезодорантом. ). Во-вторых, возьмите с собой набор чистых листов, пару ручек, ноутбук с материалами, если есть возможность, или, как минимум, пару распечаток того, как выглядит продукт, потому что часто заказчик не представляет себе интерфейса, а ваших художественных возможностей может не хватить. В-третьих, и это самое нарушаемое правило, не опаздывайте, вообще, никогда. Приходите за 15 минут до встречи, чаще всего вам придется проходить через некие проходные, что занимает время, плюс вы успеете сходить в туалет и ваши мысли во время разбора не будут заняты этим.

Все, мы выспались, сытые, пришли вовремя, встреча началась. Наступает еще один важный момент

Установление контакта с заказчиком

Скорее всего, вам предложат кофе или чай, не отказывайтесь, можете даже не пить. А вот от еды откажитесь, не стоит жевать перед заказчиком, а при попытке ответить — усыпать стол крошками. Когда садитесь за стол – постарайтесь сесть напротив человека, с которым будет происходить общение. Если людей несколько, садитесь так, чтобы не оказаться между ними.
При начале общения, поздоровайтесь и представьтесь, они представятся в ответ – запомните имена, это важно. Опишите, вкратце, как будет происходить разбор. В процессе дальнейшего общения вам необходимо будет выделить для себя несколько категорий людей:

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

Вам с самого начала нужно понять в каком ключе идет беседа. Если все крайне серьезно (что на самом деле встречается очень редко, даже у крупных заказчиков), то и вы ведите себя соответственно: не шутите, не отходите от темы, старайтесь как можно больше информации фиксировать. Если обстановка более расслабленная, то тут будут уместны и небольшие шутки из разряда «На ноутбуке не могу показать, вот на вас заработаю миллионы и куплю себе», однако перебарщивать не стоит – это удлиняет время разбора и усложняет возврат в рабочее русло. И тут мы переходим непосредственно к…

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

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

Блок 1. Общая информация. Многие забывают про это и сразу переходят к функционалу, однако, этот этап один из самых важных, как для аналитики, так и для установления контакта с заказчиком. Как же эта информация собирается? Вы просите заказчика самого рассказать о своей компании, и все, большинство собственников бизнеса с удовольствием рассказывают о себе. Тем не менее нам необходимо иногда подталкивать его рассказ в нужное нам русло. И в случае, если заказчик не очень общителен, мы тоже задаем ему эти наводящие вопросы:

• Основные направления деятельности (чем занимаетесь)
• Структура компании (отделы, подразделения, департаменты)
• Сотрудники (количество, качество)
• Можете ли назвать показатели, по которым можно понять успешна ваша деятельность или нет? Измеряете ли вы их?
• Кто ваши клиенты?

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

Блок 2. Нефункциональные требования

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

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

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

Блок 3. Функциональные требования

Это максимально специализированный блок. То есть конкретно под ваш продукт. Как он будет выглядеть в итоге, какие будут функции и т.д. (грубо говоря какого цвета и размера будет кнопка «Решить проблему заказчика»). Если вы технический специалист, то здесь начинается ваша любимая часть.

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

Подведение итогов

Еще раз, вкратце, ВКРАТЦЕ, потому что все устали и вы в том числе, пройдитесь по всем пунктам. Добейтесь согласия от заказчика по каждому из них, потом будет проще. Убедитесь, что ничего не забыли. Далее, если требуется, согласуйте дату следующей встречи, обговорите все дальнейшие действия и запишите их себе. Обменяйтесь с заказчиком контактными данными. Можете вставать и уходить.

Еще немного общей информации. Не делайте встречи более 4-4,5 часов, с учетом перерывов. После четвертого часа вы уже тяжело воспринимает информацию и можете упустить что-то важное или понять неправильно. И все предыдущие 4 часа пойду насмарку. Ничего страшного, если придется провести 2, 3, 4 и т.д. встречи, это лучше, чем месяц согласовывать сдачу проекта.

Вместо заключения

Не бойтесь заказчиков, они боятся вас больше, чем вы их.

В следующий раз немного углубимся в разбор CRM.

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

image

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

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

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

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

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

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

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

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

Преимущества:

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

Интервью

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

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

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

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

Автозапись

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

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

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

Преимущество:

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

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

image

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

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

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

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

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

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

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

Преимущество:

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

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

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

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

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

Преимущество:

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

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

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

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

Преимущества:

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

Обучение

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

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

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

Преимущество:

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

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

image

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

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

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

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

Совещание

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

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

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

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

Use case

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

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

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

Эпилог

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

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

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

Спасибо за внимание!

Авторские материалы о разработке и управлении мы также публикуем в наших соцсетях – ВКонтакте и Telegram.

  • ит-консалтинг
  • управление требованиями
  • аналитика проекта
  • сбор требований
  • Блог компании SimbirSoft
  • Анализ и проектирование систем

10 правил для успешного сбора требований

Elicitation (Выявление) — это деятельность по вытягиванию информации из заинтересованных сторон и других источников.

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

10 правил для успешного сбора требований:
— Не предполагайте, что Вы знаете, что хочет клиент — всегда спрашивайте;
— Привлекайте пользователей с самого начала;
— Сформулируйте и согласуйте рамки (объем) проекта;
— Убедитесь что требования удовлетворяют технике SMART — Конкретные, измеримые, согласованные, реалистичные и имеют временные границы;
— Проясняйте любые сомнения (через общение);
— Создайте четкий, краткий и исчерпывающий перечень документов и поделитесь им с заказчиком;
— Подтвердите Ваше понимание требований компании (воспроизведите их);
— Избегайте разговоров о технологиях или решениях до тех пор, пока требования не будут полностью поняты;
— Получите требования, согласованные с заинтересованными сторонами до начала проекта;
— Создайте прототип, если необходимо подтвердить или уточнить требования заказчика.

Добавить комментарий

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