В данном разделе мы познакомимся с ключевыми техниками сбора требований:

1. Препятствия на пути сбора требований
2. Ключевые техники
   
   • Планирование извлечения требований
   • Анализ документации
   • Интервьюирование (Interviews)
   • Семинар (Requirements Workshop)
3. Структурирующие техники
   
   • Контекстная диаграмма
   • Бизнес-моделирование (Business Modeling)
   • Прототипирование (Prototypes)
   • Словарь Данных
   • Мозговой штурм (Brainstorming & Idea Reduction)

Основные препятствия при выявлении требований и потребностей связаны с тем, что заинтересованные лица не являются экспертами в области решения.

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

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

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

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

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

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

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

Первая группа — так называемые ключевые техники. Они названы ключевыми, потому что они являются контекстом или средой, в которой применяются другие техники.

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

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

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

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

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

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

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

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

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

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

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

Техники, которые относительно редко используются, и которые мы не будем
рассматривать в данном курсе:

• проведение стратегических сессий, которые позволяют установить организационный контекст для систем, которые мы создаем, определить основные цели, которые стоят перед заказчиком.
• Role Playing — набор техник, которые позволяют нам имитировать работу с будущей системой, либо с использованием бумажных прототипов, либо вообще мысленный эксперимент в отношении того, как будут взаимодействовать люди при работе с нашим продуктом или нашей системой. Зачастую ролевые игры даже применяются внутри команды разработки, когда отдельным разработчикам или сотрудникам назначаются роли того или иного заказчика.
• Последний и, наверно, один из самых неоднозначных пунктов с точки зрения техник извлечения требований – это вопросники. Одна из основных особенностей вопросников в том, что техника кажется очень легкой в исполнении.

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

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

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

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

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

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

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

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

И последний этап, связанный с любым планированием – необходимо оценить те
риски, те последствия, которые возникают из-за принятых решений.

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

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

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

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

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

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

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

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

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

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

Одна из наиболее простых, самых распространённых и, наверно, самых недооцененных техник извлечения требований – это анализ документации.

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

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

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

Две основных цели анализа документации – 1) сократить время и повысить уважение заказчика к аналитикам или разработчикам, которые с ним работают; 2) получить ту информацию, которой уже, возможно, никто из представителей заказчика не обладает или еще не обладает.

Основные шаги по реализации анализа документации:

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

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

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

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

Один из самых важных процессов, который происходит при сборе, извлечении
требований – это проведение интервью.

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

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

Основные шаги, которые необходимо предпринять для того, чтобы интервью было
эффективным:

• Сформировать полный перечень заинтересованных лиц и пользователей, с которыми мы собираемся провести интервью. В каждой группе пользователей, необходимо выделить, как правило, двух специалистов, с которыми будем проводить интервью (один специалист предоставит нам однобокий или, возможно, специфический взгляд на проект).
• Необходимо учитывать, что, скорее всего, в процессе первичных интервью у нас появятся кандидаты на дополнительное интервьюирование. Дополнительный список интервью обычно составляет около 50% от первичного.
• К каждому интервью необходимо подготовить цели (ради чего мы встречаемся с данным конкретным человеком), и вопросы, которые мы собираемся ему задать.
  В больших структурах представители заказчика часто уже настолько издерганы и замучены различными компаниями, которые для них что-то реализовывают, что если вы не пришлете им заранее список вопросов, на которые им необходимо будет ответить, и вопросы, которые вы хотите решить, то, возможно, они даже не будут с вами встречаться.
• Согласовать календарь встреч. В календаре встреч нужно учесть время, которое вам необходимо для первичного интервью, и заранее оговорить возможность встретиться с этим человеком позднее (учесть возможность повторного интервью).
• Проведение интервью. В отдельном уроке остановимся на этом вопросе и рассмотрим более детально.
• Обработка материалов интервью. Люди очень часто планируют время на осуществление взаимодействия, но не планируют времени на то, чтобы обработать информацию.

При оценке затрат времени по извлечению требований необходимо запланировать в
среднем 3-4 часа времени для каждого интервьюируемого специалиста. При этом не
играет принципиальной роли, будет интервью длиться 20-30 минут или до часа. И в том, и другом случае вам потребуется готовиться к интервью, проводить интервью и
потратить дополнительное время на обработку результатов или выполнение договоренностей, достигнутых в процессе интервью: получить какие-то дополнительные материалы заказчика или, наоборот, направить ему соответствующие материалы.

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

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

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

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

