Requirement analysis and review
Review requirements for consistency, feasibility and verifiability, and resolve open or conflicting statements with the people who own them.
Focus topic
Requirements Engineering & Traceability
Make sure everyone builds and tests the same thing, and that every requirement can be followed to the design that implements it and the test that proves it.
Requirements work pays off when hardware, software and test teams read a requirement the same way. The scope can be the review of an existing set, the decomposition of system requirements, or building traceability for a release review.
Each definition level has a matching verification level
Traceability connects the left and right side at every level, so a change or a gap can be followed in both directions.
- Definition: Product and stakeholder needsVerification: Validation in use
- Definition: System requirementsVerification: System test
- Definition: Architecture and interfacesVerification: Integration test
- Definition: Hardware and software requirementsVerification: Component test
- Definition: ImplementationVerification: Unit test and review
What the work covers
The agreed assignment determines which activities are included and where the responsibility boundary sits.
Decomposition to hardware and software
Derive hardware and software requirements from system requirements where applicable, with the allocation and assumptions made explicit.
Interface definition
Define the interfaces between allocated elements so each team knows what it must provide and what it can rely on.
Traceability to implementation and test
Link requirements to design elements and tests, and report the gaps where a link or a result is missing.
Change-impact analysis
Assess which requirements, design elements and tests are affected by a change, and keep agreed baselines and decision records.
Typical starting points
Hardware, software and test teams interpret the same requirement differently.
A release review asks which requirements are covered by tests and no one can answer quickly.
A late change arrives and its effect on design and verification is unknown.
Example engineering outputs
Outputs are assignment-dependent and agreed for each engagement.
Reviewed requirement sets and clarification decisions.
Decomposed hardware and software requirements with allocations.
Traceability structures and gap reports.
Change-impact findings and maintained baselines.
Common questions
Which requirements tool do you use?
The requirements environment is set by the project, so results stay in the customer's own baseline. Fit for a specific tool is confirmed during technical scoping.
Can traceability be added to an existing project?
Yes. Traceability can be built up for an existing baseline, usually starting with the requirements and tests that matter for the next review or release.
Do you use model-based methods?
Model-based systems engineering, including SysML or UML-related modelling, is used where it is appropriate to the product and the customer's way of working.
Part of
Systems & Requirements Engineering
Requirements, architecture, functional allocation and interfaces, with traceability and controlled technical change.
Discuss a requirement set, traceability gap or change-impact question.
Describe the current state, the interfaces involved and the result you need. Leave confidential technical files out of the first message.