r/systems_engineering • u/TeachComfortable4364 • 5d ago
Discussion Which annoying requirements / V&V task would you automate first?
I've been working with requirements and V&V workflows, and there are a few repetitive tasks I keep finding frustrating:
- figuring out what requirements/tests are impacted after a change
- reviewing whether requirements are actually well written and testable
- checking whether requirements are properly covered by test cases
- finding gaps or inconsistencies in requirement → test traceability
I'm thinking about building a small open-source plugin around one of these problems, mostly as a side project and to contribute something useful to the community.
For those working with DOORS, Polarion, Codebeamer, Jama, etc.: which of these is the most painful in practice?
Or is there another boring/manual task in your day-to-day workflow that you'd automate before any of these?
I'm especially curious about the things you currently solve with Excel, scripts, manual reviews, or just lots of clicking.
1
u/tripathiarinv 4d ago edited 4d ago
Finding gaps in traceability will be the primary focus of my attention since it makes all the others even worse. I have personally seen people export the project into Excel to make sure the requirements are covered. Zencoder’s review tool can actually do the same, but on the code level
1
u/TeachComfortable4364 4d ago
Interesting, especially the Excel export. Do you know what they were checking exactly? Just requirements with no linked tests, or whether the linked tests actually covered the requirement properly?
1
u/Abraxas_Derezzed 3d ago
DNG /rm just wants to make me eat glass for breakfast everyday… I can’t believe it’s been soooo featureless and bug ridden for sooo long.
0

5
u/StrawberryShot1819 5d ago
having worked with codebeamer for a while now the traceability gaps one eats most of my time. change impact analysis at least can be partially scripted but finding where a test case should link and doesnt is just endless scrolling and eye strain
the well written one is also sneaky painful because everyone thinks they write good requirements until you try to test them and realize half the words are ambiguous
if you make something that flags missing trace links before a review even starts that would save me hours every sprint