Анализ требований

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

Документы, создаваемые в процессе анализа

Концепция системы / Business Vision

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

Бизнес-требования / BRD

За этим следует серия уточняющих интервью, в которых заказчик развивает свою идею. Уточняется и углубляется понимание проблем, которые система должна решать. Результирующий документ мы называем бизнес-требования или BRD (Business Requirements Document).

Функциональные требования / FRD

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

Появляется документ, который содержит функциональные требования — FRD (Functional Requirements Document). Часто его называют техническим заданием (ТЗ). Это наш главный документ, являющийся фундаментом будущей системы. В документе, как правило, присутствуют:

— Общий список компонентов системы.

— Для каждого компонента — детальное описание его функций.

— Сценарии использования системы различными пользователями.

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

План тестирования / Test Plan

План тестирования необходим для команды тестировщиков и составляется на основе FRD и других сопутствующих документов (примеры дизайна, протокол взаимодействия с сервером и прочее). Цель данного документа – ответить на 3 главных вопроса: что, как и когда будет тестироваться, иначе говоря:

— какие компоненты системы будут тестироваться

— какие виды тестов будут проводиться и что должно быть для этого сделано

— в каком порядке будут выполняться тесты

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

Риски / Risk List

Зачастую вместе с FRD составляется специальный документ — список рисков. В документе учитываются основные риски, которые могут повлиять на разработку системы в заданный срок. Указываются способы реагирования на те или иные риски. Список рисков — это ответы на множество вопросов «А что будет, если?», включающий самые пессимистичные сценарии разработки и внедрения системы. Документ этот, являясь внутренним, может быть интересен и для заказчика.

Зачем это нужно?

Работа аналитиков стоит денег. А зачем все это нужно заказчику? Документы бизнес-уровня (BRD) позволяют провести первоначальную оценку стоимости проекта и выявить организационные риски. Функциональные требования (FRD) позволяют нам сформировать точную оценку стоимости проекта и выделить технические риски. FRD также служит краеугольным камнем при тестировании системы и разрешении всех спорных вопросов между заказчиком и исполнителем. Именно поэтому FRD написан максимально точным, формальным языком — прежде всего с целью избежать двусмысленного толкования.

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