An effective structure for product development has (at least) two dimensions: product structure and traceability structure..
- We tend to organize information in a tree structure. When we were still working with documents, this structure was reflected in the headings. But as we move to fine-grained traceability we have another hierarchy. It is important to not mix the two and to understand their purpose.
Use the pattern when you set up your project. Configure your tool to follow these structures.
For example, consider a simple system description with a decomposition into subsystems and tests. Your product structure could look as follows:
But note that this structure is orthogonal to the traceability structure:
Note that this may seem "obvious" for experts who have worked with professional requirements tools before. But users coming from documents in particular tend to mirror their traceability structure in the project structure. This leads to confusion and a duplication of work.
The pattern has the following benefits and liabilities:
- Separation of concern: Structuring the project from documenting dependencies.
- This can be confusing for people using a document-based approach.
Tool support is indispensable for this approach. Ideally, both structures (project and relationship) are part of a centrally administered framework that cannot be changed by the team members working in a project.
Jama Connect allows the definition of frameworks in the backend that contain these structures, which can then be applied in a project.