Requirements Management

The budget has been set, the objective outlined, and the timeline defined: At this point, companies often rush ahead with implementation instead of taking enough time to systematically obtain the requirements all stakeholders have for the intended product and manage the specifications. As a result, the originally defined requirements formed part of the product for only around 56 percent of IT projects according to a study. This means time and budget resources are wasted. But this can be avoided with a structured requirements management process.

Requirements management – also known as requirements engineering – is an elementary component of project management in companies. The aim is to ensure that the requirements of customers as well as internal and external stakeholders are met with the final product.

The discipline encompasses defining the requirements (requirements analysis, documentation and validation) and managing the requirements (risk, change and implementation management). It’s not a one-off task performed at the beginning of a project, but a series of recurring processes that stretch over the entire duration of the project. A responsible manager or requirements engineer monitors the implementation and integration of requirements, changes as well as project progress.

IT requirements management is relatively established in the technology sector. If what features the intended software is to include and which processes it is supposed to support are not precisely defined at the start of IT projects, problems later in the project will be inevitable. Time and resource planning are not realistic without these preparations, and there is a big chance that customers will prolong the project and exceed the budget with a bunch of change requests. If change requests aren’t then properly managed, this pushes up costs even higher.

However, requirements management is important and worthwhile regardless of the sector. Especially in extensive projects with complex products, it ensures that efficiency remains at a high level throughout the project and that errors as well as disagreements between project partners are avoided. A requirements engineer can recognize problems resulting from altered customer wishes at an early stage and define measures to minimize any negative effects.

Even if higher costs are incurred to customers due to the more thorough documentation of requirements at the beginning of the project, customer satisfaction benefits from a structured requirements management process.

Nonetheless, the importance of defining and managing requirements for the success of a project is often underestimated by companies – even in the case of technology projects where IT requirements management is common. Otherwise, it would be hard to explain why 52 percent of all IT projects according to the CHAOS study of the Standish Group blow the defined budget and schedule. Only 55 percent of respondents felt that requirements management was important or very important. The rest only attached moderate or low importance to requirements management for the success of projects. This is a mistake with serious consequences – as shown by the number of projects completed according to plan.

• Higher project efficiency
• Fewer change requests during the project
• Fewer errors and disagreements
• Early recognition of problems and the need for alterations
• Lower project costs since consequential costs from mistakes are avoided
• Projects completed in time and according to budget
• Higher customer satisfaction

The most important tasks of requirements management include identifying, documenting and analyzing requirements, as well as managing changes in the course of the project.

It’s first important to identify the requirements of the various stakeholders. The requirements engineer has a range of methods available for determining the needs and wishes of stakeholders and customers. They can then prepare a requirements document on this basis.

• Interviews: The requirements engineer can conduct interviews with stakeholders in person or by phone.
• Surveys: A written survey is also a potential way to collect requirements in a structured manner. This makes it possible to ascertain the requirements of many stakeholders.
• Workshops: Using creativity techniques, stakeholders can be guided in workshops to discover aspects that need to be considered in the project, which would not have otherwise come up through simple brainstorming.
• Field observations: The requirements engineer observes the stakeholders’ workflows and documents them in text, audio or video.
• Apprenticing: The requirements engineer learns the tasks of the stakeholders. In doing so, the requirements engineer becomes aware of important requirements for the project.
• System archaeology: For IT infrastructures that are not (adequately) documented, the requirements engineer can start by examining the system and preparing documentation. They can supplement their own analysis with surveys of system users.
• Reuse: If a technical system needs to be updated, it’s likely that basic workflows that users have become accustomed to need to be maintained. Instead of revising all requirements, existing documentation should be used as a basis.

A scope statement provides the contractual foundation between the project partners. It’s the first product that needs to be prepared in requirements management. The scope statement should contain all the client’s requirements for the deliverable and define the product to be supplied by the contractor. It states what’s to be delivered. After that, a functional specification can be prepared that stipulates how the project is to be implemented.

In many cases, it makes sense to not only set down the requirements in writing but also graphically – especially when describing systems, processes, and use cases. UML diagrams are typically used for this purpose.

Once the requirements have been determined and documented, it’s the task of requirements management to analyze the requirements. Contradictory requirements must be identified and clarified with the stakeholders. What’s more, the manager should determine and evaluate the risks (using an assessment based on the potential scope for damages and the probability of occurrence). An initial prioritization of the requirements should also be carried out.

The requirements documentation should then be presented to the stakeholders for review. Only once agreement has been reached on the scope statement should work begin on implementing the project.

In (almost) any project, change requests will emerge over time. To keep discussions about incurred additional costs to a minimum and ensure it is possible to return to an old project state if the customer is dissatisfied, the use of versioning is a well-established practice. This method originally comes from software development but is also applied in project management. Here, project progress is documented, and current versions are marked as the new baseline. This enables project partners to easily compare the current scope of requirements with previous ones.

Many companies assume that requirements management is unnecessary in agile projects since the scope changes over the course of the project anyway. That’s a mistake.

Many tasks that form part of requirements management are handled by the product owner in agile projects. They oversee and manage the project as well as the implementation of requirements. Moreover, they prioritize requirements and coordinate changes. These are typical tasks of a requirements manager.

If the product owner is unable to take care of all the tasks of requirements management alone, additional employees can be appointed to make sure new requirements are added, where applicable, and that documentation is kept up to date (regarding changes, for example).

Although requirements management is less extensive in agile projects, it’s still just as important as for conventionally managed projects following the waterfall principle.