День 1927. #УрокиРазработки
Уроки 50 Лет Разработки ПО

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

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

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

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

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

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

Вы можете дополнять, а иногда и полностью заменять письменные требования различными представлениями: визуальными моделями, прототипами, макетами экранов, таблицами, математическими выражениями и диаграммами. Диаграммы позволяют иллюстрировать потоки процессов, отношения между данными, навигацию по UI, состояния системы и переходы между ними и многое другое.
Но ни одна диаграмма не в состоянии показать всё, что нужно знать о программной системе. Каждая отражает лишь часть знаний с определённой точки зрения. Бизнес-аналитикам нужно выбирать подходящие модели с учетом того, какую информацию должна получать их аудитория.

Существует множество стандартных обозначений для анализа диаграмм и моделей, в том числе:
- структурированный анализ;
- IDEF0;
- унифицированный язык моделирования (Unified Modeling Language, UML);
- язык моделирования требований (Requirements Modeling Language, RML).

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

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

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.