Category: Articles

‘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.

1. The vehicle shall carry a load of 500Kg
2. The vehicle shall pass legal requirements for use on UK roads.

and

1. The pipe insulation shall be provided in 1m lengths
2. Insulation shall be installable with standard DIY tools such as a craft knife and tie-wraps, and not require specialist equipment.
3. The insulation shall achieve a thermal conductivity of  0.033W/mK or lower
4. The insulation shall pass BS EN11925-2 BL
5. No component material shall be classed as hazardous to health under COSHH regulations 2002
6. 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.

Building your Dream

In the words of Phineas T. Barnum starting with the smallest blocks you can build it “….one brick at a time…”^[1] and then you should be able to achieve anything you can dream of.

Consider your ‘dream’ as the top level requirement, this is your ultimate goal. The problem is you’re not sure what constitutes a ‘brick’. Unless it’s a wall you’re building the smallest parts are unlikely to be equal. If only all world engineering problems could be solved with LEGO®! The aim, however is still the same, take the goal and break it down to atomic parts that we can quantify, specify and build. Together those elements will form the whole.

Breakdown Structure

Hierarchies are an important way to describe, link and visualise the ‘dream’ you’re building. The bottom of the hierarchy should be as close to the ‘brick’ as possible. A self contained, unit, the ‘atom’ within your project.

People

Most people are familiar with a company structure from the MD to the process workers via managers and team leaders workers. Imagine a company where every worker tried to talk to the main boss, as soon as there are more than a handful of employees, this would become unmanageable. Conversely consider too many layers of middle management, all pulling in slightly different directions, then the workers end up without clear direction. It’s a balancing act.

Requirement Breakdown

Your ‘dream’ may be to reach for the stars, or it may be to install the machinery to make spaghetti. In both cases you have an end goal, the main top level requirement. In each case these problems can be broken down into smaller problems, launch, travel and land, or ingredients, process and pack.

These in turn may break down into mechanical, electrical and software problems. The decision as to where to break will depend on the industry you are in, the number of issues that need to be tackled and the logical breakdown of the components. In this comparison, the launch may be considered completely different to the travel or landing requirements. However, in the factory system, it may be more prudent to devolve the level directly into the mechanical and electrical areas as there may be no significant difference between process and packing. Falling out the bottom the atomic ‘bricks’  may now be motors, control sensors, and pipes.

Realistically a more complex project can consider in parallel with the ‘dream’ or ‘User Requirements’, that there are the ‘System Requirements‘ which possibly lead to ‘Derived Requirements‘. These in turn  link to the ‘System Breakdown Structure‘ (SBS) and  ‘Product Breakdown Structure’ (PBS) .

Work Breakdown

When the problem has been broken down into the smallest conceptual parts the order that these must be assembled can also be broken into a hierarchy. The mechanical systems must be installed before they can be wired, the control systems may be developed in parallel, but they can’t be integration tested until the sensors are installed. A work breakdown structure (WBS) is a plan to ensure that the right bricks are in place at the right time to support the next layer of the structure.

Dependencies

There will be a complex relationship between each of the hierarchies in your project. If your team of electrical engineers are required to complete two different parts of the WBS they can’t be completed in parallel. This is where plan schedules are useful. Microsoft® Project is one way to achieve a schedule using Gantt Charts to illustrate the sequencing. The links between which System Requirement links to an item in the SBS or which Derived Requirement links to a PBS item must also be maintained.

Tools

Therefore, to manage a  big problem it needs to be broken down into smaller atomic ‘bricks’. But the interrelationship of those components is complex and needs to be managed.  Cradle allows all these components to be managed, linked, visualised and reported.  From whatever your original concept, to the final brilliant creation, you can build it one brick at a time.

1.  Lyrics ‘Barnum’ by Michael Stewart.

End?, No Way! A Baseline is just the beginning……

When you have a complex problem, it is always good to ‘set some bounds’¹, ‘divide and conquer’² and ‘place a line in the sand’³. That’s 3 so far on the cliché count, but they are all true reflections of baselines and configuration management processes.

Baselines and Configuration Management. No real life project is static, it never has all the answers available up front and even the most basic of tasks is likely to have a change to its requirements. Changes can range from an alteration of delivery date or change of colour, to a whole change in direction caused by a change in circumstances, finance or regulation. If we’re not careful, project managing this changing landscape⁴ the ever changing goal posts⁵ puts project completion at risk.

We need to be clear that the proposed system requirements matched up to the user requirements at a particular point in time. Recording a baseline is that proverbial ‘line in the sand’. A baseline records the conditions at a point in time. The initial user requirements right at the beginning of the project would make an ideal baseline. It gives us a foundation to work from⁶. From there we can record, measure and control how the project develops. Far from being the ‘End’ of a project lifecycle, a baseline is a really good beginning.

Point of Decision

Now that we have our foundation, we can decide whether it is solid enough to build on. At present it may be more akin to a trench with some hardcore in the bottom, and nothing ready for a wall. However, we can now discuss these baselined requirements/or characteristics before moving on.

If all is well we can specify the system requirements and get the concrete poured. This firming up of the foundations⁸ would be another good baseline point.

Managing Change

“The neighbours have complained, the wall is too short to keep the dog in”.  Back to the drawing board? Not quite, we can go back to the baseline and check what the agreed characteristics of the foundations were. We can’t build the wall higher in solid blocks as the  foundations were not laid with sufficient margin for the extra weight. However, building the top part of the wall in decorative open block-work will meet the changed requirement and satisfy the user. Costs adjusted, new quantities calculated and time to take a new baseline.

