Дарья Левашова

Как проводить анализ требований?



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

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

У каждого опытного аналитика (а, возможно, и на уровне компании) есть свой собственный выработанный подход к анализу требований, обкатанный на практике, успехах и ошибках, который будет включать те или иные методики, алгоритм работы, шаблоны документации и артефактов.
Но, к сожалению, не существует серебряной пули и универсального подхода, с которым можно гнать, как под копирку, анализ требований в любых проектах / командах / заказчиках / ИТ-ландшафтах.
Давайте на примере
Если попытаться уйти от сухой теории и философии, я бы выделила несколько этапов анализа требований.

Хотя.. подождите, вначале, чтобы анализировать требования, необходимо их выявить и собрать. Поэтому начнем от печки.
Этап 0. Выявление и сбор требований
В зависимости от типа компании работа на данном этапе может значительно отличаться.

Если компания продуктовая, типа стартапа, где основатель является профессионалом в какой-то сфере и основателем идеи/продукта; или проектный консалтинг, где существует заказчик системы и подрядчик-исполнитель, тогда всегда найдутся стейкхолдеры или product owner, от которых, так или иначе, будут исходить требования.

Но, помимо старого-доброго энтэрпрайза и продуктовых стартапов, существуют, назовем их, "интернет" компании, основной бизнес которых ведется в интернете. Например: Фэйсбук, Букинг, Инстаграм.
В таких компаниях зачастую нет аналитиков требований, потому что требования не приходят извне и не привносятся какими-либо экспертами в определенной области.
Бизнес-аналитиков тогда заменяют data-аналитиками, которые на основе анализа больших объемов данных выявляют закономерности, собирают статистику, анализируют показатели и, затем, формулируют требования к системам, которые затем передаются непосредственно разработчикам.

Методы сбора и выявления требований в таких фирмах совершенно иные и требуют специальной квалификации и знаний. Таких как:

- SQL
- Python
- R
- Tableau
- Metabase и много чего другого…
Для простоты рассмотрим пример привычной всем схемы, в которой присутствует непосредственный источник требований:
Я, начальник маркетингового отдела, хочу запустить маркетплэйс. Т.е. хочу вебсайт, где наши клиенты могут покупать что-то и получать бонусы с покупок.
С чего и как начинать анализ, когда вы получили такое требование?
Этап 1. Уточнение требований
Каждое слово в требовании должно быть максимально понятно для всей команды: от менеджеров и до разработчиков.
Чтобы этого добиться, надо задавать вопросы, много вопросов…но по делу!..
Почему мы хотим именно маркетплэйс? Может достаточно внедрить какие-то скидки или акции для пользователей?

— Почему вебсайт, а не мобильное приложение или дополнительная фича в имеющейся системе?

— Каков формат бонусов: бонусные очки или кэшбэк?

— Что именно можно покупать через такой маркетплэйс? Какие товары?

— Кто пользователи? Кто такие "наши клиенты" (какие-то определенные группы клиентов)?

— Кто будет администрировать сайт/платформу/процесс?

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

Инструменты и методы:

- Интервьюирование/анкетирование/опросы заказчика
- Мозговой штурм
- Root Cause Analysis
- 5 Why's
- Mind Maps
- Выявление и оценка заинтересованных лиц
- Оценка рисков проекта
- Определение и формализация границ проекта и скуп (что делаем, а не что не делаем)… и другие…
Этап 2. Анализ ситуации As-Is и To-Be
В разрезе бизнес процессов, текущего состояния и видения системы (желаемого результата), а также целей проекта.
В нашем примере (очень обобщенно):
AS IS: что есть сейчас? Какой процесс? Какие проблемы?
В компании нет никакой системы скидок и бонусов. Так как подписки на услуги дороже, чем у конкурентов, наши клиенты не хэппи.
TO BE: Каков желаемый процесс? Какие преимущества хотим получить?
Пользователь заходит в маркеплейс, совершает покупку, получает бонусы, которые будут потрачены, как скидка за подписку на наши услуги.
Таким образом мы сможем повысить лояльность клиентов и конкурентоспособность фирмы.
Инструменты:
- As-Is / To-Be анализ
- различные системы моделирования бизнес процессов и систем: BPMN, ARIS
- UML… и другие…
Этап 3. Декомпозиция бизнес-требований до уровня функций (фич)
Разбиение требований верхнего уровня (бизнес-требований или комплексных системных требований, определенных на шагах 1 и 2) на более мелкие и четкие требования к целостным функциям/фичам.
В нашем примере:
- Аутентификация и логин в маркетплэйс
- Совершение покупки
- Расчет и зачисление бонусов
- Списание бонусов в счет ежемесячного платежа

Инструменты:
- users stories
- use cases
- UML (use case and activity diagrams, systems components diagram) … и другие…

Этап 4. Декомпозиция функциональных требований до уровня системных
Это может быть:
- детальное описание отдельных функции, компонентов системы,
- описание технических требований к инфраструктуре, производительности - нефункциональные требования,
- системный дизайн, включая UI/UX требования, Back-end и описание логики, основных объектов базы данных и т.п.

При описании объектов системы полезно помнить про CRUD операции с объектами системы и проверять наличие и полноту требований к каждой операции.

Инструменты:
- UML (sequence diagram, objects and class diagrams, DB schemas)
- инструменты для дизайна прототипов интерфейса и экранных форм

Выводы
Анализ требований - это как анализ анамнеза пациента врачом. Это процесс уникальный для каждого случая, хотя может включать в себя стандартные и формальные этапы:
1
Cбор требований
2
Уточнение и описание (документирование) требований
3
Различные проверки на полноценность
4
Выявление зависимостей и трассировка требований
5
Проверка на техническую реализуемость и непротиворечивость
Тестирование требований с вопросами "а что если так? а что если иначе?"
6
Декомпозиция требований
И, хотя можно выделить базовые шаги, но в реальной жизни множество нюансов и исключений внесут свои поправки в работу.

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

Итак, мой ответ на вопрос: "Как проводить анализ требований?" - думать, копать в детали, спрашивать, искать истинные причины и зависимости, находить несоответствия и их устранять, описывать, моделировать, согласовывать, декомпозировать от общего к частному и собирать картинку обратно до уровня целостной системы.
Повторять все вышеперечисленное до тех пор, пока не будет найден консенсус с заказчиком и заинтересованными лицами, командой разработки и всеми остальными, которых так или иначе затронут изменения.
Дарья Левашова
Ссылка на VK


Made on
Tilda