Виды требований. Примеры

Продолжение

Переходные требования – это вид требований, существующих пока формируется решение (для перехода из состояния “as is” в “to be”). Эти требования формулируются в процессе поиска вариантов решения проблемы бизнеса. Очень часто на данном этапе производится анализ бизнес-процессов, который выражается в создании диаграмм процессов в различных нотациях и с использованием различных методологий и инструментов (BPMN, ARIS и т.д.). Как только решение принято переходные требования перестают существовать либо становятся компонентами решения.

Например, переходные требования:

  • необходимо проанализировать возможность выхода на зарубежный рынок;
  • необходимо проанализировать бизнес-процессы “as is”, выявить предпосылки к реинжинирингу (переходу в “to be”) и автоматизации.

В конечном итоге, переходное требование может стать компонентом решения.  Решение же, очевидно, может включать несколько компонентов (дополнительно рекомендуется ознакомление с циклом статей «Что такое бизнес-анализ?»).

Требования к компонентам решения могут быть 2 типов: подлежащие и не подлежащие автоматизации.

Например, требования к компоненту решения “выйти на рынок ближнего зарубежья” (для издательского дома в Республике Беларусь):

  • необходимо рассматривать рынки русскоговорящих стран (Россия, Украина);
  • либо необходимо выпускать книги на языке страны, на рынок которой планируется выход (польский для Польши и т.д.).

Требования к данному компоненту решения, очевидно, не подлежат автоматизации.

Или, например, требования к компоненту решения “внедрить CRM-систему” будут сформулированы в виде пользовательских историй или функциональной спецификации. Эти требования подлежат автоматизации. Их создание — это следующий шаг после формирования концепции.

Приведу еще примеры для различных видов требований, подлежащих автоматизации:

  • пользовательское требование (в виде пользовательских историй): как клиент я могу ввести данные, требуемые для регистрации, для того, чтобы зарегистрироваться в системе и иметь доступ к расширенному каталогу товаров;
  • функциональное требование: в системе должна быть реализована возможность регистрации клиентов (часто сопровождается созданием функциональных прототипов);
  • требования к данным (базам данных): при регистрации клиент должен указать имя, e-mail и пароль;
  • нефункциональное требование (производительность): форма для регистрации должна загружаться не более 1 секунды.

Смотрите также:

  1. Три «кита» бизнес-анализа в ИТ.
  2. Что такое бизнес-анализ?

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

w

Connecting to %s