Основные способы выявления требований

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

Интервью

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

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

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

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

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

Весьма плодотворным является метод исключений. Что мешает пользователю успешно выполнить задачу? Как система должна реагировать на различные, ошибочные условия? Задавайте вопросы, начинающиеся со слов: «Что еще могло бы...», «Что произойдет, когда...», «Вам когда-нибудь требовались...», «Где вы получаете...», «Почему вы делаете (или не делаете)...» и «А кто-нибудь когда-либо...».

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

Специалисты рекомендуют использовать бесконтекстные вопросы, узкоспециализированные вопросы и вопросы, допускающие разные толкования, чтобы выявить информацию о бизнес-проблемах и их возможных решениях. Реакция пользователей на такие вопросы, как «Какой уровень точности необходим в продукте?» или «Почему вы не согласны с предложенным ответом?», иногда более информативна, чем информация, получаемая в ответах на вопросы типа «да/нет» или «А/В/С».

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

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

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

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

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

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

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

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

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