Новые приемы управления требованиями с помощью Rational RequisitePro: Часть 1

В данной серии статей Кумара Мани предлагаются новые приемы, помогающие выявить и проследить архитектурные требования, а также управлять ими.

Введение

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

Требования важны, поскольку они образуют основу для разработки архитектур. На Рисунке 1 показан метод разработки архитектуры Open Group Architecture Framework Architecture Development Method (TOGAF ADM) и его восемь фаз.

Рисунок 1. Метод разработки архитектуры TOGAF

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

• "Я использую продукты Rational для моделирования и разработки, но как связать их с требованиями?"
• "У нас уже есть инструмент XYZ с подобными возможностями, так чем же это решение лучше?"

IT-специалисты хотели бы, чтобы их технические требования были четко выражены, чтобы им можно было начать кодирование. Менеджеры проектов и клиенты не совсем представляют себе преимущества таких инструментов, как Rational RequisitePro и возможность их использования с инструментами управления проектами, например, Rational Portfolio Manager. (В некоторых проектах используется весь набор инструментов Rational, кроме RequisitePro!) Ответам на эти вопросы и посвящена данная статья.

Такие инструменты, как Rational, при правильном использовании могут дать значительные преимущества. Некоторые менеджеры проектов используют такие инструменты (например, RequisitePro) как репозитории для требований; то есть требования импортируются в инструмент как есть , и из него публикуются отчеты. Менеджерам проектов остаётся удивляться, почему они не видят никаких ощутимых преимуществ.

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

Корпорация Empire Systems

Чтобы продемонстрировать, как наилучшим образом использовать методы управления архитектурными требованиями, в этой серии статей я буду приводить гипотетические примеры из практики Empire Systems Corporation (ESC), вымышленного производителя и поставщика ПК, ноутбуков, компьютерных компонентов и сопутствующего оборудования, например, Web-камер и микрофонов. ESC уже представлена в Web, и многие из её приложений доступны через Интернет. Теперь руководству компании нужно перевести предприятие на следующий уровень путем рационализации процессов, автоматизации деловой активности, внедрения корпоративной архитектуры, и, в конечном счете, повышения доходов и рентабельности.

Бизнес-требования

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

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

 

Будьте разумны Требования должны быть Specific (конкретными), Measurable (измеримыми), Actionable (действенными), Realistic (реалистичными) и Timebound (ограниченными во времени). Это сложнее, чем кажется. Однако этого легко сделать добиться, задавая следующие вопросы:

• Почему это должно быть сделано таким образом?
• Какой результат вы получите или сможете достичь, если эта проблема решится?
• Какой именно процесс страдает от этого недостатка?
• Какая выгода (измеримая количественно, насколько это возможно), достигается внесением поправок в процесс?
• Что можно сделать, чтобы изменить ситуацию?

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

• Когда, в соответствии с временными рамками, этого необходимо достичь, принимая во внимание ситуацию и бизнес-среду?

  Предполагается, что это не стартовая площадка для своевременного осуществления проектов, а скорее отправная точка для размышлений о бизнес -контексте. Например, коммерсант, работающий онлайн с кредитными картами, возможно захочет наметить на время праздников (их бизнес-контекст) дебют их нового Web-сайта.

Определите и уточните область действия Что на входе и что на выходе? Что следует выполнить или осуществить, и к какому времени? Определите "подлежащее" и "глагол" Это очень часто упускается из виду и является основной причиной смещения области действия. Если глагол не один, а несколько, подумайте, не сформулировать ли его как отдельное требование. Это делает ситуацию более понятной и способствует её лучшему пониманию заинтересованными сторонами. Важно что , а не как Бизнес-требования всегда выражают, что должно быть сделано, и следует избегать указаний на то, как это можно сделать. Например, предприятию могут понадобиться субъективные, целостные представления их деловой информации. Тогда в центре внимания должно быть то, что нужно сделать, а не то, что необходимо получить (например, хранилище данных).

Пример требований

