5.6 Заключение
Запросы заинтересованных в разработке системы лиц могут быть собраны с помощью различных методов сбора информации. Мы обсудили одиннадцать из них. Какую технику выбрать – зависит от природы требований и типа заинтересованного лица. Хорошей практикой считается запись результатов в RequisitePro в форме документов Запросов Заинтересованных Лиц (Stakeholder Requests), а также хранение требований в базе данных. Наличие потребностей заинтересованных лиц в базе данных позволит Вам присваивать им различные атрибуты, такие как приоритет сложности. Также это позволит Вам отслеживать требования и сводить их к требованиям другого типа.
Ссылки
[RUP04] Rational Unified Process, Version 2003.06.13, IBM, 2003.
[TAG04] Tague, Nancy. The Quality Toolbox, ASQ Quality Press, 2004.
[LAU02] Lauesen, Soren. Software Requirements: Styles and Techniques, Pearson Education.
Глава 6
Разработка Документа
Концепции (Vision)
Документ Концепции (Vision) – один из трех наиболее важных документов, создаваемых в RequisitePro (другие два: Сценарии Использования - Use Cases и Дополнительная Спецификация - Supplementary Specification). Документ Концепции содержит следующую информацию:
Описание проблемы, которая будет решаться новой системой.
Высокоуровневое описание решения проблемы.
Список основных функциональных особенностей системы.
Концепция может выступать в качестве контракта между заказчиком и разработчиками для технических требований. Назначение документа Концепции:
Определить границы системы.
Определить ограничения, налагаемые на систему.
Прийти к соглашению с заказчиком по поводу объема работ.
Создать основу, на которой определить Сценарии Использования (Use Cases) и Дополнительную Спецификацию (Supplementary Specification).
Концепция – это хранилище для требований типа Feature (Функциональные особенности), как показано на Рисунке 6.1. Данная глава показывает несколько примеров извлечения функциональных особенностей из потребностей, а также рассматривает атрибуты функциональных особенностей.
Рисунок 6.1. Функциональные особенности находятся на втором уровне пирамиды.
6.1 Структура Документа Концепции
Содержание документа Концепции (Vision), предустановленное шаблоном RequisitePro [RUP04]:
1. Introduction (Введение)
1.1 Purpose (Назначение)
1.2 Scope (Область Применения)
1.3 Definitions, Acronyms, and Abbreviations (Определения, Акронимы и Аббревиатуры)
1.4 References (Ссылки)
1.5 Overview (Обзор)
2. Positioning (Позиционирование)
2.1 Business Opportunity (Возможности Бизнеса)
2.2 Problem Statement (Изложение Проблемы)
2.3 Product Position Statement (Изложение Позиции Продукта)
3. Stakeholder and User Descriptions (Описание Заинтересованных Лиц и Пользователей)
3.1 Market Demographics (Демография на Рынке)
3.2 Stakeholder Summary (Сводка по Заинтересованным Лицам)
3.3 User Summary (Сводка по Пользователям)
3.4 User Environment (Программная Среда Пользователей)
3.5 Stakeholder Profiles (Профили Заинтересованных Лиц)
3.6 User Profiles (Профили Пользователей)
3.7 Key Stakeholder or User Needs (Ключевые Потребности Заинтересованных Лиц или Пользователей)
3.8 Alternatives and Competition (Альтернативы и Конкуренция)
3.8.1 <Конкурент>
3.8.2 <другойКонкурентr>
4. Product Overview (Обзор Продукта)
4.1 Product Perspective (Перспективы Продукта)
4.2 Summary of Capabilities (Сводка по Возможностям)
4.3 Assumptions and Dependencies (Предположения и Зависимости)
4.4 Cost and Pricing (Стоимость)
4.5 Licensing and Installation (Лицензирование и Установка)
5. Product Features (Функциональные Особенности Продукта)
5.1 <ФункциональнаяОсобенность>
5.2 <другаяФункциональнаяОсобенность>
6. Constraints (Ограничения)
7. Quality Ranges (Пределы Качества)
8. Precedence and Priority (Очередность и Приоритетность)
9. Other Product Requirements (Другие Требования к Продукту)
9.1 Applicable Standards (Приемлемые Стандарты)
9.2 System Requirements (Системные Требования)
9.3 Performance Requirements (Требования к Производительности)
9.4 Environmental Requirements (Требования к Программной Среде)
10. Documentation Requirements (Требования к Документации)
10.1 User Manual (Руководство Пользователя)
10.2 Online Help (Он-лайн Справка)
10.3 Installation Guides, Configuration, and Read Me File (Руководство по Установке, Конфигурированию, Файл «Прочти Меня»).
10.4 Labeling and Packaging (Маркировка и Оформление Пакета Программы)
Вы можете изменить содержание согласно Вашему проекту, удаляя неподходящие пункты или добавляя новые пункты, специфичные для конкретного проекта.
Концепция представляет собой хранилище для требований типа Feature (Функциональные особенности). Они перечисляются в пункте «Product Features» («Функциональные Особенности Продукта»). Другие пункты обычно заполняются в свободной форме и не содержат никаких требований.
6.2 Извлечение Функциональных Особенностей из Потребностей Заинтересованных Лиц
Функциональные особенности извлекаются из запросов заинтересованных лиц. Для каждой функциональной особенности важно отслеживать, из какого запроса она была получена. Тогда при хранении запросов заинтересованных лиц в RequisitePro они могут быть трассированы в реализующие их функциональные особенности.
Полученные от заинтересованных лиц требования не обязательно обладают характеристиками хорошего требования, описанных в пункте 1.4 «Характеристики Хорошего Требования» в Главе 1 «Управление Требованиями». Извлечение функциональных особенностей из запросов заинтересованных лиц предоставляет Вам хорошую возможность исправить это. Один из подходов – это пройти по всем требованиям STRQ и применить соответствующее преобразование для создания одного или более требований FEAT.
Могут быть применены следующие преобразования:
Copy (Копирование): Если не требуется дополнительных изменений, STRQ может быть просто скопировано в FEAT без изменений. Наличие требований разного типа с одинаковым текстом вполне нормально. Тем не менее, лучше избегать таких одинаковых требований, иначе требования будут многословными.
Split (Разделение): Если требование не элементарное, мы можем разделить его на два или более требований.
Clarification (Пояснение): Пояснение (или объяснение) может быть применено, когда оригинальное требование непонятное или двусмысленное.
Qualification (Уточнение): Мы выполняем уточнение путем наложения ограничений или условий на требования. Это может помочь разрешить противоречивые требования.
Combination (Комбинирование): Многословные или перекрывающиеся требования могут быть скомбинированы в одно.
Generalization (Обобщение): Если требование не абстрактно и включает некоторые ненужные детали, мы можем применить обобщение.
Cancellation (Отмена): Иногда требование нужно удалить. Это может случиться, когда требование невыполнимое, ненужное или несовместимо с другим требованием.
Completion (Завершение): Если набор требований не закончен, нам может понадобиться добавить требования на данную стадию.
Correction (Коррекция): Коррекция может означать как перефразировку требования, чтобы исправить грамматические ошибки, орфографические и ошибки пунктуации, так и изменение неверной части требования.
Unification (Унификация): Требования, которые используют недопустимую терминологию, могут быть приведены к соответствующему виду.
Adding Details (Добавление Деталей): Если требование определено не точно, мы можем добавить детали. Этот способ часто используется, чтобы сделать все требования возможными для тестирования.
Глава 5 «Сбор Требований» описывает требования типа запросов заинтересованных лиц. Проанализируем все запросы заинтересованных лиц, собранные в Главе 5 (одно за другим) и создадим из них функциональные особенности.
STRQ1 Пользователь должен иметь возможность сравнивать цены на билеты в других близлежащих аэропортах.
Это требование считается многословным вместе с STRQ11. Они могут быть скомбинированы в одно требование:
FEAT1 Пользователь должен иметь возможность сравнивать цены на билеты в других близлежащих аэропортах (для рейсов вылета и прибытия).
STRQ2 Дата должна отображаться в формате дд/мм/гггг.
Это требование не совпадает с STRQ16, которое указывает формат даты мм/дд/гггг. Требование STRQ2 было получено из Франции, а STRQ16 – из США. Подпункт «Метод «Мозгового Штурма» (Brainstorming Sessions)» пункта 5.2 «Методы Сбора Требований» Главы 5 рассматривает, каким образом разрешать такую ситуацию. Требования STRQ2 и STRQ16 были заменены следующим требованием:
FEAT2 Даты должны отображаться в формате, принятом в настройках веб-браузера.
STRQ3 На формах ввода данных система должна показывать, какие поля являются обязательными для заполнения.
На определенном этапе будет принято решение о том, каким именно образом должны обозначаться обязательные поля. Это решение может быть принято при создании требования типа FEAT, либо немного позже, когда из функциональных особенностей извлекаются дополнительные требования. Предположим, что мы хотим это сделать сейчас, так что мы добавим пояснение для создания FEAT:
FEAT3 На формах ввода данных система должна показывать, какие поля являются обязательными для заполнения, с помощью звездочки перед обязательным полем.
STRQ4 Может быть предоставлена возможность отмены покупки билета.
Для большей точности при описании требований лучше использовать стандартные конструкции. Например, использовать «должна» вместо «может». Использование таких слов, как «может» вместо «должна», может привести к неправильному пониманию уровня необходимости требования. (Например, «должна» звучит более убедительно, чем «может»).
Здесь необходимо пояснение, кто именно будет иметь возможность отменить билет (пользователь, представитель отдела обслуживания клиентов или администратор), а также на какой стадии процесса эта операция будет допустима:
FEAT4 Пользователь должен иметь возможность отменить покупку билета в любое время перед последним подтверждением о покупке.
STRQ5 Пользователь должен иметь возможность отменить заказ машины или номера в гостинице.
Решение о том, является ли определенное требование элементарным или нет, зависит от системного аналитика. В этом случае он решил, что возможность отмена брони машины или номера в гостинице должны быть в одном требовании, поэтому нет необходимости разделять его:
FEAT5 Пользователь должен иметь возможность отменить заказ машины или номера в гостинице.
STRQ6 Список рейсов вылета и возвращения должен быть отсортирован по наименьшему количеству остановок.
Терминология требования не совпадает с STRQ11. Рейсы «прибытия» в данном требовании названы в STRQ11 «рейсами возвращения». Предположим, что после консультации со специалистами, мы решили использовать термин «рейсы возвращения». Тем не менее, мы уже соединили STRQ11 и STRQ1 в FEAT1. Мы должны вернуться обратно к FEAT1 и соответственным образом изменить его:
FEAT1 Пользователь должен иметь возможность сравнивать цены на билеты в других близлежащих аэропортах (для рейсов вылета и возвращения).
Т.к. мы изменили FEAT1 соответственно с STRQ6, мы можем переписать STRQ6 в FEAT6:
FEAT6: Список рейсов вылета и возвращения должен быть отсортирован по наименьшему количеству остановок.
Однако это противоречит STRQ18, которое указывает, что рейсы должны быть отсортированы по цене билета. Мы можем объединить эти два требования в одну функциональную особенность:
FEAT6 Пользователь должен иметь возможность выбирать, сортировать рейсы по наименьшему количеству остановок или по цене.
Как Вы видите, извлечение функциональных особенностей - это итеративный процесс, и некоторые требования должны быть изменены по нескольку раз, пока они станут соответствовать друг другу, и перестанут быть многословными.
STRQ7 Пользователь должен иметь возможность выбрать место в самолете.
Чтобы требование выглядело абсолютно независимым, добавим пояснение:
FEAT7: При покупке билета на самолет пользователь должен иметь возможность выбрать место в самолете.
STRQ8 Интерфейс системы должен быть на естественном языке.
На первый взгляд с этим требованием все в порядке. Однако после анализа объема системы и некоторых ограничений стало ясно, что это требование нереально (невыполнимо). Оно противоречит требованию STRQ27, которое указывает, что система должна быть разработана в течение трех месяцев. Выполнение интерфейса в естественном языке заняло бы более чем три месяца. Это требование отменено, а предоставивший это требование пользователь извещен об отмене.
STRQ9 Система должна показывать всплывающее окно с календарем, когда пользователь вводит дату.
Это требование перекрывается STRQ21, которое указывает, что календарь должен появляться при вводе даты рейса. Т.к. STRQ9 более общее (оно имеет в виду любую дату, включая даты пребывания в гостинице и даты аренды автомобиля), мы перепишем STRQ9 и отменим STRQ21. В качестве пояснения, мы можем привести список всех дат:
FEAT8: Система должна показывать всплывающее окно с календарем, когда пользователь вводит даты, такие как дата рейса, дата пребывания в гостинице и дата аренды автомобиля.
STRQ10 Пользователь с помощью флажка должен указывать, нужен ли ему/ей билет только в один конец, или билет туда и обратно.
Это требование содержит ненужные элементы дизайна. Подобные детали реализации должны быть оставлены на усмотрение дизайнера. На этой стадии не должно происходить подобного анализа и детализации:
FEAT9: Пользователь должен иметь возможность указывать, нужен ли ему/ей билет только в один конец или билет туда и обратно.
STRQ11 Для рейсов вылета и прибытия пользователь должен иметь возможность сравнивать цены на билеты в других близлежащих аэропортах.
Это требование было соединено с STRQ1 в FEAT1, и поэтому может быть удалено.
STRQ12 Иногда пользователь будет вводить код аэропорта, который система будет распознавать. В других случаях пользователь будет вводить близлежащий город. В этом случае пользователю нет необходимости знать код аэропорта, поскольку система будет понимать название города.
Это предложение очень сложное и непонятное. Мы можем заменить его на более простое:
FEAT10: Система будет идентифицировать аэропорт на основании кода аэропорта, либо названия города.
STRQ13 Система будет проста в управлении.
Это требование довольно неточное, и оно недостаточно определено для проведения тестирования. Из него могут быть извлечены две более конкретных функциональных особенности:
FEAT11: Для основной функциональности должны присутствовать отдельные закладки.
FEAT12: На каждой странице кнопка Next (Далее) должна определять основной сценарий работы приложения.
STRQ14 Если пользователь прежде уже покупал билет, то он не должен будет вводить заново информацию, такую как адрес или номер кредитной карты.
В этом требовании мы добавим пояснение «при следующих операциях»:
FEAT13: Если пользователь прежде уже покупал билет, то при следующих операциях он не должен будет вводить заново информацию (такую как адрес или номер кредитной карты).
STRQ15 Должна быть реализована возможность оплаты через PayPal.
Это требование противоречит STRQ41, которое указывает, что оплата через PayPal не может быть доступна. Т.к. по некоторым причинам этот сервис не может быть предоставлен, мы должны отменить это требование.
STRQ16 Дата должна отображаться в формате мм/дд/гггг.
Это требование было соединено с требованием STRQ2 в FEAT1.
STRQ17 Список доступных рейсов должен включать такую информацию, как номер рейса, время отправления и время прибытия для каждого отрезка пути.
С этим требованием все в порядке, так что мы просто переписываем его:
FEAT14: Список доступных рейсов должен включать такую информацию, как номер рейса, время отправления и время прибытия для каждого отрезка пути.
STRQ18 Он должен быть отсортирован по ценам.
Слово «Он» относится к предыдущему требованию. Но если порядок требований изменить, то это требование будет непонятно.
Чтобы стать независимым, требование должно быть перефразировано следующим образом:
Список доступных рейсов должен быть отсортирован по ценам.
Однако мы уже включили это требование в FEAT6.
STRQ19 Должна быть предоставлена возможность сравнения цен различных компаний на аренду машин.
Требование корректно. Нам только нужно удалить пассивный залог:
FEAT15: Система должна предоставлять возможность сравнения цен различных компаний на аренду машин.
STRQ20 Цены на аренду машин должны включать все соответствующие налоги (включая налог штата - 6%).
Налоги зависят от конкретного штата, поэтому предоставленная цифра в 6% некорректна. Мы можем вырезать эти слова в скобках, оставив вычисление налогов дизайнерам:
FEAT16: Цены на аренду машин должны включать все соответствующие налоги.
STRQ21 Для удобства выбора даты рейса в системе должен присутствовать календарь.
Это требование было включено в FEAT8.
STRQ22 Система должна предоставлять возможность бронировать рейс, покупать билет, бронировать номер в гостинице, арендовать автомобиль, а также будет предоставлять информацию о туристических развлечениях.
Это требование представляет собой комбинацию пяти элементарных требований, которые делают сложным процесс трассировки (установки связей). Это требование будет разделено на пять элементарных:
FEAT17: Система должна предоставлять возможность бронировать рейс.
FEAT18: Система должна предоставлять возможность покупать билет на самолет.
FEAT19: Система должна предоставлять возможность бронировать номер в гостинице.
FEAT20: Система должна предоставлять возможность арендовать автомобиль.
FEAT21: Система должна предоставлять информацию о туристических развлечениях в определенных местах пребывания.
STRQ23 Пользователь должен иметь возможность купить билет через веб-сайт без необходимости звонков по телефону туристическому агенту.
С этим требованием все в порядке, так что мы просто копируем его:
FEAT22: Пользователь должен иметь возможность купить билет через веб-сайт без необходимости звонков по телефону туристическому агенту.
STRQ24 Система должна следовать инструкциям по разработке, установленных в сети наших бюро путешествий.
Это требование не совсем ясно до тех пор, пока отсутствует конкретный документ с инструкциями по реализации. Либо если просто не перечислены все инструкции. Например:
FEAT23: Система должна использовать архитектуру J2EE.
FEAT24: Если архитектура требует сервер приложения, должен быть использован IMB WebSphere.
FEAT25: Если система требует базу данных, должен быть использован Oracle.
STRQ25 Страницы, где представители служб сервиса предлагают свои услуги, должны быть защищены паролем. Представители гостиниц, агенты по найму автомобилей и представители авиалиний должны иметь свои ID (идентификаторы) и пароли для доступа к этим страницам.
С этим требованием все в порядке, так что мы просто копируем его:
FEAT26: Страницы, где представители служб сервиса предлагают свои услуги, должны быть защищены паролем. Представители гостиниц, агенты по найму автомобилей и представители авиалиний должны иметь свои ID (идентификаторы) и пароли для доступа к этим страницам.
STRQ26 Система должна быть доступной 24 часа в сутки с уровнем надежности, соответствующим коммерческим приложениям.
Это требование недостаточно определено для проведения тестирования. На определенном этапе нам будет нужно заменить его более детальным требованием относительно надежности. Мы можем сделать это сейчас, в процессе создания функциональных особенностей, либо мы подождать до создания Дополнительной Спецификации. Вполне нормально принимать окончательные решения по нефункциональным требованиям в процессе извлечения дополнительных требований из функциональных особенностей. На настоящий момент, сохраним требование так, как оно есть:
FEAT27: Система должна быть доступной 24 часа в сутки с уровнем надежности, соответствующим коммерческим приложениям.
STRQ27 Система должна быть разработана в течение трех месяцев.
Мы можем добавить пояснение, когда именно начинается отсчет времени:
FEAT28: Система должна быть разработана в течение трех месяцев с начала даты, когда заказчик подпишет документы Сценариев Использования и Дополнительную Спецификацию.
STRQ28 Пользователи должны выбирать свой ID и предоставлять пароль при покупке билета.
Мы можем просто скопировать это требование, т.к. оно не требует исправлений:
FEAT29: Пользователи должны выбирать свой ID и предоставлять пароль при покупке билета.
STRQ29 Функция поиска должна позволять представителю отдела обслуживания клиентов искать запись, используя следующие критерии: Фамилия, Пункт Назначения, Дата, и т.д.
«И т.д.» выражает некую неопределенность. После того как источник требования подтвердил, что не требуется никаких других критериев поиска (кроме перечисленных в требовании), «и.т.д.» было удалено.
FEAT30: Функция поиска будет должна представителю отдела обслуживания клиентов искать запись, используя следующие критерии: Фамилия, Пункт Назначения, Дата.
STRQ30 Представитель отдела обслуживания клиентов должен иметь возможность вносить изменения в детали брони или отменить заказ.
Т.к. это требование не элементарно, разделим его на два требования:
FEAT31: Представитель отдела обслуживания клиентов должен иметь возможность вносить изменения в детали брони.
FEAT32: Представитель отдела обслуживания клиентов должен иметь возможность отменить заказ.
STRQ31 При вводе данных контент-менеджер должен иметь возможность вводить обычный текст без тегов HTML.
С этим требованием все в порядке, так что мы просто копируем его:
FEAT31: При вводе данных контент-менеджер должен иметь возможность вводить обычный текст без тегов HTML.
STRQ32 Информация должна храниться в текстовом файле.
Решение того, каким образом информация будет храниться, и затем передаваться пользователю, должно приниматься дизайнерами или архитекторами системы. Это требование может быть отменено. Тем не менее, предположение может быть передано дизайнерам для рассмотрения.
STRQ33 Система должна быть полностью протестирована под только популярными браузерами.
После доведения до сведения заказчика того, что нереально протестировать систему под всеми доступными браузерами, заказчик согласился сократить их число до двух: Internet Explorer и Netscape.
FEAT34: Система должна быть полностью протестирована под следующими браузерами: Internet Explorer и Netscape.
STRQ34 Система должна отображать схему проезда до аэропорта.
Это требование поступило от разработчика, не являющимся ни заказчиком, ни пользователем. После согласования с заказчиком было подтверждено, что это требование не нужно, так что оно было отменено.
STRQ35 Функция поиска должна позволять пользователю искать заказ по следующим критериям: Фамилия, Дата.
Т.к. STRQ35 является частью STRQ29, который был включен в FEAT30, мы можем отменить STRQ35.
STRQ36 Любая активность на сайте должна записываться в лог.
Мы добавим немного деталей и пояснений:
FEAT35: Все транзакции и ошибки должны быть записаны и доступны для администратора.
STRQ37 Должны быть доступны различные отчеты.
Это требование не определено до конца. После дополнительных интервью, были добавлены детали:
FEAT36: Следующие отчеты должны быть доступны администратору:
Список всех билетов на самолет, купленных за данный период времени.
Список всех заказов автомобилей за данный период времени.
Список всех заказов номеров гостиниц за данный период времени.
STRQ38 При бронировании номера в гостинице клиент будет предоставить следующую информацию: город, даты пребывания, количество взрослых, количество детей, предпочтения в отношении номеров.
С этим требованием все в порядке, так что мы просто копируем его:
FEAT37: При бронировании номера в гостинице клиент будет предоставить следующую информацию: город, даты пребывания, количество взрослых, количество детей, предпочтения в отношении номеров.
STRQ39 При предоставлении информации о гостинице будет отображаться следующая информация: Адрес, Телефон, Факс, Электронная почта, Предлагаемые скидки, Доступные способы оплаты, и т.д.
Было удалено «и т.д.»:
FEAT38: При предоставлении информации о гостинице будет отображаться следующая информация: Адрес, Телефон, Факс, Электронная почта, Предлагаемые скидки, Доступные способы оплаты.
STRQ40 Пользователю будет предложено заключение соглашения на полет и гостиницу.
Добавлено небольшое пояснение:
FEAT39: Пользователю будет предложен пакет услуг, состоящий из полета и номера в гостинице.
STRQ41 Должна приниматься оплата только через кредитные карты. Ни по чекам, ни через PayPal.
Сделано небольшое перефразирование в целях пояснения:
FEAT40: При оплате билета на самолет должны приниматься только кредитные карты. Оплата через чеки и PayPal не принимается.
6.3 Атрибуты Функциональных Особенностей
Атрибуты описывают свойства требований. Они помогают структурировать и анализировать требования в проекте. Мы можем создать правила (на основе атрибутов) для определения того, какие требования реализовывать на следующей итерации, стадии или релизе. Например, Вы можете определить, что на стадии Проектирования (Elaboration) вы хотите реализовать все требования, у которых есть Риск (Risk) и Важность (Importance) с высоким приоритетом. А также все требования, у которых высокая Важность (Importance) и высокая или средняя Сложность (Difficulty).
Атрибуты могут быть как в виде списка, то есть в виде набора предустановленных значений, например: High, Medium and Low (Высокий, Средний и Низкий), так и в виде полей для ввода (текст, дата, цифровое значение).
Функциональные требования имеют следующие установленные по умолчанию атрибуты:
Priority (Приоритет): обычно используется для определения порядка реализации.
Status (Статус): отслеживает прогресс выполнения требования – Proposed (Планируемый), Approved (Подтвержденный), Incorporated (Включенный), Validated (Проверенный).
Difficulty (Сложность): насколько сложна реализация этого требования. Значения по умолчанию – High (Высокий), Medium (Средний) и Low (Низкий).
Stability (Устойчивость): возможность того, что функциональная особенность не изменится в течение проекта.
Risk (Риск): возможность возникновения спорных вопросов относительно этого требования – проблемы с реализацией, пропущенные сроки и т.п.
Planned Iteration (Планируемые Итерации): например, E1 – первая итерация стадии Проектирования (Elaboration).
Actual Iteration (Фактические Итерации).
Origin (Источник): источник требования.
Contact Name (Имя Контакта):
Enhancement Request (Запрос на Обновление).
Defect (Ошибка).
Author (Автор).
Location (Расположение): место, где находятся документы.
Этот список может варьироваться в зависимости от версии RequisitePro.
Очень часто нам приходится добавлять атрибуты. Ниже приведены несколько примеров.
Нам может потребоваться атрибут Importance (Важность), т.к. это не совсем одно и то же, что Priority (Приоритет). Он может помочь в управлении объемом работ в случае непредвиденных перерывов в работе. Значениями атрибута могут быть: Mandatory (Обязательный), Desirable (Желательный), Nice to have (Возможный). В экстремальных ситуациях, многие атрибуты могут хранить эти значения, т.к. Важность относительно пользователя может отличаться от Важности относительно менеджера проекта.
Помимо Difficulty (Сложности), у нас может быть атрибут Effort (Ресурсы). Он выражается в человеко-днях и может предоставить детальную оценку времени, требуемого на разработку этого требования.
Чтобы получить наилучшую оценку стоимости, мы можем добавить атрибут Cost to implement (Стоимость разработки). Этот атрибут полезен, если имеются различия в стоимости ресурсов (например, различные стоимости часа работы консультантов, вовлеченных в проект). Мы можем использовать этот атрибут для вычисления отношения стоимости к оплате, значения которых мы можем хранить в атрибутах Cost/reward (Стоимость/Оплата) или Risk/Reward (Риск/Оплата).
Вместо Contact Name (Имя контакта) часто используется атрибут Assigned To (Исполнитель).
Вместо Planned Iteration (Планируемые Итерации) и Actual Iteration (Фактические итерации) мы можем использовать Planned completion date (Планируемая дата завершения) и Actual completion date (Фактическая дата завершения).
Risk (Риск) может быть разделен на два отдельных атрибута: Risk probability (Возможность риска - какова возможность возникновения проблем), и Risk impact (Последствия риска – если проблема возникла, насколько тяжелыми будут последствия).
Описанные атрибуты может быть использованы не только для функциональных особенностей, но также для других требований (таких как сценарии использования и дополнительные требования).
Добавление нового атрибута не представляет никаких сложностей, так что Вы не должны даже сомневаться делать это, если новый атрибут поможет в управлении требованиями соответствующего типа.
6.4 Создание Документа Концепции (Vision) в RequisitePro
Документ Концепции (Vision) включен в шаблон Use Case (Сценариев Использования) в каталог Features and Vision (Функциональные Особенности и Концепция) в окне Explorer (Проводника). Чтобы открыть существующий документ выполните следующие действия:
Откройте папку Features and Vision (Функциональные Особенности и Концепция).
Двойным щелчком мышки нажмите на иконке документа Концепции.
Шаблон документа открывается в окне Word.
Если Вы используете шаблон, который не содержит документ Концепции, Вы можете создать его, выполнив следующие действия:
В Explorer (Проводнике) выберите папку, куда Вы хотите поместить документ Концепции.
Выберите File>New>Document (Файл>Новый >Документ). Откроется диалоговое окно Document Properties (Свойства Документа).
Введите имя, описание и название файла документа.
Выберите Document Type (Тип Документа) из списка - Vision (Концепция).
Нажмите ОК.
Эскиз документа Концепции откроется в Microsoft Word, как показано на Рисунке 6.2.
Рисунок 6.2. Документ Vision (Концепция): начальный шаблон.
Шаблон содержит общие названия, такие как <Company Name> (Название Компании) или <Project Name> (Название Проекта). Глава 5 описывает, как заменить их фактическими значениями.
Структура документа представлена на Рисунке 6.1, «Структура Документа Концепции (Vision)». Заполните соответствующие пункты информацией о проекте. Удалите ненужные пункты документа. Если необходимо, добавьте новые пункты.
Существует некоторая свобода действий в отношении заполнения пункта Product Features (Функциональные Особенности Продукта). Здесь допустимо применение различных подходов:
Описывать требования отдельными, ненумерованными предложениями в пункте 5, Product Features (Функциональные Особенности Продукта), как показано на Рисунке 6.3.
Нумеровать каждый элемент (5.1,5.2, 5.3 и т.д.).
Структурировать требования и группировать их в нумерованные пункты. Например, 5.1 Основная функциональность, 5.2 Функциональность для Администратора, … 5.9 Требования к производительности. Мы также можем сделать более детализированные группы, например 5.1 Заказ билета на самолет, 5.2 Бронирование номера в гостинице, 5.3 Бронирование машины, и т.д.
Рисунок 6.3. Список функциональных особенностей в пункте 5 документа Концепции.
Для простоты в нашем примере мы будем использовать первый подход, но в реальном проекте я бы рекомендовал группировку и структурирование требований.
6.5 Создание Функциональных Требований (FEAT)
После перечисления требований в пункте Product Features (Функциональные Особенности Продукта) документа Концепции (Vision) Вы должны сохранить их в базе данных. Это поможет Вам работать с атрибутами в Матрице Атрибутов (Attribute Matrix) и отслеживать трассировку (связи) между функциональными особенностями продукта и требованиями к программному обеспечению.
Чтобы создать функциональное требование выполните следующие действия:
Выделите текст, который описывает требование, как показано на Рисунке 6.4.
Выполните одно из следующего:
Правой кнопкой мышки нажмите на тексте и выберите Create Requirement (Создать Требование).
Выберите RequisitePro>Requirement>Create (Требование>Создать).
Нажмите на иконку New Requirement (Новое Требование)
.
Появится диалоговое окно Requirement Properties (Свойства Требования).
Рисунок 6.4. Выделение требования.
Введите название требования. Т.к. требованием по умолчанию в документе Концепции является FEAT (Feature - Функциональная особенность), то поле Type (Тип) должно быть уже установлено в FEAT, как показано на Рисунке 6.5.
Рисунок 6.5. Диалоговое окно Requirement Properties (Свойства Требования).
Нажмите на закладку Attributes (Атрибуты) и установите атрибуты требования (Вы также можете сделать это позже).
Нажмите ОК.
Требованию будет назначен тег «FEATpending», как показано на Рисунке 6.6. Слово «pending» (ожидаемый) будет убрано после сохранения документа.
Рисунок 6.6. Ожидающее (pending) требование.
Выберите RequisitePro>Document> Save (Документ>Сохранить).
После сохранения тег называется FEAT1, как показано на Рисунке 6.7.
Рисунок 6.7. Сохраненное требование.
Повторяйте эти действия для каждого требования, описанного в пункте Product Features (Функциональные Особенности Продукта) документа Концепции. Когда Вы закончите, выберите RequisitePro>Document>Save (Документ>Сохранить).
RequisitePro назначает теги с упорядоченными номерами всем создаваемым требованиям.
После сохранения функциональных особенностей продукта в базе данных, они становятся доступны из Explorer (Проводника), как показано на Рисунке 6.8.
Рисунок 6.8. Функциональные особенности в Explorer (Проводнике).
6.5 Трассировка
Трассировка – это техника, используемая для установки связи между требованиями, проектированием и реализацией системы. Благодаря трассировке мы можем проследить путь требования в обоих направлениях (прямом и обратном). Это техника позволяет Вам проследить источники любого требования. Когда требование изменяется, трассировка помогает проанализировать последствия этого изменения в отношении остальных требований.
Пирамида требований была представлена в Главе 1. Чаще всего мы используем трассировку для отслеживания связи между требованиями соседних уровней:
Из STRQ в FEAT.
Из FEAT в UC.
Из FEAT в SUPL.
Обычно требование становится более детальным при движении вниз по пирамиде требований. Например:
Запросы Заинтересованных Лиц: Данные должны быть постоянными.
Функциональная особенность: Система должна использовать реляционную базу данных
Дополнительное Требование: Система должна использовать базу данных Oracle 9i.
Главное назначение трассировки заключается в следующем:
Подтвердить, что реализация соответствует требованиям (вся требуемая функциональность была реализована и протестирована).
Подтвердить, что приложение делает только то, для чего оно предназначено (вся реализованная функциональность была запрошена заказчиками).
Помочь в управлении изменениями (анализировать последствия изменения требований).
Структура трассировки (в какие требованиями трассируется определенное требование) устанавливается в Плане Управления Требованиями (Requirements Management Plan).
В различных источниках Вы можете встретить различные интерпретации «Trace To» («Трассировка В») и «Trace From» («Трассировка Из»). Эти понятия определяют направления трассировки. Даже два образца проектов RequisitePro (QuarterByte Savings Bank Example и Learning Project) используют различную терминологию. В RequisitePro версии 2003 требования «Learning Project – Сценарии Использования» трассируются в направлении из извлеченных - к исходным. В «Learning Project – Традиционный», требования трассируются в направлении из исходных - к извлеченным. Данная книга полагает, что требования трассируются в направлении из исходных - к извлеченным. Таким образом, STRQ трассируется в FEAT, FEAT трассируется в UC, а FEAT трассируется в SUPL, и т.д. Некоторые ранние издания и классы RequisitePro в rational.net используют другие способы. Извлеченное требование трассируется в исходное – т.е., UC трассируется в FEAT, а FEAT трассируется в STRQ. Тем не менее, не важно, какой способ Вы хотите использовать, если он будет неизменным для каждой трассировки на протяжении всего проекта.
Структура трассировки, описанная в данной книге и используемая в нашем образце проекта, показана на Рисунке 6.10.
Рисунок 6.9. Структура трассировки, соответствующая пирамиде на Рисунке 1.1.
Рисунок 6.10. Структура трассировки с запросами заинтересованных лиц, функциональными особенностями и дополнительными требованиями.
В некоторых проектах могут быть дополнительные элементы трассировки – например, PROB (Problems with existing solution – Проблемы с существующим решением) трассируются в STRQ, как показано на Рисунке 6.11. Этот подход имеет смысл, только если дополнительные элементы описывают основные высокоуровневые проблемы, такие как «Текущая система слишком сложна для обучения», но не определяет ошибки системы. Если проблема относится к области управления ошибками, она должна храниться в ClearQuest и ссылаться на соответствующее требование в RequisitePro, а не создаваться непосредственно в самом RequisitePro.
Рисунок 6.11. Структура трассировки с проблемами, запросами заинтересованных лиц, функциональными особенностями и дополнительными требованиями.
6.7 Представления
RequisitePro представляет визуальное представление трассировки (связей) в виде двух типов представлений: Traceability Matrix (Матрица Трассировки) и Traceability Tree (Дерево Трассировки). Матрица Трассировки представляет связи между двумя типами требований. Дерево Трассировки показывает представление всего проекта.
Матрица Трассировки показывает связи между требованиями одного или разных типов. Матрица также используется также для создания, просмотра, изменения и удаления отношений трассировки (связи).
Доступ к Предварительно Созданному Представлению
Некоторые представления уже созданы как часть шаблона, который Вы использовали при создании проекта. Например, в шаблоне Use Case (Сценариев Использования) есть предустановленное представление. В зависимости от используемой Вами версии RequisitePro, оно может располагаться в различных папках. В более старой версии представление Матрицы Трассировки называлось Features to Stakeholder Requests (Из Функциональных Особенностей в Запросы Заинтересованных Лиц) в папке Features and Vision (Функциональные Особенности и Концепция). В версии 2003 она называется Features Traced to Stakeholder Request» (Функциональные Особенности, Трассируемые в Запросы Заинтересованных лиц) и располагается в папке Coverage. Чтобы отобразить это представление на рабочем пространстве View (Области Представлений) выполните следующие действия:
Двойным щелчком мышки нажмите на иконку в Explorer (Проводнике).
Откроется представление. Вам может понадобиться изменить размеры представления, чтобы увидеть полные наименования требований, как показано на Рисунке 6.12.
Матрица Трассировки содержит в строках - все Функциональные особенности, в столбцах - все Запросы Заинтересованных Лиц. Это представление используется для создания, изменения, просмотра и удаления отношений трассировки (связи).
Рисунок 6.12. Матрица Трассировки, показывающая все функциональные особенности и запросы заинтересованных лиц.
Установка Трассировки
Чтобы установить трассировку (связь) выполните следующие действия:
Правой кнопкой мышки нажмите на пересечение строки и столбца.
Выберите Traced Frоm (Трассируется Из). (Если Вы используете другую интерпретацию направления трассировки, выберите Traced To (Трассируется В).
Рисунок 6.13 показывает некоторые связи между STRQ и FEAT.
Рисунок 6.13. Матрица Трассировки, показывающая связь между требованиями.
Удаление Трассировки
Чтобы удалить трассировку (связь) выполните следующие действия:
Павой кнопкой мышки нажмите на ссылку
Выберите Delete Trace (Удалить Связь).
Изменение требований в Представлении
Вы можете изменять требования из Матрицы представлений:
Павой кнопкой мышки нажмите на требование (либо в строке, либо в столбце).
Выберите Properties (Свойства).
Редактируйте свойства.
Запросы
Вы можете использовать запросы для фильтрации и сортировки информации на любом представлении. Например, отобразим все требования STRQ, которые не трассируются ни в одно FEAT:
Правой кнопкой мышки нажмите на верхнем левом квадрате представления.
Выберите Query Column Requirements (Запрос к Требованиям в Столбце).
Выберите атрибут Traced-To (Трассирован В), как показано на Рисунке 6.14.
Рисунок 6.14. Выбор атрибутов для фильтрации.
Выберите Not Traced (Не Трассируются) в диалоговом окне Query Requirements (Запросы к Требованиям), как показано на Рисунке 6.15.
Рисунок 6.15. Выбор тира требований для запроса.
Нажмите ОК.
Диалоговое окно Query Column Requirements (Запрос к Требованиям в Столбце) отображается с одним критерием, как показано на Рисунке 6.16. Вы можете добавить больше критериев для фильтрации.
Рисунок 6.16. Критерии запроса.
Нажмите ОК.
Представление показывает только столбцы, которые не имеют идущих от них связей «trace-to» (трассируются в), как показано на Рисунке 6.17. Эти запросы заинтересованных лиц нужно пересмотреть, чтобы убедиться, что показываются только отмененные требования.
Рисунок 6.17. Результат запроса.
Подозрительная Трассировка
Когда требование изменяется, RequisitePro автоматически помечает все относящиеся к нему связи как подозрительные. Подозрительная связь значит, что соответствующие требования должны быть проанализированы, т.к. изменение могло их коснуться. Подозрительные ссылки помечаются красной диагональю в Матрице Трассировки и Дереве Трассировки:
После пересмотра требований, отмеченные подозрением и внесения необходимых изменений, Вы можете удалить отметку о подозрительности.
Чтобы удалить метку о подозрительности выполните следующие действия:
Правой кнопкой мышки нажмите на ячейке.
Выберите Clear Suspect (Убрать Подозрение).
Вы также можете вручную пометить связь как подозрительную:
Правой кнопкой мышки нажмите на ячейке связи.
Выберите Mark Suspect (Установить Подозрение).
Другие Операции над Представлениями
Вы можете копировать представление в другой каталог:
Выберите File>Save View As (Файл>Сохранить Представление Как).
Измените диалоговое окно View Properties (Свойства Представления). Вы можете изменить Name (Название), Description (Описание), Package (Папка).
Нажмите ОК.
Чтобы удалить представление выполните следующие действия:
Правой кнопкой мышки нажмите на представлении в Explorer (Проводнике).
Выберите Delete (Удалить).
Чтобы изменить представление, выполните следующие действия:
Правой кнопкой мышки нажмите на представлении в Explorer (Проводнике).
Выберите Properties (Свойства).
Измените имя, и нажмите ОК.
Дерево Трассировки (Traceability Tree)
Дерево Трассировки (Traceability Tree) показывает связи к главным требованиям (или от главных требований) определенного типа. Матрица Трассировки (Traceability Matrix) показывает трассировку только между требованиями двух типов, а Дерево Трассировки отображает все требования в проекте, которые трассируются к требованию (или трассируются от требования).
Создадим Дерево Трассировки для отображения STRQ и FEAT требований:
Выделите каталог, в котором Вы хотите создать представление (может быть выбран каталог Features and Vision – Функциональные Особенности и Концепция).
Выберите File>New>View (Файл>Новое>Представление).
В диалоговом окне View Properties (Свойства Представления), как показано на Рисунке 6.18, введите название и описание представления.
Выберите View Type Traceability Tree (Тип Представления Дерева Трассировки) – Traced into. Существует два типа Дерева Трассировки: Traced into (Трассируется В) и Traced off (Трассируется Из). Их отличие показано далее в последующих примерах.
Рисунок 6.18. View Properties (Свойства Представления) Дерева Трассировки (Traceability Tree).
Выберите Row Requirement Type (Тип Требования в Строке) – в данном случае, FEAT.
Нажмите ОК. Дерево Трассировки отображается на экране, как показано на Рисунке 6.19.
Рисунок 6.19. Дерево Трассировки (Traceability Tree) – трассировка в функциональные особенности (traced to).
В данном примере, Функциональные Особенности находятся на верхнем уровне дерева, а Запросы Заинтересованных Лиц представляют собой ответвления. Представление в таком виде имеет смысл, когда в проекте присутствует более чем два типа требований. Мы рассмотрим это в Главе 8 «Дополнительная Спецификация» и Главе 9 «Создание Тестовых Сценариев (Test Cases) из Сценариев Использования (Use Cases)», после того как мы добавим сценарии использования в проект.
Та же информация может быть отображена в другой форме, если Вы выберите View Type Traceability Tree (Тип Представления Дерева Трассировки) – Traced out off (Трассируется Из) и Row Requirement Type (Тип Требования в Строке) – STRQ, как показано на Рисунке 6.20.
Рисунок 6.20. View Properties (Свойства Представления) Дерева Трассировки (Traceability Tree).
Теперь Требования Заинтересованных лиц (STRQ) находятся на вершине дерева, а Функциональные Особенности представляют собой ответвления дерева, как показано на Рисунке 6.21.
Рисунок 6.21. Дерево Трассировки (Traceability Tree) – трассировка из запросов заинтересованных лиц (traced out off).
Выделив требование в Дереве Трассировки, Вы сможете просмотреть свойства требования. Свойства показываются только в режиме чтения в правой части экрана. Чтобы изменить свойства, Вам необходимо открыть диалоговое окно Properties (Свойства), нажав правой кнопкой мышки на требовании и выбрав Properties (Свойства).
Представления трассировки (связей) помогают Вам быстро найти определенную проблему:
Сценарий Использования (UC) или Дополнительное Требование (SUPL) не трассируются ни из каких требований (это означает, что Вы реализовали что-то, что не было запрошено заказчиками).
Функциональная Особенность (FEAT) не трассируется ни в какой UC или SUPL (это означает, что Вы не реализовали что-то из требуемой заказчиком функциональности).
Чтобы облегчить этот анализ, Вы должны создать представление, показывающее соответствующие запросы, например:
|
|
|
|
|
|