4.3 Заключение

Настройка проекта RequisitePro состоит из следующих шагов:

• Выбор названия проекта и его местоположения на жестком диске.

• Выбор шаблона со структурой, подходящей Вам больше всего.

• Настройка шаблона.

• Импорт документов, которые были созданы до создания проекта.

Настройка может включать следующие операции:

• Добавление нового типа документов.

• Удаление ненужных типов документов.

• Добавление новых типов требований.

• Удаление ненужных типов требований.

• Добавление новых атрибутов требований.

• Удаление ненужных атрибутов требований.

• Изменение набора значений для определенных атрибутов.

В этой главе было рассмотрено добавление новых атрибутов требований и изменение набора значений для определенных атрибутов. Другие варианты будут рассмотрены в последующих главах.

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

Глава 5

Сбор

Требований

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

Рисунок 5.1. Потребности заинтересованных лиц располагаются на высшем уровне пирамиды требований.

Вторая часть главы показывает, каким образом можно оформить требования заинтересованных лиц в документы Запросов Заинтересованных Лиц (Stakeholder Requests documents), используя RequisitePro. Данная часть описывает решение следующих задач:

• Добавление типа документа «Запросы Заинтересованного Лица» в проект (если он отсутствует в проекте).

• Создание документа из шаблона.

• Заполнение документа необходимой информацией.

• Хранение требований в базе данных.

• Использование views (представлений) с требованиями.

5.1 Определение заинтересованных лиц

Большое количество требований поступает от лиц, заинтересованных в разработке системы. Словарь в Rational Unified Process (RUP) определяет заинтересованное лицо (stakeholder) как «Лицо, на которое результат работы системы оказывает непосредственное влияние». Можно выделить две основных группы заинтересованных лиц:

• Заказчики, по требованию которых осуществлялась разработка. Они подтверждают результат и обычно финансируют проект.

• Пользователи системы.

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

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

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

Пройдемся по списку потенциальных заинтересованных лиц и определим их для нашего проекта:

• Заказчики.

Выявленные заинтересованные лица: владелец агентства путешествий.

• Пользователи.

Пользователи, участвующие в предоставлении требований: Пользователь 1 (из США) и Пользователь 2 (из Франции).

• Все кто участвует в разработке системы (бизнес аналитики, дизайнеры, кодировщики, тестеры, менеджеры проектов, менеджеры по внедрению, дизайнеры сценариев использования (use cases), графические дизайнеры).

Заинтересованные лица, участвующие в предоставлении требований: разработчики и контент-менеджеры.

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

В данной группе заинтересованные лица не выявлены.

• Руководство (президент компании, которого представляют заказчики, директор отдела информационных технологий компании, проектирующей и разрабатывающей систему).

Владелец бюро путешествий, упомянутый в первой группе.

• Лица, вовлеченные в управление, настройку и сопровождение системы (хостинговая компания, справочная служба).

Выявленные заинтересованные лица: представитель отдела обслуживания клиентов, администратор.

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

В данной группе заинтересованные лица не выявлены.

• Сторонние компании, вовлеченные в процесс.

Выявленные заинтересованные лица: представитель гостиницы, агент по найму автомобиля, представитель авиалиний.

5.2 Методы сбора требований

Запросы заинтересованных лиц могут быть собраны с использованием различных методов:

• Интервью (индивидуальный диалог с заинтересованным лицом).

• Анкеты (набор вопросов, отправленный большому количеству заинтересованных лиц).

• Семинары (заинтересованные лица собираются на определенный период для интенсивных, насыщенных дискуссий).

• Сценарии приложения (использование визуальных/графических инструментов для демонстрирования поведения системы).

• Ролевые игры (каждому члену группы назначается определенная роль, обычно роль одного из пользователей).

• Сессии с применением метода «мозгового штурма» (Brainstorming sessions - групповой метод решения вопросов путем изложения идей в течение непродолжительных, интенсивных сессий).

• Использование прототипов (разработка прототипов для получения отклика о системе).

• Сценарии использования (Use Cases – взаимодействие между пользователем и системой, представленное в виде последовательности шагов).

• Анализ существующих документов (извлечение информации из документов Microsoft Word, электронной почты и записей).

• Наблюдение и демонстрирование задач (наблюдение за пользователями, выполняющими определенную задачу).

• Анализ существующих систем (сбор требований от морально устаревших заменяемых систем или от систем, разработанных в ходе конкуренции).

Таблица 5.1. описывает методы сбора требований, которые были отобраны для нашего проекта для сбора требований каждого заинтересованного лица, определенного в Главе 4 «Настройка Проекта».

Таблица 5.1. Заинтересованные Лица и Используемые Методы Сбора их Требований.

Заинтересованное лицо	Метод сбора требований	Объяснение
Владелец агентства путешествий	Интервью Семинар	Данное заинтересованное лицо – заказчик, кто сделал заказ на разработку системы, и будет оплачивать ее разработку. Это определяет его/ее высший приоритет. Обычно в данном случае мы применяем более чем один метод сбора требований для обеспечения максимального охвата требований. Сценарий интервью, включенный в шаблон для документа Запросов Заинтересованного Лица, весьма приемлем, потому он может быть использован как первый шаг в процессе сбора требований. Следующий метод - семинар – может быть использован для уточнения требований с целью минимизировать возможность упущения деталей. Будучи заказчиком, заинтересованное лицо должно также участвовать в предоставлении нефункциональных требований, таких как производительность и надежность.
Пользователь 1	Семинар Сценарии приложения	Семинар предоставляет больше возможностей для получения более детальных требований. Так как Пользователь 1 способен встретиться с командой разработчиков, мы можем пригласить его на семинар. Сценарии приложения используются в течение того же семинара.
Пользователь 2	Документ (электронная почта)	Пользователь 2 находится в другой стране и нельзя встретиться с ним лично. Он оказывает услугу, предоставляя свой отклик о системе, так что мы хотим, чтоб его расходы оставались минимальными. Его попросили прислать электронное письмо с перечнем его требований.
Представитель отдела обслуживания клиентов	Ролевые игры	Функциональность, требуемая представителем отдела обслуживания клиентов, составляется на основе диалога с пользователями, обращающимися с различными проблемами. Так что ролевые игры – это подходящий инструмент для воссоздания подобных ситуаций.
Администратор	Семинар	Все три заинтересованных лица являются членами отдела информационных технологий и работают в одном месте. Собрать их одновременно очень легко. Семинар обычно не требует подготовки формальных документов, таких как анкета или сценарий интервью.
Контент-менеджер	Семинар
Разработчик	Семинар
Представитель гостиницы	Анкета	Одни и те же вопросы задаются всем трем службам предоставления услуг, поэтому для них может быть использована одна анкета. Все три представителя находятся в разных компаниях в различных частях страны. И они не могут встретиться лично.
Агент по найму автомобиля	Анкета
Представитель авиалиний	Анкета

