Requirements Management

CMMI has this to say:

The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

I don’t know about you, but this sentence leaves me confused.

Which is really unfortunate, because requirements are very important, and at the same time many people neglect them.

This topic is so broad it deserves its own series (which I will write in time), so let’s just give a 10000ft view here.

What are requirements?

They are a description of what your product shall do.

I know this is a broad definition. It has to be, because requirements can exist at varying levels of detail, from a very coarse high-level overview over a system down to a detailed discussion of how a part of the system should handle a very specific case.

They will often be in text form, but they may also consist of diagrams, user interface sketches, videos or anything else that is useful in describing what the finished product should be like.

Requirements are collected in specification documents (where “document” is a pretty loose term – it might be a video if that’s useful).

In industrial applications, specifications are often written in multiple layers with increasing levels of detail.

If done rigorously, these layers are linked together, each requirement (and even each block of code) justifying its existence by pointing to a requirement in a layer above it that it satisfies. This is particularly crucial in safety-critical applications to prove that all necessary safety precautions have in fact been taken.

I have requirements, now what?

As has been a common theme for this article series, you need to be explicit about your goals so you can track your progress towards them, and spot if the goals change over time. Remember that changing goals are fine, but the changes need to be clear and visible so they can be dealt with (e.g. in the form of changing contracts, or timelines, or engineer allocations).

This means that specifications on their own serve only a very limited purpose: they are a summary of your product’s properties, an useful thinking tool if you will.

But only if you incorporate them into feedback loops will you take full advantage of them.

• Decide whether you are building the *right* product (does it really have the properties you specified?)
• Discuss with your customer which features to build, and when
• Predict development effort
• Spot troubles in your progress

and many more.

Requirements in an Agile World

It would be tempting to claim that requirements aren’t needed anymore if you practice agile development. However, that isn’t true.

At the outset, you will have at least a rough idea of your finished product – otherwise, how can you even start? And as you work on your product, spinning user stories and splitting out tasks, you are specifying, albeit in a more ad-hoc and less top-down manner.

So don’t fall into the trap of renouncing this topic: agile projects need and use requirements just as much as traditional ones, they just take a different approach and perspective.

Requirements and Testing

Requirements are also the basis for any tests.

If you don’t have requirements, how can you decide whether what you are observing is correct? Fine, sometimes it will be obvious, but in many cases it’s open to debate (and even “obvious” things aren’t in fact obvious to everyone).

Specifying the desired characteristics of your product will allow you to decide (and justify to your customer) that your product is of acceptable quality and that you are done developing.

Managing Requirements

It’s crucial to be deliberate about requirements. Collect them explicitly, use them explicitly, and change them explicitly. They are the fundamental link between your customer and your product.

Working with requirements is hard, and should be done carefully. This isn’t to say that it needs to be a drawn-out tedious process. If you can get away with having only a handful requirements to guide your development, perfect. But be deliberate in figuring out what kind of requirements you …er… require.

Most projects I’ve seen get in trouble were, at least in part, suffering from careless handling of requirements. Being sloppy in this area creates a vagueness of direction, and leads to tedious and painful discussions with stakeholders. Because the requirements will inevitably be discovered – whether deliberately or by accident, before or after you think you are finished. So the best thing you can do for yourself (and you customer) is to make sure you collect all the information you need to move your project forward in an explicit way.

This is a very broad and challenging (and rewarding) subject, and this post is far too short to do it justice. If you would like to learn more about it, stay tuned for my more in-depth series focusing on requirements management.