Глосарій

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

Крім того, глосарій є відправною точкою для побудови більш розгорнутих моделей проблемної області, які, на стадії реалізації інформаційної системи, лягають в основу об'єктної моделі (для об'єктно-орієнтованих додатків) і моделі даних (для генерації схеми бази даних).

Глосарій оформлюють, як текст, що складається з абзаців, кожен з яких визначає значення одного з термінів проблемної області. Термін зазвичай виділяють напівжирним кеглем. Іноді проблемну область доцільно сегментувати на ряд «підгалузей» (subject areas). Тоді кожній з них у глосарії виділяється окремий параграф.

Існують різні шаблони опису варіантів використання. Так, у монографії [2] розглядаються наступні основні стилі опису:

• вільний формат,

• повний формат (запропонований А. Коберном),

• таблиця у дві колонки,

• таблиця у три колонки,

• стиль RUP.

Крім того, іноді доцільно використати:

• псевдокод,

• діаграму активності UML (див. тему №8),

• інші графічні моделі.

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

Шаблон повного опису варіанту використання за а. Коберном

Назва <коротка фраза у вигляді дієслова в невизначеній формі доконаного виду, що відображає мету>

Контекст використання <уточнення мети, за необхідності, умови її нормального завершення>.

Зона дії <посилання на рамки проекту>. Наприклад, підсистема бухгалтерського обліку.

Рівень <один з трьох: узагальнений, цілі користувача, підфункції>. При цьому задається обумовлена трьохрівнева класифікація вимог, що загалом відповідає поділу вимог на бізнес-вимоги, вимоги користувачів і функціональні вимоги (див. Тема№1).

Основна дійова особа <ім'я ролі основного актора або його опис>.

Учасники і інтереси <список інших акторів-учасників прецеденту з вказівкою їх інтересів>.

Передумова <те, що очікується, вже має місце>.

Мінімальні гарантії <що гарантується акторам-учасникам>. Наприклад, у разі невдалої транзакції усі дані, що були у системі до її початку, зберігаються незмінними.

Гарантії успіху <що отримають актори-учасники у разі успішного досягнення мети>.

Тригер <те, що «запускає» варіант використання, зазвичай - подія у часі>.

Основний сценарій <тут перераховуються кроки основного сценарію, починаючи від тригера і до досягнення гарантії успіху>.

Формат опису: <Номер кроку>, <Опис дії>.

Розширення <тут послідовно описуються усі альтернативні сценарії>. Кожна з альтернатив прив'язана до кроку основного сценарію.

Формат опису: <Номер кроку. Номер розширення> <Умова>: <Дія або посилання на підпорядкований варіант використання>.

Будь-який з кроків основного сценарію може мати одне або більше розгалуження. Кожне розгалуження оформлюється у вигляді розширення. У блоці «Розширення» усі розширення описуються послідовно.

У разі, якщо альтернативний сценарій не вдається описати одним рядком, застосовується наступний формат.

Починаючи з рядка, наступного після опису розширення, йде опис його дій у форматі основного сценарію:

<Номер кроку. Номер розширення. Номер кроку розширення> <Дія>.

Опис розширення закінчується описом виходу з розширення. Основні варіанти виходу з розширення: повернення до чергового за номером кроку основного сценарію, закінчення прецеденту, перехід до іншого кроку основного сценарію.

Перелік змін у технології і даних <що гарантується акторам-учасникам>. Наприклад, у випадку невдалої транзакції усі дані, що були в системі до її початку, зберігаються незмінними.

Допоміжна інформація <додаткова інформація, корисна при описі варіанту використання>.