Since I started to work with requirements (information) quality I’ve met a lot of folks out there that in my opinion have an unhealthy belief in requirements management as the sole facilitator of the requirements work needed.
If I asked: “Do you work with requirements?”, almost immediately the conversation turs into 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 in a discussion on the need to change over to more Agile ways of working using User Stories, Personas, Modeling, etc. from the old way of working (water fall and written requirements).
If we for a moment stop this here and just thinks about this… I just want to reason with you a bit here..
I asked about If someone works with requirements, right? Not about tools or development processes or methods, right?
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 to legal regulations, a business need, a technical situation, market need, competition, etc..
So, why the discussion on tooling or Agile methods? My sense here is that A:
- People don´t know that requirements are really used for, OR B:
- They don’t understand why they work with them in the first place.
If we consider the definition of the discipline Requirements Engineering (i.e. all things associated with requirements) it’s like this:
Requirements Engineering (RE) refers to the process of defining, documenting and maintaining requirements in the engineering design process.
So when I put these to together (Requirements and process) I end up in basically the notion of being able to understand a need/problem, defining it in a suitable way (notation technique, language and “chunks”) and maintaining this clearness thought the project endeavor put in place to solve this specific need and problem. Ok, basically 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 run, right?
To solve complex things, I need to develop suitable pieces of this puzzle and give these to the people that needs them to help me. For this I typically need clear pieces of information that together with the other pieces builds the complete 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 see. Each broken down requirements are derived to contribute to satisfy its originator one floor up in the hierarchy. For this we need to keep control over the links that becomes 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 requirements management tool. Is it enough to have a tool for managing those requirements and links?
No, absolutely not! Have your heard the phrase “shit in, shit out”?
To only focus on the management part of requirements engineering one tends to create an over reliance on the management 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 sentence put down.
A badly formulated requirement is therefore the parent of a lot of new requirements all of them inheriting the bad genes:
Why requirements quality is important
So, to round of this blog post. Requirement Management IS important, I agree to 100%
One need to be able to trace requirements to do impact analysis on suggested changes, do testing in a clever and incremental way and basicaly have an idea when to be done with the project, but…
Wrong information derived and traced into more low-quality information will lead to a disaster. A recent study actually showed that of all failed projects investigated over 40% had come to the conclusion that it was because of bad requirements or beeing unable to understand the true stakeholder need in the first place. If you are lucky you dont fail your project due to bad requirements, perhaps you “only” get alot of late design changes, angry test teams, frustrated project managers, failed finacial 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 cosntraints), you will still have huge problems, RM tool or no RM tool. Shit in is, and will always be, shit out!
PS. The rest that didn´t blame the requirements for their recent project failure, blamed the project manager. Just so you know. The story contines and so will the failed projects…