Согласно RUP, лицо, ответственное за деятельность Сбора Требований Заинтересованного Лица – это системный аналитик (system analyst). В RUP, системный аналитик (как и другие роли) – это роль, выполняемая членом или членами проектной команды, и не обязательно является должностью в компании. Во многих проектах эта задача выполняется бизнес-аналитиком (business analyst) или каким-либо другим лицом.

Интервью

Один из наиболее распространенных методов сбора требований – это интервью с выбранной группой заинтересованных лиц. Преимуществом данного подхода является интерактивность, предоставляющая возможность внесения дополнений или доработки вопросов в зависимости от полученных ответов. Интервью - это хороший способ собрать требования по удобству использования системы, надежности, производительности и удобству сопровождения. Обычно заказчики не упоминают эти нефункциональные требования, пока их явно не спросить об этом. Для интервью бизнес-аналитик должен иметь приготовленный заранее первоначальный набор вопросов. Однако, в процессе интервью, могут возникнуть дополнительные вопросы. Шаблон ReqeuisitePro для документа Запросов Заинтересованного Лица содержит пример сценария, который может быть использован для интервью. Этот сценарий довольно общий и, возможно, потребует доработки для каждого конкретного интервью.

Несколько рекомендаций для проведения интервью:

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

• Напишите первоначальный список вопросов.

• Проговорите ответы своими словами, чтобы убедиться, что Вы понимаете смысл.

• Вы не должны предлагать ответ на Ваш вопрос. Например: Какое время реакции системы Вы ожидаете? Три секунды?

• Не соединяйте несколько вопросов в один. Например: Необходимо ли Вам печатать ответ, отправлять его по электронной почте и факсу? Быть может, пользователю нужна только возможность печати отчета и отправки его по электронной почте, но нет необходимости в факсе.

• На этом этапе, не спрашивайте о деталях реализации. Например: Вы предпочитаете list-box или radio-buttons для выбора метода оплаты?

• Не используйте слишком длинные и сложные вопросы.

• Не задавайте следующий вопрос, если еще не получен ответ на предыдущий.

• Если ответ непонятен, задайте дополнительные вопросы, даже если их нет в сценарии интервью.

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

• Фиксируйте каждое упомянутое пользователем требование, даже если в настоящий момент оно кажется неуместным.

• Спросите пользователей о дополнительной информации (экранные формы системы).

• При разговоре с заказчиками не говорите о том, будет ли их требование выполнено или нет. Это будет решено позже.

• В конце разговора спросите вопрос для получения дополнительной информации, например «Что еще я должен знать?».

• Выясните у заинтересованного лица приоритет для каждого требования.

• Делайте примечания или используйте записывающее устройство.

В качестве примера, используем план документа Запросов Заинтересованного Лица (Stakeholder Requests) [RUP04], как основу для интервью с владельцем агентства путешествий.

1. Официальное Представление.

2. Заполнение Профиля Заинтересованного Лица или Пользователя

   • Имя: Mark Merphy.

   • Компания/Область: Incredible Travel Agency, Inc.

   • Должность: Владелец.

   • Каковы Ваши основные обязанности? Руководство агентством, увеличение прибыли от продаж.

   • Какие услуги Вы предоставляете? Для кого? Продажа билетов на самолет, бронирование номеров в гостиницах и предоставление автомобилей в аренду.

   • Каким образом определяется успешность деятельности? Прибылью от продаж и от привлеченных средств.

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

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

3. Определение Проблемы

• Для каких проблем Вам необходимо хорошее решение? Он-лайн продажи.

• Перечислите, каковы они?

Для каждой проблемы, задайте следующие вопросы:

• Почему существует данная проблема?

• Как Вы решаете ее сейчас? В настоящее время, заказчики звонят, чтобы сделать заказ.

• Как бы Вы хотели решить ее? Мы бы хотели, чтобы клиенты имели возможность покупать билеты он-лайн, без необходимости звонить агенту.

4. Понимание Среды Пользователя

• Кто является пользователем системы? Всякий, кто хочет купить билет на самолет, взять в аренду автомобиль или забронировать номер в гостинице.

• Какое у них образование? Разное.

• Какое у них компьютерное образование? Имеют компьютерное образование, могут пользоваться Интернетом.

• Есть ли у пользователей опыт работы с приложением данного типа? Да.

• Какие платформы они используют? Каковы Ваши предложения в плане будущих платформ? Приложение будет платформо-независимым, и будет доступно через браузер.

• С какими дополнительными приложениями, которые Вы используете, система будет взаимодействовать? Airline Reservation.

• Каковы Ваши ожидания в плане удобства использования продукта? Система должна быть проста в использовании.

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

• Какие печатные копии и он-лайн документация Вам необходимы? Он-лайн помощь для пользователей. Печатная копия документации для представителя отдела обслуживания клиентов, контент-менеджера и администратора.

5. Обобщение для Понимания

• Вы сказали мне….(перечислите своими словами список проблем, обозначенных заинтересованным лицом).

• Отражает ли это Ваши текущие проблемы с существующими решениями?

• С какими проблемами Вы уже встречались (если есть)?

6. Взгляд Аналитика на Проблемы Заинтересованного Лица (утверждение или аннулирование требований)

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

Для каждой предложенной проблемы, задайте следующие вопросы:

