3.5. КЕРУВАННЯ ВИМОГАМИ ЗА ДОПОМОГОЮ IBM RATIONAL REQUISITEPRO

CASEзасіб IBM Rational RequisitePro (надалі — RequisitePro) призначений для організації колективної праці аналітиків та автоматизації створення, оновлення, структуризації, встановлення пріоритетів, відстежування, контролю змін вимог та їх атрибутів, а також формування різноманітних звітів на всіх етапах розробки ІС. Систему RequisitePro було розроблено у 1996 року компанією Requisite Inc., яку 1997 року придбала корпорація RationalSoftware, що, своєю чергу, у 2003 року увійшла до складу корпорації IBM.

Основні характеристики RequisitePro:

— проектування і розгортання процесу керування вимогами «з нуля» — користувач може визначити власні типи вимог та їхні атрибути, типи і нові шаблони документів, побудувати ієрархію вимог, що можуть міститися в різних документах, встановити зв’язки між вимогами для відстежування змін тощо;

— інтеграція з Microsoft Word полегшує постановку процесу керування вимогами за наявності великої кількості документів у відповідному форматі. До того ж RequisitePro допомагає інтегрувати ці документи, вносити і відстежувати зміни та доповнення в них, шукати потрібну інформацію. Це досягається шляхом імпорту документів і виокремлення з них вимог потрібних типів і запису їх у БД. RequisitePro підтримує низку провідних СКБД (Oracle, Microsoft SQL Server, Microsoft Access), за допомогою яких можна легко організовувати і відстежувати відношення, встановлювати пріоритети і відстежувати зміни вимог. Автори вимог та інші зацікавлені особи можуть складати, переглядати, редагувати і затверджувати документи незалежно від БД проекту. Ці документи автоматично синхронізуються з проектом під час їх запису;

— трасування вимог — за зміни будьяких вимог наочно активуються зв’язки між ними. Таким чином полегшується перевірка актуальності інформації в репозиторії, оскільки необхідно перевірити не всі дані, а лише ті, що логічно пов’язані із виконаними змінами. Як вимоги у RequisitePro можна записувати будьякі твердження, посилання на зовнішні джерела або якусь значущу інформацію і користуватися можливостями навігації та керування змінами;

— Webінтерфейс практично повністю реалізує можливості «товстого клієнта», включно з великим набором адміністративних функцій;

— можливості авторизації доступу на основі сучасних механізмів керування безпекою, групами користувачів та окремими користувачами, а також налаштовування прав їх доступу до даних;

— підтримка методології IBM Rational Unified Process — наявність готових регламентів, шаблонів репозиторіїв вимог і шаблонів документів у складі IBM RUP (див. п. 2.2). Це полегшує, прискорює і зменшує трудомісткість запровадження дисципліни керування вимогами, зменшує необхідні інвестиції для проектування відповідних процесів і дозволяє уникати витрат на залучення консультантів з їх упровадження;

RequisitePro зорієнтований на роботу з різними типами вимог (рис. 3.9):

— потреби та запити зацікавлених осіб. Це може бути як один тип вимог, так і два — потреби як вимоги найвищого рівня і деталізовані запити зацікавлених осіб (Stakeholder requests, STRQ);

— характеристики (Features, FEAT) — зазвичай один із найважливіших типів вимог, але в разі формулювання користувачем вимог у формі прецедентів характеристики не потрібні;

— прецеденти (Use cases, UC) — якщо в системі не передбачається взаємодія з користувачем, прецеденти не розробляються. Прикладом є пакетні програми, які користувач лише запускає на виконання;

— додаткові вимоги (Supplementary requirements, SUPL) — нефункціональні вимоги. Оскільки зазвичай не існує відчутних відмінностей між додатковими вимогами і нефункціональними характеристиками, їх можна додати до вимог типу FEAT;

— сценарії (Scenarios, SC) використовуються для подання дієвих шляхів здійснення прецедентів. Сценарії полегшують перехід між прецедентами і тестовими сценаріями. Під час проектування на основі сценаріїв створюють діаграми послідовності. Вони також критичні для керування проектом, оскільки за одну ітерацію зазвичай реалізують не цілий прецедент, а набір сценаріїв із кількох прецедентів, отримуючи повністю реалізовані прецеденти лише наприкінці конструювання. Найчастіше робота розпочинається з основного потоку, а згодом додаються альтернативні потоки. Оскільки в RequisitePro сценарії не визначені як стандартний тип вимог, користувач має створити його самостійно;

