A useful way through
- List the actual products or variants and the user tasks they serve. Identify a shared capability only when the team has evidence for it. Similar names or screens do not prove that two products share a maintainable implementation.
- Make a feature matrix with one row per capability and one column per supported variant. Mark required, optional, excluded and unknown separately. Add constraints in plain language, especially where choosing one option changes another part of the product.
- Connect each supported configuration to its owner, version and acceptance examples. Include a negative or unsupported combination so the boundary is visible. Ask the engineering team to review the model before presenting it as a production architecture or a promise of lower development cost.
- Use changes to the matrix to identify documentation and test work. Keep observed test results separate from planned coverage. A reused component needs verification in its actual configurations; the diagram is a planning record, not proof that the software works.
Read the map as text
THE WORKING DETAIL · FEATURE · BASIC · TEAM · Export · YES · YES · Shared review · NO · YES · Test each supported path. · A planned case is not a passed case.
- Shared capability
- Variable feature
- Constraint
- Evidence
Put it into practice
In a fictional publishing tool, both Basic and Team variants export a document, while only Team offers shared review. The matrix excludes shared review from Basic and names an acceptance case for each supported export path. If a team adds a new export format, it reviews both variants instead of assuming shared code has already proved them correct.
Illustrative example, not a reported client project or test.
Your take-away checklist
Map a small software family with a feature and test matrix
- □ Shared capability: ____________________
- □ Variable feature: ____________________
- □ Constraint: ____________________
- □ Evidence: ____________________
Before you act
The example is conceptual and does not describe a tested software product or quantify savings from reuse.
A worked record
Use the example to see the decisions, then download a blank record for your own task.
- Shared capability
- Document exportTwo supported variants
- Variable feature
- Shared reviewTeam only
- Constraint
- No review in BasicExplicitly excluded
- Evidence
- Named cases and resultsPlanned is not passed
A compact test record
Write configuration, initial state, action, expected result, actual result and version. A checklist of feature names is not a test record. Record a failure and its owner explicitly; do not mark a whole family accepted because one variant opened successfully.
Know when the matrix is too simple
When combinations multiply or technical constraints become difficult to express, involve the product and engineering owners in a more formal model. This small example helps reveal the problem; it does not replace architecture, security or release validation.
Sources & context
The earlier topic was published 2021-08-25 under the Maria Baldwin byline. The present procedure, examples and diagrams are new work by MichaelT editorial; they do not attribute a new test or professional assessment to the earlier author.