• Это реальная проблема? Да.

• Каковы причины данной проблемы? Отсутствие веб-сайта.

• Каким образом Вы решаете эту проблему? С помощью телефонных звонков.

• Как бы Вы хотели решить проблему? Осуществлением продаж через веб-сайт.

• Каким образом Вы бы распределили по приоритету решение данных проблем по сравнению с остальными, Вами обозначенными?

7. Оценка Вашего Решения

• Что если бы Вы могли….(суммирование главных возможностей предложенного Вами решения).

• Как бы Вы оценили значимость этого?

8. Оценка Возможности.

• Кому необходимо данное приложение в Вашей организации? Главная польза будет для пользователей. Использовать приложение будут администратор, представитель отдела обслуживания клиентов и контент-менеджер.

• Насколько много пользователей данного типа будут пользоваться приложением? Один администратор, два представителя отдела обслуживания клиентов и один контент-менеджер.

• Как бы Вы оценили успешное решение? Оценка успеха: количество продаж через Интернет, количество обращений к агентам по аренде автомобилей и к представителям гостиниц.

9. Определение Надежности, Производительности и Требований Сопровождения

• Каковы Ваши ожидания в плане надежности? Сопоставимо с другими коммерческими веб-сайтами в этом плане.

• Каковы Ваши ожидания в плане производительности? Сопоставимо будет сопоставима с другими коммерческими веб-сайтами в этом плане.

• Будете ли Вы сами осуществлять сопровождение продукта или ее будет осуществлять иные лица?

• Есть ли у Вас какие-либо специальные требования к сопровождению? Как насчет обслуживания и сервисного доступа?

• Каковы требования к безопасности? Представители гостиниц, агенты по найму автомобилей и представители авиалиний будут иметь свои идентификаторы (ID) и пароли для страниц, где они могут предоставлять свои услуги. Пользователи будут выбирать свой ID и предоставлять пароль при покупке билета.

• Каковы требования к установке и конфигурированию системы? Установка на пользовательских компьютерах не требуется.

• Есть ли специальные требования по лицензиям? Нет.

• Каким образом будет осуществляться распространение системы? Система будет установлена на сервере хостинговой компании.

• Каковы требования к маркировке и оформлению пакета требований? Нет.

• Каковы (если есть) Ваши требования к инструкциям или среде? Должна ли осуществляться поддержка стандартов? Нет.

• Есть ли еще какие-либо требования, о которых мы должны знать? Система должна быть разработана в течение трех месяцев.

10. Подведение итогов.

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

• Если я должен задать сопутствующие вопросы, я могу звонить Вам? Да.

• Хотели бы Вы участвовать в обзоре требований? Да.

11. Резюме Аналитика.

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

• Пользователь должен иметь возможность купить билет через веб-сайт без необходимости звонков по телефону туристическому агенту.

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

• Представители гостиниц, агенты по найму автомобилей и представители авиалиний должны иметь свои ID (идентификаторы) и пароли для доступа к страницам, где они предлагают свои услуги.

• Система должна быть доступной 24 часа в сутки с уровнем надежности, соответствующим коммерческим приложениям.

• Система должна быть разработана в течение трех месяцев.

• Система должна запрашивать ID и пароль пользователя при покупке авиабилета.

Анкеты

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

В проекте он-лайн агентства путешествий мы посылаем следующие вопросы трем заинтересованным лицам (представителю гостиниц, агенту по найму машин и представителю авиалиний):

1. Какая информация от клиента Вам необходима?

2. Какую информацию Вы будете отображать для клиента?

3. Требуете ли Вы оплату при бронировании?

4. Если Вы требуете оплату, какой тип оплаты Вы предпочитаете?

5. Есть ли у Вас какие-либо дополнительные требования?

Вот ответы, полученные от представителя гостиниц:

1. Какая информация от клиента Вам необходима?

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

2. Какую информацию Вы будете отображать для клиента?

При предоставлении информации о гостинице, следующая информация будет отображаться:

Адрес

Телефон

Факс

Электронная почта

Предлагаемые скидки

Доступные способы оплаты

И т.д.

3. Требуете ли Вы оплату при бронировании?

Нет.

4. Если Вы требуете оплату, какой тип оплаты Вы предпочитаете?

Нет необходимости в оплате.

5. Есть ли у Вас какие-либо дополнительные требования?

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

Семинары

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

Ниже приведены несколько задач организатора:

1. Перед семинаром:

   • Пригласите участников.

   • Распространите план и предварительный материал, чтобы участники могли подготовиться к встрече.

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

2. В процессе семинара:

• Поручите кому-нибудь делать записи.

• Ведите дискуссию в соответствии с планом.

• Стимулируйте к участию в беседе всех заинтересованных лиц.

• Подведите итоги семинара.

3. После семинара:

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

• Распространите результаты среди участников.

• Если необходимо, назначьте дополнительные семинары по результатам.

Семинар по требованиям предоставляет возможность применить другие техники сбора требований, такие как технику «мозгового штурма», использование сценариев приложения и ролевые игры. Задачей семинара может быть как сбор новых требований, так и обзор, уточнение и расстановка приоритетов существующих требований. Результаты семинара по требованиям должны быть документально оформлены. И лучше всего сделать это в документах Запросов Заинтересованных Лиц (Stakeholder Requests).

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

Примеры требований, собранных в течение семинара:

Пользователь 1:

1. Для рейсов вылета и прибытия пользователь должен иметь возможность сравнивать цены на билеты в других близлежащих аэропортах.

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

3. Система должна быть проста в управлении.

4. Если пользователь прежде уже покупал билет, то он не должен будет вводить заново информацию, такую как адрес или номер кредитной карты.

5. Должна быть реализована возможность оплаты через PayPal.

6. Даты должны отображаться в формате мм/дд/гггг.

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

8. Он должен быть отсортирован по ценам.

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

10. Цены на аренду машин должны включать все соответствующие налоги (включая налог штата - 6%).

11. Для удобства выбора даты рейса в системе должен присутствовать календарь.

Администратор:

1. Функция поиска должна позволять пользователю искать заказ по следующим критериям:

   • Фамилия

   • Дата

