Лабораторна робота №1 Case–засоби для зберігання та керування вимогами Мета роботи

Вивчити основні можливості IBM Rational Requisite Pro, ознайомитись з його інтерфейсом та навчитися створювати відповідні проекти.

Основні теоретичні відомості

IBM Rational Requisite Pro – засіб керування вимогами до програмних проектів. Дозволяє команді розробників розробляти, структурувати, встановлювати пріоритети, відстежувати, контролювати зміни вимог, які з’являються на будь-якому етапі розробки компонентів додатку.

Установка RequisitePro. Установка програми складається з наступних кроків:

1. Скопіювати на комп'ютер папки Rational Requisitepro і Rational Rose Enterprise Edition 2003 + License.

2. Під час установки програми відключити антивіруси.

3. Запустити файл RationalRoseEnterpriseEditionforWindows.exe з папки Rational Rose Enterprise Edition 2003 + License

4. Вибрати шлях куди буде встановлена програма, нажати Next. Далі дочекатися поки розпакуються файли, нажати Next. Потім вибрати пункт Rational License Server, нажати Next.

5. Далі завершити установку дотримуючись вказівок програми.

6. Скопіювати файл rational_perm.dat з папки Rational Rose Enterprise Edition 2003 + License\License\Rational\Common у папку C:\Program Files\Rational\common

7. Запустити файл setup.exe з папки Rational Requisitepro \C90MHML.

8. Нажати опцію Install IBM Rational Requisitepro.

9. Нажати далі й додержуватися вказівок установника.

Мінімальні системні та програмні вимоги до ресурсів. Необхідність використання IBM-сумісного ПК, наявність операційної системи Windows XP Professional SP1 або SP2, вільного робочого простору на жорсткому диску 288 Mb, оперативної пам'яті 256-512 Мб і більше, браузера Internet Explorer, Firefox Mozilla.

Запуск RequisitePro. Для запуску IBM Rational Requisitepro потрібно виконати наступні дії Пуск Програми  Management  IBM Rational  Rational Requisitepro.

Вікно RequisitePro Let’s Go RequisitePro забезпечує простий доступ до інформації про програму і прийомам роботи з нею з використанням системи вбудованої допомоги.

У вікні Let’s Go RequisitePro можна вибрати чотири варіанти доступу до інформації про програму IBM Rational Requisite Pro і прийомам роботи з нею.

При натисканні іконок з наступними найменуваннями з'являються:

1. RequisitePro Quick Tour – рекомендації зі швидкого освоєння RequisitePro.

2. RequisitePro Tutorial – підручник по RequisitePro.

3. Requirements Management Tour – опис керування вимогами.

4. Project Administration Tips – рекомендації з адміністрування проекту.

Система вбудованої допомоги HELP забезпечує підтримку одержання різної інформації, включаючи допомогу по розширеному інтерфейсу RequisitePro, розширену довідку, пошук інформації.

Інтерфейс RequisitePro. Інтерфейс RequisitePro складається з наступних основних частин (рис. 1.1): Explorer window (вікно Провідника RequisitePro) ліворуч; Views (Область Подань) праворуч; Menus (Меню) і Toolbars (Панелі Інструментів) зверху.

Під час роботи з документами, в окремому вікні відкривається робочий простір Word.

Провідник RequisitePro (Explorer). Провідник RequisitePro – це головне вікно навігації, що відображає компоненти проекту у вигляді дерева (рис. 1.1). Документи, вимоги й подання об'єднані в папки. Можна додати будь-яку кількість папок. Папки можуть містити документи, подання, вимоги й інші папки.

RequisitePro підтримує 6 шаблонів проекту:

– шаблон бізнес процесів (Business Modeling project template);

– комплексний шаблон (Composite project template);

– шаблон глобальних вимог (Global Requirement project template);

– традиційний шаблон (Traditional project template);

– шаблон сценарії використання (Use Case project template);

– шаблон RUP (RUP project template).

Панель Інструментів

Область

Подань

Вікно Проводника

Опис

Рисунок 1.1 – Робочий простір RequisitePro

Для шаблону Use Сase за замовчуванням створюються наступні папки:

– Features and Vision – функціональні вимоги та документ Vision;

