Путь от бизнес-требований до функциональных в процессе разработки ПО

«Самая сложная часть разработки систем — решить, что именно создавать» (Ф. Брукс).

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

Бизнес-требования – это метрики, которых заказчик планирует добиться благодаря внедрению цифрового продукта. Но как перевести бизнес-цели на язык программного обеспечения? Для этого аналитик перерабатывает бизнес-требования в функциональные требования.

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

Таким образом, всем участникам разработки от заказчика до команды необходимо понимать как применять те или иные требования, а значит в нашей сегодняшней статье мы узнаем: какова роль бизнес-требований и какими они бывают, какие методы сбора бизнес-требований практикуются в реальных проектах, как аналитик анализирует бизнес требования и переводит их на язык ПО, в чём разница и польза функциональных и нефункциональных требований и как максимально эффективно согласовать ТЗ?

Роль бизнес-требований

Правильно сформулированные и реалистичные бизнес-требования играют ключевую роль в соблюдении баланса между эффективностью ПО и затрачиваемыми на него ресурсами.

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

Основные характеристики бизнес-требований

Долгосрочная перспектива:

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

Фокус на бизнес-цели:

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

Связь с миссией и видением:

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

Инновационность и конкурентные преимущества:

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

Примеры грамотно сформулированных бизнес-требований на основе разных целей

1. Увеличение рыночной доли: компания может поставить перед собой цель занять большую долю на конкретном рынке путём расширения клиентской базы или улучшения предложения.

Пример: «Захватить 20% рынка к концу следующего финансового года».

2. Повышение эффективности операций: улучшение внутренних процессов для сокращения затрат и повышения качества обслуживания.

Пример: «Сократить среднее время реакции на обращения с 2 часов до 30 минут».

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

Пример: «Увеличить прибыль на 10% за счет внедрения новой модели монетизации».

4. Расширение географии присутствия: выход на новые рынки или расширение существующих рынков сбыта.

Пример: «Осуществить запуск продукции в пяти новых странах Европы к концу текущего года».

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

Пример: «Создать технологию, позволяющую снизить себестоимость производства на 30%, что обеспечит значительное преимущество перед основными конкурентами».

Сбор бизнес-требований

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

1. Интервью

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

Подходы:

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

Преимущества:

- Личное общение позволяет глубже понять контекст и тонкости потребностей.

- Возможность уточнять неясные моменты прямо в процессе разговора.

Недостатки:

- Может занимать много времени.

- Результаты зависят от квалификации интервьюера и вовлеченности респондента.

2. Анкетирование и опросы

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

Особенности:

• Анкеты могут содержать закрытые (выбор из вариантов), полузакрытые (с возможностью добавления комментариев) и открытые вопросы.
• Удобство проведения через онлайн-сервисы (например, Google Forms).

Преимущества:

- Экономия времени.

- Легкость обработки больших объемов данных.

- Анонимность, что иногда способствует большей откровенности респондентов.

Недостатки:

- Невозможно уточнить ответы в случае двусмысленности.

- Отсутствие живого общения снижает глубину понимания потребностей.

3. Анализ документов и спецификаций

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

Виды документов:

• Технические задания.
• Пользовательские сценарии.
• Отчеты о проблемах и инцидентах.
• Исторические данные по использованию аналогичных продуктов.

Преимущества:

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

- Эффективен для выявления скрытых проблем и возможностей оптимизации.

Недостатки:

- Документы могут устареть или быть неполными.

- Требует времени на тщательное изучение и сопоставление различных источников.

4. Обзор рабочих процессов (Job Shadowing)

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

Как проводится:

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

Преимущества:

- Получение наглядной картины работы пользователей.

- Выявление реальных проблем и неэффективностей.

Недостатки:

- Требуется значительное количество времени.

- Возможны субъективные интерпретации наблюдателя.

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

Как мы уже выяснили, функциональные требования – это перечень функций продукта, направленных на удовлетворение бизнес-требований. Таким образом, если бизнес-требование звучит так: «Сократить среднее время реакции на обращения с 2 часов до 30 минут». Функциональное требование будет описывать функцию способную автоматизировать процесс ответа на обращение клиента.

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

Моделирование

Моделирование – это процесс создания абстрактной модели, представляющей ключевые аспекты будущей системы. Этот метод помогает визуализировать структуру и поведение системы до её реализации. В зависимости от целей и контекста используются различные виды моделей:

Основные типы моделей:

• Диаграммы потоков данных (DFD) – показывают потоки данных между различными компонентами системы и пользователями.
• ER-диаграммы (Entity Relationship Diagram) – отображают отношения между сущностями базы данных.
• UML-диаграммы (Unified Modeling Language) – семейство диаграмм, включающее, например, диаграммы классов, последовательности, состояний и другие, которые помогают описать архитектуру системы, взаимодействие компонентов и состояния объектов.
• Бизнес-процессы (BPMN, IDEF0) – описывают последовательность действий, выполняемых системой для достижения определённых бизнес-целей.

Преимущества моделирования:

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

- Помогает выявить пробелы и несоответствия в требованиях.

- Упрощает коммуникацию между командой разработчиков и заказчиком.

Прототипирование

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

Типы прототипов:

• Низкоуровневые прототипы (low-fidelity prototypes) – простые наброски интерфейса, часто сделанные вручную или с использованием базовых инструментов.
• Высокоуровневые прототипы (high-fidelity prototypes) – детально проработанные интерактивные прототипы, близкие к финальному продукту.

Преимущества прототипирования:

- Быстрое получение обратной связи от пользователей.

- Возможность тестирования различных вариантов дизайна и функционала.

- Экономия ресурсов на ранней стадии проекта.

Техническое задание (ТЗ)

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

Структура технического задания:

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

Преимущества технического задания:

- Четкое определение ожиданий заказчика.

- Юридическая основа для взаимодействия между сторонами.

- Удобство для контроля качества и соответствия требованиям.

Согласование требований

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

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

Разработка ПО от 66 Бит

Поздравляем чемпионов, дошедших до конца! Теперь вы знаете всё о требованиях, их грамотной формулировке и эффективном согласовании. Дело за малым – применить полученные знания на практике. А чтобы быть уверенным в качестве будущего продукта, обращайтесь в компанию 66 Бит! Наши опытные специалисты поддержат и воплотят в жизнь ваши идеи и помогут максимально эффективно реализовать любое бизнес-требование. Подробнее читайте на сайте.