2. Любая активность на сайте должна записываться в лог.

3. Должны быть доступны различные отчеты.

Контент-менеджер:

1. При вводе данных контент-менеджер должен иметь возможность вводить обычный текст без тегов HTML.

2. Информация должна храниться в текстовом файле.

Разработчик:

1. Система должна быть полностью протестирована под только популярными браузерами.

2. Система должна отображать схему проезда до аэропорта.

В течение семинара было также использованы сценарии (описание приведено далее).

Использование сценариев

Идея сценариев – применение визуальных или графических инструментов для иллюстрирования желаемого поведения системы. Организатор семинара показывает первоначальные сценарии группе. Затем, на основании полученных комментариев от участников, сценарии корректируются и показываются вновь. Корректировка сценариев – процесс многократный. Это означает, что используемый графический инструмент должен позволять быстро вносить изменения в реальном времени в процессе семинара. Вы можете использовать как программные приложения, так и офисное приложение по созданию презентаций.

Несколько примеров инструментов, которые могут быть использованы:

• Бумага, карандаш, ластик.

• Мольберт, маркеры.

• Доски, с которых можно стирать сухими средствами.

• Доски для презентаций.

• Приложения по созданию пользовательского графического интерфейса, такие как Visual Basic или Visual C++.

• Microsoft Power Point.

• Microsoft Visio.

• Графические редакторы, такие как Microsoft Paint.

• Текстовые редакторы, такие как Microsoft Word.

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

Рисунок 5.2. Простой сценарий, созданный в Microsoft Power Point.

Ролевые игры

Членам групп присваиваются роли, связанные с разрабатываемой системой. Наиболее часто берутся роли пользователей системы, либо иных взаимодействующих с системой лиц. Команда проходит через различные сценарии.

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

Диалог 1

Пользователь:	Здравствуйте. Вчера я забронировал номер в гостинице. Однако я должен отменить мою поездку, так что я бы хотел отменить мой заказ.
CSR	Без проблем. Ваша фамилия?
Пользователь:	Smith.
CSR	У меня 187 броней на фамилию Smith. Ваше имя?
Пользователь:	John.
CSR	Все еще 47 совпадений. Какой у вас пункт назначения?
Пользователь:	Miami.
CSR	Дата?
Пользователь:	С 12 сентября до 25 сентября.
CSR	Хорошо. Ваш заказ отменен.

Диалог 2

Пользователь:	Добрый день.
CSR	Чем я могу Вам помочь?
Пользователь:	Я забронировал билет на самолет и заказал место около окна. Я бы хотел поменять его на место около прохода.
CSR	Как Вас зовут?
Пользователь:	Arctos Postopolis
CSR	Хорошо. Запись с таким имени уникальна, так что другой информации мне не требуется. У вас самолет до Лос-Анджелеса 5 апреля?
Пользователь:	Да.
CSR	Хорошо. Изменения внесены.

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

• Функция поиска должна позволять представителю отдела обслуживания клиентов искать запись, используя следующие критерии:

  • Фамилия

  • Пункт Назначения

  • Дата

• CRS должен иметь возможность вносить изменения в детали брони или отменить заказ.

Метод «Мозгового Штурма» (Brainstorming Sessions)

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

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

Пример.

В течение сбора требований пользователей были обнаружены два противоречивых требования:

От пользователя из США:

Треб.1: Даты должны отображаться в формате мм/дд/гггг.

От пользователя из Франции:

Треб.2: Даты должны отображаться в формате дд/мм/гггг.

Следующая команда была собрана для решения этой проблемы с помощью метода «мозгового штурма»:

• Пользователь 1

• Системный аналитик

• Разработчик

• Дизайнер

Участники выступили с различными идеями:

• Идея 1: Жестко закодировать дату в формате мм/дд/гггг и указать формат для каждого поля ввода.

• Идея 2: Запрашивать регистрацию пользователя при доступе к системе. В процессе регистрации одним из вопросов будет о том, какой формат даты предпочитает пользователь.

• Идея 3: Создать конфигурационный файл, который будет содержать настройки пользователя в отношении формата даты. Система будет считывать конфигурационный файл с жесткого диска.

• Идея 4: Использовать формат даты из настроек браузера.

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

Идея 1 была отклонена, так как она носит негибкий характер и не предоставляет корректный формат для пользователей вне США.

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

Идея 3 была отклонена по техническим причинам и причинам безопасности.

Идея 4 была принята как самое верное решение.

Диаграммы Сходства

Использование диаграмм сходства не является отдельной техникой; они используются в сочетании с сессиями «мозгового штурма» или семинаров по требованиям. Цель такого метода – это сгруппировать большое количество идей, полученных, например, в процессе сессий «мозгового штурма». Этот метод также может быть использован для группировки требований, которые были собраны в процессе семинара по требованиям.

Диаграммы сходства были изобретены Jiro Kawakita из Японии. Они особенно применимы в случаях, когда:

• Количество идей очень велико.

• Соотношения между отдельными пунктами не совсем ясны.

• Существуют сложные спорные моменты.

• Необходимо прийти к консенсусу внутри группы.

Эта техника включает следующие шаги [TAG04]:

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

• Сортировка карточек. Каждый участник выделяет пункты, имеющие какую-либо взаимосвязь, и помещает соответствующие карточки рядом друг с другом. Участники не должны взаимодействовать в течение этого шага. Если один пункт подходит сразу к нескольким группам, можно сделать копии карточек и поместить их в несколько групп. Этот шаг занимает несколько дней.

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

• Создание заголовков. Наименование будет создано для каждой группы.

• Структурирование модели. Если необходимо, некоторые группы можно будет скомбинировать в более большие группы, либо разделить на более мелкие.

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

Использование Прототипов

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

Анализ Существующих Документов

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

Бизнес модель	Комментарии к совещаниям
Содержание работы	Корпоративные нормы
Заявка на разработку	Письма
Бизнес правила	Электронная почта

Один из методов - это чтение документов и использование выделения текста чтобы отметить предложения, которые составляют требования.

