Challenges with Requirements Management
An expectation on some object
A requirement is a statement expressing a property on some object.
A requirement is a phrase like “Total vehicle mass is less than 1000kg” or “Controller repairability is high” or “Machine can drill 20mm diameter holes in concrete”.
Requirement Management is all about links
Requirements are given by customers, laws, norms, or business goals. So one needs to drive and monitor their impact on deliveries.
Only when we control the links from requirements to deliveries can we stand clear on our feet and assert “Job done!“.
It's all about links
The challenge with requirements management is to stay aware of every connection to deliverables:
- Where is it dealt with?
- Have we considered all of them?
- What if a requirement changes?
- Are they compatible to one another?
- What if we have deliverables not connected with a requirement?
Requirements are naturally ambiguous
Removing ambiguity is best when done early
“Machine can drill 20mm diameter holes in concrete” is ambiguous: through which concrete? how fast? Is drilling 10 mm deep in 10 minutes acceptable?
As early as possible, requirements must be thoroughly clarified with customer to remove any possible ambiguity. If ambiguity is resolved later on, it could constitute an expensive change event on requirements.
Bridging customer's world with ours
Customer requirements are spelled out using their domain references. On the other hand, deliveries are built using another set of domain references.
For instance, is customer is asking for “bright red“, we may translate into “Pantone18-1664 Fiery Red“.
Flowing down requirements
Refine requirements until actionable and verifiable
After ambiguities are settled (for now!), requirements are turned into more and more specific statements.
Iterations stop when requirements are granular enough to be:
- a complete specification for a delivery characteristic,
- verifiable by test, inspection or analysis.
Maintain a network of refinements
Successive requirements form a network flowing customer requirements into deliverable items. Such network is the central tool for demonstrating traceability. And it’s also central to answer questions such as “have all requirements been considered?”, “do we have stuff that is not linked to any requirement?”.
Flowing up satisfaction
Resolve requirements
Someone has to decide when a requirement is resolved. Typically, proof of resolution would be contained in a document. This could be an affirmation from a designer, or the result of a test, or a statement that requirement is abandoned.
Evaluate overall satisfaction
If initial requirements are refined from the top down, satisfaction is computed from the bottom up. Fine-grain requirements are asserted as satisfied or not. Then satisfaction is aggregated as a percentage measure all the way up to the initial requirements.
See it in action with Qinaps
Connect requirements to deliveries
After a customer Request for Proposal has been uploaded into Qinaps, requirements are highlighted inside the original text.
Individual text blocks are created for each requirement.
A response document is created with so-called “delivery blocks”.
Delivery and Requirement Blocks are connected through logical dependencies.
Build automated summaries
Qinaps knows how to combine logical dependencies between Requirement Blocks and Delivery Blocks.
The same Blocks can be shown in many different representations and layout with Qinaps.
There is no need to juggle with another spreadsheet or database. Everything is here at your finger tips. Always up to date.