The Requirement of Requirements

Design processes and requirements aren’t exactly a thrill ride of a topic, and highly unlikely to be the reason any of us originally became design engineers.?You don’t want to write about it, engineering is about solutions; you want to get your hands dirty, start messing about with inventive and creative ideas, get into the nuts and bolts and solve the heart of the problem. But there it is, the fundamental problem to all of this…?How can you solve it, if you don’t know what it is.

Previously my colleague, Colin Funnell , wrote an interesting article on Switching Mindset to Test Driven Development. This following article explores what requirements are, the importance and value of requirements and how getting them right can save you time and money, all while contributing to a healthy and happy development.

Why do I need to spend time on the requirements, they’re boring and anyway, I know what I want?

What do you see when you look at a building??The interesting lines, scale, shapes and textures of the materials? Perhaps. The foundations? Probably not, but if the foundations are poorly constructed, the building will probably fall down because they are what the building is based on.?Requirements are similar; they are what development is based on and if they are poor the project might just fall apart – or at least cause headaches. Spending a little time up front developing requirements has the potential to save considerably more time and money later in the project, by reducing the chance of late changes and redesigns.

A complete set of requirements should describe clearly what the product is, so that it may be developed.?One of the key purposes of developing the requirements is to communicate this information to the relevant stakeholders to ensure everyone is clear what is being developed with no ambiguity or assumptions.?

Who are the stakeholders?

Stakeholders are anyone with an interest in the product and as such have an influence on the requirements. Examples may include: the customer, end users, product managers, project managers, development engineers, sales, marketing and manufacturing, but the list could be extensive and varied. Not only are there potentially many stakeholders, but their influences and viewpoint will also be varied, from product use, environment and market, through to functional, performance, safety and cost. These will need to be managed, and some may take precedence where conflicting requirements arise.

Different stakeholders may have differing views and expectations on what is required, stemming from a variety of influences, use cases and criteria, all of which need to be carefully managed. It’s unlikely any one person will have all the answers, so managing people and expectations from the start can help in keeping everyone happy and achieving that final sign-off.

So, what are these all-important requirements?

According to an online dictionary a requirement is ‘Something that is required; a necessity.’ OK, but what does that mean to development? The requirements will obviously vary from product to product, as they essentially describe what the product is, or equally is not.?Not how it will be implemented -?though consideration of this will almost certainly be useful during analysis.?For a requirement to be useful, it needs to fulfil certain criteria; for example, it should be quantifiable.?If you specify a large glass of wine, what makes it large? The person pouring it controls it, but that’s not going to be consistent.?If you specify a 250ml glass of wine, now it can be measured, and it will be consistent.?This can now also be tested, which is another useful criterion for a requirement. At the end you’ll need to prove that the product meets the specified requirements, so they’ll need to be written in a way that is empirically testable.

Other attributes such as severity and priority are useful, particularly where conflicts arise.?You may also need a method for establishing traceability between your requirements, development and testing, particularly where safety or security applications are concerned.?There’s a lot to consider when capturing and developing requirements but thankfully there are a range of useful tools to assist you in managing them.

That’s enough, wrap it up

In summary there’s a lot to consider with requirements. However, a bit of time spent developing them, evaluating them, ensuring that nothing is left out or assumed can give the opportunity to mitigate design and project risks early on and provide a clear description of what the product will be and do. If it’s not in the requirements, don’t expect it to be in the product.

If it’s so important and useful, why do people shy away from it? Because it is difficult.?Perhaps the appropriate skills or resources are unavailable. Making decisions about a product that does not exist is sometimes tough.?However, going through the requirements process will force you to think about exactly what your product is, it’s very purpose and reason, the market, the use cases, risks and technical challenges. The bottom line is, if you take the time to consider and describe the product using specific requirements, you stand a better chance of success developing it

At Hitex we have plenty of experience developing a vast range of interesting embedded solutions and we can help you to take that spark of an idea, develop the requirements, hardware and software and realise your product.

For more information visit our website: www.hitex.co.uk or get in touch: [email protected]. Or connect with us: @hitexuk (Facebook, LinkedIn & Twitter)