Yesterday I was interviewed by the trade press about Requirements Management. Of all the areas in IT today this is the one that is in most serious need of attention. For decades we have failed so enormously in this area and tried to fix the problem downstream instead of focusing on getting requirements right. I think we need a radical rethink of how requirements are gathered, recorded, managed and used.

Here are five ideas on how we can revamp how we do requirements that won’t cost much to implement and which will deliver giant benefits to the organization:

1. Pictures not words
2. Prioritized lists
3. Public lists
4. Pick the waterline
5. Practice agile requirements

1: A picture paints a thousand words
The English language is so inadequate in explaining what we want. We can take thousands of words to explain in precision what we mean, look at any piece of legislation, yet Bread had it nailed in 1971 with their song “If [a picture paints a thousand words]”. So why don’t we follow their lead and move to requirements in pictures. After all what we are going to deliver is, for the most part, a visual experience.

So I welcome the arrival of prototyping and simulation technologies that enable business analysts and even users to draw facsimile applications and experiment with them. However there is much more to the application than the user experience.

What about the business rules, the flow of work through, the data model? All of these carry valuable information about the solution that needs to be created. We need to move to a new standard for documenting business systems, a standard that incorporates all the function and non-functional requirement and that is entirely, or as much as is possible, pictorial. And I’d like to see it start with a baseline of our current systems.

In fact as we have seen the massive growth in workflow tools being introduced into businesses we are steadily developing the most comprehensive documentation of business in history. While we see this as an essential part of managing the business we should be looking to take this as the de facto “truth” about how the business works. And if it is not the truth we must work to ensure that it rapidly becomes so.

Using our BPM tool to document the business is a delightful unexpected consequence and for any business teetering on the the decision this is the one benefit that will repay itself over and over again over time.

From the baseline that is our current BPM model we can now engage in a conversation with the business about where they want to evolve their business and we can do it in a pictorial language that is concise and precise.

2: Sink or swim by prioritization
We gather hundreds or requirements every day from the users. We document them and we categorize them and we validate them. But the most important thing we can do is prioritize them.

My first boss once said to me “There can only be one priority one” which was profound and obvious at the same time. Unfortunately he was prone to follow this with “and here they are!”

Prioritization can be can be controversial. Once we have an ordinal list someone’s requirement is going to be above someone else’s and below another’s. However, instead of IT being the villain and deciding which requirements get done, the business users can now engage in a conversation about relative value of the requirements and negotiate amongst themselves on the order. This leaves IT to act as advisor and technical guide organizing and optimizing the list for development efficiency (but not at the expense of business need).

A more engaged business, a more informed business user means better quality of debate and better outcome for the system and the organization in the end.

3: Publish and empower
So now we have a prioritized list but where is it? It should be in the hands of the users. In fact every requirement must have a business sponsor who is notified every time that requirement is changed, updated in any way.

And these requirements need to be out in the public (at least internal public if you get my drift) domain. If everyone in the organization can see how the requirements are prioritized they can contribute to the debate.

It is important for users to mention when the requirement is wrong but if they can’t see them how can they do that? It is critical that they mention things like “this is a legislative change” or “marketing are starting the TV campaign in September” that affect the prioritization. Remember IT tends to work the list in priority order so it is critical to empower all the stakeholders to tell everything they know about the requirement especially information that affects its priority.

And when those users edit the requirements the stakeholders need to know. The owner of the requirement needs to approve the change, the architect, designer, developer and tester working from those requirements need to know too.

There is no reason why requirement can’t change while there are in motion, being developed, but equally there is no reason why the change necessarily makes it into the code. Each situation needs to be taken on its merits. The essential point here is the requirements tie stakeholders, business and IT, together with anyone and everyone involved in the requirements, users, customers, suppliers, etc. Keeping this information siloed only makes the problems worse.

Just a word about crowd sourcing. This is a technique for gaining a collective opinion on which are the highest priority requirements. The process is simple – let the people vote. Adding voting capability to a requirements management system makes it possible for interesting consensuses to emerge that might not occur if a lone manager makes the prioritization decisions.

4: Sink or swim by the waterline
When have our prioritized list, and it is in a place where all stakeholders can access it we, as IT, need to add a waterline. A line which says, above this line are the requirements we have the resources to do, below this line are the requirements that will have to wait.

The waterline is added by taking the initial estimates in the requirements and comparing them to the IT resources assigned for this project.

Now we can see why prioritization is essential. Math will take you below or above the waterline. Not some capricious or suspicious invisible process. When the waterline appears everyone below the surface starts to improve the quality of argument about the requirements and suddenly they get much better.

Once again it is the business that is determining the priorities and therefore which requirements don’t make the cut. Of course, from time to time, the “must haves” are going to go below the surface. What happens now is that it suddenly becomes obvious that we are either over-thinking this project, or overloading it or, perhaps, IT needs more resources. How much more compelling is it for the business units to agitate on behalf of IT for more project funding?

The waterline is a wonderful discipline that is easy to implement, that everyone understands and that takes IT out of the decisions and once again places us in advisor position.

5: Can we do requirements in an agile manner?
We certainly can. As the foregoing (or is that four-going?) ideas show we can turn to automation to  improve how we manage requirements and move the ownership and decision making process to the business.

Given that the business is as eager to see requirements definition improve as much as IT is: it is equally true that the business does not like the months of interviewing just as IT hates it too. So can we apply the disciplines we are evolving in agile software development to requirements gathering?

When we have an informed user community we can start to ask them to give us their needs in priority order. We can then start to work on those priorities much earlier in the lifecycle.

Then we can go and get the next set of priorities and work on those.

Of course requirements change, as we’ve said, and when they do it is a lot better to be able to insert updated ones into the next wave of priorities and wait a few weeks for the update to appear as opposed to a few months (or years!).

So agile requirements go hand-in-hand with agile development and agile testing.

Summary
If there is one theme here it is that empowerment of stakeholders involved in requirements. Empowered users make better decisions as long as they realize that with that empowerment comes accountability. So when you decide to Empower Change in your organization’s requirements management processes remember that when it comes to requirements: change is not as expensive as ignorance.