Из документов, которые уже есть в электронной форме, Вы можете вырезать части текста и вставлять в RequisitePro в документ Запросов Заинтересованного Лица (Stakeholder Requests) - выделять с помощью мышки любое предложение, которые представляет собой требование, и хранить документ в базе данных. Пункт 5.4 объясняет, каким образом можно это выполнить.

В нашем проекте-образце требования от Пользователя 2 были получены через электронную почту:

-----Оригинальное Сообщение-----

От: Claude

Отправлено: Суббота, 26 Августа, 2006 19:01

Кому: Julia

Тема: Требования

Дорогая Julia,

В ответ на твое письмо я собрала немного требований для Вашей новой системы:

1. Пользователь должен иметь возможность сравнивать цены на билеты в других близлежащих аэропортах.

2. Даты должны отображаться в формате дд/мм/гггг.

3. На формах ввода данных должно показываться, какие поля являются обязательными для заполнения.

4. Должна быть возможность отмены покупки билета.

5. Пользователь должен иметь возможность отменить заказ машины или номера в гостинице.

6. Список рейсов вылета и возвращения должен быть отсортирован по наименьшему количеству остановок.

7. Пользователь должен иметь возможность выбрать место в самолете.

8. Интерфейс системы должен быть на естественном языке.

9. Система должна показывать всплывающее окно с календарем, когда пользователь вводит дату.

10. Пользователь с помощью флажка должен указывать, нужен ли ему/ей билет только в один конец, или билет туда и обратно.

С наилучшими пожеланиями,

Claude

Сценарии Использования (Use Cases)

Сценарии использования (Use Cases) являются одним из типов требований в пирамиде на Рисунке 1.1. в Главе 1 «Управление Требованиями». Это также формат, используемый заинтересованными лицами для выражения своих потребностей. Формат сценариев использования, созданный заинтересованными лицами, в конечном счете, используется аналитиками. Тем не менее, аналитики должны просмотреть поступившие от пользователя сценарии использования. Перед тем как поместить сценарии использования на третий уровень пирамиды, аналитики должны выполнить следующие действия:

1. Убедиться, что каждый шаг сценариев использования содержит все атрибуты для того, чтобы требование можно было считать хорошим, как было описано в пункте 1.4 «Характеристики Хорошего Требования» в Главе 1.

2. Импортировать сценарии использования в RequisitePro.

3. Создать требования, которые будут отсортированы в базе данных.

4. Установить соответствие с функциональными особенностями системы.

Наблюдение и демонстрирование задач

Иногда пользователи не могут выразить словами детали их задач. В этом случае может быть гораздо легче показать бизнес-аналитикам, каким образом эта задача должна быть выполнена [LAU02]. Преимуществом данного подхода является то, что пользователь может сконцентрироваться на задаче, в то время как аналитик записывает комментарии и проводит наблюдение. Отличием между наблюдением и демонстрированием задач является то, что при наблюдении пользователь представляет обычные задачи без привлечения внимания системного аналитика. При демонстрировании задач аналитик может попросить пользователя выполнить определенную задачу, и пользователь может выполнить демонстрацию с объяснениями.

Анализ Существующих Систем

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

• Морально устаревшие заменяемые системы.

• Системы, разработанные в ходе конкуренции.

Достаточно часто в ситуации, когда новая система заменяет старую систему, одним из требований должно быть:

Треб.1: Новая система должна предоставлять всю функциональность от предыдущей системы.

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

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

Так как в Интернете доступно большое количество агентств путешествий, для нашего проекта-образца системные аналитики решили проанализировать следующие веб-сайты:

• http://travel.yahoo.com

• www.expedia.com

• www.cheaptickets.com

• www.travelocity.com

5.3 Создание Документа Запросов Заинтересованного Лица

Вся полученная в процессе сбора требований информация должна быть документально оформлена в документ Запросов Заинтересованного Лица (Stakeholder Requests). В Вашем проекте Вы можете создать один документ, который будет содержать в себе запросы всех заинтересованных лиц, один документ для каждого заинтересованного лица, либо можете собрать запросы нескольких заинтересованных лиц в одном документе. Если нет необходимости описывать требования заинтересованного лица в деталях, Вы можете создать пункт «Stakeholders Requests» («Запросы Заинтересованных Лиц») в документе Концепции (Vision). Это снизит необходимость создания отдельного документа. Предположим, что в целях нашего проекта мы создадим шесть документов Запросов Заинтересованного Лица, сгруппировав заинтересованных лиц по методам сбора их требований (примененных к ним в пункте 5.2):

• «Запросы Заинтересованного Лица–Заказчик» содержит требования владельца агентства путешествий, собранные в результате интервью.

• «Запросы Заинтересованного Лица–Пользователь 1» содержит требования Пользователя 1.

• «Запросы Заинтересованного Лица–Пользователь 2» содержит требования Пользователя 2, отправленные по электронной почте.

• «Запросы Заинтересованного Лица–CSR» содержит требования CSR (представителя отдела обслуживания клиентов), собранные в процессе ролевых игр.

• «Запросы Заинтересованного Лица–Отдел Информационных Технологий» содержит требования администратора, контент-менеджера и разработчиков, собранные в результате семинара по требованиям.

• «Запросы Заинтересованного Лица–Служба Предоставления Услуг» содержит требования представителя гостиницы, агента по найму автомобиля и представителя авиалиний, собранные в результате анкетирования.

Создадим документ Запросы Заинтересованного Лица (Stakeholder Requests). В первую очередь, Вам нужно открыть созданный в предыдущей главе проект.

Открытие Проекта

Когда Вы запускаете RequisitePro, появляется диалоговое окно Open Project (Открыть Проект), как показано на Рисунке 5.3.

Рисунок 5.3. Диалоговое окно Open Project (Открыть проект).

Вы можете выбрать проект из списка (по умолчанию список содержит все ранее используемые проекты) или создать новый проект. Если Вы хотите открыть существующий проект, которого нет в списке, Вы должны сначала добавить проект в список существующих проектов нажатием на кнопку Add (Добавить). В данном случае мы выбираем проект Он-Лайн Агентство Путешествий (Online Travel Agency) из списка.