– Glossary – глосарій;

– Stakeholder Requests – запити зацікавленої особи;

– Supplementary Requirements – додаткові вимоги;

– Use Cases – сценарії використання.

Елементи проекту представлені в Провіднику спеціальними іконками, що вказують на тип елементу:

–  документи MS Word;

– подання:

–  – Матриця Атрибутів;

–  – Матриця Трасування;

–  – Дерево Трасування;

–  вимоги RequisitePro.

У Провіднику можна здійснювати основні операції (створення, перегляд, оновлення, видалення) над поданнями, вимогами й документами. Також можна змінити структуру елементів, просто перетаскуючи їх між папками.

Toolbar (Панель Інструментів). Панель інструментів RequisitePro, показана на рис. 1.2, забезпечує швидкий доступ до інформації проекту та головних операцій.

Рисунок 1.2 – RequisitePro Toolbar (Панель інструментів)

Views (Область Подань). Область подань – це область для аналізу інформації з вимог. Подання відображає атрибути вимог або відносини між вимогами. Воно може відображатися у вигляді матриці або дерева. В Області подань можно створювати й оновлювати вимоги, встановлювати відношення між ними (наприклад, відношення ієрархії й трасування), сортувати й фільтрувати вимоги, а також запитувати статус проекту.

Існує три типи подань:

– Attribute Matrix (Матриця Атрибутів) – відображає вимоги певного типу і їхні атрибути, All Features, як показано на рис. 1.3.

Рисунок 1.3 – Attribute Matrix (Матриця Атрибутів)

– Traceability Matrix (Матриця Трасування) – відображає відносини між двома типами вимог у формі матриці, наприклад Features Traced to Stakeholder Requests, як показано на рис.1.4.

Рисунок 1.4 – Traceability Matrix (Матриця Трасування)

