Effective requirements engineering

Everyone should have effective requirements engineering. Everyone should have efficient requirements management. It would be nice to have a way to know that your work with requirements is well spent. The question is more easily asked than answered.

The goodness of the req eng process

When Casimir Artmann asked a question about effective requirements work in agile and how to measure it, it sparked a long discussion on Twitter with Ethar Ali, Thomas Cagley, Johan Natt och Dag and a few others chiming in.

H2 measure if your organisation is good in managing requirements in agile projects? @TCagley @GregerWikstrand @EtharUK @WoodyZuill

— Casimir Artmann (@artmann) January 9, 2017

Both Thomas Cagley and Johan Natt och Dag noted that the answer depends on the definition of good. Johan also noted that processes are usually evaluated by their outputs.

@artmann @TCagley @GregerWikstrand @EtharUK RM is a process. Typically you evaluate a process by measuring the outcome (value). RM KPIs.

— Johan Natt och Dag (@JohanNattochDag) January 10, 2017

I would add to that that processess are usually evaluated on how well they transform the inputs to the desired outputs. They are often evaluated on how effective, efficient, robut, resilient and stable they are. In other words, a good process should be possible to execute as “standard work”. A good process should not require a hero to make it work. As Joe Dager of Business 901 would put it:

@GregerWikstrand I agree w you just protecting standard work so ppl don't minimize importance of it. Hate 4 entire budget 2go2 innovation 😉

— Joe Dager (@business901) December 29, 2016

The question then is this: Should we evaluate requirements engineering on metrics that are only tied to that process? Should we look at how many requirements they have, how much they change and how well they can be traced?

Software quality can be maintained by checking quality attributes in requirements document. Requirements metrics such as volatility, traceability, size and completeness are used to measure requirements engineering phase of software development lifecycle.

I do not agree with this view. This view is based on a “waterfall process” where requirements are elicited, verifed and quality checked before they are passed to the next stage, verification. The next stage is called construction, design or perhaps architecture.

The real scope of effective requirements engineering

In my experience, effective requirements engineering cannot be separated from any other part of the process. Requirements are the fuel that the engine runs no matter if it is a train of many waggons or a car in a long line of cars going down the highway. Requirements are the electrons and the electricity that powers the computer that you are reading this on. I don’t mean this literally, but figuratively.

The real scope of software engineering is to take invention and innovation seeds and turn them into fruit bearing, profitable innovations. Just as you cannot draw a clear line that separates the acorn from the oak, you cannot draw a line between requirements engineering and any other aspect of software engineering and software intensive innovation. Requirements are what we start the process with as “ideas” or “needs” but they are also what comes out – transformed – at the other end of the process as a valuable delivery. (Go ahead and scroll to slide four in the presentation below.)

So how would you know that you have great requirements? The same way that you know that you have great seeds. Looking at the seeds, even through a microscope, can only let you know so much about the seed. The real interest lies in what the tree looks like after ten or a hundred years. Of course a lot of intervening variables will have played in through all the long years of the lifetime of a tree but it won’t be a great tree unless it was a great seed to begin with. In the same way, good requirements engineering cannot be measured by the quality of the documents that describe the requirements. Good requirements will be measured by how well the resulting systems work and on how fit they are for purpose.

A final note

You need to get what you need even if you are not able to formulate clearly what it looks like. After all, we need to avoid “death by requirements”.

Death by requirements? @artmann pic.twitter.com/rLHtI8ZWVH

— Greger Wikstrand PhD (@GregerWikstrand) November 6, 2015