9.5 Документирование требований

Документирование бизнес-требований определяет точность коммуникации между бизнесом и исполнителями. Классический формат — текстовый документ бизнес-требований (БТ), создаваемый в любом редакторе и включающий цели проекта, термины и определения, а также описание проектируемого решения и процесса; это наиболее полный формат. В составе БТ выделяются функциональные требования (описывают необходимые процедуры, реакции системы, сущности, таблицы и атрибуты, которые нужно создать или доработать) и нефункциональные требования (отвечают за производительность и доступность функционала, учитываются при проектировании инфраструктуры). Пользовательская история (user story) — краткий формат для agile-методологий, фиксирующий потребность пользователя в одном предложении по схеме «тип пользователя — функциональность — цель», например: «как пользователь мобильного банка, я хочу скачивать чеки по операциям, чтобы предоставлять их как подтверждение оплаты».

User story должна соответствовать критериям INVEST: быть независимой, обсуждаемой, ценной, оцениваемой, небольшой и тестируемой. Структура истории включает намерение о получаемой ценности (тип пользователя, функциональность, цель), критерии приёмки (действия пользователя и ответ системы, выполнимые за один спринт) и критерии завершённости (контрольный список мероприятий); каждая история оценивается, чаще всего в условных единицах по ряду Фибоначчи. Сценарий использования (use case) — более детализированный формат, применимый как в agile, так и в водопадных методологиях; описывает последовательность действий пользователя и системы, ведущую к цели (например, оформление заказа в интернет-магазине: выбор товара, корзина, оплата, подтверждение). Структура use case включает действующих лиц, предусловие (стартовое состояние, например прохождение идентификации), задействованные системы, основной сценарий, постусловия (зафиксированный результат) и альтернативные сценарии (реакция на сбои).

Критерии качества use case: простой язык без сложных терминов, достаточная детализация, структурированность (детали — в приложении), разбиение процесса на самостоятельные этапы и обязательное описание альтернативных сценариев. Преимущества use case — проработка всех путей процесса, единое понимание для команды, упрощённая передача знаний новым участникам, фиксация принятых решений и возможность проверки корректности внедрения; недостаток — метод не подходит для сбора нефункциональных требований. Уровень детализации документа определяется составом читателей и должен отвечать в том числе на технические вопросы, например формат поля ввода телефона, что напрямую влияет на скорость вывода решения на рынок.