Whilst ideally the project would have been planned from start to finish, before the first components were laid, this is not always possible or practical in real life. Recording when and why changes were made will help us make decisions based on firm ground⁹, rather than walking on sinking sand¹⁰.

Far from being end points, baselines should be seen as stepping stones to your goal¹¹. However, they should not be seen as a linear path. There may be more than one path across the river¹², and not all routes will lead successfully to the other side. Assume the neighbour decides to move and takes their dog with them. We can rewind to the baseline taken at the foundation stage and progress down the original planned height in solid bricks as we have the record that this was a possible solution at that point in time¹².

Baselines and Configuration Management (CM)

CM is a process that aims to establish and maintain the quality and consistency of a system’s performance, functional, and physical attributes throughout its life. It is tightly linked to the Quality Management System (QMS) and Requirements Management System (RM/REQM) employed on a project. Deciding when and whether items should be baselined, would generally be subject to review (QMS). Providing traceability through the project’s lifecycle also a QMS function. Gathering, eliciting, and decomposing requirements is an RM function. Dealing with change, would need elements of all three. Whilst it may be fun playing cliché bingo, it really is time to place a stake in the ground¹³ and record milestones in your project¹⁴. Don’t delay baseline TODAY!

To the parents of…….

First reports of the new School year are landing on parent’s laps up and down the country. How have their little prodigies settled into their new class, how are they doing with new subjects? Will the envelope contain a list of ‘Could Do Better‘ or will it be a list of ‘ Excellent Effort‘

As a parent you always hope that the report will be positive, but what do you do about the negatives? How do you better support your child at school?

5 Out of 7 Subjects Great, 2 Need improvement.

Ok, so as a parent we know Geography is lacking, but where. Is it a lack of understanding or a lack of world experience or bad handwriting. We could watch some BBC BiteSize revision clips take a world cruise, or get the lined paper and practice cursive fonts. The feedback lacks a little.

B2B Engagement

3SL are generally in the Business to Business market. We want to form a relationship with our customers more akin to the partnership between  parents and teachers than that of a Crisps^* manufacturer selling to the mass millions and offering a chance to feedback via a popup on their website. The incentive in this case may be the year’s supply of ‘Cheese and Onion‘ but the quality of the feedback is likely to be limited to my thoughts on whether 6 or 8 packets is ideal as the size of a in a multi-pack or whether I rate the ‘Beef Goulash – special edition‘ higher or lower than my regular ‘Ready Salted‘

^{(* Crisps: en; Thin slices of potato fried until crunchy and crisp, en_US; known as potato chips)}

Let’s Do a Survey

Surveys definitely have their place. They define a set of measurable criteria against which the business wishes to perform. “All posted correspondence must be dealt with within 14 days” is a laudable criterion, you can ask your customers if they received their mail within
7◘  14◘  21◘  longer◘  N/A◘ days.

However, this is not much use if the main mail is simply the invoice sent to the company’s finance department. The users of the product, were really more bothered about their email to support being answered promptly, as the project was on the critical path.

Let’s Wait and See

“Businesses will tell us when we’re doing well” right? Generally, wrong!

B2B or B2C will regularly tell you when something is wrong, but far less frequently tell you when something is right. It’s just the way we are. You finish a meal in a restaurant and it was OK you up and leave, you enjoyed it you may leave a tip, you hated it and though the service was awful you may write and complain. (If you’re British you’ll probably say “tut tut, not going there again” but that’s a cultural issue!)

Ask….

If the waiting staff see you are finished and approach your table and ask “Was everything OK? Did you enjoy your meal?” They may well get a range of responses from “Fine” to “Great evening” to “The steak sauce was superb, I hope it’s on the specials again soon“. From this the business can glean more about how well they are doing. You wouldn’t want your waiter to sit down with you and ask if there were areas you felt were lacking and how they could better serve you next time. (It would somewhat ruin an evening). On the other hand getting feedback from that teacher about where improvements could be made, asking what they could do to assist and what you could do to support is a vital way to improve achievements.

Help Us to Help You

3SL are asking.

We want to build that relationship and make Structured Software Systems Ltd, the company you want to deal with. We want to understand how we can better support you.

And the Survey Said…

We know we can answer the phone within a minute (during UK office hours), we know we can respond to emails within the service level agreement. But what we don’t know is whether these are the most important aspects that you value. We can ask Google how fast our pages load, but it may be a piece of vital content that you rate more highly.
So the survey says NO we’re not going to restrain you to a set of tick boxes. We know different customers value different aspects and we want to be able to respond to all those things. We are, therefore, throwing the ball into your court, asking you to provide us with a virtual “parent’s evening” to raise your concerns (or lavish your praise) on us, as the parents, of Cradle.

Get in touch…

social-customer@threesl.com, call us +44 (0)1229 838867 DM us @threesl or post a letter Suite2, 22a Duke Street, Barrow-in-Furness, Cumbria, LA14 1HH U.K (and we’ll try and respond within 14 days!). Tell us what you want, what you rate well and where we ‘Could Do Better’

3rd Party Review Sites

We are also keen for you to provide public feedback at Capterra or TrustRadius which can help others decide on the value of Cradle. Obviously if you have a problem we’d welcome you contacting us first so we can help resolve it, that will benefit you , us and the rest of our customer base.

Further reading:

This article from TrustRadius for vendors is quite insightful  The Engagement Economy: How to build the relationship B2B buyers want

UPDATE: September 2020 – 3rd Party Reviews