Чтобы избежать "челночных" переговоров, можно применять специальную форму групповой работы, которая называется Requirements Workshops, или совместная сессия работы над требованиями. В рамках работы в группе мы:

• Ускоряем процесс сбора требований. Мы помещаем представителей заинтересованных лиц в одну среду, в которой происходит одновременный обмен мнением и валидация тех или иных предположений.
• Когда мы собираем большое количество заинтересованных сторон в одном месте, одна из важнейших и сложных задач – обеспечить эффективную работу людей всех вместе. Многие знают по собственному опыту, что как только на собрании собирается 5-7 человек, результатов у такого совещания, как правило, бывает немного. Через час-два после начала работы люди переходят в конфликтные позиции, и решить те или иные вопросы зачастую не удается. Для того, чтобы этого избежать, необходимо, чтобы ведущий такого Workshop'а осуществлял фасилитацию, или управление процессом.

Requirements Workshops – это мероприятие, которое должно быть спланировано заранее, в котором идет подготовка, который модерируется и управляется.

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

Среднестатистическое время, необходимое, чтобы провести небольшой Workshop на 3-4 человека — 8 часов.

Если это действительно масштабное мероприятие, то уйдет как минимум один-два рабочих дня на его подготовку и, в зависимости от того, что мы делаем, либо 4-х часовая, либо двухдневная сессия. Двухдневная сессия – это достаточно большая редкость, тем не менее, для больших продуктов с большими направлениями 2 дня бывает в самый раз.

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

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

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

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

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

Это – основной инструмент определения границ и достижения полноты требований к системе.

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

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

И последний шаг – обозначить характер взаимодействия системы со всеми выделенными ранее внешними объектами.

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

На создание контекстной диаграммы в коммерческом проекте я рекомендую резервировать от 4 до 16 часов, в зависимости от сложности решения.

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

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

Бизнес-моделирование применяют во многих случаях.

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

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

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

И последнее применение, которое делает работу над бизнес-моделированием отдельной дисциплиной и в котором реализовано большое количество различных подходов и отдельных внутренних техник – реинжиниринг бизнес-процессов. Реинжиниринг бизнес-процессов – это классическая работа по модели: перейти от ситуации, как она есть, к ситуации, как она должна быть (As Is и To Be). Мы можем сформировать модель процессов как есть и определить модель процессов, как это должно быть. Революционное изменение или значимый эффект от внедрения информационных систем, как правило, невозможен без пересмотра того, как осуществляется деятельность организации.

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

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

Для того, чтобы это сделать, нам потребуется эксперт в предметной области, который разбирается в бизнес-процессах организации. Чтобы сформировать модель As Is, понадобится эксперт в области существующего решения, а чтобы сформировать модель To Be, – специалист в области технологий, которые мы собираемся применить, и тех возможностей, которые может нам дать информационная технология, и которая потребует изменение бизнес-процессов.

Бизнес-моделирование достаточно редко применяется. В одном из 10 - 15 проектов встречаются те или иные аспекты моделирования бизнес-процессов или бизнес-моделирование.

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

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

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

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

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

На разработку глоссария, проработку словаря данных необходимо планировать от 2 до 40 часов работы, в зависимости от количества информационных объектов и понятий для глоссария. Чем дольше и больше мы работаем в определенной предметной области, тем более полный глоссарий у нас есть на начальном этапе проекта. Всё, что нам необходимо сделать — это добиться того, чтобы те данные, тот глоссарий, который мы черпаем из предыдущего опыта, прошел проверку экспертом со стороны заказчика.

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

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

В мозговом штурме может участвовать от 5 до 20-30 человек. Конечно, 20-30 человек на мозговом штурме – это достаточно сложная задача, но, как правило, мозговой штурм применяется в контексте RequirementsWorkshop, как один из этапов для растормаживания работы группы, для того, чтобы обеспечить наиболее оптимальное включение участников.

На всякий случай, напомню основные принципы и правила применения мозгового штурма.

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

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

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

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

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

Для того, чтобы исследовать и понять, что необходимо нашим заказчикам, мы можем использовать достаточно большой арсенал техник: мы можем использовать интервьюирование, семинар, прототипирование. Наверно, три самых основных техники, которые применяются в небольших проектах – это интервьюирование и прототипирование, и техника применения Workshop'ов и семинаров – в больших и крупных проектах.

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

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

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

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