Добавление Типа Документа в Проект

Каждый тип документа обычно связан с некой моделью - шаблоном Microsoft Word (.dot файл). Суть данной модели и является стартовой точкой при создании нового документа. Модель включает в себя форматы, параметры страницы и шрифты. Вы можете использовать уже предустановленные шаблоны RequisitePro, либо создать их сами. Если Вы установите модель в None, то при создании нового документа этого типа откроется пустой документ Microsoft Word.

Тип документов «Запросы Заинтересованного Лица» включен в шаблон Use Case (Сценариев Использования), который мы использовали для создания нашего проекта, так что нет необходимости добавлять этот тип документа в наш проект.

Если Вы не уверены, что Ваш проект включает в себя тип документов «Запросы Заинтересованного Лица», выполните следующие действия:

1. Выберите проект в Explorer (Проводнике).

2. Выберите File>Properties (Файл>Свойства).

3. Выберите закладку Documents Type (Тип Документов).

Если тип документов «Запросы Заинтересованного Лица» находится в списке, то Вам не нужно добавлять его. Однако если этот тип документа отсутствует в проекте, следующие шаги помогут добавить его:

1. Выберите File>Properties (Файл>Свойства). Появится диалоговое окно File properties (Свойства Проекта).

2. Выберите закладку Documents Type (Тип Документов).

3. Нажмите Add (Добавить). Появится диалоговое окно Document Type (Тип Документа), как показано на Рисунке 5.4.

Рисунок 5.4. Диалоговое окно Document Type (Тип Документа).

4. Введите название документа, описание и расширение файла.

5. В списке Default Requirement Type (Тип Требования по Умолчанию) выберите «Запросы Заинтересованного Лица». Если такого типа нет в списке, создайте его, нажав на кнопку New (Новый), и заполнив диалоговое окно.

6. В списке Outline Name (Названия Моделей) выберите RUP Stakeholder Requests outline.

7. Нажмите OK, чтобы закрыть диалоговое окно Document Type (Тип Документа).

8. Нажмите OK, чтобы закрыть диалоговое окно Project Properties (Свойства Проекта).

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

Создание Документа Запросов Заинтересованного Лица

Чтобы создать документ Запросов Заинтересованного Лица (Stakeholder Requests) выполните следующие шаги:

1. Выберите папку, где Вы хотели бы создать документ. В шаблоне Use Case (Сценариев Использования), папка «Stakeholders Requests» («Запросы Заинтересованных Лиц») уже создана.

2. Выберите File>New>Document (Файл>Новый>Документ) (или нажмите правой кнопкой мышки на папке и выберите New>Document).

Появится диалоговое окно Document Properties (Свойства Документа), как показано на Рисунке 5.5.

3. В поле Name (Имя) введите имя документа. Если у вас только один документ в проекте, он может называться просто «Запросы Заинтересованного Лица». Если Вы создаете документ для каждого заинтересованного лица, включите в название документа имя или тип заинтересованного лица, например «Пользователь». Если это комбинированный документ для нескольких заинтересованных лиц, к которым был применен определенный метод сбора требований, Вы можете включить метод в название документа, например «Запросы Заинтересованного Лица–Анкетирование», либо можете использовать название группы заинтересованных лиц, например «Запросы Заинтересованного Лица-Служба Предоставления Услуг».

4. В поле Description (Описание) введите краткое описание документа.

Рисунок 5.5. Диалоговое окно Document Properties (Свойства Документа).

5. В поле Filename (Название Файла) введите название файла, которое RequisitePro будет использовать при сохранении документа. Оно может быть аналогично названию документа или являться только его аббревиатурой.

6. Выберите Document Type (Тип Документа) - Stakeholder Requests (Запросы Заинтересованного Лица).

7. Нажмите ОК.

Новый созданный документ появится в окне Microsoft Word, как показано на Рисунке 5.6.

Рисунок 5.6. Начальная страница документа Запросов Заинтересованного Лица (Stakeholder Requests).

RequisitePro управляет документом через рабочее пространство Microsoft Word. Вы можете изменять текст в документе так же, как бы Вы это делали с обычным документом Microsoft Word. Некоторые поля в шаблоне содержат общие названия как <Company Name> (Название Компании) или <Project Name> (Название Проекта). При выборе, фон у этих полей становится серым. Они должны быть заменены актуальными значениями. Наиболее удобный способ их поменять - это открыть диалоговое окно Properties (Свойства) (выберите File>Properties (Файл>Свойства)) и ввести соответствующие имена, как показано на Рисунке 5.7.

Рисунок 5.7. Диалоговое окно Document Properties (Свойства Документа).

После того как были установлены свойства документа, Вы можете сменить поле в шаблоне путем помещения курсора на поле и нажатия F9. Поле будет заполнено соответствующим значением из диалогового окна Properties (Свойства), как показано на Рисунке 5.8.

Рисунок 5.8. Первая страница документа с соответствующими полями, полученными из диалогового окна Document Properties (Свойства Документа).

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

Формат документа Запросов Заинтересованного Лица зависит от используемого при сборе требований метода. Изначальная версия документа содержит сценарий интервью, используемый в предыдущем пункте «Интервью». Тем не менее, общая структура документа может быть модифицирована в зависимости от Ваших потребностей.

Рисунок 5.9. показывает простой формат, который мы использовали для создания этого документа для Пользователя 2, предоставившего требования по электронной почте. Требования были просто вырезаны из письма и вставлены в параграф №3 документа.

Рисунок 5.9. Пример структуры документа Запросов Заинтересованного Лица (Stakeholder Requests).

После заполнения документа считается хорошей практикой пересмотреть таблицу содержания:

1. Поместите курсор на таблицу содержания.

2. Выберите Insert>Reference>Index and Tables (Вставить> Ссылка>Таблицы).

3. Выберите закладку Table of Contents (Таблица Содержания).

4. Нажмите ОК. Появится сообщение, спрашивающее Вас: «Желаете ли Вы заменить выбранную таблицу содержания?».

5. Нажмите Yes (Да).

