The Reliance on Requirements Management Tools as the Engineering Messiah
|
A version of this blog post first appeared on requirementdoctor.blog.
I’ve met a lot of folks who have an unhealthy belief in requirements management as the sum total of requirements work needed.
For example, whenever I ask if someone works with requirements, almost immediately the conversation turns into two things: either a discussion on tooling (IT support in the shape of a relational database for tracing different requirement statements to and from each other) or a conversation around the need to change to more Agile ways of working using methods like User Stories, Personas, Modeling, etc.
The thing is, I asked if someone works with requirements. Not about tools or development processes or methods.
What are requirements?
Requirements are capabilities that a product must meet to satisfy a stakeholder’s need to solve a specific problem. The stakeholder’s needs can come from a number of sources, including compliance to a standard or regulation, a business need, a technical situation, market need, competition, etc.
So, why are so many discussions around tooling or Agile methods?
My sense is that:
A: People don´t know that requirements are really used for
or
B: They don’t understand why they work with requirements in the first place.
If we consider the definition of the discipline of Requirements Engineering (i.e., all things associated with requirements) it’s this:
“Requirements Engineering (RE) refers to the process of defining, documenting and maintaining requirements in the engineering design process.”
So, when I put requirements and process together, I end up with the notion of being able to understand a need and/or problem, defining it in a suitable way (notation technique, language and “chunks”) and maintaining this clearness throughout the project to solve the specific need and problem.
That’s the boiled down version.
That means to get from point A (the problem) to point B (the solution), I need to do a lot of clever stuff to understand, define, build, prove and deliver B to satisfy A.
The way of working (that endless discussion about development methodologies) is of lesser importance here. You still need to validate in some way that you have understood the problem before you start to building a solution.
To solve complex things, I need to develop suitable pieces of this puzzle and give these to the people helping me. To do this, I typically need clear pieces of information that, together with the other components, completes the picture.
I need to describe this specific, correct and unambiguous piece of information. This basically becomes a Christmas tree in shape, with the original need at the top, which is broken down and developed into those well-known requirement types of functions, constraints and capabilities we are used to seeing.
Each broken down requirement is derived to satisfy its originator one floor up in the hierarchy. For this, we need to keep control over the links that become one of the results of this activity.
How can we otherwise know what will become the consequence of a change?
But is requirements management enough?
So, back to the question on a requirements management tool. Is it enough to have a tool for managing those requirements and links?
No, absolutely not! Have your heard the phrase “garbage in, garbage out?”
If you only focus on the management part of requirements engineering, you’ll create an over reliance on the tool to show when a link requires an overview due to a change somewhere.
Haven’t you forgot one thing?
Requirements are stated by humans for humans, and the knowledge captured because of a decision to state a new requirement in the first place must be captured in the original sentence.
A badly-formulated requirement is therefore the parent of a lot of new requirements, with all of them inheriting the bad genes:
Why requirements quality is important
Don’t get me wrong. Requirements management IS important, I agree 100%.
One needs to be able to trace requirements to do impact analysis on suggested changes, do testing in a clever and incremental way and basically have an idea when to be done with the project, but…
Wrong information derived and traced into more low-quality information will lead to disaster.
A recent study showed that of all failed projects investigated, more than 40% concluded that failure was because of bad requirements or being unable to understand the true stakeholder’s need in the first place.
If you are lucky, your project won’t fail due to bad requirements. Maybe you’ll “only” get a lot of late design changes, angry test teams, frustrated project managers, failed financial goals and unhappy customers.
You better stop saying that you are good at requirements ONLY because you own a RM tool!
Without good engineering practices to discover and formulate the correct and consistent requirements and making that specification complete (to describe full need of functions, qualities and constraints), you will still have huge problems, RM tool or no RM tool. Garbage in is, and will always be, garbage out.
PS: The rest of the people in that study who didn’t blame the requirements for their recent project failure, blamed the project manager. Just so you know. The story continues and so will the failed projects…
Register now to join the author of this blog post, Christer Fröling, and Jama Software for a webinar, “Garbage In, Garbage Out: How Poor Requirements Inhibit Systems Development.”
Christer Fröling writes about organizations' reliance on requirements management solutions.
Latest posts by Christer Fröling (see all)
- The Reliance on Requirements Management Tools as the Engineering Messiah - January 3, 2018