Наведений перелік є актуальним для великих корпоративних проектів. Прості проекти можуть включати вимоги одного чи двох типів.

Тип вимоги зазначається при її відображенні. Формат такий:

Префікс Номер вимоги: Опис вимоги

Наприклад:

UC6: Формувати підтвердження контрагенту FEAT5: Система буде приймати платежі з кредитної картки

Вимоги можуть зберігатися або лише у базі даних проекту RequisitePro, або і в базі даних, і в документах. Під час створення вимоги у документі вона динамічно пов’язується з її поданням у базі даних. У базі даних зберігаються атрибути вимог, їхні зв’язки, відомості про версію, історія змін, обговорення, рівень безпеки тощо. Зазвичай це внутрішня для RequisitePro база даних Microsoft Access. Також є можливість підключення до бази даних підприємства (Oracle або SQL Server), що рекомендовано для великих проектів із тисячами вимог за потреби одночасної роботи з базою даних більш як п’яти користувачів або роботи команди в кількох віддалених місцях.

Для відстежування атрибутів вимог і зв’язків між ними документи не потрібні. Ці операції виконуються на основі бази даних. Водночас використання документів надає деякі переваги:

— легкий доступ до вимог для учасників команди, які не мають доступу до RequisitePro;

— можливість візуально групувати та організовувати вимоги;

— подання вимог у зручній для сприйняття формі;

— легкість додавання коментарів і пояснень.

Альтернативою для керування вимог у документах є використання звітів. Наприклад, можна створити шаблони специфікації прецедентів у системі документування SoDA і за необхідності обговорення прецедентів згенерувати відповідний звіт.

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

— прецеденти через їх описовий характер (один документ на прецедент);

— характеристики включають в огляд (Vision, див. нижче);

— додаткові вимоги у відповідній специфікації (Supplementary Specification).

Вимоги типу «потреби зацікавлених осіб» можна організувати за одним з трьох варіантів:

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

Таблиця 3.2

АТРИБУТИ ТА ЗНАЧЕННЯ АТРИБУТІВ, ЩО ВСТАНОВЛЮЮТЬСЯ ЗА УМОВЧАННЯМ ДЛЯ ВИМОГ ТИПІВ FEAT, SUPL, UC, STRQ

У RequisitePro встановлюються за умовчанням такі атрибути вимог: пріоритет (priority), стан (status), вартість (cost), складність реалізації (difficulty), стабільність (stability), «призначений» (assigned to), джерело (origin).

Оскільки деякі атрибути є неясними, під час планування корисно визначити їх трактування, наприклад:

— «пріоритет — високий» — має бути реалізований під час першої ітерації фази конструювання;

— «пріоритет — середній» — має бути реалізований не пізніше останньої ітерації фази конструювання;

— «пріоритет — низький» — може бути реалізований у разі наявності вільного часу;

— «ризик технології — високий» — використання нової технології, з якої команда не має досвіду;

— «ризик технології низький» — використання добре відомої технології, з якої команда має чималий досвід.

Для вимог можуть встановлюватись зв’язки ієрархії та залежності.

Зв’язки ієрархії — це зв’язки типу «батько — дитина». При цьому вимоги вищого рівня (загальніші) можуть бути декомпозовані на вимоги нижчого рівня (детальні), наприклад вимогабатько

Система має відображати інформацію про клієнта може мати вимогудитину

Система має відображати детальну інформацію про клієнта: Найменування, Адреса, Контактні телефони

Кожна вимога-нащадок може мати лише одного батька. Вимога може бути водночас і батьком, і нащадком. Вимоги зі зв’язком «батько—дитина» мають відображатися в одному документі. У разі видалення вимогибатька слід видалити і вимогунащадок або призначити останній іншого батька.

Робоча ділянка Word відкривається в окремому вікні і містить ту саму функціональність, що й Microsoft Word. Додаткова панель RequisitePro надає доступ до специфічних операцій з документами RequisitePro.                     

Користувач може імпортувати в ReхquisitePro існуючий документ Word або створити новий документ у середовищі системи на основі наявних шаблонів, стандартних або створених користувачем.

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

Найчастіше створюються і використовуються документи таких типів:

— огляд (бачення, Vision) — містить опис проблеми, що вирішується за допомогою нової ІС, високорівневий опис всієї системи та перелік головних функцій (один на проект). Цей документ визначає межі системи та обмеження, що накладаються, і підтверджує згоду замовнику на масштаб проекту. Огляд виступає в ролі контракту між розробником і замовником щодо технічних вимог. На основі огляду розробляють прецеденти та додаткову специфікацію;