У ESC есть несколько Web-приложений. Поскольку каждое приложение разрабатывалось самостоятельно, клиенты сталкиваются с такими проблемами, как необходимость регистрироваться отдельно в каждом приложении и работать с различными представлениями для каждой бизнес-функции, что вызывает недовольство. В ответ на это бизнес-группа ESC сформулировала следующее требование:

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

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

BR264: В ESC5.0 клиенты смогут однократно зарегистрироваться для всех приложений ESC, в том числе ESCWeb, ESCOrderStatus, ESCVendor и ESCSupport.

BR265: В ESC5.0 во всех приложениях ESC реализуются ESC Web Standard 273-1 и 273-2, что приведет к уменьшению количества ошибок пользователей на 10%.

Прием 1. Определение бизнес-требований в RequisitePro

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

1. Определите Requirement Type (Тип требования) для бизнес-требований. Все бизнес-требования получат этот тип. BUS - это обычный префикс.
2. Определяя тип требований, используйте опцию Requirement Must Contain (Требование должно содержать) для указания разделителя (например "/"). Подлежащее и глагол могут помещаться по любую сторону от разделителя. Это не обязательно для соблюдения; в руководстве RequisitePro имеется более подробное описание. Идея в том, чтобы осторожно ввести порядок при определении подлежащего-глагола для требований.
3. Создайте пакет для бизнес-требований на высшем уровне. Вы сразу же увидите, как это улучшает послеживаемость.

Прием 1 завершен. Вы записали понятное и точное бизнес-требование, и готовы перейти к следующей фазе. Этот приём показан на Рисунке 2.

Рисунок 2. Использование приема 1 для записи бизнес-требования
 

Варианты использования

Прием 2 (Связь вариантов использования с требованиями) касается следующей фазы проекта. Как только бизнес-требования будут определены, бизнес-архитектор или аналитик разрабатывает варианты использования для большей ясности. Бизнес-аналитики часто сталкиваются с двумя проблемами, в особенности в больших или сложных проектах:

• Требования размещаются в документах (если не использовать Прием 1), а варианты использования "живут" в моделях, например Rational Rose Enterprise (Rose).
• Таким разобщенным набором объектов становится трудно управлять при увеличении количества требований (и вариантов использования).

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

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

Принцип именования для вариантов использования

Почему имеет значение имя варианта использования? Вспомните, для определения требований мы ввели структуру подлежащее-глагол. Это понятие здесь расширено. В модели варианта использования подлежащее представлено исполнителями (actors). Наш принцип именования вариантов использования заключается в том, что варианты использования должны быть названы при помощи настоящего времени или герундия (ing -формы) глагола. В некоторых случаях это помогает включить имя объекта, модифицированного глаголом.

Прием 2. Соединение вариантов использования с требованиями

Теперь пора определить варианты использования и соединить их с требованиями. Цели этого приема - поддерживать ясность в определении вариантов использования и обеспечить их связь с требованиями (трассируемость), выполняя следующие шаги.

1. Если ваш проект RequisitePro не содержит пакета для вариантов использования или типа требований для вариантов использования, создайте их.
2. Свяжите модель Rose с проектом RequisitePro, используя диалоговое окно Associate Model to RequisitePro project (Связать модель с проектом RequisitePro). Убедитесь, что в качестве Default Requirement Type (Типа требования по умолчанию) установлено Use Case (Вариант использования).
3. Теперь можете начинать создавать модели в Rose. Для каждого варианта использования вначале создайте требование RequisitePro типа Use Case с именем, соответствующим принципу именования, как показано на Рисунке 3. Введите имя в Requirement Text (Текст требования).

   Рисунок 3. Принцип именования варианта использования
   

4. Создайте вариант использования в Rose. Нажмите правой кнопкой на вариант использования, чтобы вызвать диалог Associate Requirement to Use Case (Связать требование с вариантом использования). Выберите Use Case in RequisitePro и нажмите OK. В результате появится диалог Resolve Use Case Name, который важен тем, что он связывает варианты использования с требованиями с помощью глагола, как показано на Рисунке 4.

   Рисунок 4. Соединение варианта использования с требованиями
   

