Translate need into verifiable intent
Stakeholder language must become requirements that are necessary, unambiguous, feasible and verifiable. Derived requirements and assumptions need the same ownership as requested features.
- Separate needs, requirements and design decisions.
- Define measures, tolerances and operating conditions.
- Trace every requirement to its source and owner.
- Identify conflicts before detailed design.
Architect functions and interfaces
Architecture allocates behaviour to mechanical, electrical, embedded, software and operational elements. Interfaces must include physical, energy, signal, data, timing and responsibility boundaries.
- Maintain functional and physical views.
- Define coordinate systems, units and timing.
- Assign ownership on both sides of an interface.
- Review interactions and emergent behaviour.
Plan verification and validation with the design
Verification method, evidence and acceptance criteria should be defined while requirements are being written—not after implementation is complete.
- Select analysis, inspection, demonstration or test.
- Connect each verification activity to a requirement.
- Define test articles, environments and configuration.
- Distinguish building the system right from building the right system.
Make change impact visible
A product configuration includes requirements, models, drawings, software, calibration and test evidence. Change control should expose downstream impact before release.
- Baseline connected product information.
- Assess interface and verification impact.
- Record concessions, deviations and residual risk.
- Release a coherent evidence set, not isolated files.
Apply the method to the decision—not as a checklist.
The appropriate evidence depends on intended use, technical risk, operating environment, contractual obligations and the authority responsible for acceptance. This guide is educational and does not replace project-specific analysis, applicable standards or independent review.