В конце сохраните документ. Выберите RequisitePro>Document>Save (Документ>Cохранить). (Не выбирайте File>Save (Файл>Сохранить), как Вы бы сделали в обычном документе Microsoft Word).

5.4 Создание Требований в RequisitePro

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

Документ Запросов Заинтересованного Лица не содержит специально выделенного места для размещения требований типа STRQ (Stakeholder Requests или Запросы Заинтересованного лица). Требования могут быть вложены в качестве ответов на вопросы интервью, либо собраны в последнем параграфе, названным «Резюме Аналитика».

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

Требования могут быть созданы в RequisitePro пятью разными способами:

1. Создание в документе (используя рабочее пространство Microsoft Word).

2. Создание во view (представлении).

3. Создание в Explorer (Проводнике).

4. Импорт из файла, имеющем точку с запятой в качестве разделителя (CSV).

5. Импорт из документа требований.

Данная глава описывает создание требований из документа Microsoft Word, который является наиболее популярным.

Добавление Требований в Документ

Для создания требований в документе Microsoft Word выполните следующие действия:

1. Выделите текст, описывающий требование, как показано на Рисунке 5.10.

Рисунок 5.10. Выделение текста требования в документе.

2. Выберите RequisitePro>Requirement>New (Требование>Новое), или нажмите правую кнопки мышки на тексте и выберите Create Requirement (Создать Требование), или нажмите иконку New Requirement (Новое Требование) на панели управления.

Появится диалоговое окно Requirement Properties (Свойства Требования), как показано на Рисунке 5.11. Текст уже скопирован с выделенной в документе области. Если необходимо, Вы можете добавить название. Для этого типа документа тип установлен по умолчанию. Вы можете поменять его при необходимости.

Рисунок 5.11. Диалоговое окно Requirement Properties (Свойства Требования): Основная закладка.

3. Выберите STRQ (Запросы Заинтересованного лица) как тип требования.

4. Если Вы хотите настроить атрибуты, нажмите закладку Attributes (Атрибуты), как показано на Рисунке 5.12.

Рисунок 5.12. Диалоговое окно Requirement Properties (Свойства Требования): закладка Атрибуты.

5. Нажмите ОК.

Атрибуты требования могут быть также изменены из view (представления) и из Explorer (Проводника). Каждое требование включает префикс и числовое значение. RequisitePro присваивает уникальный тег каждому создаваемому требованию. Тег требования – это его уникальный идентификатор. Префиксы связаны с типами требований.

Пока документ еще не сохранен, теги отображаются со словом «pending» (ожидающие), как показано на Рисунке 5.13.

Рисунок 5.13. Находящиеся на ожидании требования.

Чтобы сохранить документ, выберите в окне Microsoft Word RequisitePro>Document>Save (Документ>Сохранить). Не выбирайте File>Save (Файл>Сохранить).

После сохранения документа,теги содержат префиксы с описанием типа требования и упорядоченными номерами, как показано на Рисунке 5.14.

Рисунок 5.14. Сохраненные требования.

Требования могут быть просмотрены в окне Explorer (Проводника), как показано на Рисунке 5.15.

Когда Вы закончите с первым документом Запросов Заинтересованного Лица, Вы можете создать подобные документы для остальных заинтересованных лиц.

Рисунок 5.15. Окно Проводника, отображающее STRQ требования (Запросы Заинтересованного лица).

Изменение Атрибутов Типов Требований

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

1. Поместите курсор на название проекта в Explorer (Проводнике).

2. Выберите File>Properties (Файл>Свойства).

3. Выберите закладку Requirement (Требование).

4. Выберите тип требования STRQ (Запросы Заинтересованного лица), как показано на Рисунке 5.16.

Рисунок 5.16. Выбор типа требования STRQ (Запросы Заинтересованного лица).

5. Нажмите Edit (Редактировать).

6. Смените цвет требования на Dark Blue (темно-голубой), как показано на Рисунке 5.17.

Появится следующее окно сообщений: «Данная функция требует, чтобы проект был открыт эксклюзивно. Хотите ли Вы получить эксклюзивный доступ к проекту сейчас?».

Рисунок 5.17. Смена цвета требования на темно-голубой.

7. Нажмите Yes (Да) для подтверждения открытия проекта в эксклюзивном режиме. Появится окно сообщения о подтверждении действия.

8. Нажмите OK в окне подтверждения.

9. Нажмите OK в диалоговом окне Requirement Type (Тип Требования).

10. Нажмите OK на экране Project Properties (Свойства Проекта).

Атрибут, отвечающий за цвет для STRQ требований (Запросов Заинтересованного лица), сменился.

Добавление Требований из Проводника

Если Вы решили, что проект не требует документов Запросов Заинтересованного Лица, но Вам необходимы требования типа STRQ (Запросы Заинтересованного лица), Вы можете добавить требования из view (представления) или из Explorer (Проводника).

Для добавления требования из Explorer (Проводника) выполните следующие действия:

1. Нажмите правой кнопкой мышки на названии папки, в которой Вы хотите создать требование.

2. Выберите New>Requirement (Новое>Требование). Появится то же самое диалоговое окно Requirement Properties (Свойства Требования).

3. Заполните необходимые поля и нажмите ОК.

Изменение Требований из Проводника

Вне зависимости от того, каким образом требование было создано, Вы можете изменить его через Explorer (Проводник).

1. Нажмите правой кнопкой мышки на требовании STRQ (Запросы Заинтересованного лица) в Explorer (Проводнике) и выберите Properties (Свойства).

2. Внесите необходимые изменения и нажмите ОК.

Удаление Требований из Проводника

Для удаления требования из Explorer (Проводника) выполните следующие действия:

1. Выделите требование.

2. Нажмите правой кнопкой мышки на нем и выберите Delete (Удалить).

Удаленные требования не могут быть восстановлены. Если Вы считаете, что Вам необходима функциональность восстановления, лучше создать дополнительный статус, названный «Deleted» (Удаленный). Требования с этим статусом могут быть восстановлены путем смены статуса в обратном порядке на Proposed (Планируемый) или Approved (Подтвержденный).

5.5 Создание Views (Представлений) для Анализа Требований

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

