It looks like you are looking for the V-Model development process used in the industry (e.g. automotive).
A typical requirement in this model is handled like this:
1. the high level specification define what is the change about (e.g. implement a hillholder function).
2. architecture phase: you identify which part/module of the system are impacted by the high level requirement. You define what each part will do and you specify how they interface.
3. detailed design phase: each part is formally specified, in the automotive industry we typically use Model based development (Simulink) to specify this phase.
4. implementation: actual coding being done, if you use Simulink this is done by the Simulink/dSpace. A unit test is then performed to check that the detailed design from part 3 has been correctly done.
5. Integration and test: all parts are collected and compiled, and we look that the interfaces are matching.
6. System test: all parts are now tested together against the specifications done in the architecture phase (part 2) and part 1
In the automotive industry, each step can be done by a different person/team/company thus the documentation done in each phase is extremely important to avoid finger pointing in case a problem is detected after delivery.
Ah okay. So PLM systems would be used to store and manage the requirements, the requirement documents are going to be, at least in my corner of the world... Word and/or Excel templates.
Which is only narrow subset of what PLM system does. PLM is generally about tracking what data artifacts (drawings, manufacturer datasheets and so, formal specifications are somewhat secondary to that) are relevant for given assembly and how such subassemblies fit together on high level.
Yes, that's much more of what I am aware of in the context of PLM. As I wrote in a sibling comment, I'm interested in improving the storage and representation of the requirements/spec itself...
Right, and this is actually exactly the area that I am interesting in improving: providing a canonical, systematic way to store and represent the actual requirements & specifications, and provide ways to feed into other software such as PLM or project management, etc.
A typical requirement in this model is handled like this: 1. the high level specification define what is the change about (e.g. implement a hillholder function). 2. architecture phase: you identify which part/module of the system are impacted by the high level requirement. You define what each part will do and you specify how they interface. 3. detailed design phase: each part is formally specified, in the automotive industry we typically use Model based development (Simulink) to specify this phase. 4. implementation: actual coding being done, if you use Simulink this is done by the Simulink/dSpace. A unit test is then performed to check that the detailed design from part 3 has been correctly done. 5. Integration and test: all parts are collected and compiled, and we look that the interfaces are matching. 6. System test: all parts are now tested together against the specifications done in the architecture phase (part 2) and part 1
In the automotive industry, each step can be done by a different person/team/company thus the documentation done in each phase is extremely important to avoid finger pointing in case a problem is detected after delivery.