< Попередня  Змiст  Наступна >

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). Це полегшує, прискорює і зменшує трудомісткість запровадження дисципліни керування вимогами, зменшує необхідні інвестиції для проектування відповідних процесів і дозволяє уникати витрат на залучення консультантів з їх упровадження;

— автоматичне генерування і публікація звітів — подання даних репозиторію вимог у наочній або уніфікованій формі. Для генерування звітів використовується BIRT (Business Intelligence & Reporting Tool), побудований на основі Eclipse. На сервері публікацій RequisitePro можна опублікувати звіти, підготовлені за допомогою BIRT, і ця інформація доступна для всіх зацікавлених осіб;

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

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

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

— інтеграція з іншими інструментальними засобами. RequisitePro дає змогу використовувати вимоги з власного репозиторію іншим засобам IBM Rational — Software Modeler, Software Architect, Rational Rose, ClearQuest, TestManager, QualityManager, SoDA, ClearCase. Частину таких зв’язків унаочнює рис. 3.8. Відкритість архітектури RequisitePro надає змогу інтегрувати його із засобами інших розробників — SQA Suite, PVCS VersionManager, Microsoft Visual SourceSafe, Microsoft Project, Atlassian JIRA тощо.

Інтеграція IBM Rational RequisitePro з CASE-засобами IBM Rational

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

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

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

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

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

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

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

— проблеми (Problems with existing solution, PROB) — головні проблеми з наявними рішеннями, що їх має вирішити нова система. Зазвичай вони розташовуються на вершині піраміди.

Ієрархія вимог RequisitePro

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

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

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

 

Наприклад:

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— в огляді (Vision) — створюється лише один документ, але він поєднує вимоги стосовно предметної області (STRQ) з вимогами, що описують безпосередньо рішення (FEAT).

Тип вимоги зумовлює асоційовані з нею атрибути та їх значення, що встановлюються за умовчанням. У табл. 3.2 наведено приклади атрибутів та їхніх значень, встановлених за умовчанням у шаблоні UC для вимог типу FEAT, SUPL, UC, STRQ (вони можуть змінюватися залежно від версії RequisitePro, що використовується). Перелік цих атрибутів та їхні значення можуть змінюватися користувачем.

 

Таблиця 3.2

 

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

 


Атрибут

Значення атрибута

Типи вимог

FEAT

SUPL

UC

STRQ

Пріоритет (Priority)

Високий (High) Середній (Medium) Низький (Low )

+

+

+

 

Тип (Type)

Функціональний (Functional) Зручність і простота використання (Usability)

Надійність (Reliability) Продуктивність (Performance) Можливість підтримки (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

+

+

+

 

Запланована ітерація (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)

 

 

 

+

 

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

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

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

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

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

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

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

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

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

 

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

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

 

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

Зв’язки залежності «зумовлює» (is traced to) та «залежить від» (traсed from) встановлюються між вимогами різних типів, наприклад вимоги щодо тестування залежать від функціональних вимог до системи. Можна встановити зв’язок залежності між вимогами в одному документі, в різних документах, у БД проекту. Заборонений зв’язок залежності між батьком і нащадкам, але між батьком і нащадками інших батьків таку залежність можна встановити.

RequisitePro підтримує також непрямі залежності між вимогами з неможливістю їх безпосереднього змінення: якщо А зумовлює B, а B зумовлює C, то між А і C є непряма залежність.

Ієрархічні вимоги і вимоги «батько—дитина» мають складну нумерацію:

 

Номер вимоги вищого рівня. Номер вимоги наступного рівня

 

Наприклад:

 

SR4: Система має відображати SR4.1: Адресу

SR4.1: Найменування клієнта

 

Зв’язки між вимогами надають можливість відстежувати життя вимоги від джерела її формулювання через проектування до реалізації, а також у зворотному напряму. В разі зміни вимоги відбувається трасування зв’язків для перевірки впливу цих змін на інші вимоги. Найчастіше структура зв’язків вимог наслідує ієрархію вимог, представлену на рис. 3.9, і може мати вигляд, представлений на рис. 3.10. У багатьох проектах цю структуру спрощено, наприклад, відсутні сценарії і тестові сценарії. З іншого боку, можуть простежуватися зв’язки між проблемами (PROB) і запитами (STRQ). Якщо проблеми з наявною системою є глобальними (наприклад, складність супроводу), то вони стоять на верхньому щаблі ієрархії вимог. Якщо ж вони стосуються окремих дефектів, можна передбачити їх запис до системи керування дефектами (наприклад, IBM Rational ClearQuest) і встановлення відповідних посилань на вимоги у RequisitePro.

Зв’язки трасування згідно з ієрархією вимог

Основними елементами інтерфейсу, з якими працює користувач, є провідник (Explorer, у головному вікні RequisitePro його вікно розташоване зліва, див. рис. 3.11), форми (Views, ділянка праворуч) та робоча ділянка Word, що відкривається в окремому вікні.

Вікно провідника — це головне вікно навігації, яке показує компоненти проекту RequisitePro у деревоподібній формі — документи (Document), вимоги (Requirement) та форми (View, див. далі), організовані в пакети (Package). Проект створюється адміністратором проекту, який визначає його структуру і встановлює права доступу користувачів проекту.

Залежно від обраного шаблона за умовчанням можуть встановлюватися такі пакети: аналіз покриття (Coverage Analysis), характеристики і огляд (Features and Vision), глосарій (Glossary), запити зацікавлених осіб (Stakeholder Requests), додаткові вимоги (Supplementary Requirements), прецеденти (Use Cases).

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

Головне вікно RequisitePro

Робоча ділянка 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) і згодом вносити невеликі зміни для відображення специфіки конкретного проекту.

 

