Специфікація нефункціональних вимог

Опис нефункціональних вимог, зазвичай, здійснюється у формі, близькій до вільного формату опису варіанту використання. RUP рекомендує зосереджувати нефункціональні вимоги у документі, що описує варіант використання в усіх випадках, коли це можливо. У разі, якщо нефункціональні вимоги носять загальний характер і не можуть бути прив'язані до конкретного прецеденту, вони виносяться до документу «Додаткова специфікація».

Атрибути вимог

Описи вимог мають бути облікованими. Для цього усі вимоги повинні враховуватися в тій або іншій обліковій системі, будь то електронна таблиця MS Excel, спеціалізована база даних, або інтегроване середовище управління змінами. При реєстрації вимоги воно проходить класифікацію відповідно до певної системи ознак. Основні ознаки (атрибути) вимог були розглянуті у темах №1-2. Крім того, для оперативного управління вимогами буває корисно призначити їм такі властивості, як проект, відповідальну особу, статус, ризик, міру закінченості тощо. У RUP для управління атрибутами вимог передбачений артефакт «Атрибути вимог».

Артефакт «Атрибути вимог», пропонований RUP, є репозиторій текстів вимог, їхніх атрибутів і трасованості.

Атрибути вимог представлені матрицею атрибутів вимог, де для кожного типу вимог перераховуються вимоги по одній осі і атрибути вимог цього типу по іншій. Для кожної вимоги вказуються значення її відповідних атрибутів. Приклади атрибутів: статус у часі, пріоритет, важливість, ризик, № ітерації (етапу) в плані.

Трасованість описується у вигляді дерева, що показує у графічному вигляді зв'язки трасованості, що входять та (або) виходять.

Література до теми:

1. Фаулер М, Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. Пер. с англ. - М.:Мир, 1999. - 191 с.

2. Коберн А. Современные методы описания функциональных требований к системам

3. Новиков Л. Введение в Rational Unified Process

7.3. Питання для самоконтролю

1. Дайте визначення «варіантів використання» (Use Cases), наведіть приклади.

2. Охарактеризуйте основні стилі опису варіантів використання.

3. Від чого, на вашу думку, залежить вибір форми опису варіантів використання?

4. Підготуйте приклад опису варіантів використання за обраною вами методологією.

Тема №8. Розширений аналіз вимог. Моделювання

8.1. Методичні вказівки до вивчення теми

Які моделі використовувати

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

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

Щоб полегшити процес формулювання і розуміння вимог для замовника, існує ряд прийомів. По-перше, вимоги можна формулювати на різних рівнях абстракції. Так, рівень опису вимог, підтримуваний у документі «Бачення», є досить збалансованим. Те ж можна сказати і про стислі (у один абзац) описи ключової функціональності системи. Діючи таким чином, ми, очевидно, розв'яжемо проблему залучення замовника до аналізу завдань, проте вказані вище ризики будуть знижені недостатньо: концептуальні описи функціональності залишають багато свободи для тлумачення у той чи інший бік.

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

На сьогоднішній день в арсеналі аналітика існують десятки методик, мов, візуальних уявлень, що дозволяють моделювати вимоги до системи. При створенні програмних систем стандартом де-факто являється універсальна мова моделювання, UML [1,2].

Як визначити доцільність використання тих або інших прийомів, методик, мов моделювання при аналізі вимог? Можна запропонувати такі практичні рекомендації:

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

По-друге, аналіз вимог повинен знаходити відповідь на те, ЩО робить система, абстрагуючись від деталей реалізації, тобто того, ЯК вона це робить. Тому, припустимо, діаграму взаємодії об'єктів, що реалізовують той або інший варіант використання, можна розглядати скоріше, як ілюстрацію внутрішнього устрою системи, корисну для програміста, ніж модель для замовника.

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