9.1 Требования
Требования — это главный артефакт бизнес-аналитика. Именно на их основе происходит разработка, и именно здесь сосредоточен наибольший объём работы. В этом видео разбираем, что такое требования, как их классифицировать и почему это важно для каждого проекта.
В видео рассмотрим:
- что такое требование и на чём должен фокусироваться аналитик при работе с ним; четыре типа требований: бизнес-требования, требования заинтересованных сторон, требования к решению и переходные требования
- чем функциональные требования отличаются от нефункциональных, и примеры каждого типа
- явные, скрытые и подразумеваемые требования: как их выявлять; ГОСТ 34.602: зачем он нужен и как помогает унифицировать работу с требованиями; почему классификация требований помогает ничего не упустить в крупных проектах
Видео будет полезно, если вы:
- только начинаете работать с требованиями и хотите разобраться в их типах
- участвуете в проектах с большим количеством заинтересованных сторон
- хотите выстроить системный подход к сбору и документированию требований
- работаете на стыке бизнеса и IT и хотите говорить с обеими сторонами на одном языке
Конспект лекции▾
Требование в бизнес-анализе определяется как пригодное для использования представление потребности, сфокусированное на ценности, которая будет получена в результате его выполнения; оно может быть оформлено как документ или набор документов и может быть явным, скрытым или подразумеваемым — задача бизнес-аналитика состоит в том, чтобы выявить требования во всех этих формах. Выделяют четыре типа требований. Требования бизнеса описывают высокоуровневые цели и задачи организации и формируют основу для последующей работы — например, повышение прибыли за счёт вывода нового продукта или улучшение клиентского сервиса. Требования заинтересованных сторон определяют их ожидания от решения и то, как разные группы пользователей будут взаимодействовать с системой — например, требование, что сотрудник по работе с обращениями должен видеть всю информацию о клиенте и его продуктах.
Требования к решению описывают функциональность системы — что и при каких обстоятельствах она должна делать; они делятся на функциональные, описывающие поведение системы, конкретные действия и данные, которыми она управляет (например, система должна сохранять информацию о клиентах в базе данных), и нефункциональные, задающие ограничения и характеристики — производительность, безопасность, масштабируемость, удобство использования (например, время ответа системы не должно превышать двух секунд). Переходные требования связаны с процессом внедрения решения и описывают переход от текущего состояния к целевому — например, требование обучить сотрудников работе с новой системой. Описание требований в российской практике регламентируется государственным стандартом ГОСТ 34. 602, входящим в комплекс стандартов на автоматизированные системы; он определяет форматы и подходы к описанию требований — структуру документов, терминологию, основные принципы.
Цель стандарта — создать унифицированные правила, позволяющие разработчикам, аналитикам и заказчикам одинаково понимать требования; следование ГОСТ облегчает интеграцию требований в корпоративные процессы, их передачу между командами и проверку на соответствие ожиданиям заказчика. Классификация требований в целом помогает бизнес-аналитику структурировать работу и гарантировать, что ничего не упущено, что особенно важно при большом объёме задач и множестве заинтересованных сторон в проекте.
Ещё больше пользы — в Telegram
Разборы терминов, инструменты для аналитиков и анонсы новых лекций — в канале Open BA.
t.me/open_ba →Прокачайтесь по-настоящему — не просто посмотрите
Видео можно смотреть бесплатно. А в БА Академии курс превращается в тренажёр.
