Уровень 3. Структурирование требований

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

Во-первых, вы должны выделять требования как атомарные единицы для того, чтобы было легче:

• понять, что данное требование описывает;

• ссылаться на конкретное требование, а не на страницу со сплошным текстом;

• воспринимать изменения требований;

• разрабатывать и тестировать конкретную функциональность;

• присваивать атрибуты требованиям.

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

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

• приоритезировать;

• понимать, какие описаны, какие разработаны, а какие протестированы,

• понимать, в какой версии ПО они реализованы, и т.д.

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

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

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

На данном уровне вам уже будет трудно управлять требованиями с помощью простого текстового редактора (MS Word Open или Office Writer), и на помощь могут прийти специализированные инструменты: IBM Rational RequisitePro и IBM Telelogic Doors.

Уровень 3.1. Моделирование требований

Даже идеально структурированные и организованные требования могут не дать полной картины потребности заказчика, потому что 20–50 страниц текста воспринять очень трудно. На помощь нам могут прийти разного рода модели, которые позволяют активизировать второе полушарие мозга и взглянуть на требования «по-новому».

При изучении и документировании бизнес-требований могут помочь модель объектов предметной области (Business/Domain Object Model), модель бизнес-вариантов использования (Business Use Case Model) или модель бизнес-процессов (Business Process Model).

При более детальном изучении потребностей заказчика (пользовательские требования) помогут модель системных вариантов использования (Use Case Model), представление пользовательских классов (View of Participating Classes) или диаграммы действий, состояний, взаимодействия.

Дальше идет уже проектирование ПО: диаграммы классов приложения и БД, диаграммы взаимодействия компонентов и классов, диаграммы действий и т.д.

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