Can we fix requirements management?

So, clearly, we want to simplify the requirements management process so that customers can communicate with their software programmers and tell them what they really want and, crucially, get what they want — and, even more crucially, get what they really need.

Serena Software chief evangelist Kevin Parker suggests that there is conflict in requirements management today between speed and accuracy.

So what are our objectives here?

• We don’t want to produce the 400 page specifications that no one ever reads and that are out of date before development begins.

• We don’t want to create requirements that are so vague and poorly thought out that they cannot be implemented.

“With Agile and Lean we get to change our approach but this changes our relationship with the business units: we have to train them to recognise how to prioritise the areas we are to work on. The key to success here is the ‘product owner’ role: having a team member who is at ease with being in the business and who understands how it works,” says Parker.

So is a new generation of requirements management tools on the way to make this stage of activity more collaborative, open and more traceable?

Let’s ask a more ‘punctual’ question perhaps i.e. is the ‘consumerisation of IT’ making requirements management easier or harder?

Serena’s Parker says that the honest answer is both.

As users get more familiar with IT and use applications every day, they get to know what it is they really want from their applications. Business users see how technologies are being exploited and then use these examples.

“But the ever-present spectre is more pressure to deliver quickly. Look at how fast Lehman Brothers disappeared, Borders Books collapsed, Virgin Records left the high street: IT is not about margin and competitive wins; it is about business survival,” he said.

So what is next for requirements management? Serena’s Parker writes as follows:

“Requirements churn continues to be a significant drag: When requirements change after they have been approved it can cost up to 20% of the overall development budget. According to Tom Murphy at Gartner, errors found in production are 3 times more likely to be errors from bad requirements than from implementation errors.”

“So we have to develop systems that allow for requirements to evolve that are integrated into the development lifecycle. We get to make informed decisions about the impact of the change on the schedule. We get to gather approvals from the stakeholders to sign up for the delay and the extra costs.”

“And we get to communicate the delay downstream so that teams can adjust their project plans. Of course we also get to see where the late changes are coming from and adjust resources, develop training and modify the cadence of development to match that of the business.”

“We need to take a leaf from the civil and mechanical engineering playbook and remember that development requirements are owned by the business and managed by the contractors. We need this same shift to occur with software requirements: the business needs to see them as the definitive definition of their business, their business process and their business systems.”

“When they change their business it needs to be documented in the requirements management tool. Then we need to communicate those changes downstream as change-orders to IT.”