Do Requirements Management Right From The Start – Who Does What and Why?

This article was written by our product owner Ulf Eriksson.

Every year I encounter hundreds of companies that want to improve their requirements management. Doing so involves some challenges and there are a few of these which occur very often. These pitfalls include focusing on solutions too early, unclear responsibilities, and too little communication.

In this article I will share with a few tips to solve these problems. To illustrate my thoughts, I am going to adopt an imaginary scenario which plays out in a fairly regular workplace.

A medium-sized company has decided to build a digital archive system for storing documentation for completed projects. The business representative is Jane Doe, a middle-aged woman who began her career as a software developer but now she has more overall business responsibility. She also is a product owner for some of the company’s IT systems.

At present the company does all its archiving manually. When a project is completed, the documents to be saved are printed out and put in folders in the archive room of the respective local offices. The process is very time consuming, too much paper is used and the staff often complain that their skills are not being taken advantage of because of all the administrative work.

In addition, the paper-based archive results in documents being locked up in the respective offices, meaning that in order to access a document, one must either get to the place where the archive is or ask any staff in place to scan and email the information.

The new filing system would contribute to faster storage management, requires less of the staff’s time and would definitely be much greener from an environmental perspective. The transition to a digital archive would also make project information searchable and accessible to more people in a completely different way than before.

Jane decides to order the system and turns to her colleague Carina Jones at the IT department. Carina works as a requirements manager and project manager.

Jane says: “We need a system to store project info on two servers, one server to store documents for three years and the other to store documents for ten years. I want you to start your project as soon as possible.”

“Absolutely”, Carina responds. “First, I need talk to all stakeholders to get enough information so that I can form a better idea of what the needs are. Very often I’m only provided with the basic needs and requirements are added from various stakeholders during the project and that ultimately led to delays. I’d like to avoid that happening this time.”

Jane replies. “But I already told you my needs! If you absolutely need more information, I might add that I want the system to be a web application that is built on .NET 4.0, file transfer is done by a service application and storage of data is done in an SQL database.”

“I understand.” Carina responds. “I’ll make sure that we work up a proposal, which you may authorize.”

Jane says, “I trust you Carina, you usually do a good job. I want you to concentrate on delivering the system in the near future so that it can be deployed in the fall. In the process, I will contact you to keep me updated on the project’s status as the need arises.”

Now let’s back up and look at the scenario from a requirements engineering perspective, as there are some points in which both Jane and Carina can improve so as to lighten and simplify the requirements process:

1. Focus on needs instead of solutions in the early phases

Let’s begin by looking at the event from Jane’s perspective. With her background as a developer, she has knowledge of what the solution might look like and therefore, the need is never formally stated. Instead she directly proposed a solution to speed up the requirements process:  “An application will be built to store projects on two different servers in three and ten years.”

It’s not just people with a development background who can be solution-focused, most people are, in fact somewhat focused on the solution. If we face a problem, we are often quick to find a solution. In some cases it may be a good feature but within the requirements perspective, a solution proposal that is developed too early in the process does more harm than good.

The danger of proposing solutions too early is that the real need might be forgotten. The solution that is built might correspond to the suggested solution, but it may not solve the original demands.

To easily formulate the overall business requirements, you can use the so-called WWW template that describes three important parts:

• Who?

• What?

• Why?

The WWW template describes who the stakeholder is, what the stakeholder wants (the goal) and why the stakeholder wants this (the motive behind the requirement).

If we apply the WWW method on the requirement above, it may look as follows:

If we see the situation from Carina’s perspective, she is fully aware that the need is important. She does not feel quite satisfied with the requirement as Jane put it, but most of all she wants to make the requirement clearer. The requirement as it is right now is too solution-oriented. It is in her interest (and her responsibility!) as a requirements manager to question everything unless and until the underlying need is clear.

This is why she suggests that she should start out quite broadly and capture the needs of all stakeholders in order not to miss anything.

When Carina takes up the aspect of needs, Jane again wants to streamline the process by ‘clarifying’ and providing more detail instead of answering the question. The requirement now becomes even more full of details and restrictions: “It will be a web application. NET 4.0, a service to transfer files and data to be stored in a SQL database.”

Including more and more details in the hope that the requirements will be clearer is extremely common and comes up every time I talk to customers.

Let’s put the details into the WWW template to see what happens with the requirement:

 

Does the requirement appear clearer now we’ve added the details? What has happened is that we added more details to the ‘what’ column, which describes the goal. However we have still not explicitly stated the need or motive behind the requirement. “In order to store project data” is an answer to why we want to build the application, but not the answer to the underlying need.

A supplier that would have been given this information would of course use the solution and the technology specified, because in reality a supplier will have no idea how relevant the requirements and restrictions are. Suppliers do not really have an input, which means the solution will be as good or as bad as the client had the ability to express.

Of course, the requirements do need to be detailed and supplier will have to present possible solutions, but that is a later step, not one to be taken so early on.

The information that we are really looking for is found in the introduction of this article. The actual need was to make better use of staff skills, increase efficiency and improve information sharing.

Only now is the WWW template starting to resemble what is called ‘user stories’. User stories are a requirements pattern technique commonly used in agile projects. User stories are usually expressed as follows:

As a [type of user] I want [some goal] so that [some reason].

As a client, I want to digitize the archiving process so that we achieve better use of staff skills, increase efficiency and improve information sharing.

2. Client is responsible for the need, supplier for the solution

At the end of the dialogue Carina indicates that she wants to develop the requirements specification and a solution proposal that the client can accept.

Actually, it is the client’s responsibility to develop needs / business requirements and the supplier’s responsibility to come up with a proposed solution. Many times the client can not handle formalization of the requirements but needs to hand over the task to the supplier. This may be all right, but it is still the customer’s responsibility to get it done and to ensure that the needs are formalized in the right way.

What this means by extension is that the client must have an active role in requirements management if the results are to be successful. It is not enough, as Jane suggests, that “I will contact you to keep me updated on the project’s status as the need arises.”

3. Confirm the interpretations of requirements and solutions

Now that we have come up with the needs, formalized business requirements and a proposed solution, the client needs to confirm that our interpretation of the requirements and solutions address the actual needs.

In this example, there could very well be several months between the meetings, depending on how active the client is. At worst, we could find that both the requirements specification and the proposed solution were out of line with what the customer had in mind and many hours were spent on development that had to be started over.

This is why reminding yourself and your team members of the significance of confirming requirements can not be done too often.

Summary

There is lots to consider in terms of requirements engineering, but some of the most important aspects are:

• Think of ‘needs’ not of ‘solutions’ when early on in the project.

• The client is responsible for the need and the supplier is responsible for the solution.

• Confirm interpretations of requirements and solutions.

The next step

For further reading, I recommend that you read our other articles, such as “A cloud on the horizon: How Cloud Computing will change requirements management and testing”, “How to set SMART goals” and “Use Personas as a portrait of your user”.This article was written by our product owner Ulf Eriksson.