Таблиця 3.3 ПРИКЛАД ПЛАНУ ПРОЕКТУ

 

Документ

Вимога

Найменування

Тип Розширення

Мітка Тип

Зумовлює вимогу

Залежить від вимоги

Словник термінів предметної області

Словник .GLS

TERM Термін

Не має

Не має

Бізнес-правила предметної області

Бізнесправила .BRUL

BUS Бізнес-правило

UC

Не має

Технічне завдання

Технічне завдання .TT

UC Функція системи

ТС (функції, що тестуються

NEED (потреби замовника

 

Форми показують атрибути вимог або взаємозв’язки між ними і використовуються для аналізу вимог. У RequisitePro є три форми — матриця атрибутів (Attribute Matrix), матриця трасування (матриця зв’язків, Traceability Matrix) і дерево трасування (дерево зв’язків, Traceability Tree).

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

Форми трасування призначені для керування ланцюговими наслідками змін вимог.

Матриця трасування показує взаємозв’язки між двома типами вимог (рис. 3.13) і використовується для створення, модифікації, видалення та аналізу зв’язків, перегляду непрямих зв’язків, аналізу впливу. Типи вимог можуть як різними, так і тими самими.

Матриця атрибутів RequisitePro

Матриця трасування RequisitePro

Комірки матриці зв’язків можуть мати такий вміст:

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

— стрілка, перекреслена за діагоналлю червоною лінією, — підозрілий зв’язок;

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

— пуста комірка — відсутність зв’язку;

— трикутник, перекреслений по діагоналі червоною лінією, — підозрілі ієрархічні відношення.

Дерево трасування показує залежності вимог певного типу (рис. 3.14). Тут доступні операції створення та оновлення вимог, встановлення зв’язків між ними, сортування та накладання фільтрів, формування запитів щодо статусу проекту, експорту в інші формати.

Дерево трасування RequisitePro

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

На окрему увагу заслуговують можливості 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) набір покрокових інструкцій для виконання тесту. Може формулюватися або як документальна інструкція для виконання вручну, або як машинний текст для автоматизованого виконання.

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

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

Трасування вимог — зв’язок вимог з іншими вимогами чи артефактами і пов’язаними елементами проекту.


< Попередня  Змiст  Наступна >
Iншi роздiли:
4.2. АВТОМАТИЗОВАНА ПІДТРИМКА ГРУПОВОГО ПРОЕКТУВАННЯ
4.3. ПІДТРИМКА ПРОЕКТУВАННЯ НА ОСНОВІ ІНТЕЛЕКТУАЛЬНОГО РЕПОЗИТОРІЮ
4.4. АВТОМАТИЗАЦІЯ ПРОТОТИПУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ
Тема 5. АВТОМАТИЗАЦІЯ ОБ’ЄКТНО ОРІЄНТОВАНОГО ПРОЕКТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ
5.2. АВТОМАТИЗАЦІЯ АНАЛІЗУ ТА ПРОЕКТУВАННЯ ЗА ДОПОМОГОЮ IBM RATIONAL ROSE
Дисциплiни

МаркетингАнглійська моваПравоЕтика та естетикаІсторіяБухгалтерський облікЕкономікаІнформатикаМенеджментПолітологіяСтатистикаФінанси

Бібліотека підручників та статтей Posibniki