Chemicals & Materials Now!

From basic to specialty, and everything in between

Select category
Search this blog

Requirements That Are Actually Helpful

Posted on September 15th, 2016 by in Chemical Manufacturing Excellence

change-671374_640

Having spent a good number of years working as a systems engineer in the defence industry, I know what a bad rep requirements specs have. Cumbersome, outdated, slow moving, restrictive, dull, unnecessary, take your pick of words to describe the common perception of requirements specifications and those who produce them.

But I’ve also seen the power, and dare I say beauty, of a good requirement spec. They can give focus, structure and accountability to a project. They can demonstrate the validity of innovation, give evidence of its correct implementation and be a foundation to test new ideas upon.

But defining requirements well is difficult. It’s often not done well and, sadly, a lot of the criticism requirements specs receive is justified.

But it doesn’t have to be that way!

Below are my three golden rules for requirements in keeping them relevant, useful and necessary.

They Define What, Not How

When thinking about requirements, we’re still very much focused on the problem (rather than the solution). We’ve looked before at the importance of starting with the what before moving onto the how. And it’s a requirement specification that should capture that what.

A good requirement specification is completely unbiased as to the solution that will eventually meet the requirements. It’s irrelevant at this stage how the requirements will be met.

It only matters that the requirements fully specify and articulate the boundaries of the problem we’re looking to solve.

They Can Be Verified

There is nothing worse than getting to the very end of a project and finding that it’s impossible to test the solution that’s been developed against all of the requirements. Verifying the solution against the requirements is how we know we’ve been successful. It’s often how we get paid by a user or client too.

But some (badly written) requirements are impossible to verify a solution against in an objective way. One I’ve seen a lot is something like, “the xxx shall be easy to use”. What does that mean? How can you objectively measure whether a solution meets that or not? A much easier requirement to verify a solution against looks more like, “the xxx shall have a density of less than yyy”.

So when writing requirements at the start of a project, give some thought to how you might be able to verify a solution against them. You’ll thank yourself for it at the end.

They Are Traceable

No requirement should stand in isolation. They should all point back to the high level problem we’re trying to solve. While the high level problem statement on its own isn’t enough to define the problem in more technical terms or to a level that’s helpful in coming up with potential solutions, it’s the high level problem statement that we need to start with.

So every requirement needs to be an expansion of that higher level. No new requirement should be added a low, detailed level. They should all be derived from, and point back to, a higher level parent.

In my experience, a solid understanding of the problem being solved and a good requirements specification are key foundations upon which any successful project should be built. It’s possible to succeed without them, but doing both of those things well makes success much more likely.


 

All opinions shared in this post are the author’s own.

R&D Solutions for Chemicals & Materials

We're happy to discuss your needs and show you how Elsevier's Solution can help.

Contact Sales