Консультация

   Очень часто мы сталкиваемся с ситуацией, когда клиент обращается с пожеланиями  «чтобы всё хорошо было». Однако бывает так, что когда мы получаем огромный список бизнес требований, чаще всего все они не ясно сформулированы, ведут к достижению непонятных никому, в том числе и заказчику целей.
  
   Поэтому сегодняшняя статья будет посвящена методологии управления требованиями. Прежде всего давайте вспомним из чего состоит любой проект автоматизации:

Младшая методология (рисунок 1).

971a06e98b0bad0560faec9818faf16f.png

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

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

Старшая методология (рисунок 2).


Несмотря на то, что методология управления корпоративной архитектурой, является самой высокоуровневой на сегодняшний день, управление требованиями по-прежнему остаётся двигателем всей системы. именно поэтому стрелки на рисунке двухсторонние.

А теперь давайте перейдём к самому процессу управления требованиями (рисунок 3).



Начнём по порядку.

- Бизнес-требования (business requirements), содержат в себе высокоуровневые цели организации или заказчиков системы.  Бизнес-требования сохраняются в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter).

- Требования пользователей (user requirements), описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие - отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы. Пример варианта использования — «сделать заказ» для заказа билетов на самолет.

- Функциональные требования (functional requirements), определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований.

- Требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «система должна по электронной почте отправлять пользователю подтверждение о заказе».

- Системные требования (system requirements), обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть система (например iso). говоря о системе, мы подразумеваем программное обеспечение или подсистемы по и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространиться и на людей.

 - Бизнес-правила (business rules), включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы.

- Функциональные требования документируются в спецификации требований к ПО (software requirements specification, srs), где описывается так полно, как необходимо, ожидаемое поведение системы.

  - Атрибуты качества (quality attributes), представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям.

- Ограничения (constraints), касаются выбора возможности разработки внешнего вида и структуры продукта.

- Внешний интерфейс - "юзабилити" - это, по сути, показатель того, в какой степени пользователю удобно взаимодействовать с интерфейсом приложения. об этом пункте 99,9 % разработчиков забывают постоянно, запихивая кнопочку, которую потом пользователи ищут 10 минут.  Эти 10 минут легко превращаются в 20 потерянных компанией часов и это только за один рабочий день!

Ход процесса управления требованиями (рисунок 4).

1ff6adfdb2ba8375cddcbfdc6ac9c71b.png

На стадии извлечения мы собираем данные от пользователей, на второй – анализируем, на третьей результаты анализа документируем утверждённым образом, а на последней согласовываем с клиентом.

Важнейшие критерии бизнес-требований

1.Полнота. Каждое требование должно полно описывать запрос бизнеса.

2.Односмысленность. Требование все участники понимают одинаково.

3.Необходимость. Требование связанно с достижением конкретной цели.

4.Осуществимость. Важнейший критерий. Требование должно быть обеспеченно необходимыми ресурсами. Например, специалистами и временем.