Матриця трасування вимог

Найбільш типовий спосіб подання зв'язків між вимогами та іншими елементами системами -матриця трасування вимог,яку також називаютьматрицею відстеження вимог аботаблицею трасируемости (requirements traceability matrix) (Sommerville і Sawyer, 1997). У табл. 20-показана частина такої матриці для Chemical Tracking System. Коли раніше створював такі матриці, я робив копію базової версії специфікації вимог і видаляв усе, крім ідентифікаторів функціональних вимог. Потім я створював таблицю, відформатовану як і, як табл. 20-1, і заповнював лише стовпець Функціональна вимога. Далі ми поступово заповнювали порожні комірки у матриці у міру розробки проекту.

Таблиця 20-1. Один з типів матриці трасування вимог

У табл. 20-1 показано, як кожна функціональна вимога пов'язана з певним варіантом використання (в напрямку назад) та з одним або більше елементами проектування, коду та тестування (в напрямку вперед). Елементи дизайну можуть бути об'єктами в таких моделях аналізу, як діаграми потоку даних, таблиці реляційної моделі даних або класах об'єктів. Посилання коду можуть бути методами класу, процедурами, що зберігаються, іменами файлів вихідного коду, а також процедурами або функціями у вихідному файлі. Ви можете додати додаткові стовпці для розширення посилань на інші робочі продукти, наприклад документацію довідкової системи. Додавання деталей трасируемости - додаткова робота, але ви отримуєте точні розташування пов'язаних елементів ПЗ, що економить масу часу під час аналізу впливу й обслуговуванні.

Заповнюйте інформацію у міру виконання роботи, а не в міру планування. Тобто вводьте "catalog.sort()" в стовпець Модулькоду першого рядка у табл. 20-1 тільки коли код у цій функції написано, пройшов тестування елементів і вже інтегрований з базовою версією вихідного коду продукту. Таким чином, читач матрицю буде знати, що заповнений осередки матриці для відстеження вимог вказують на роботу, яка вже виконана. Зверніть увагу, що перелік варіантів тестування для кожної вимогине вказує на те, що програмне забезпечення протестоване. Це просто означає, що деякі тести були написані для перевірки вимог у відповідний час. Трасування стану тестів - це окрема проблема.

Нефункціональні вимоги, такі, як завдання щодо продуктивності та атрибути якості не завжди простежуються безпосередньо до коду. Вимога часу відгуку може диктувати вибір певного устаткування, алгоритмів, структур баз даних чи архітектури. Вимога легкості переміщення може обмежити функції мови, що використовуються програмістом, однак не призведе до створення певних фрагментів коду, які активізують цю можливість. Інші атрибути якості дійсно реалізуються в коді. Вимоги до цілісності для аутентифікації користувачів активізує створення похідних функціональних вимог, що реалізуються за допомогою, скажімо, паролів або біометричних параметрів. У цих випадках слід трасувати відповідні функціональні вимоги у зворотному напрямку, до батьківських нефункціональних вимог, і, як завжди, у прямому, до готового продукту. На рис. 20-3 показано можливий ланцюг трасування за участю нефункціональних вимог.

Мал. 20-3. Приклад ланцюга трасування для вимог, що стосуються безпеки програми

Зв'язки трасування можуть визначити відносиниодному», «один до багатьох» або «багато хто до багатьох» між елементами системи. Формат у табл. 20-1 передбачає це, дозволяючи вводити кілька позицій у кожному осередку таблиці. Нижче наведено приклади можливих зв'язків.

«Один до одного»: один елемент проектування реалізується в одному модулі коду.
«Один до багатьох»: одна функціональна вимога перевіряється безліччю варіантів тестування.
«Багато багатьох»: кожен варіант використання породжує безліч функціональних вимог, а певні функціональні вимоги є спільними для декількох варіантів використання. Подібним чином, загальні або повторювані елементи проектування можуть задовольнити кілька функціональних вимог. В ідеалі варто було б зафіксувати всі ці взаємозв'язки, проте на практиці відносинами трасування типу «багато хто до багатьох» складно і важко управляти.

Інший спосіб представити інформацію трасування - за допомогою набору матриць, що визначають зв'язки між парами елементів системи, наприклад:

один тип вимоги з іншою вимогою цього типу;
один тип вимоги з вимогою іншого;
один тип вимоги із варіантами тестування.

Ви можете використовувати ці матриці для визначення різних взаємин, можливих між парами вимог, наприклад «вказує/вказаний», «залежить від», «є батьківським для» і «обмежує/обмежений» (Sommerville і Sawyer, 1997).

У табл. 20-2 показана двостороння матриця трасування. Більшість осередків матриці не заповнені. Кожна комірка на перетині двох зв'язаних компонентів позначена для вказівки з'єднання. Ви можете використовувати різні символи в осередках, щоб явно визначити "трасується до" і "трасується від" абоінші взаємини. У табл. 20-2 стрілка показує, що це функціональне; вимога відстежується від певного варіанта використання. Ці матриці більше піддаються автоматизації засобами підтримки, ніж, що в табл. 20-1.

Таблиця 20-2. Матриця для трасування вимог, що показує зв'язки між варіантами використання та функціональними вимогами