2022-04-21 12:02:20
Техники сбора требований к разработке ПОПрежде, чем начать собирать требования, нам необходимо понимать, что такое требование (1), для чего их собирать (2), выявить всех заинтересованных лиц / стейкхолдеров (3), которые будут пользоваться системой
Требования к ПО- это спецификация того, что должно быть реализовано в системе.
Требования к ПО состоят из трех уровней:
- бизнес-требования
- требования пользователей
- функциональные требования
Сбор требований - это один из самых важных этапов процесса создания любой информационной системы, будь то десктопное, веб или мобильное приложение или же просто доработка уже существующего решения
Стейкхолдеры - это физическое или юридическое лицо, группа лиц, чьи действия и решения могут влиять на деятельность бизнеса, процессы в нем и прибыль. К стейкхолдерам относятся поставщики, сотрудники, акционеры, клиенты и другие стороны, которые напрямую заинтересованы в работе компании и ее результатах или имеют возможность воздействовать косвенно.
Теперь разберемся с
техниками сбора требований. Не существует единственной техники, которой можно собрать абсолютно все требования к продукту. Для каждого этапа детализации потребностей подходит одна конкретная техника или комбинация нескольких.
Разберем наиболее часто используемые техники:
Интервьюирование - проходит один на один со сстейкхолдером в форме свободной беседы, в офлайн или онлайн формате. Прежде чем назначить встречу необходимо подготовить тему разговора и список вопросов, и направить собеседнику, чтобы он тоже подготовился. Интервью помогает детализировать понимание глобального вопроса, разбить общую тему на отдельные задачи, уточнить требования конкретного стейкхолдера к проекту
Мозговой штурм - метод решения задач, в котором участники обсуждения генерируют максимальное количество идей решений задачи, в том числе самые фантастические и глупые. Обычно используется для определения возможных решений проблем и уточнения деталей возможностей
Прототипирование - это техника для построения быстрой и приблизительной версию желаемой системы или части этой системы. Прототип демонстрирует возможности системы пользователям и дизайнерам. Прототип представляет механизм связи, позволяющий рецензентам, понять взаимодействие внутри системы
Анализ существующей документации - Данная методика может быть использована при наличии в организации документации, которая может помочь в определении потребностей Заказчика. Примеры документации включают в себя: регламенты,
описания процессов, структура организации, спецификации продукта, различные процедуры, стандарты и инструкции, шаблоны документов и т.д.
Анализ вариантов использования (Use case) это описательный документ, в котором излагается последовательность событий, описывающих использование пользователем системы для достижения определенных целей. Use case описывают поведение системы, предназначенное для разработки, без описания того как это поведение должно быть разработано
Пользовательские истории (User story) это простой подход к сбору требований, который сдвигает фокус с формального документирования требований к разговору, который позволяет проекту быть более восприимчивыми с момента его создания. Пользовательские истории отличаются от вариантов использования тем, что они написаны клиентами
Также есть и другие техники по сбору требований, такие как, воркшоп, семинары, совещания, работа в фокус-группе и тд.
----------------------
Комбинирование методик позволяет повысить эффективность сбора требований, а так же избежать их «потери». При сборе требований необходимо помнить, что важны не только функциональные требования (ЧТО делает система), но и нефункциональные (КАК система это делает)
Тщательно собранные требования минимизируют риски проекта, т.к. позволяют сформировать четкий и понятный базис для разработки системы
1.2K views09:02
B
