​​Техники сбора требований к разработке ПО

Прежде, чем начать собирать требования, нам необходимо понимать, что такое требование (1), для чего их собирать (2), выявить всех заинтересованных лиц / стейкхолдеров (3), которые будут пользоваться системой

1️⃣ Требования к ПО- это спецификация того, что должно быть реализовано в системе.
Требования к ПО состоят из трех уровней:
- бизнес-требования
- требования пользователей
- функциональные требования

2️⃣ Сбор требований - это один из самых важных этапов процесса создания любой информационной системы, будь то десктопное, веб или мобильное приложение или же просто доработка уже существующего решения

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

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

Разберем наиболее часто используемые техники:

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

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

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

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

📌Анализ вариантов использования (Use case) это описательный документ, в котором излагается последовательность событий, описывающих использование пользователем системы для достижения определенных целей. Use case описывают поведение системы, предназначенное для разработки, без описания того как это поведение должно быть разработано

📌 Пользовательские истории (User story) это простой подход к сбору требований, который сдвигает фокус с формального документирования требований к разговору, который позволяет проекту быть более восприимчивыми с момента его создания. Пользовательские истории отличаются от вариантов использования тем, что они написаны клиентами

Также есть и другие техники по сбору требований, такие как, воркшоп, семинары, совещания, работа в фокус-группе и тд.

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

Комбинирование методик позволяет повысить эффективность сбора требований, а так же избежать их «потери». При сборе требований необходимо помнить, что важны не только функциональные требования (ЧТО делает система), но и нефункциональные (КАК система это делает)

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