• Attribute Matrix (Матрица Атрибутов)

• Traceability Matrix (Матрица Трассировки)

• Traceability Tree (Дерево Трассировки)

В этой главе рассматривается Матрица Атрибутов. Остальные два типа будет рассмотрены в следующих главах.

Создание Матрицы Атрибутов

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

1. Нажмите правой кнопкой мышки на папке, где Вы хотите создать представление (папка «Stakeholders Requests» будет хорошим выбором в данном случае), и выберите New>View (Новое>Представление). В качестве альтернативы Вы можете выделить папку, где Вы хотите создать view, и выбрать File>New>View (Файл>Новое>Представление).

Появится диалоговое окно View Properties (Свойства Представления), как показано на Рисунке 5.18.

2. Дайте название представлению.

3. Выберите View Type (Тип Представления - Матрица Атрибутов, Матрица Трассировки или Дерево Трассировки). В данном случае - Матрица Атрибутов.

4. Выберите Row Requirement Type (Тип Требования в Строке) – в данном случае STRQ (Запросы Заинтересованного Лица).

Если бы Вы создавали Матрицу Трассировки, Вам бы также понадобилось бы выбрать Column Requirement Type (Тип Требования в Столбце).

Рисунок 5.18. Диалоговое окно View Properties (Свойства Представления).

5. Нажмите ОК.

Открытие View (Представления)

Многие представления уже предустановленны в шаблонах проектов. Так как мы использовали шаблон Use Case (Сценариев Использования), у нас уже есть представление All Stakeholders Requests (Все Запросы Заинтересованного Лица) в папке Stakeholders Requests. Нам надо лишь открыть представление, выполнив следующие действия:

1. Откройте папку Features and Vision (Функциональные Особенности и Концепция).

2. Двойным щелчком мышки нажмите на представление All Features (Все свойства).

Матрица Атрибутов отобразит все требования определенного типа с их атрибутами. Это отображение в табличном виде с именами требований в строках и атрибутов в столбцах, как показано на Рисунке 5.19.

Рисунок 5.19. Матрица Атрибутов, показывающая все потребности заинтересованных лиц и их атрибуты.

Чтобы изменить набор отображаемых атрибутов выполните следующие действия:

1. Поместите курсор на заголовок строки на панели представления, нажмите правой кнопкой мышки и выберите Displayed Attributes (Отображаемые Атрибуты).

2. В списке Displayed Attributes (Отображаемые Атрибуты) выберите атрибуты, которые Вы хотите видеть на представлении, как показано на Рисунке 5.20.

Рисунок 5.20. Выбор атрибутов для отображения в матрице атрибутов.

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

1. Нажмите правой кнопкой мышки на соответствующей ячейке и выберите Set Value (Установить Значение).

2. Выберите значения из списка, как показано на Рисунке 5.21.

Рисунок 5.21. Установка значения атрибута с использованием диалогового окна Set Value (Установить Значение).

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

Рисунок 5.22. Установка значения атрибута с использованием выпадающего списка в ячейке.

Чтобы изменить Requirement Name (Название Требования) или Text (Текст), нажмите правой кнопкой мышки на требовании и выберите Properties (Свойства).

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

Экспорт Представлений (Views)

Мы можем экспортировать представления в документ Microsoft Word или в CSV-файл (который мы можем открыть с помощью Microsoft Exсel). Это позволяет использовать данную информацию вне среды Requisite Pro.

Для экспорта только что созданной нами матрицы атрибутов выполните следующие действия:

1. Выберите File>Export>Export to CSV (Файл>Экспорт>Экспорт в CSV).

2. Введите название файла.

3. Нажмите кнопку Save (Сохранить).

Представление сохраняется в CSV-файле, который Вы можете открыть с использованием Microsoft Exсel, как показано на Рисунке 5.23.

Рисунок 5.23. Матрица Атрибутов, экспортированная в Excel.

Создание Запросов для Требований

Вы можете создавать запросы для требований (на фильтрацию и сортировку информации) в Матрице Атрибутов (Attribute Matrix). Чтобы фильтровать строки, Вы можете указать, каким критериям должны удовлетворять строки для отображения в матрице. В качестве примера, отобразим только требования, которые имеют приоритет High (Высокий) или Medium (Средний), а Origin (Источник) требования - Пользователя 1 или Пользователя 2.

1. Нажмите правой кнопкой мышки на левом верхнем квадрате представления.

2. Выберите Query (Запрос). Появятся диалоговые окна Query Row Requirements (Запрос к Требованиям в Строке) и Select Attribute (Выбор Атрибута).

3. Выберите Priority (Приоритет) из списка атрибутов и нажмите ОК.

4. Выберите High (Высокий) и Medium (Средний) из списка значений атрибутов и нажмите ОК.

5. Нажмите Add (Добавить).

6. Выберите Origin (Источник) из списка атрибутов. Нажмите ОК.

7. Выберите Пользователь 1 и Пользователь 2 из списка значений атрибутов, как показано на Рисунке 5.24.

Рисунок 5.24. Выбор значений атрибутов для фильтрации.

8. Сохраните все изменения нажатием кнопки ОК, как показано на Рисунке 5.25.

Рисунок 5.25. Все критерии запроса (соединенные оператором «AND» - «И»).

В диалоговом окне Query Row Requirements (Запрос к Требованиям в Строке) Вы также можете установить Sort Order (Порядок Сортировки) для выбираемых атрибутов в Ascending (Восходящий) or Descending (Нисходящий).

Чтобы отменить все фильтры и вернуться к оригинальному виду выполните следующие действия:

1. Нажмите правой кнопкой мышки на левом верхнем квадрате view.

2. Выберите Query (Запрос).

3. Нажимайте кнопку Remove (Удалить) в диалоговом окне Query Row Requirements (Запрос к Требованиям в Строке), пока Вы не удалите все строки.

4. Нажмите ОК.

Вы можете сохранить результаты запроса в представлении. Представление будет отображать состояние на момент времени запроса. Чтобы отобразить недавно сделанные изменения в базе данных, Вам необходимо выбрать View>Refresh (Представление>Обновить).