top of page

BA Q&A: Типы запросов на изменение требований

Решил публиковать некоторые вопросы и ответы, обсуждаемые на «Комплексном онлайн тренинге по бизнес-анализу»

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

Ответ: Во-первых, нам нужно понять, для чего мы используем эту классификацию. Это может быть обусловлено особенностями контракта: запрос на изменение оплачивается из одного бюджета, запрос на новую функциональность из второго, расширение – из третьего. Или мы хотим понять, насколько качественно бизнес-аналитик провел выявление требований, предполагая, что запрос на изменение = некачественное выявление требований. Но ясно, что это не всегда так. Требования могут изменяться не по вине БА, а значит, при фиксации запроса на изменение нам потребуется дополнительно определить атрибут «Причина изменения». В любом случае классификация должна быть чем-то вызвана, кроме здорового любопытства.

Давайте рассмотрим три типа – запрос на изменение, новое требование и расширение существующего требования – через примеры.

Запрос на изменение

  • Поле «Х» было обязательным, должно стать необязательным

  • Изменить размещение элементов в интерфейсе

  • Значение атрибута «Х» в отчете рассчитывалось по формуле Ф1, должно рассчитываться по формуле Ф2.


Итак, система уже определенным образом что-то делает, и есть запрос, чтобы она делала это иначе. У нас есть оригинальное требование, запрос его меняет. Было бы неплохо их связать между собой (трассировка).

Новое требование

  • Добавить новый отчет

  • Создать новый API

  • Добавить новую функцию для пользователя

Чтобы понять, что речь идет о новом требовании, мы должны заранее определить исходные границы. Это могут быть ТЗ, Видение системы, Дорожная карта и т.д. Если у нас есть первоначальный список предусмотренной функциональности, мы можем классифицировать запрос как «Новая функциональность». То есть мы хотим добавить новое относительно сложное поведение (набор сценариев), которое изначально не предполагалось.

Расширение существующего требования

  • Добавить новую проверку при создании/редактировании сущности

  • Добавить новую колонку в отчет

  • Добавить новый атрибут на форму

  • Автоматически определять значение атрибута Х при заполнении формы

Честно говоря, этот тип я никогда не использовал, ограничиваясь «Запросом на изменение» и «Новым требованием». По моему мнению, в большинстве случаев это подтип «Запроса на изменение» - уже есть определенное требование, и мы хотим его модифицировать, но не путем изменения, а дополнения.

Интересный вопрос относительно изменения/добавления нефункциональных требований. К примеру, есть у нас функция построения отчета. Никому не пришло в голову определить требования по быстродействию. И вот появляется новое требование «Отчет должен строиться не больше 5 секунд». Или у нас было требование «Отчет должен строиться не дольше 10 секунд», а теперь есть желание снизить это время до 5 секунд. Во втором случае это запрос на изменение или расширение существующего требования. В первом случае – это пропущенное требование, отчет уже существует, следовательно, и это запрос на смену. Но согласитесь, что это очень разные запросы на изменения 😊

749 просмотров0 комментариев

Недавние посты

Смотреть все

Comments


bottom of page