Как писать бизнес требования для проекта

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

1.1 Исходные данные

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

1.2 Возможности бизнеса

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

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

Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoft

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

1.3 Бизнес-цели

Суммирует важные преимущества бизнеса, предоставляемые продуктом, в количественном и измеряемом виде. Банальности («стать компанией мирового класса») и нечетко сформулированные улучшения («обеспечить высокий уровень сервиса для клиентов») нельзя считать ни полезными, ни поддающимися проверке. В табл. 5-1 приведены примеры и финансовых и нефинансовых целей (Wiegers, 2007).

Табл. 5-1. Примеры финансовых и нефинансовых бизнес-целей

Финансовые целиНефинансовые цели

Освоить X% рынка за Y месяцев	Достигнуть показателя удовлетворения покупателей, равного по крайней мере X, в течение Y месяцев со времени выпуска продукта
Увеличить долю рынка в стране W с X% до Y% за Z месяцев	Увеличить производительность обработки транзакций на X% и снизить уровень ошибок данных до величины не более Y%
Достигнуть объема продаж X единиц или дохода в Y долларов за Z месяцев	Разработать надежную платформу для семейства связанных продуктов
Получить X% прибыли по инвестициям в течение Y месяцев	Разработать специальную базовую технологическую основу для организации
Достигнуть положительного потока денежных средств по этому продукту в течение Y месяцев	Добиться признания продукта лучшим по на- дежности в опубликованных обзорах продуктов к определенной дате
Сэкономить X долларов в год, которые в настоящий момент расходуются на обслуживание унаследованной системы	Обеспечение выполнения определенных нормативов регулирующих органов
Уменьшить затраты на поддержку с X до Y долларов за Z месяцев	Получить не более X звонков в службу обслуживания по каждой единице товара и Y звонков по гарантии каждой единице товара в течение Z месяцев после выпуска продукта
Увеличить валовую маржу для существующего бизнеса с X до Y% в течение одного года	Уменьшить время выполнения заявки до X часов на Y% звонков в службу поддержки

Организации обычно предпринимают проект для решения задачи или использования имеющейся возможности. Модель бизнес-целей отображает иерархию связанных бизнес-проблем и измеряемых бизнес-целей (Beatty и Chen, 2012). Проблемы описывают, что не позволяет организации достичь требуемых ориентиров в настоящее время, тогда как бизнес-цели определяют способы измерения достижения этих ориентиров. Задачи и цели взаимосвязаны: понимание одной раскрывают суть второй.

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

Разговор между бизнес-аналитиком и куратором, одним из топ-менеджеров компании, с целью определить бизнес-задачи и цели может выглядеть, как показано на рис. 5-4. Это иллюстрация к проекту системы Chemical Tracking System в компании Contoso Pharmaceuticals, описанной в главе 2. На основе ответов топ-менеджера компании бизнес-аналитик может сформулировать бизнес-цели для Chemical Tracking System, как показано на рис. 5-5.

Рис. 5-4. Пример разговора между аналитиком и куратором проекта

1.4 Критерии успеха

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

Рис. 5-5. Пример модели бизнес-целей для системы контроля химикатов

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

Для системы контроля химикатов одним из критериев может быть Бизнес-цель 3на рис. 5-5:

«Сократить время заказа химикатов до 10 минут в 80% заказов», потому что среднее время заказа можно измерить во время тестирования или после выпуска. Другой критерий успеха может быть связан с Бизнес-целью 2 с временем, намного более ранним, чем год после выпуска, например: «Отслеживать 60% контейнеров промышленных химикатов и 50% специализированных химикатов через четыре месяца».

Внимание!Внимательно выбирайте критерии успеха. Убедитесь, что они оценивают то, что важно для бизнеса, а не просто то, что легко оценить. Критерий «Сократить затраты на производство продукта на 20%» легко оценить. Его также легко реализовать путем увольнения сотрудников или сокращения инвестиций в инновации.

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

1.5 Положение о концепции

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

