Requirements Traceability Matrix (RTM)¶
0. Document Control And Relationship Rules¶
| Item | Baseline |
|---|---|
| Document ID / type | SPEC-RTM / Requirements Traceability Matrix |
| Trace direction | bidirectional, from a requirement to the design, implementation and verification, and from a deliverable to a requirement |
| Identification | the existing REQ, BR, AC, UI, DATA, IF, SEQ, TC and EVD IDs and their revisions are kept |
| State | authoring, implementation, verification, user acceptance and release are separated |
| Missing | an empty cell is not treated as complete, and the reason for being unwritten, TBD or N/A is shown |
| Baseline | the revision and the valid scope of the source, the document and the execution evidence are recorded |
A template candidate requirement or a fictitious evidence is not brought in as a traceability row. A relationship is linked only when the real original, implementation and verification locations are confirmed.
1. Purpose And Traceability Level¶
It links the system and area requirements of SRS to the design, data, interfaces, behaviour, screens, implementation, tests and evidence. This document is not the Booking RTM with a different name. What follows is the upper traceability frame between the whole-system requirements and the specification volumes, and the detailed command, field and test mapping is only partially written.
2. System Common Requirement Traceability¶
| Requirement | Design, data and behaviour | Screen and test | Remaining detail traceability |
|---|---|---|---|
| SYS-C01 authentication, tenant and authority | SAD, Interfaces | Screens, Tests | the real per-area role, command and isolation cases |
| SYS-C02 UUID and the compatibility boundary | Data, Interfaces | Tests | the whole public contract and the physical mapping |
| SYS-C03 independent work facts and state | SDD, State | Screens, Tests | the per-area state and follow-up impact |
| SYS-C04 duplicate, conflict and unknown recovery | SDD, Sequence | Tests | the per-command recovery and the real result |
| SYS-C05 Client basis and the common owner | SAD, SDD | Screens, Tests | C1 Legacy/C2 reference the difference comparison |
3. Per-Area Traceability Contents¶
Every row links the same area through SRS area → SAD responsibility → SDD processing → Data, Interfaces, Sequence And State and Screens → Tests. A cell without an existing detail below is not filled in as an implementation or test completion.
| Requirement and area | Detail design, data, interface and screen linkage | Implementation and test traceability state | |
| --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| SYS-F01 administration, access and settings | the administration volume of each volume | TST-01, the detailed mapping is unwritten |
| SYS-F02 master data | the master data volume of each volume | TST-02, the detailed mapping is unwritten |
| SYS-F03 trade | the trade volume of each volume | TST-03, the detailed mapping is unwritten |
| SYS-F04 inbound and outbound | Receipt detail and the system inbound and outbound volume | TST-04, the RCP evidence is partial and the full mapping is incomplete |
| SYS-F05 field work and Transload | the TRN-* detail of the 9 volumes compared with the Operations source | TST-05 the detail cases are written; the real acceptance is NOT_RUN |
| SYS-F06 weighing | the SCL-* detail of the 9 volumes and the Receipt and Scale boundary | TST-06 the detail cases are written; the real device, role and DB acceptance is NOT_RUN |
| SYS-F07 inventory and warehouse | the INV-* detail of the 9 volumes and the Receipt detail | TST-07 and RCP are linked; the real full C2 acceptance is NOT_RUN |
| SYS-F08 transport and Booking | Requirements·Design·Data·API·Screens | TST-08, the existing BKG traceability and acceptance, the rest of transportation is unwritten |
| SYS-F09 equipment and yard | the equipment volume of each volume | TST-09, the detailed mapping is unwritten |
| SYS-F10 documents and output | the Booking output detail and the system document volume | TST-10, the full mapping is incomplete |
| SYS-F11 billing and settlement | the settlement volume of each volume | TST-11, the detailed mapping is unwritten |
3.1 Current Source, Design And Test Linkage¶
| Requirement group | Source-reconciled owner | Design, data and interface | Screen and test | Current traceability state |
|---|---|---|---|---|
| SYS-F01 | Platform/Tenant/Role source reconciliation | the SAD access chain and the DATA platform tables | the administration screens and TST-01 | partially written — the typed context and the complete action and audit are incomplete |
| SYS-F02 | Master Data source reconciliation | the master-data contract and the DATA company, commodity, UOM and location | the master compatibility pages and TST-02 | partially written — UOM, location and the generic owner are unresolved |
| SYS-F03 | Commercial source reconciliation | the commercial public→Web→DB path and the order and item records | the agreement list and detail and TST-03 | partially written — the real status and correction policy is unresolved |
| SYS-F04 | Commercial/Service intake + fulfillment contract | the fulfillment command and source bridge and T_LOAD and the items |
the Inbound and Outbound editor and TST-04 | partially written — the Service Request and appointment slot detail is unresolved |
| SYS-F05 | Operations/Transload reconciliation | the transload public, route and writers and the transload, planner and time records | planning, Loader and timeline and TST-05 | partially written — the assignment canonical and the Undo scope are unresolved |
| SYS-F06 | Scale reconciliation | the scale public→tradeData→DB evidence and the ticket and event | the Scale workspace and TST-06 | partially written — the real acceptance of precision, correction and device is incomplete |
| SYS-F07 | Receipt/Lot/Placement + Allocation reconciliation | the inventory command and writers and the lot, location and allocation records | lot, receipt and allocation and TST-07 | partially written — quantity, weight, reverse and reopen and the real C2 acceptance are incomplete |
| SYS-F08 | Booking + Transportation reconciliation | the existing Booking SRS, SDD, DATA and API and the transport candidates | Booking, dispatch and external carrier and TST-08 | partially written — Booking is the most detailed, and Shipment, Leg and cardinality are unresolved |
| SYS-F09 | Yard/Equipment reconciliation | the equipment and yard records and the target commands | the Yard and container screens and TST-09 | partially written — the lifecycle, the partial recovery and the real movement acceptance are incomplete |
| SYS-F10 | Documents module | the renderer and source projection and the file and provider separation | preview and output and TST-10 | partially written — only the render contract is confirmed, and issuance and provider are incomplete |
| SYS-F11 | Settlement module | the source-line projection and the independent financial boundaries | the settlement read screens and TST-11 | partially written — margin, landed cost, posting and payment are not approved |
partially written is the traceability completeness of this document, not a Product Reality state or a Task state. An unresolved item in each row is linked to the existing ID and evidence of the relevant source owner, and the document does not decide a policy on its own.
A source comparison document is read with the revision and the review scope recorded in its original. The detail ID links below go to the original of the relevant specification, and a test ID is linked to a test case. A real execution result is checked with its revision and environment in the original Task evidence.
3.2 Per-Area Application Check Of The Common Requirements¶
| Area | SYS-C01 access | SYS-C02 UUID | SYS-C03 independent state | SYS-C04 recovery | SYS-C05 Client basis |
|---|---|---|---|---|---|
| Administration and settings | the actor, subject, tenant and action | the global and local identity | the current, proposed and applied setting | the revision and read-back | a common foundation with a compatibility difference |
| Master data | the tenant reference scope | the Party and Material UUID | the live reference and snapshot | a duplicate and reference conflict | C1 Legacy and C2 reference |
| Commercial and Fulfillment | the counterparty and source authority | the order, line and source UUID | the agreement, execution and receipt | a duplicate number, a version and unknown | centred on the C2 reference, with the C1 source separate |
| Operations and Scale | the actor, job and record scope | the work and ticket UUID | the plan, start, complete, Office and consumer | the commit, provider, Undo and unknown | the detailed C1 internal and the C2 policy difference |
| Inventory | the lot, location and target scope | the lot, placement and allocation UUID | the identity, balance, placement and allocation | an overdraw, replay and reversal | the custody and owned-stock policy difference |
| Transportation and Equipment | the Booking, leg, Yard and return action | the booking, delivery and equipment UUID | the transport, Yard, equipment and return | a partial command and read-back | the C1 internal and C2 external carrier difference |
| Documents and Settlement | the source authority | the source, document and settlement UUID | the preview, issue, send, post and pay | the provider and reconcile | the per-Client form and settlement policy |
3.3 SYS-F05 Transload Detail Traceability¶
The current entry point of the implementation owner is packages/modules/operations/src/transload.ts, apps/web/src/transport/semanticTransloadRoutes.ts, packages/db-mysql/src/transload-*.ts and apps/web/src/composition/pages/transload/. These rows mean the source mapping is complete, not the real role screen, DB and provider acceptance or the assignment canonical decision.
3.4 SYS-F06 Scale Detail Traceability¶
The current implementation entry point is packages/modules/scale/src/public.ts, apps/web/src/transport/semanticTradeRoutes.ts::scaleTicketsRoute, packages/db-mysql/src/trade/scale-{read,write,evidence}.ts and apps/web/src/composition/pages/trade/TradeReadExperiences.tsx::ScaleExperience. A source mapping and a simulated evidence check are not the real device, role, MySQL or downstream acceptance.
3.5 SYS-F07 Inventory Detail Traceability¶
| Requirement | SAD and SDD | DATA, IF and STATE | Screen and implementation owner | Test and current verdict |
|---|---|---|---|---|
| SYS-F07-R01,R05 | INV-ARC-01,02, INV-SDD-01 | INV-DATA-01~03, INV-IF-02, INV-STATE-01 | INV-UI-02; Inventory command/writer | INV-TC-01 · NOT_RUN |
| SYS-F07-R02,R07 | INV-ARC-02,05, INV-SDD-02,07 | INV-DATA-01~04,07, INV-IF-01, INV-STATE-02,05 | INV-UI-01,02; Lot/Ledger/Placement | INV-TC-02,03,10 · NOT_RUN |
| SYS-F07-R03,R08 | INV-ARC-03, INV-SDD-04 | INV-DATA-05,06, INV-IF-04,05, INV-STATE-03 | INV-UI-04; Allocation owner | INV-TC-04,05 · NOT_RUN |
| SYS-F07-R04,R09 | INV-ARC-04, INV-SDD-03,05~07 | INV-DATA-03~06, INV-IF-03,06,07, INV-STATE-04,06, INV-SEQ-01 | INV-UI-01,03~05; exact owner readback | INV-TC-05~09 · NOT_RUN |
| SYS-F07-R06 | INV-ARC-02, INV-SDD-01,02 | INV-DATA-01,03,04, INV-IF-02, INV-STATE-01,02 | INV-UI-02; Receipt/Placement owners | INV-TC-02 · NOT_RUN |
| SYS-F07-R10 | INV-ARC-05, INV-SDD-07,08 | INV-DATA-01,02,07, INV-IF-08, INV-STATE-05 | INV-UI-01,06; client policy/consumer owners | INV-TC-09,10 · NOT_RUN |
The current implementation entry point is packages/modules/inventory/src/{commands,public}.ts, apps/web/src/transport/semanticTradeRoutes.ts, packages/db-mysql/src/trade/inventory-*.ts and apps/web/src/composition/pages/trade/{FulfillmentOrderExperience,InventoryExperience,InventoryLoadingDialog}.tsx. The detail RCP evidence and the current system rows are linked, but the real C2 DB, role and follow-up document acceptance is separate.
4. Authoring Items Of A Detail RTM Row¶
One row is written in this order: the requirement or rule ID → the design section → the data field and relationship → the API, command, query and event ID → the sequence and state transition → the screen and action → the real implementation owner → the test ID → the real evidence, revision and environment → the difference and unresolved item. A column that does not apply is given a reason. The existing catalog, BKG-R, SCN and RCP identifiers are preserved and are not replaced with a new system contents ID.
5. Change And Freshness¶
When a requirement or a source changes, the effect on the design, data, API, screen and test of that row is checked. The freshness of the generated content is confirmed with a Markdown hash or a generation check, but the freshness of a work fact needs a real source comparison. No automatic source impact analysis and no new registry is added.
Completing the document system and completing the detail traceability of every area are separate. The current step defines the 9 system documents and the per-area extension points and links the existing detail. The follow-up work fills the unwritten area volumes from the source basis, and it is not a repetition of the Booking functional tests.
In this expansion, the confirmed current contracts of the existing source-reconciled documents and the module READMEs are linked to the system rows. The next detail work is not a matter of priority but a matter of filling the unwritten cells of each volume with the same requirement ID. Even when one area is chosen, the SRS→SAD/SDD→DATA/INTERFACE/BEHAVIOR→SCREEN→TEST→RTM linkage is updated together.
6. Detail Traceability Row And Reverse Traceability Card¶
| Column | Authoring criteria |
|---|---|
| Requirement basis | REQ ID@revision, the original text, source, state and the Client and context |
| Acceptance and rule | AC and BR with the normal and forbidden result |
| Design | the SAD, ADR and SDD section and the module, component and transaction owner |
| Data, linkage and behaviour | the DATA field and relation, the IF operation, and the sequence and state transition |
| Screen and implementation | the UI, POP and route and the source revision and symbol |
| Verification | TC@revision and the required environment, role, dataset and method |
| Execution and evidence | RUN and EVD and the real result, time, scope and validity |
| Defect, change and verdict | DEF, CR and waiver, the impact and re-verification, and the acceptance and release state |
The reverse traceability checks which requirement and approval an implementation symbol, schema field, route, screen, test and evidence is based on. An orphan deliverable, a broken link and a combination of different revisions are recorded as a change impact.
7. Coverage, Review And Change Control¶
The coverage states the valid baseline and the denominator of the applicable targets, and does not inflate the number by excluding N/A, BLOCKED and NOT_RUN. When a requirement changes, all the relationships and the validity of the previous executions are re-evaluated, and a deleted or merged ID leaves a replacement relationship. The final review checks the forward and reverse trace, the required context combinations, the unresolved items, risks and waivers, and the separation of user acceptance and release.¶
Source:
new-system/docs/specifications/RTM.md— ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged. A user instruction quoted inside the text is kept in its original language.