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”.
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!“.
The challenge with requirements management is to stay aware of every connection to deliverables:
“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.
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“.
After ambiguities are settled (for now!), requirements are turned into more and more specific statements.
Iterations stop when requirements are granular enough to be:
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?”.
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.
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.
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.
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.
Just sign up into Qinaps. Create a free account and try Enterprise Features, including Requirements Management, for 30 days. No questions asked. No credit card required.
Your contact details will not be shared with anyone (see our privacy policy). We’ll send you an e-mail to confirm your registration. Please check your spam folder. If you don’t receive any email within the next couple of hours, please get in touch with us.
Time permitting, we’d be glad to host a 45 minute pesonal demo for Qinaps features on Requirements Management. Please use our calendar on this page to select a time slot. Or use this link.
We found the International Requirements Engineering Board website to be particularly insightful. There are lots of learning, training and self-evaluation resources over there. Enjoy reading!
