Използвайте този шаблон
При повечето внедрявания на системи изискванията живеят в един документ, дизайните в друг, тестовите случаи — в тестов инструмент, а SOP-ите, ръководствата (runbooks) и обучението — в папки, към които никой не се свързва. После настъпва промяна на изискване, появява се дефект или одитор пита как е тестван даден контрол, и никой не може да каже къде е отишло това изискване. Шаблонът за матрица на проследимостта на изискванията решава това, като свързва всяко изискване — в една таблица — с всичко, което го доставя, и с доказателствата, че работи.
Този безплатен шаблон за матрица на проследимостта на изискванията свързва всяко изискване с раздела от документа с функционални изисквания (FRD), дизайна, елемент за конфигурация или за изграждане, SOP-а или runbook-а, който го управлява, тестовите случаи, които го валидират, обучението, което го преподава, и текущия му статус. Включва попълнен пример, типовете проследимост, които да използвате, и начин да поддържате матрицата актуална, докато проектът се променя. Копирайте структурата по-долу или я отворете в Trupeer и я персонализирайте за вашия проект.
Какво е шаблон за матрица на проследимостта на изискванията?
Шаблонът за матрица на проследимостта на изискванията, често наричан RTM, е структурирана таблица, която свързва всяко изискване с документите и работните елементи, които го доставят и проверяват. Всяка колона започва с изискване и го проследява напред към функционалната спецификация, дизайна и изграждането, SOP-а или runbook-а, който хората използват, за да го управляват, тестовите случаи, които доказват, че работи, и обучението, което подготвя потребителите. Може да проследява и назад — от тестов случай или SOP към изискването, което обслужва.
Резултатът е един изглед, който отговаря на въпросите, които всеки проект в крайна сметка си задава: покрито ли е всяко изискване, какво е засегнато, ако това се промени, и откъде знаем, че работи?
Защо да използвате матрица на проследимостта на изискванията?
Нищо не изпада между етапите. Всяко изискване трябва да има дизайн, тест и отговорник.
Влиянието от промени е видимо. Когато изискване се промени, можете да видите всички документи, тестове и SOP-и, които са засегнати.
Тестването е завършено. Всяко изискване се свързва поне с един тестов случай, а всеки тестов случай се връща към изискване.
Операциите са готови. Изискванията се свързват със SOP-ите и runbook-ите, които хората ще използват след go-live, не само с изграждането.
Одитите са по-лесни. Можете да покажете как е проектиран, тестван и документиран даден контрол, базиран на изискване.
Предаването е по-чисто. Екипът по run получава карта на това, което е изградено, и защо.
Кой използва шаблон за матрица на проследимостта на изискванията?
Бизнес анализатори, които притежават изискванията и техните връзки.
Мениджъри на проекти и програми, които следят покритието и влиянието от промени.
Архитекти на решения и функционални консултанти, които проектират и изграждат спрямо изискванията.
Мениджъри на тестове, които потвърждават тестовото покритие.
Екипи по операции и поддръжка, които притежават SOP-ите и runbook-ите след go-live.
Лийдове по обучение, които гарантират, че всяка променена процедура има обучение.
Екипи по качество, риск и одит, които се нуждаят от доказателства за контролни изисквания.
Прегледайте шаблона за матрица на проследимостта на изискванията
Шаблонът се отваря с резюме на проекта и конвенции за ID. След това следва основната матрица с по един ред за всяко изискване: ID, описание, източник, приоритет, раздел от FRD, елемент за дизайн или изграждане, SOP или runbook, тестови случаи, статус на тестовете, съдържание за обучение, отговорник и общ статус. Резюме за покритието показва изискванията без дизайни, тестове, SOP-и или обучение, а дневникът на промените записва всяка промяна на изискване и нейното влияние. Всяка колона е редактируема, така че можете да добавяте регулаторни препратки, номера на версии на release или връзки към вашите инструменти.
Как да персонализирате този шаблон в Trupeer
Стъпка 1: Отворете секцията Templates
Отидете в секцията Templates от главната навигация.
Стъпка 2: Изберете и отворете шаблон
Кликнете върху който и да е шаблон, с който искате да работите, за да го отворите.
Стъпка 3: Разгънете изгледа на шаблона
Ако е нужно, разгънете изгледа на шаблона, за да виждате пълната структура и детайлите ясно.
Стъпка 4: Редактирайте шаблона
Кликнете върху Edit, за да започнете да променяте избрания шаблон.
В редактора можете да:
Добавяте нови секции
Дефинирате или актуализирате правила за форматиране
Добавяте лого и настройвате позицията му и свързаните настройки
Стъпка 5: Запазете персонализирания си шаблон
След като направите всички необходими промени, кликнете върху Save, за да запазите обновения шаблон като свой.
Стъпка 6: Прегледайте и фино настройте шаблона
Когато искате да видите как изглежда вашият персонализиран шаблон, отворете Preview.
От екрана за преглед можете да продължите да правите корекции директно, ако е нужно, като гарантирате, че шаблонът изглежда точно както искате.
С шаблон за матрица на проследимостта на изискванията можете да:
Доказвате покритие: Вижте с един поглед кои изисквания са проектирани, изградени, тествани и документирани.
Проследявате изискванията към операциите: Свържете всяко изискване със SOP-а или runbook-а, който го изпълнява след go-live.
Оценявате влиянието от промени бързо: Открийте всички засегнати документи, тестове и SOP-и за секунди.
Подкрепяте одит и съответствие: Покажете как всяко изискване е доставено и валидирано.
Предавате чисто: Дайте на екипа по run пълна карта на системата.
Какво трябва да съдържа шаблонът за матрица на проследимостта на изискванията
Колона | Какво да запишете |
|---|---|
ID на изискването | Уникална, стабилна референция, например REQ-P2P-014 |
Описание на изискването | От какво се нуждае бизнесът, на прост език |
Източник | Откъде е дошло: workshop, регулация, fit-gap ред или as-is запис |
Приоритет | Must have, should have или could have |
Раздел от FRD | Разделът от документа с функционални изисквания, който го специфицира |
Елемент за дизайн или изграждане | Конфигурация, обект за разработка или интерфейс, който го доставя |
SOP или runbook | Оперативната процедура, която хората следват, за да го изпълняват или поддържат |
ID на тестови случаи | Тестовите случаи или UAT скриптовете, които го валидират |
Статус на теста | Не е пуснат, преминал, неуспешен или блокиран |
Съдържание за обучение | Ръководството или видеото, което преподава промяната на потребителите |
Отговорник | Лицето, което носи отговорност за изискването |
Статус | Отворено, в дизайн, в изграждане, тествано, документирано или приключено |
История на промените | Промените в изискването и тяхното влияние |
Безплатен шаблон за матрица на проследимостта на изискванията: структурата за копиране
Копирайте структурата по-долу във вашата собствена електронна таблица или я отворете в Trupeer и я персонализирайте.
1. Резюме на проекта. Проект: [name]. Система: [system and release]. Обхват: [processes]. RTM отговорник: [business analyst or PMO]. Последна актуализация: [date].
2. Конвенции за ID. Изисквания: REQ-[process]-[number]. Раздели от FRD: FRD-[section]. Елементи за изграждане: [development or configuration IDs]. SOP-и и runbook-и: SOP-[number] или RB-[number]. Тестови случаи: TC-[number] или UAT-[number].
3. Матрица на проследимостта.
Req ID | Изискване | Източник | Приоритет | Раздел от FRD | Елемент за дизайн или изграждане | SOP или runbook | Тестови случаи | Статус на теста | Обучение | Отговорник | Статус |
|---|---|---|---|---|---|---|---|---|---|---|---|
[REQ-ID] | [Description] | [Source] | [Must / should / could] | [FRD-x.x] | [Item ID] | [SOP or RB ID] | [TC or UAT IDs] | [Status] | [Guide or video] | [Owner] | [Status] |
4. Резюме на покритието. Изисквания без раздел от FRD, без елемент за изграждане, без тестов случай, без SOP или runbook и без обучение.
5. Дневник на промените. Дата, ID на изискването, промяна, причина, засегнати елементи и одобрение.
Пример за матрица на проследимостта на изискванията: procure to pay
Ето как може да изглежда част от RTM за procure to pay при внедряване на ERP. Детайлите са илюстративни.
Req ID | Изискване | Раздел от FRD | Елемент за изграждане | SOP или runbook | Тестови случаи | Статус на теста | Обучение | Статус |
|---|---|---|---|---|---|---|---|---|
REQ-P2P-014 | Тристранно съвпадение на фактури за стоки в рамките на толеранса | FRD-4.2 | Конфигурация на толеранса | SOP-AP-003 обработка на фактури | UAT-P2P-001 стъпки 3–4 | Преминал | Видео за AP фактури | Приключено |
REQ-P2P-015 | Блокиране на фактури над толеранса за цена за преглед от купувача | FRD-4.3 | Конфигурация за блокиране на плащания | SOP-AP-003, таблица с изключения | UAT-P2P-001 стъпка 5 | Неуспешен, след това преминал при повторен тест | Видео за AP изключения | Приключено |
REQ-P2P-021 | Нощна интеграция на одобрени фактури към системата за плащания | FRD-6.1 | Интерфейс INT-07 | RB-INT-07 runbook за мониторинг на интерфейса | TC-INT-07-01 до 04 | Преминал | Разходка с runbook за екипа по поддръжка | Тествано |
REQ-P2P-030 | Проверка на промени в банковите данни на доставчика преди плащане | FRD-3.5 | Работен процес с двойно одобрение | SOP-VMD-002 проверка на промени в банкови данни | UAT-VMD-004 | Не е пуснат | Видео за доставчик master | В изграждане |
Всеки ред показва не само дали изискването е изградено и тествано, но и как ще се управлява: SOP за бизнес потребителите и runbook за екипите по поддръжка.
Типове проследимост
Тип | Посока | На какъв въпрос отговаря |
|---|---|---|
Проследимост напред | Изискване → дизайн → изграждане → тест → SOP | Покрито ли е всяко изискване — доставено, тествано и документирано? |
Проследимост назад | Тест, SOP или елемент за изграждане → изискване | Служи ли всичко, което сме изградили или написали, на изискване? |
Дву посочна проследимост | И в двете посоки | Пълно покритие и без ненужна работа; стандартът за повечето проекти |
Използвайте двупосочна проследимост при повечето внедрявания на системи. Тя открива липсващи тестове и документация, а също така открива и персонализирана работа и процедури, които вече не се проследяват към изискване.
Веригата на проследимостта през внедряване
Матрицата свързва документи, които обикновено се създават от различни екипи в различни моменти. Ето как се подреждат:
Етап | Документ | Какво свързва матрицата |
|---|---|---|
Откриване | Записи as-is и документи | Доказателствата зад всяко изискване |
Проучване | Анализ fit-gap | Кои изисквания се вписват в стандартното решение и как се решават пропуските |
Специфициране | Документ с функционални изисквания (FRD) | Разделът, който специфицира всяко изискване |
Изграждане | Елементи за конфигурация и разработка | Какво доставя всяко изискване |
Тест | Тестови случаи и UAT скриптове | Как се валидира всяко изискване, с резултати |
Деплой | SOP-и, runbook-и и обучение | Как хората управляват и поддържат всяко изискване след go-live |
Run | Заявки за промени и releases | Какво се променя и кои документи и тестове са засегнати |
За изискванията и решенията за пропуски в началото на веригата използвайте шаблона за анализ fit-gap.
Проследимост на изискванията за регулирани и одитирани процеси
В регулирани индустрии и за финансови контроли проследимостта не е опция. Одиторите и екипите по валидация обикновено искат да видят за всеки контрол или регулирано изискване спецификацията, доказателствата от теста и процедурата, която хората следват. Добавете колона за препратката към регулацията или контрола, маркирайте кои изисквания са контроли и прикачете доказателствата от теста, като UAT записи, директно към тези редове. Преглеждайте контролни изисквания преди всяко release, защото промяна, която нарушава контрол, е много по-скъпо да се поправи след констатация от одит.
Защо да проследявате изискванията към SOP-и и runbook-и?
Повечето матрици на проследимостта спират до тестването. Това доказва, че системата работи в деня, в който е тествана, но не и че хората могат да я управляват след това. Добавянето на SOP-и и runbook-и затваря тази празнина:
Бизнес потребителите получават SOP за всяко изискване, което променя начина, по който работят.
Екипите по поддръжка получават runbook за всеки интерфейс, job и техническо изискване, което ще наблюдават.
Изключенията в изискването се появяват в таблицата с изключения в SOP-а и в стъпките за отстраняване на проблеми в runbook-а.
Промените в изискване показват точно кои SOP-и и runbook-и трябва да се актуализират.
За готов формат на оперативна процедура използвайте шаблона за runbook.
Как да изградите матрица на проследимостта на изискванията стъпка по стъпка
Съгласете конвенциите за ID за изисквания, раздели от FRD, елементи за изграждане, SOP-и, runbook-и и тестове.
Избройте всяко изискване заедно с източника му, като свържете as-is доказателства, когато ги имате; вижте събиране на ERP изисквания от записи на процеси.
Свържете всяко изискване със съответния раздел от FRD и елемент за дизайн или изграждане.
Свържете тестовите случаи, докато ги създавате, включително UAT скриптове; използвайте шаблона за UAT тест скрипт.
Свържете SOP-и, runbook-и и обучение за всяко изискване преди go-live.
Актуализирайте статуса на тестовете след всеки тестов цикъл.
Преглеждайте резюмето на покритието на всяка контролна точка и затваряйте пропуските.
Записвайте всяка промяна на изискване заедно с влиянието и одобрението.
Как да поддържате матрицата актуална
Назначете един човек за отговорник за RTM, обикновено водещия бизнес анализатор или PMO.
Актуализирайте я като част от всяка заявка за промяна, а не постфактум.
Преглеждайте покритието на всяка контролна точка: одобрение на дизайна, изход от теста и готовност за go-live.
Предайте я на екипа по run при go-live, с отговорници за всеки SOP и runbook.
Дръжте свързаните SOP-и и runbook-и с версии, за да сочи матрицата винаги към текущата процедура; вижте контрол на версиите на SOP.
Формати за матрица на проследимостта на изискванията
Електронна таблица е най-често използваният формат, с филтри за статус, отговорник и пропуски.
Инструмент за управление на изисквания или тестове подхожда на големи програми, които се нуждаят от автоматизирани връзки и табла.
Документ подхожда за подписано резюме на покритието на всяка контролна точка.
Какъвто и формат да използвате, поддържайте една главна матрица и свързвайте към нея от проектните документи.
Най-добри практики за проследимост на изискванията
Използвайте стабилни, уникални ID, които никога не се използват повторно.
Записвайте по едно изискване на ред, а не комбинирани изисквания.
Свързвайте с доказателства, като записи на as-is процеса, а не само с бележки от workshop.
Проследявайте към операциите, със SOP-и и runbook-и, а не само към тестването.
Преглеждайте резюмето на покритието редовно, не само в края.
Дръжте матрицата достатъчно лека, за да я поддържат реално хората.
Чести грешки, които да избягвате
Създаване на матрицата в края на проекта, за да удовлетворите одит.
Спиране при тестови случаи, без връзка към SOP-и, runbook-и или обучение.
Комбиниране на няколко изисквания в един ред, така че покритието да е неясно.
Без отговорник, така че матрицата да излезе от актуалност.
Без запис на промени, така че влиянието да не може да се проследи.
Чеклист за матрица на проследимостта на изискванията
Конвенциите за ID са договорени за всеки тип елемент.
Всяко изискване има източник, приоритет и отговорник.
Всяко изискване се свързва с раздел от FRD и с елемент за изграждане.
Всяко изискване се свързва поне с един тестов случай, със текущ статус.
Всяко изискване, което променя начина, по който хората работят, се свързва със SOP или runbook и обучение.
Резюмето на покритието показва, че няма необяснени пропуски.
Промените се записват заедно с влиянието и одобрението.
Как Trupeer ви помага да завършите веригата на проследимостта
Предизвикателство при проследимостта | Как Trupeer помага |
|---|---|
Липсват доказателства за изискванията | Записвайте SMEs, които изпълняват реалния процес, и свързвайте всяко изискване със записа и с документа as-is, който Trupeer създава от него |
SOP-ите и runbook-ите още не съществуват | Записвайте конфигурирания процес или задачата по поддръжката и SOP creator на Trupeer го превръща в SOP или runbook стъпка по стъпка |
Доказателствата от теста са разпръснати | Записвайте UAT изпълнения и свързвайте записите с тестовите случаи в матрицата |
Липсва обучение за променени изисквания | Същите записи стават обучителни видеа и ръководства за всяка роля |
Документите излизат от актуалност след промени | Актуализирайте SOP-ите и видеата, като редактирате скрипта, и заменете една стъпка вместо да записвате наново |
За екипите по поддръжка AI runbook generator на Trupeer превръща записи на технически задачи в runbook-и, които можете да свържете от матрицата.
Genpact използва подхода „записване първо“ за внедряване на Workday в цялата компания, превръщайки записани сесии на процеси в повече от 500 обучителни материали в 20 работни направления на пет езика — за 140 000 служители в 40 държави, за 3 месеца вместо за 12. Прочетете customer story за Genpact.
Изтеглете безплатния шаблон за матрица на проследимостта на изискванията
Отворете шаблона в Trupeer, добавете вашите изисквания, свържете вашия FRD, елементи за изграждане, SOP-и, runbook-и и тестове и го споделете с вашия екип по проекта. Вземете безплатния шаблон за матрица на проследимостта на изискванията.
Свързани шаблони
Често задавани въпроси
Какво е шаблон за матрица на проследимостта на изискванията?
Това е структурирана таблица, която свързва всяко изискване с документите и работните елементи, които го доставят и проверяват, като например раздела от FRD, елемент за дизайн или изграждане, SOP или runbook, тестови случаи и обучение — със статус и отговорник.
Какво трябва да включва матрица на проследимостта на изискванията?
ID на изискването, описание, източник, приоритет, раздел от FRD, елемент за дизайн или изграждане, SOP или runbook, тестови случаи, статус на тестовете, съдържание за обучение, отговорник, статус и история на промените, плюс резюме на покритието.
Каква е разликата между проследимост напред и назад?
Проследимостта напред следва изискване през дизайн, изграждане, тест и документация. Проследимостта назад започва от тест, SOP или елемент за изграждане и го проследява обратно към изискването, което обслужва.
Защо да свързвате изискванията със SOP-и и runbook-и?
Защото тестването доказва, че системата работи в деня, в който е тествана, докато SOP-ите и runbook-ите доказват, че хората могат да я управляват след това. Като ги свържете, показвате кои процедури трябва да се актуализират, когато изискване се промени.
Кой притежава матрицата на проследимостта на изискванията?
Обикновено водещият бизнес анализатор или PMO, като отговорниците за изискванията поддържат редовете си актуални, а екипът по run поема отговорността при go-live.
Кога трябва да създадете матрица на проследимостта на изискванията?
В началото на проекта, докато изискванията се събират, и я актуализирайте на всяка контролна точка: дизайн, изграждане, тест и go-live.
Има ли шаблон за матрица на проследимостта на изискванията в Excel?
Да. Матрицата работи добре в Excel, с филтри за статус, отговорник и пропуски в покритието. Отворете шаблона в Trupeer, персонализирайте го и го експортирайте, или копирайте структурата в Excel.
Има ли шаблон за матрица на проследимостта на изискванията в Word или PDF?
Да. Използвайте Word или PDF за подписани резюмета на покритието на контролни точки и поддържайте работната матрица в електронна таблица или инструмент.
Безплатен ли е шаблонът за матрица на проследимостта на изискванията?
Да. Регистрирайте се безплатно, за да отворите шаблона в Trupeer, да го персонализирате и да го експортирате.
Как се използва RTM при ERP внедрявания?
Тя свързва изискванията fit-gap с функционалните спецификации, елементите за конфигурация и разработка, UAT скриптовете, SOP-ите, runbook-ите и обучението, така че програмата да може да докаже покритие и да управлява промените.
Как поддържате матрица на проследимостта актуална?
Назначете един човек за отговорник, актуализирайте я като част от всяка заявка за промяна, преглеждайте покритието на всяка контролна точка и поддържайте свързаните SOP-и и runbook-и с версии.
Може ли матрица на проследимостта да подкрепя одити?
Да. За контролни изисквания тя показва дизайна, доказателствата от теста и оперативната процедура — това, което одиторите обикновено искат да видят.