– Traceability Tree (Дерево Трасування) відображає весь ланцюг трасування (зв'язки) у вигляді дерева, як показано на рис.1.5.

Рисунок 1.5 – Traceability Tree (Дерево Трасування)

Матриця Атрибутів може бути використана для виконання наступних завдань:

– перегляд вимог певного типу;

– додавання, оновлення й видалення вимог;

– настроювання атрибутів вимог;

– запит вимог, що задовольняють певним критеріям (фільтрація й сортування вимог на підставі їхніх атрибутів);

– пошук вимог у документах.

У додаванні до цих завдань, Матриця Трасування може бути використана для наступного:

– установка й аналіз трасування (зв'язку);

– керування змінами з використанням підозрілого трасування (зв'язку);

– аналіз наслідків.

Дерево Трасування використовується в основному для відображення й аналізу ланцюжка трасування (зв'язку).

У кожному поданні можно робити наступне:

– сортувати та фільтрувати вимоги;

– зберігати запити, за допомогою яких формувалося подання;

– експортувати інформацію подання в інші формати;

– друкувати подання.

Робочий простір Word. Робочий простір Word – це середовище, у якому користувач створює, відображає й змінює документи. Воно відкривається у вигляді вікна Microsoft Word усередині RequisitePro і надає ту ж функціональність, що й Microsoft Word. Крім цього, панель інструментів RequisitePro дає можливість здійснювати додаткові операції над документами й вимогами RequisitePro. На рис.1.6 показані іконки на цій панелі інструментів. Можно імпортувати існуючі документи Word в RequisitePro або створювати документи в середовищі RequisitePro на основі існуючих шаблонів. Кожний документ позначається іконкою Word у Провіднику.

Створити

новий

документ

Довідка RequisitePro

Показати Проводник RequisitePro

Перейти

до вимоги

Знайти

вимогу

Копіювати

вимогу

Зберегти

документ

Відкрити

документ

Створити нову вимогу

Властивості

вимоги

Вирізати

вимогу

Видалити

вимогу

Вставити

вимогу

Рисунок 1.6 – Панель інструментів RequisitePro в робочому просторі Word

Документи. В RequisitePro можна створювати як документи за заздалегідь визначеним шаблоном, так і власні документи.

RequisitePro надає шаблони для таких документів:

– Stakeholder Requests: зберігаються запити зацікавлених осіб (декілька на проект);

– документ Vision: містить повний опис системи й функціональних особливостей (один на проект);

– Use Case Specification: визначає поводження системи в термінах послідовності дій (декілька на проект);

– Supplementary Specification: функціональні вимоги, не зв'язані зі сценаріями використання або нефункціональні вимоги (один на проект);

– Glossary: описує всі терміни, що відносяться до проекту (один на проект);

– Requirements Management Plan (RMP): містить в собі загальні підходи до управління вимогами в проекті. Він описує, яким чином створюються вимоги, як вони упорядковуються, змінюються і відстежуються впродовж життєвого циклу проекту. Він також описує усі використовувані в проекті типи вимог і їх атрибути.

Кожний документ належить певному типу документів. Тип документа визначає шаблон, застосовуваний у документі. Цей шаблон визначає стандартне форматування, зміст, пункти за замовчуванням і заголовки. Всі документи такого ж типу мають однакове розширення файлу. Вони не мають використовуваних в Microsoft Word розширень, так що вони можуть бути змінені тільки з RequisitePro.

Вимоги. Вимога задається на природній мові, має унікальний ідентифікатор і атрибути і може зберігається тільки у базі даних або в документах і базі даних.

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

Вимоги можуть бути створені в RequisitePro п'ятьма різними способами:

– створення в документі (використовуючи робочий простір Microsoft Word);

– створення в Області Подання;

– створення в Провіднику;

– імпорт з файлу, що має крапку з комою в якості роздільника(CSV);

– імпорт з документу вимог.

Типи Вимог. У простих проектах можуть використовуватися одне або два типи вимог. Складні програмні продукти потребують вимог різного рівня.

В RequisitePro використовуються наступні типи вимог:

– Features (FEAT) – функціональні вимоги;

– Supplementary requirements (SUPL) – додаткові вимоги;

– Use cases (UC) – сценарії використання;

– Stakeholder requests (STRQ) – запити зацікавлених осіб.

Приклад вимоги:

F EAT	8 :	Система повинна надавати можливість сортування електронних листів
мнемонічне ім'я, відображає тип вимоги	номер вимоги, усередині даної категорії	Вимога

Атрибути Вимог. Атрибути вимог відіграють важливу роль в управлінні проектом. Спільно з представленнями, вони є потужним інструментом для аналізу. На основі значень атрибутів можна фільтрувати і сортувати вимоги за допомогою запитів. Результати запитів відображаються в представленнях.

У кожної вимоги є відповідні атрибути. Вони визначають властивості вимог, такі як Priority (Пріоритет), Status (Статус), Difficulty (Складність), Risk (Ризик) і Origin (Джерело). Атрибути надають інформацію для управління вимогами. Вони можуть використовуватися для планування, комунікацій і моніторингу проектної діяльності. Можливо здійснювати як налаштування значень атрибутів, встановлених за умовчанням, так і створювати власні атрибути. Початкові вимоги поступають в RequisitePro із вже предвстановленим за замовченням набором атрибутів. Цей набір може мінятися залежно від того, яка версію програми використовується. Таблиця 1.1 містить вимоги включені в шаблон Use Cases.

Таблиця 1.1 – Атрибути і їх значення, встановлені за замовченням для вимог: FEAT, SUPL, UC и STRQ

Атрибут	Значения	FEAT	SUPL	UC	STRQ
1	2	3	4	5	6
Priority (Пріоритет)	High (Високий) Medium (Середній) Low (Низький)	*	*	*
Type (Тип)	Functional (Функціональне) Usability (Зручність використання) Reliability (Надійність) Supportability (Можливість супроводження) Design Constraint (Обмеження на дизайн) Implementation Requirement (Вимога реалізації) Physical Requirement (Вимога до апаратного забезпечення) Interface Requirement (Вимога інтерфейсу)	*
Status (Статус)	Proposed (Планований) Approved (Підтверджений) Incorporated (Включений) Validated (Перевірений)	*	*	*
Difficulty (Складність)	High (Високий) Medium (Середній) Low (Низький)	*	*	*
Stability (Стійкість)	High (Високий) Medium (Середній) Low (Низький)	*	*	*
Risk (Ризик)	Schedule – High (Високий ) Schedule – Medium (Середній) Schedule – Low (Низький) Technology – High (Технологічний ризик –Високий) Technology – Medium (Технологічний ризик – Середній) Technology – Low (Технологічний ризик – Низький)	*	*	*

Продовження табл.1.1

Атрибут	Значения	FEAT	SUPL	UC	STRQ
1	2	3	4	5	6
Planned Iteration (Плануємі Ітерації)	Integer (Ціле)	*		*
Actual Iteration (Фактичні Ітерації)	Integer (Ціле)	*		*
Origin (Джерело)	Help Desk (Довідкова Служба) Partners (Партнери) Competition (Конкуренція) Large Customers (Важливі Замовники) End Users (Кінцеві Користувачі)	*			*
Contact Name (Ім'я Контакту)	Text (Текст)	*	*	*
Enhancement Request (Запит на оновлення)		*	*	*
Defect (Помилки)		*	*	*
Obsolete (Недійсність)	True (Істина) False (Брехня)	*	*	*
Affects Architecture (Вплив на Архітектуру)	True (Істина) False (Брехня)			*
Stakeholder Priority (Пріоритет Зацікавленої Особи)	High (Високий) Medium (Средній) Low (Низький)				*

При створенні проекту може знадобитися налаштування атрибутів і їх значень, щоб вони підходили до проекту.

Т.к. деякі значення атрибутів достатньо неточні, буде корисним вказати в документі RMP, які точно значення маються на увазі. Наприклад:

– Пріоритет – Високий: може бути реалізовано не пізніше, ніж в першій ітерації фази Розробки;

– Пріоритет – Середній: може бути реалізовано не пізніше, ніж в кінці фази Розробки;

– Пріоритет – Низький: може бути реалізовано, якщо дозволяє час;

– Технологічний ризик – Високий: використання нової технології, досвіду роботи з якою команда не має;

– Технологічний ризик – Низький: використання добре відомої технології, досвід роботи з якою у команди дуже великий.

Зберігання вимог. Для відстежування атрибутів вимог і трасування (встановлення зв'язку), не обов'язково зберігати вимоги в документах. Вони можуть бути розташовані у базі даних.

Альтернативою управлінню вимог в документах є використання звітів. Наприклад, шаблони Use Case Specification SoDA (Специфікації сценаріїв використання) можуть бути створені так, що коли треба об'єднати сценарії використання, може бути згенерований звіт. Цей звіт матиме таку ж структуру, що і шаблон Use Case Specification RequisitePro.

Наступні типи вимог зазвичай зберігаються не лише у базі даних, але і у відповідних документах

– із-за своєї наочної природи, сценарії використання мають бути пов'язані з документами – один документ на окремий сценарій використання;

– функціональні особливості включені в документ Vision;

– додаткові вимоги фіксуються в Supplementary Specification.

Вимоги типу STRQ зазвичай включаються в документи Stakeholder Requests. Але окрім цього, існує ще три основні підходи до оформлення потреб. Вимоги цього типу можуть зберігатися:

– в документах Stakeholder Requests (переваги: усі потреби пов'язані з певною зацікавленою особою; існує місце для додаткових коментарів і для усіх відповідей зацікавлених осіб; не складає труднощів дати увесь документ зацікавленій особі для розгляду; недоліки: збільшення кількості документів, які потребують постійного оновлення);

– тільки у базі даних (переваги: зменшується кількість документів; недоліки: найменш читабельна форма, особливо якщо хочуть вислухати думку зацікавленої особи);

– в документе Vision (переваги: зменшується кількість документів; недоліки: концепція стає документом, який містить вимоги як з області проблем(STRQ), так і з області рішень(FEAT)).

Вся отримана в процесі збору вимог інформація повинна бути документально оформлена і розміщена в документ Stakeholder Requests. В проекті необхідно створити один документ, який міститиме в собі запити всіх зацікавлених осіб, один документ для кожної зацікавленої особи, або можна зібрати запити декількох зацікавлених осіб в одному документі. Якщо немає необхідності описувати вимоги зацікавленої особи в деталях, то можна створити пункт «Stakeholders Requests» («Запити Зацікавлених Осіб») в документі Vision. Це знизить необхідність створення окремого документа.

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