‘Shall’ Counting
“Count the shalls!” This was one of the strangest introductions to Requirements Management that I’ve heard. Firstly as a young engineer I didn’t know what a ‘shall‘ was, let alone why I should count it. For those of you reading this thinking “… no Idea what he’s on about..” let me explain. A crude method of working out the size of a project requirement was to count the number of paragraphs containing the word ‘shall‘. This gave the number of mandatory contractual statements that must be met for the project. Paragraphs containing ‘should‘ or ‘may‘ could be ignored as they were ‘nice to haves‘ rather than obligations.
Limitations
There is some logic to the approach, if the statements have been written atomically. However, as a provider one should never presume the customer has written the requirements to the right level for ‘shall counting‘. For example these two customers’s requirement sets are wildly different.
- The vehicle shall carry a load of 500Kg
- The vehicle shall pass legal requirements for use on UK roads.
and
- The pipe insulation shall be provided in 1m lengths
- Insulation shall be installable with standard DIY tools such as a craft knife and tie-wraps, and not require specialist equipment.
- The insulation shall achieve a thermal conductivity of 0.033W/mK or lower
- The insulation shall pass BS EN11925-2 BL
- No component material shall be classed as hazardous to health under COSHH regulations 2002
- The wholesale price point shall be 20p / m or lower
On a ‘shall‘ count the first project seems easiest just two requirements. But seriously! would you accept a customer level requirement like this, and price up the work and expect a happy customer?
Have a Ford Transit, job done.
Then you find the customer wants to crane the load on. Secondly you find they need a tailgate lift to unload it. Additionally you find the product needs weather protection during transit and so on.
The second project has SMART requirements
S pecific
M easurable
A ttainable
R ealisable
T raceable
Count the shalls here, and the measure may be a little more meaningful.
Shoulds and Mays
Can you afford to ignore ‘shoulds‘ and ‘mays‘ ? Contractually you could argue they don’t matter, but in forming a meaningful customer relationship, they are still important. “The insulation should be a mute colour” could contractually be met with vivid red foam, but you’re unlikely to get repeat business.
When the customer has an idea of the implementation (OK, requirements purists, don’t have a coronary) then they are guiding you as to the options they see as most appropriate. “The vehicle shall have a mechanism to remove the load at a customer site” could be met with a separate fork lift truck being supplied. However “The vehicle may have a powered tailgate lift, or a body mounted mini crane” suggests the customer is seeing these as preferred solutions. In costing a bid these should certainly be considered. However, if your vehicles come with built in vehicle body to floor conveyors, this could still be a viable solution for the customer. After discussion your system requirement, linked to your customer requirement may become “The vehicle shall be fitted with a 800Kg NWL body/floor conveyor ” Of course this requirement would also have extra data within or linked to it minuting the discussion with the customer where they agreed this would meet their requirement.
Solutions
There are definitely merits for someone or something to ‘count the shalls’. If you have 1678 requirements in your project and 1698 ‘shalls‘ you obviously have some non atomic requirements. Running a Conformance Checker can validate the semantics, across your whole requirement set. What automated tools can’t do is look at the logic and complexity of the requirement. In these cases breaking your customer requirement into a number of domain specific system requirements ensures the level of the requirements against which you bid, design and build are truly SMART. Whilst unsurprisingly we advocate the use of a tool to manage your requirements, to link the User Requirements to the derived or system requirements, we don’t claim a tool will solve the problem of poor specification; For that you need good, competent engineers, whose job is made easier by using the correct tools.
