
- •Методичні вказівки
- •Лабораторна робота №1 Case–засоби для зберігання та керування вимогами Мета роботи
- •Основні теоретичні відомості
- •Порядок виконання роботи
- •Завдання на лабораторну роботу
- •Контрольні запитання
- •Лабораторна робота №2 Розробка функціональних вимог Мета роботи
- •Основні теоретичні відомості
- •Порядок виконання роботи
- •Завдання на лабораторну роботу
- •Контрольні запитання
- •Література
- •Додаток а Перелік тем для лабораторних робіт
- •Додаток б Зміст документів Rational Requisite Pro б.1 Зміст документа Vision
- •Б.2 Зміст документа Glossary
- •Б.3 Зміст документа Requirements Management Plan
- •Б.4 Зміст документа Stakeholder Requests
Порядок виконання роботи
Створення документа Vision в RequisitePro. Документ Vision включений в шаблон Use Case в каталог Features and Vision у вікні Провідника. Щоб відкрити існуючий документ виконайте наступні дії:
1. Відкрийте папку Features and Vision.
2. Подвійним клацанням мишки натисніть на іконці Документу Vision.
3. Шаблон документу відкривається у вікні MS Word.
Якщо використовується шаблон, який не містить Документ Vision, можна створити його, виконавши наступні дії:
1. В Провіднику виберіть папку, куди треба помістити Документ Vision.
2. Виберіть FileNewDocument (ФайлНовийДокумент). Відкриється діалогове вікно Document Properties(Властивості Документу).
3. Введіть ім'я, опис і назву файлу документу.
4. Виберіть Document Type (Тип Документу) зі списку − Vision.
5. Натисніть ОК.
Шаблон містить загальні назви, такі як <Company Name> (Назва Компанії) чи <Project Name> (Назва Проекту). Заповніть відповідні пункти інформацією про проект. Видаліть непотрібні пункти документу. Якщо необхідно, додайте нові пункти.
Існує деяка свобода дій відносно заповнення пункту Product Features. Тут допустиме застосування різних підходів:
1. Описувати вимоги окремими, ненумерованими реченнями.
2. Нумерувати кожен елемент (5.1,5.2, 5.3 і так далі).
3. Структурувати вимоги і групувати їх в нумеровані пункти.
Наприклад,
5.1 Основна функціональність, 5.2 Функціональність для Адміністратора, ... 5.9 Вимоги до продуктивності. Також можна зробити більше деталізовані групи, наприклад 5.1 Замовлення квитка на літак, 5.2 Бронювання номера в готелі, 5.3 Бронювання машини, і т. д.
Отримання функціональних вимог із запитів зацікавлених осіб. Функціональні вимоги (ФВ) отримуються із запитів зацікавлених осіб (ЗЗО).
Для кожної ФВ важливо відстежувати, з якого запиту вона була отримана. Тоді при зберіганні ЗЗО в RequisitePro вони можуть перетворені в ФВ, що їх реалізують.
Отримані від зацікавлених осіб вимоги не обов'язково мають характеристики хорошої вимоги. Отриманння ФВ із ЗЗО надає добру можливість виправити це. Один з підходів – це пройти за усіма вимогами ЗЗО і застосувати відповідне перетворення для створення одного або більше ФВ.
Можуть бути застосовані наступні перетворення:
1. Copy (Копіювання): якщо не потрібні додаткові зміни, ЗЗО може бути просто скопійований у ФВ без змін. Наявність вимог різного типу з однаковим текстом є цілком нормальною. Проте, краще уникати таких однакових вимог, інакше вимоги будуть багатослівними.
2. Split (Розділення): якщо вимога не елементарна, то її можна розділити на дві або більше.
3. Clarification (Пояснення): пояснення може бути застосоване, коли оригінальна вимога незрозуміла або двозначна.
4. Qualification (Уточнення): уточнення виконується шляхом накладення обмежень або умов на вимоги. Це може допомогти вирішити суперечливі вимоги.
5. Combination (Комбінування): багатослівні або вимоги, що перекриваються, можуть бути скомбіновані в одну.
6. Generalization (Узагальнення): якщо вимога не абстрактна й включає деякі непотрібні деталі, можна застосувати узагальнення.
7. Cancellation (Скасування): іноді вимогу потрібно видалити. Це може трапитися, коли вимога нездійсненна, непотрібна або несумісна з іншою вимогою.
8. Completion (Завершення): якщо набір вимог не закінчений, може знадобитися додавання вимоги на дану стадію.
9. Correction (Корекція): корекція може означати як перефразування вимоги, щоб виправити граматичні помилки, орфографічні й помилки пунктуації, так і зміну невірної частини вимоги.
10. Unification (Уніфікація): вимоги, які використовують неприпустиму термінологію, можуть бути приведені до відповідного виду.
11. Adding Details (Додавання Деталей): якщо вимога визначена не точно, можна додати деталі. Цей спосіб часто використовується, щоб зробити всі вимоги можливими для тестування.
Атрибути функціональних вимог. Атрибути описують властивості вимог. Вони допомагають структурувати і аналізувати вимоги в проекті. Можна створити правила (на основі атрибутів) для визначення того, які вимоги реалізовувати на наступній ітерації , стадії або релізі.
Створення функціональних вимог (FEAT). Після переліку вимог у пункті Product Features Документу Vision потрібно зберегти їх у базі даних. Це допоможе працювати з атрибутами в Матриці Атрибутів і відстежувати трасування (зв'язки) між ФВ продукту й вимогами до програмного забезпечення.
Щоб створити ФВ потрібно виконати наступні дії:
1. Виділіть текст, що описує вимогу, як показано на рис.2.1. Виконайте одну із наступних дій:
Правою кнопкою мишки натисніть на тексті й оберіть Create Requirement (Створити Вимогу) або виберіть RequisitePro Requirement Create (Вимога Створити). Натисніть на іконку New Requirement (Нова Вимога). З'явиться діалогове вікно Requirement Properties (Властивості Вимоги).
Рисунок 2.1 – Виділення вимоги
2. Введіть назву вимоги. Оскільки вимогою за замовчуванням у Документі Vision є FEAT, то поле Type (Тип) повинне бути вже встановлене в FEAT, як показано на рис.2.2.
Рисунок 2.2 – Діалогове вікно Requirement Properties (Властивості Вимоги)
3. Натисніть на закладку Attributes (Атрибути) і встановіть атрибути вимоги.
4. Натисніть ОК.
5. Вимозі буде призначений тег «FEATpending». Слово «pending» (очікуваний) буде вилучено після збереження документа.
6. Виберіть RequisitePro Document Save (Документ Зберегти).
7. Після збереження тег називається FEAT1.
8. Повторюйте ці дії для кожної вимоги, описаної в пункті Product Features Документа Vision. Після закінчення роботи, виберіть RequisiteProDocumentSave (ДокументЗберегти).
RequisitePro призначає теги з упорядкованими номерами всім створюваним вимогам. Після збереження ФВ в базі даних, вони стають доступні із Провідника, як показано на рис.2.3.
Рисунок 2.3 – Функціональні вимоги в Провіднику
Трасування. Трасування – це техніка, що використовується для встановлення зв'язку між вимогами, проектуванням і реалізацією системи. Завдяки трасуванню можна відстежити шлях вимоги в обох напрямах (прямому й зворотному). Це техніка дозволяє відстежити джерела будь-якої вимоги. Коли вимога змінюється, трасування допомагає проаналізувати наслідки цієї зміни відносно інших вимог.
Найчастіше використовується трасування для відстеження зв'язку між вимогами сусідніх рівнів: з STRQ в FEAT; з FEAT в UC; з FEAT в SUPL (рис.2.4).
Головне призначення трасування полягає в наступному:
– підтвердити, що реалізація відповідає вимогам (вся необхідна функціональність була реалізована й протестована);
– підтвердити, що застосування робить тільки те, для чого він призначений (вся реалізована функціональність була призначена замовниками);
– допомогти в керуванні змінами (аналізувати наслідки зміни вимог).
Структура трасування (в які вимоги трасується певна вимога) установлюється в RMP.
Поняття «trace to» і «trace from» визначають напрям трасування. Приймемо, що вимоги трасуються в напрямку з вихідних – до отриманих. Таким чином, STRQ трасується в FEAT, FEAT трасується в UC, а FEAT трасується в SUPL, і т.д.
Рисунок 2.4 − Приклад структури трасування вимог
Доступ до попередньо створеного подання. У шаблоні Use Case є встановлене подання Матриці Трасування, що називається Features Traced to Stakeholder Request (ФВ, що трасуються в ЗЗО) і розташовується в папці Coverage. Щоб відобразити це подання на робочому просторі Області Подань виконайте наступні дії: подвійним клацанням мишки натисніть на іконку в Провіднику. Відкриється подання. Може знадобитися змінити розміри подання, щоб побачити повні найменування вимог, як показано на рис.1.4. Матриця Трасування містить у рядках − всі ФВ, у стовпцях − всі ЗЗО. Це подання використовується для створення, зміни, перегляду й видалення відносин трасування (зв'язку).
Установка Трасування. Щоб установити трасування (зв'язок) виконайте наступні дії:
1. Правою кнопкою мишки натисніть на перетинання рядка й стовпця.
2. Виберіть Traced Frоm (Трасується з) (якщо використовувати іншу інтерпретацію напряму трасування, виберіть Traced To (Трасується в). Рисунок 1.4 показує деякі зв'язки між STRQ і FEAT.
Видалення Трасування. Щоб видалити трасування (зв'язок) виконайте наступні дії: правою кнопкою мишки натисніть на посилання, потім виберіть Delete Trace (Видалити зв'язок).
Зміна вимог у Поданні. Можна змінювати вимоги з Матриці Подань: правою кнопкою мишки натисніть на вимогу (або в рядку, або в стовпці); далі виберіть Properties (Властивості) і відредагуйте властивості.
Запити. Визначаючи запит, можна фільтрувати (обмежувати відображувану інформацію) і сортувати (упорядковувати інформацію). За допомогою запитів можна обробляти наступні вимоги:
– рядки в Матриці Атрибутів;
– рядки й стовпці в Матриці Трасування;
– вимоги в кореневому каталозі Дерева Трасування.
Деякі приклади запитів, які можуть бути відображені в поданнях:
– показати всі сценарії використання, які ще не підтверджені, і сортувати їх за пріоритетом;
– показати всі ЗЗО, які трасуються особливо;
– показати всі ФВ, які були реалізовані на даній ітерації;
– показати всі ФВ із найвищим пріоритетом, які витягнуті з додаткових вимог, призначених певним розроблювачем;
– показати ланцюжок трасування (зв'язків) для всіх ЗЗО, які були отримані від кінцевих користувачів.
Створення запитів для вимог. Можна використовувати запити для фільтрації й сортування інформації на будь-якому поданні. Наприклад, відобразимо всі вимоги STRQ, які не трасуються в жодне FEAT: правою кнопкою мишки натисніть на верхньому лівому квадраті подання; потім виберіть Query Column Requirements (Запит до вимог у стовпці); далі виберіть атрибут Traced-To (Трасований в), як показано на рис. 2.5.
Рисунок 2.5 − Вибір атрибутів для фільтрації
Виберіть Not Traced (Не трасуються) у діалоговому вікні Query Requirements (Запити до вимог), як показано на рис.2.6. Натисніть ОК.
Рисунок 2.6 − Вибір тиру вимог для запиту
Діалогове вікно Query Column Requirements (Запит до вимог у стовпці) відображається за одним критерієм, як показано на рис.2.7. Можна додати більше критеріїв для фільтрації. Натисніть ОК.
Рисунок 2.7 − Критерії запиту
Подання показує тільки стовпці, які не мають зв'язків, що йдуть від них, «trace-to» (трасуються в), як показано на рис.2.8. Ці запити зацікавлених осіб потрібно переглянути, щоб переконатися, що показуються тільки скасовані вимоги.
Рисунок 2.8 − Результат запиту
Трасування
підозрілих зв’язків. Коли
вимога змінюється, RequisitePro
автоматично позначає всі стосовні до
неї зв'язки як підозрілі. Підозрілий
зв'язок означає, що відповідні вимоги
повинні бути проаналізовані, тому що
зміна могла їх стосуватися. Підозрілі
посилання позначаються червоною
діагоналлю в Матриці
Трасування й Дереві
Трасування
.
Після перегляду вимог, відзначених підозрілими й внесення необхідних змін, можна видалити мітку про підозрілість.
Щоб видалити мітку про підозрілість виконайте наступні дії:
1. Правою кнопкою мишки натисніть на чарунці.
2. Виберіть Clear Suspect (Видалити підозрілий зв'язок).
Також можна вручну позначити зв'язок як підозрілий:
1. Правою кнопкою мишки натисніть на чарунці зв'язку.
2. Виберіть Mark Suspect (Встановити підозрілий зв'язок).
Подання можна копіювати в інший каталог і видаляти непотрібні.
Дерево Трасування (Traceability Tree). Дерево Трасування показує зв'язок до головних вимог (або від головних вимог) певного типу. На відміну від Матриці Трасування Дерево Трасування відображає всі вимоги в проекті, які трасуються до вимоги (або трасуються від вимоги).
Створимо Дерево Трасування для відображення STRQ і FEAT вимог:
1. Виділить каталог, у якому потрібно створити подання (може бути обраний каталог Features and Vision).
2. Виберіть FileNewView (ФайлНовеПодання).
3. У діалоговому вікні View Properties (Властивості подання), як показано на рис. 2.9, уведіть назву й опис подання.
4. Виберіть View Type Traceability Tree (Тип подання Дерева Трасування) – Traced into. Існує два типи Дерева Трасування: Traced into (Трасується в) і Traced off (Трасується з). Їхня відмінність показана далі в наступних прикладах.
Рисунок 2.9 − Вікно View Properties (Властивості подання) Дерева Трасування
Виберіть Row Requirement Type (Тип вимоги в рядку) − у цьому випадку, FEAT. Натисніть ОК. Дерево Трасування відображається на екрані, як показано на рис. 2.10.
Рисунок 2.10 − Дерево Трасування – трасування у ФВ (traced to)
У даному прикладі, ФВ перебувають на верхньому рівні дерева, а ЗЗО представляють собою відгалуження. Подання в такому виді має сенс, коли в проекті присутні більш ніж два типи вимог. Та ж інформація може бути відображена в іншій формі, якщо вибрати View Type Traceability Tree (Тип подання Дерева Трасування) – Traced out off (Трасується з) і Row Requirement Type (Тип вимоги в рядку) – STRQ. Тепер ЗЗО перебувають на вершині дерева, а ФВ представляють собою відгалуження дерева, як показано на рис.2.11.
Рисунок 2.11 − Дерево Трасування – трасування зі ЗЗО (traced out off)
Виділивши вимогу в Дереві Трасування, можна переглянути властивості вимоги. Властивості можна переглянути тільки в режимі читання в правій частині екрана. Щоб змінити властивості, необхідно відкрити діалогове вікно Properties (Властивості), натиснувши правою кнопкою мишки на вимозі й вибравши Properties (Властивості).
Подання трасування (зв'язків) допомагають швидко знайти певну проблему:
− Use Cases або Supplementary Specification не трасуються ні з яких вимог (це означає, що було реалізовано щось, що не було запропоновано замовниками);
− ФВ не трасується ні в яку Use Cases або Supplementary Specification (це означає, що потрібна замовнику функціональность не була реалізована).