Матрица за проследяване на изискванията
Най-често срещаният начин за представяне на връзките между изискванията и други елементи на системите е - матрица за проследяване на изискванията, което се нарича още матрица за проследяване на изискванията или таблица на проследимостта(матрица за проследяване на изискванията) (Sommerville and Sawyer, 1997). Таблица 20 показва част от такава матрица за системата за химическо проследяване. Когато създадох матрици като тази преди, направих копие на спецификацията на базовите изисквания и премахнах всичко, освен идентификаторите на функционалните изисквания. След това създадох таблица, форматирана същото като таблица. 20-1 и само попълни колоната за функционални изисквания. След това постепенно попълвахме празни клетки в матрицата с развитието на проекта.
Таблица 20-1. Един от видовете матрица за проследяване на изискванията
Таблица 20-1 показва как всяко функционално изискване е свързано със специфичен случай на употреба (назад) и един или повече дизайн, код и тестови елементи (напред). Елементите на дизайна могат да бъдат обекти в модели за анализ, като диаграми на потока от данни, таблици в релационен модел данни или обектни класове. Препратките към кода могат да бъдат методи на клас, съхранени процедури, имена на файлове с изходен код и процедури или функции в изходен файл. Можете да добавите допълнителни колони, за да разширите връзките към други работни продукти, като помощна документация. Добавянето на подробности за проследяването е допълнителна работа, но получавате точни местоположения на свързани софтуерни елементи, което спестява много време при анализ на въздействието и поддръжка.
Попълнете информацията с напредването на работата, а не както планирате. Тоест, въведете "catalog.sort ()" в колоната Кодов модул на първия ред в Таблица. 20-1 само когато кодът в тази функция е написан, преминал е тестване на елементи и вече е интегриран с основната версия на изходния код на продукта. По този начин читателят на матрицата ще знае, че попълнените клетки в матрицата за проследяване на изискванията показват вече извършена работа. Моля, обърнете внимание, че изброяването на опциите за тестване за всяко изискване не посочваче софтуерът е тестван. Това просто означава, че са били написани определени тестове за валидиране на изискванията в подходящия момент. Проследяване на състоянието на теста е отделен въпрос.
Нефункционалните изисквания, като например целите на изпълнението и атрибутите на качеството, не винаги са пряко проследими до кода. Изискването за време за реакция може да диктува избора на конкретен хардуер, алгоритми, структури на база данни или архитектура. Изискването за лекота на придвижване може да ограничи езиковите функции, използвани от програмиста, но няма да доведе до създаването на специфични кодови фрагменти, които активират тази възможност. Други атрибути за качество всъщност са внедрени в кода. Изискванията за почтеност за удостоверяване на потребителя активира създаването на производни функционални изисквания, които се изпълняват, използвайки, да речем, пароли или биометрични данни. В тези случаи съответните функционални изисквания трябва да бъдат проследени обратно до техните нефункционални изисквания и, както обикновено, да бъдат изпратени до крайния продукт. На фиг. 20-3 показва възможна верига за проследяване, включваща нефункционални изисквания.