Как стать настоящим аналитиком? Часть 2. Выявляем требования

Доброе время суток, дорогие читатели! Данная статья является продолжением топика ^[1], и в ней хотелось бы начать обсуждение стадии создания требований. Если вы успешно справитесь с этой стадией процесса, вы получите отличный продукт, счастливых заказчиков и удовлетворенных разработчиков. В противном случае вам грозит непонимание, разочарование и разногласия.

Стадию создания или разработки требований условно можно разделить на 4 этапа.

1. Выявление требований (сбор информации).
2. Анализ требований.
3. Спецификация (документация) требований.
4. Проверка требований.

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

Выявление требований — самый трудный, важный, подверженный ошибкам и требующий интенсивного общения этап разработки ПО.
Выявление требований – это творческий процесс, и каждый использует свои инструменты для получения результата, т.е. требований. В моем багаже есть такие методы, которые я называю «Классика», т.е. это те приемы, которые срабатывают в 90% случаев. К традиционным методам выявления требований относятся использование интервью и анкет, наблюдение и изучение деловых документов. Это простые и экономичные методы. Надеюсь, опытные читатели дополнят список своими.

Разделение пользователей на группы

Чтобы не упустить из виду потребности отдельных пользователей необходимо:

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

ИМХО: Выбирайте не тех людей, кто болтает много, а тех, кто говорит по существу.

Работа с пользователями для выяснения требований к продукту

1. Анкетирование/ Интервьюирование

Выясните у пользователей, какие задачи им требуется выполнять средствами ПО. Обсудите, как должен клиент взаимодействовать с системой для выполнения каждой такой задачи. Используйте в своей беседе следующие вопросы: Что мешает пользователю успешно выполнить задачу? Как система должна реагировать на различные ошибочные условия? Что произойдет, когда? Вам когда-нибудь требовались?, Где вы получаете?, Почему вы делаете (или не делаете)? и А кто-нибудь когда-либо?
Правильно сформулированные вопросы заставляют собеседника задуматься, помогают сосредоточиться на конечном результате, заполняют неловкое молчание, подсказывают новый поворот разговора и помогают наладить контакт с собеседником.
Умение задавать вопросы – это полезная технология, освоение которой может оказать неоценимую поддержку в работе. На просторах интернета много материала по данной теме, не поленитесь ее изучить!
После каждого интервью документируйте информацию, которая обсуждалась, и попросите участников просмотреть список и внести исправления. Просмотр на ранних стадиях необходим для успешного сбора требований, поскольку только те люди, которые эти требования предоставили, могут судить, правильно ли они зафиксированы.

2. Наблюдение

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

3. Проведение совместных семинаров

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

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

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

1. пользователи уже не могут придумать новые варианты использования.
2. пользователи предлагают новые варианты использования, однако вы уже вывели соответствующие функциональные требования из других вариантов использования.
3. пользователи описывают проблемы, которые уже обсуждались;
4. предлагаемые новые функции выходят за рамки проекта;
5. пользователи предлагают возможности, которые имеет смысл реализовать когда-то позже.

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

Литература:

Карл Вигерс «Разработка требований к программному обеспечению»

Автор: analista

Источник ^[2]