Из смутных представлений – в четкие спецификации

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

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

Способы выявления и извлечения требований

Могут применяться различные способы сбора информации:

• интервью;

• семинары;

• анализ документов;

• опросы;

• посещение рабочих мест клиентов;

• анализ бизнес-процессов;

• анализ документооборота и задач;

• списки событий;

• анализ конкурирующих продуктов;

• исследование существующих систем;

• ретроспективы развития предыдущего проекта.

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

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

Интервью

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

Основные моменты при проведении интервью:

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

• Задавайте контекстно-свободные вопросы – вопросы, которые не предполагают какого-либо конкретного ответа и заставляют интервьюируемого говорить о проблеме. Например, вопрос «Кто использует систему?» является контекстно-свободным и способствует обсуждению, тогда как вопрос «Систему используете вы?» предполагает ответ «Да/нет» и заканчивает дискуссию.

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

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

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

Анкеты

Анкеты не заменяют интервью.

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

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

Навыки, необходимые аналитику

• Умение слушать

• Умение опрашивать и задавать вопросы

• Навыки анализа

• Навыки создания комфортных условий общения

• Умение наблюдать

• Навыки написания документации

• Организационные навыки

• Навыки моделирования

• Навыки межличностного общения

• Творческий подход

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

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

Выработка требований – итеративный процесс

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

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

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

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

На разработку требований в успешных проектах тратится от 10 до 30 % ресурсов

Менеджеров проекта часто интересует, сколько времени и усилий понадобится для разработки требований. Для небольших проектов этот этап обычно стоит от 12 до 15% всех затрат, однако показатель зависит от объема и сложности проекта. Несмотря на опасения, что работа над требованиями замедлит создание продукта, доказано, что понятные требования ускоряют процесс разработки, что и показывают следующие примеры:

• изучение 15 проектов в сфере телекоммуникаций и банковской сферы показало, что в наиболее успешных проектах примерно 28% ресурсов тратилось на разработку требований: 11% — на сбор информации по требованиям, 10% — на моделирование, а 7% на проверку и утверждение. На разработку требований для среднего проекта необходимо 15.7% всех ресурсов и 38.6% времени;

• в проектах NASA, в которых затрачивалось более 10% всех ресурсов на разработку требований, затраты и отклонения от графика оказались существенно ниже, чем в проектах, где на требования затрачивалось меньше ресурсов;

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

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

Тестирование и требования

Тестирование и разработка требований связаны синергетически. Чем лучше требования, тем качественнее тесты.

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

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

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

• Образ и границы проекта.
  Расползание границ становится более вероятным, если у лиц, заинтересованных в проекте, нет ясного, единого мнения о том, что продукт должен из себя представлять (и не представлять) и делать.

• Время, затраченное на разработку требований.
  Жесткие сроки проекта часто заставляют менеджеров и клиентов пренебрегать составлением требований; они считают, что если программисты не начнут работать над кодом немедленно, то не закончат вовремя. Проекты широко варьируются в зависимости от размера и класса приложения (например, информационные системы, системное ПО, коммерческие или военные), но по самым грубым прикидкам стоит расходовать не менее 10-15% ресурсов проекта (до 30% в ряде случаев) на действия по разработке требований.

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

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

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

• Несформулированные требования.
  У клиентов часто есть скрытые ожидания, о которых они не сообщают, и поэтому те не документируются.

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

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

Риски при создании спецификации требований

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

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

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

Утверждение требований

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

Требования – фундамент успеха

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

Хорошо проработанные требования позволяют:

• выработать общее понимание между заказчиком и разработчиком;

• определить рамки проекта;

• более точно определить финансовые и временные характеристики проекта;

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

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

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

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

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

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

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

• определение границ системы

• определение интерфейса между пользователями и системой.

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