— прецедент (Use Case) — описує поведінку системи у термінах послідовностей дій (кілька на проект);

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

— глосарій (Glossary) — пояснює всі терміни проекту (один на проект).

Причиною частого використання названих документів є те, що вони містять вимоги найважливіших типів — FEAT, UC, SUPL і можуть стати своєрідним зв’язком між командою розробки та користувачами.

Документ «Запити зацікавлених осіб» (Stakeholder Requests) використовується у 50 % проектів. Глосарій передбачений практично в усіх шаблонах проектів, але здебільшого не розробляється. План керування вимогами (Requirements Management Plan, RMP) є дуже корисним документом, але відчутно не змінюється в різних проектах — достатньо розробити його один раз (див. приклад у табл. 3.3) і згодом вносити невеликі зміни для відображення специфіки конкретного проекту.

Зв’язки залежності подаються у вигляді стрілок, а ієрархія — трикутниками. Якщо стрілка вказує на вимоги гілки дерева, то вимога, розташована вище, зумовлює вимогу на гілці. В іншому разі вимога гілки залежить від вимоги, розташованої вище. Підозрілі зв’язки подаються трикутником або стрілкою, перекресленою за діагоналлю.

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

Дискусія може бути організована як класичний форум — започаткування нової дискусії або додавання репліки в наявну дискусію викликає запуск поштової розсилки всім її учасникам. Більш ефективним є механізм організації дискусій на основі інтеграції RequisitePro з офісною поштовою системою. До складу системи при цьому входять:

— IBM Rational RequisitePro як «товстий» клієнт або Webінтерфейс RequisiteWeb — забезпечує можливості з керованого доступу до матеріалів дискусій, визначення учасників, зв’язування дискусії з однією або кількома вимогами, розсилання сповіщень учасників при додаванні нових реплік;

— технічний сервіс ClearQuest MailReader Service — імпортує у сховище RequisitePro репліки від учасників, нагромаджені у формі поштових повідомлень у технічній поштовій скриньці поштового сервера;

— поштовий сервер із доступом за протоколом POP3 принаймні для однієї електронної адреси (наприклад, Microsoft Exchange Server) — обмін поштовими повідомленнями між учасниками дискусії;

— робочі комп’ютери аналітиків із поштовими клієнтами (наприклад, поштовими програмами Microsoft Outlook) — взаємодія між учасниками дискусії поштою через служби сервера Microsoft Exchange Server і надані ним поштові скриньки.

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

Резюме

Розробку вимог можна вважати першим кроком проектування майбутньої ІС, бо вони стають єднальною ланкою між потребам зацікавлених осіб і проектними рішеннями, а згодом — і основою для перевірки правильності реалізації системи. Сучасні системи автоматизації керування вимогами мають різні функціональні можливості та інші характеристики, котрі слід ураховувати при їх виборі. Неодмінною умовою їх застосування є інтеграція з іншими CASEзасобами. Одним із найпопулярніших повнофункціональних засобів керування вимогами є система IBM Rational RequisitePro.

Терміни та поняття

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

Елемент трасування — елемент проекту, що його слід явно відстежувати в іншому елементі проекту для моніторингу залежності між ними. В IBM Rational RequisitePro ця вимога виконується поданням елементів проекту як екземпляра типу вимог RequisitePro.

Огляд (бачення) — перспектива продукту, що розробляється, з погляду користувача або замовника, виражена як ключеві потреби зацікавлених осіб і можливості системи.

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

Специфікація — декларативний опис того, чим є об’єкт або що він робить.

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

Тестовий сценарій — 1) послідовність дій (станів під час виконання), що визначає досліджувані функції в контексті виконання тесту. Він описує поведінку на певному рівні, посилаючись на один або кілька поведінкових екземплярів; 2) набір покрокових інструкцій для виконання тесту. Може формулюватися або як документальна інструкція для виконання вручну, або як машинний текст для автоматизованого виконання.

Тип вимоги — класифікація вимог на підставі загальних особливостей та атрибутів. Деякі типи вимог виникають із джерел вимог, таких як потреби зацікавлених осіб, можливості, варіанти використання, допоміжні вимоги, документація, апаратне забезпечення, вимоги до програмного забезпечення тощо. Вимоги можна також класифікувати за аспектами якості програмного забезпечення.

Трасування — залежність, що вказує на хронологічне або процесне відношення між двома елементами, які представляють одну й ту саму концепцію, але без жодних правил, які дозволяють вивести один елемент з іншого.