• Для[целевая аудитория покупателей];
• Который[положение о потребностях или возможностях];
• Эта(этот) [имя продукта];
• Является[категория продукта];
• Который(ая) [основные функции, ключевое преимущество, основная
• причина[для покупки или использования];
• В отличие от[основной конкурирующий продукт, текущая система или текущий бизнес-процесс];
• Наш продукт[положение об основном отличии и преимуществе нового продукта].

Вот как выглядит положение о концепции системы контроля химикатов Chemical Tracking System в Contoso Pharmaceuticals, о которой говорилось в главе 2; ключевые слова выделены полужирным:

Для ученых, которым нужно запрашивать контейнеры с химикатом, данная система Chemical Tracking System является информационной системой, которая обеспечит единую точку доступа к складу химикатов и к поставщикам. Система будет знать местоположение каждого контейнера с химикатом в компании, количество химиката в контейнерах и полную историю перемещения и использования каждого контейнера. Эта система сэкономит компании 25% затрат на химикаты в первый год работы, позволив полностью использовать уже полученные химикаты, утилизировать меньшее количество частично израсходованных или просроченных химикатов и применять единую стандартную систему приобретения химикатов. В отличие от действующих сейчас ручных механизмов заказов химикатов наш продукт будет генерировать все отчеты, необходимые для регулирующих органов, в которых требуются сведения об использовании, хранении и утилизации химикатов.

Разработка концепции продукта

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

Билл всегда немного ворчит, потому что знает, что это заставит его хорошо подумать о том, какой конкретно результат он ожидает получить. Но созданный Биллом документ концепции всегда дает четкое понимание, что нужно сделать, и мы можем эффективно сотрудничать. Это стоит потраченного времени.

Можно попросить несколько заинтересованных лиц написать свое положение раздельно, а не в группе. Сравнение этих положений о концепции будет хорошим способом обнаружить различия в понимании целей проекта. К тому же писать положение о концепции никогда не поздно. Даже если проект уже в работе, разработка положения о концепции обеспечит правильное направление оставшейся части проекта. Положение о концепции создается быстро, но создание правильного положения и согласование его со всеми заинтересованными лицами займет больше времени.

1.6 Бизнес-риски

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

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

Предположение (assumption)— это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного.

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

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

Задокументируйте все предположения, сделанные заинтересованными лицами, когда они обдумывали проект и создавали данный документ о концепции и границах. Часто предположения одних лиц не разделяют другие стороны. Если вы запишите их и просмотрите позже, то избежите возможной путаницы и ухудшения ситуации в будущем.

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

Анализ требований к программному обеспечению

Анализ требований— это процесс сбора требований к программному обеспечению (ПО), их систематизации, документирования, анализа, выявления противоречий, неполноты, разрешения конфликтов в процессе разработки программного обеспечения. В англоязычной среде также говорят о дисциплине «инженерия требований» (англ. Requirements Engineering). В процессе сбора требований важно принимать во внимание возможные противоречия требований различных заинтересованных лиц, таких как заказчики, разработчики или пользователи.

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

Анализ требований включает три типа деятельности:

Сбор требований: общение с клиентами и пользователями, чтобы определить, каковы их требования.

Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.

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

Выделяют следующие типы требований:

Эксплуатационные требования определяют характеристики разрабатываемого программного обеспечения, проявляемые в процессе его использования. К таким характеристикам относят:

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

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

Какие бывают требования?

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

Функциональная спецификация состоит из трех частей:

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

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

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

Дата добавления: 2016-10-06; просмотров: 1846 | Нарушение авторских прав

Источник: steptosleep.ru

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

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

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

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

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

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

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

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

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

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

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

• Почему это должно быть сделано таким образом?
• Какой результат вы получите или сможете достичь, если эта проблема решится?
• Какой именно процесс страдает от этого недостатка?
• Какая выгода (измеримая количественно, насколько это возможно), достигается внесением поправок в процесс?
• Что можно сделать, чтобы изменить ситуацию? Ответить обычно бывает трудно, и заинтересованные стороны часто возвращаются к постановке задачи. Специалист по требованиям может начать с нескольких предположений типа «а что если» , чтобы выявить некоторые возможности. Однако важно от них отступить, как только заинтересованные стороны вернутся к вопросам.
• Когда, в соответствии с временными рамками, этого необходимо достичь, принимая во внимание ситуацию и бизнес-среду? Предполагается, что это не стартовая площадка для своевременного осуществления проектов, а скорее отправная точка для размышлений о бизнес -контексте. Например, коммерсант, работающий онлайн с кредитными картами, возможно захочет наметить на время праздников (их бизнес-контекст) дебют их нового 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%.

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

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

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

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

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

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

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

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

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

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) — это требования, которые непреднамеренно «вползли» на один уровень, не имея прецедента на предшествующем уровне. Важно перехватить и то, и другое в начале цикла, поскольку гораздо легче обработать предупреждение на этой стадии, чем работать с отчетом об ошибках после реализации системы. Не менее важно автоматизировать эти функции.

Этот прием показывает, как построить представления 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, которая познакомит вас с этапом решения и различными стадиями разработки решений (в плане архитектуры), и рассмотрит новые приемы по управлению созданием решений.

Ссылки по теме

• Обратиться в «Интерфейс» за дополнительной информацией/по вопросу приобретения продуктов
• Приобрести продукты IBM Rational в электронном магазине ITShop.ru
• Подробнее о продуктах Rational Software

07.2007

Источник: www.interface.ru