5. Теперь вы увидите диалог Requirement Properties (Свойства требования). Выберите вкладку Traceability (Трассируемость), и трассируйте вариант использования до требования BUS.

Данный прием завершен. Вы начали с называния варианта использования в RequisitePro, что дало вам возможность определять, разрабатывать и трассировать вариант использования полностью в Rose. Это подчеркивает большое преимущество Rational: интеграцию между требованиями, моделированием и конструированием.

Трассируемость

Почему важна трассируемость? Трассируемость - это способность отслеживать жизнь требования, начиная с происхождения, через различные воплощения, как вперед, так и в обратном направлении. По мере развития предприятий развиваются и системы (и их требования), которые их поддерживают. Трассируемость - это необходимое звено, которое связывает прошлое, настоящее и будущее требований. Отчеты о трассируемости содержат данные, на основании которых можно выполнять различные виды анализа проекта, например анализ затрат, охвата и воздействия.

Трассируемость трудно достижима на практике. Главная проблема - в том, что трассируемость рассматривается как дополнительный аспект выработки требований. Требования определены в документах, а модели создаются в Rose. Трассируемость записывается, часто вручную, в электронные таблицы, после того, как завершена работа по моделированию. Поддерживать электронную таблицу сложно и чревато ошибками. Но в большей степени проекту вредит то, что сама электронная таблица служит отчетом о трассируемости и поэтому ее правильность нельзя проверить.

Наш следующий прием решает эту проблему. Первая часть приема - ввести дисциплину прослеживания требований при их создании. (Мы показывали это в предыдущем приеме с вариантами использования.) Идея в том, чтобы поддерживать дисциплину во время всего рабочего цикла требования вплоть до теста. Вторая часть - cгенерировать отчеты об охвате (coverage) и "свисаниях" (danglers). Отчет о "свисании"(dangler) - первый уровень анализа воздействия. Основная идея - в том, что эти отчеты, генерируемые автоматически, запрашивают тщательную проверку во время анализа.

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

Прием 3. Трассировка охвата и "свисаний"(danglers)

Этот прием показывает, как построить представления Coverage и Dangler, чтобы найти пробелы между бизнес-требованиями и вариантами использования. Эти представления соответствуют стандартной инфраструктуре представления RequisitePro. Выполните следующие шаги.

1. Из Coverage в пакете бизнес-требований выберите новое View (представление), где View Type (Тип представления) - это матрица трассируемости, Row Requirement Type (тип требований в ряду) - BUS, а Column Requirement Type (тип требований в колонке) - UC. Обратите внимание, что мы повторно используем пакет BUS из Приема 1.
2. В окне View Properties (Свойства представления) создайте Query (Запрос) под названием Business Requirements Coverage (Охват бизнес-требований) в требованиях ряда. Теперь Add (добавьте) атрибут Traced-from в Query.
3. В результате появится диалог Query Requirements (Требования к запросу). Как показано на Рисунке 5, выберите Not Traced и поставьте галочку на Direct links only (Только прямые ссылки).

   Рисунок 5. Охват трассируемости
   

4. Теперь обновите View. Вы увидите бизнес-требования, которые не имеют связанных с ними вариантов использования. Вы можете создать полный отчет View, пропустив шаги 2 и 3.
5. Представления Dangler создаются путем инверсии критериев Query в этом приеме. Мы начинаем с требований типа в колонке (варианты использования) и выбираем требование Traced-to BUS. Это представление отражает все ссылающиеся на несуществующий объект варианты использования.

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

Выводы

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

Тем не менее, мы всё ещё находимся на этапе задачи. Настройтесь на работу с частью 2, которая познакомит вас с этапом решения и различными стадиями разработки решений (в плане архитектуры), и рассмотрит новые приемы по управлению созданием решений.