reflection [Article] Why are Requirements so difficult to master?

[Jimi Wikman]

Requirements are very important. In fact I would say that 95% of all failed IT projects can be traced to a poor requirement process. This is baffling because requirements are really not that complicated and yet I see people fail in organization after organization.

After I started to look into the different flavors of Requirements I start to understand why things are so very hard to understand for many. There are such confusion about what type of work you should actually do, who you actually work for and what you actually should deliver.

So let us define what a requirement is first:

 

"A Requirement is a legal agreement between the requester and the performer."

 

That statement alone will surely get a few people raising their eyebrow for the simple reason that it does not fit in their job description. Again this baffles me that we have so many different work description for a single discipline. My only explanation is that people are confused on what different levels you work with requirements.

If we simply break down the three most common way of working I have seen: Facilitate, Investigate and Document. Then add it to the three common areas of work: Business, IT and translation between the two, then we can make a nice matrix. From there we can see what actual roles people have.

 

 

For me I think that anyone working with facilitating meetings as their primary function is a manager. Anyone who just document the need is a secretary. Those two types of "requirement analysts" I see frequently and in my opinion we should make sure that we call them for what they are so people do not think that this is requirement work.

In the investigative category it is common to work in all 3 areas depending on who you work for. Business analysts help business to define their need and IT analysts help IT define their need. This is however not requirements as their final product, but need. That comes BEFORE requirements. In this matrix we can see that the only role that actually work with requirements as the final product are the Requirement Analysts. This makes sense since the definition of requirements as a final product is:

 

"The outcome of a Requirement is a translation between need and realization of that need."

 

This is where many fail. I see many, many requirements that are nothing more than a granular break down of a need, but lacking the translation.  Many are often either to undefined and border on a business need, or other times I see technical specifications instead of the need. My theory is that people do not understand what requirements are and who they are for.

We can see this in the delivery of requirements as well. I do not know how many times I have seen people claiming to work with requirements simply dump a bunch of documents on the development team and move on to next project, or next iteration of the project. This way of working when you build walls and throw packages over it is NOT a proper way to work with requirements.

As we can see in the matrix above a requirement analyst sit between business and IT. There she function as a bridge between the two, translating need in both direction to ensure everyone understand and agree on what should be realized. This can only be done with active communication, person to person, and you never deliver a requirement, you make a handover.

I think that this is the key for making requirement processes work: handover and asking development and test to take over the responsibility of the requirement. To ask the most important question there is: "do you understand what business want and can you realize that need with the information you have been provided?" If the answer is no to that question, then you are not done with the requirement.

If you just understand your place in the requirement process and you understand what a requirement is, then the requirement process will be easy for you. If your organization understand that as well, then life will be great for everyone.

 

So do you still think requirements are difficult?

View full blog article