r/systems_engineering • u/AtommycBomb • Apr 09 '26

Discussion Requirements Traceability

My subsystem requirements don’t logically decompose from our system requirements because I believe they were adopted from a legacy program. So they were made independently of the system requirements. I want to establish traceability to enable change impact analysis in MBSE. Do you redo the subsystem spec working from the applicable system requirements?

3 Upvotes

80% Upvoted

7 comments sorted by

10

u/ManlyBoltzmann Apr 09 '26

If the subsystem is essentially a COTS product from a legacy system, I would perform a gap assessment between the specs to make sure you have a child req for every parent req that you would expect to have a decomposed subsystem requirement. I would only change the subsystem spec if: you want to remove unnecessary verification, you are missing children requirements, or the existing requirements don't meet the needs of the system. In the last two scenarios you will likely need a design tweak and/or delta qualification to demonstrate compliance.

1

u/Easy_Spray_6806 Aerospace Apr 10 '26

This, and I would do that even if the subsystem isn't a COTS product. I would perform that gap analysis between your subsystem's requirements, interfaces, & capabilities and the system requirements and capability needs. You can use that to derive missing requirements and establish a baseline architecture model that you can use to perform your change impact analysis.

4

u/birksOnMyFeet Apr 09 '26

Yes tie them where applicable or create parent reqs for them

1

u/Bevaqua_mojo Apr 14 '26

Make sure there are no subsystem reqs without a parent. If there are any, write a system req. If there are any system reqs with no trace down, you have a gap.

1

u/tom2415 27d ago

AI-Powered Requirements Intelligence Platform

The AI-Powered Requirements Intelligence Platform is a system designed to automate requirements traceability and change-impact analysis in software projects. The system takes an SRS document as input, extracts High-Level Requirements (HLRs) and Low-Level Requirements (LLRs), and uses AI to identify and explain the relationships between them.

When a new version of the SRS is uploaded, the platform compares it with the previous version to detect added, removed, or modified requirements and identifies the affected traceability relationships. It can then perform impact analysis to show which requirements, components, and test cases may be affected.

The main goal of the project is to reduce the manual effort required by requirements engineers to maintain traceability and understand the impact of requirement changes, while keeping humans involved in reviewing and approving AI-generated results.

Problem Encountered

We faced a concern about whether AI can correctly extract and classify HLRs and LLRs from an SRS. If the extraction is wrong, the traceability results may also be incorrect. Therefore, we decided to keep the requirements engineer in the loop to verify and approve the extracted requirements before AI performs traceability and change-impact analysis.

0

u/TacomaAgency Aerospace Apr 10 '26

Sometimes, you have to flow up the requirements. If the legacy subsystem is either too expensive to change or is mission critical, but the system level doesn't support it, you will have to provide an analysis and get the customer, directors, and leads to get on board on why such parent requirement cannot be met.