Re­quire­ments Man­age­ment

The budget has been set, the objective outlined, and the timeline defined: At this point, companies often rush ahead with im­ple­men­ta­tion instead of taking enough time to sys­tem­at­i­cal­ly obtain the re­quire­ments all stake­hold­ers have for the intended product and manage the spec­i­fi­ca­tions. As a result, the orig­i­nal­ly defined re­quire­ments 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 struc­tured re­quire­ments man­age­ment process.

Re­quire­ments man­age­ment – also known as re­quire­ments en­gi­neer­ing – is an el­e­men­tary component of project man­age­ment in companies. The aim is to ensure that the re­quire­ments of customers as well as internal and external stake­hold­ers are met with the final product.

The dis­ci­pline en­com­pass­es defining the re­quire­ments (re­quire­ments analysis, doc­u­men­ta­tion and val­i­da­tion) and managing the re­quire­ments (risk, change and im­ple­men­ta­tion man­age­ment). 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 re­spon­si­ble manager or re­quire­ments engineer monitors the im­ple­men­ta­tion and in­te­gra­tion of re­quire­ments, changes as well as project progress.

IT re­quire­ments man­age­ment is rel­a­tive­ly es­tab­lished in the tech­nol­o­gy 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 in­evitable. Time and resource planning are not realistic without these prepa­ra­tions, 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, re­quire­ments man­age­ment is important and worth­while re­gard­less of the sector. Es­pe­cial­ly in extensive projects with complex products, it ensures that ef­fi­cien­cy remains at a high level through­out the project and that errors as well as dis­agree­ments between project partners are avoided. A re­quire­ments 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 doc­u­men­ta­tion of re­quire­ments at the beginning of the project, customer sat­is­fac­tion benefits from a struc­tured re­quire­ments man­age­ment process.

Nonethe­less, the im­por­tance of defining and managing re­quire­ments for the success of a project is often un­der­es­ti­mat­ed by companies – even in the case of tech­nol­o­gy projects where IT re­quire­ments man­age­ment 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 re­spon­dents felt that re­quire­ments man­age­ment was important or very important. The rest only attached moderate or low im­por­tance to re­quire­ments man­age­ment for the success of projects. This is a mistake with serious con­se­quences – as shown by the number of projects completed according to plan.

• Higher project ef­fi­cien­cy
• Fewer change requests during the project
• Fewer errors and dis­agree­ments
• Early recog­ni­tion of problems and the need for al­ter­ations
• Lower project costs since con­se­quen­tial costs from mistakes are avoided
• Projects completed in time and according to budget
• Higher customer sat­is­fac­tion

The most important tasks of re­quire­ments man­age­ment include iden­ti­fy­ing, doc­u­ment­ing and analyzing re­quire­ments, as well as managing changes in the course of the project.

It’s first important to identify the re­quire­ments of the various stake­hold­ers. The re­quire­ments engineer has a range of methods available for de­ter­min­ing the needs and wishes of stake­hold­ers and customers. They can then prepare a re­quire­ments document on this basis.

• In­ter­views: The re­quire­ments engineer can conduct in­ter­views with stake­hold­ers in person or by phone.
• Surveys: A written survey is also a potential way to collect re­quire­ments in a struc­tured manner. This makes it possible to ascertain the re­quire­ments of many stake­hold­ers.
• Workshops: Using cre­ativ­i­ty tech­niques, stake­hold­ers can be guided in workshops to discover aspects that need to be con­sid­ered in the project, which would not have otherwise come up through simple brain­storm­ing.
• Field ob­ser­va­tions: The re­quire­ments engineer observes the stake­hold­ers’ workflows and documents them in text, audio or video.
• Ap­pren­tic­ing: The re­quire­ments engineer learns the tasks of the stake­hold­ers. In doing so, the re­quire­ments engineer becomes aware of important re­quire­ments for the project.
• System ar­chae­ol­o­gy: For IT in­fra­struc­tures that are not (ad­e­quate­ly) doc­u­ment­ed, the re­quire­ments engineer can start by examining the system and preparing doc­u­men­ta­tion. They can sup­ple­ment 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 ac­cus­tomed to need to be main­tained. Instead of revising all re­quire­ments, existing doc­u­men­ta­tion should be used as a basis.

A scope statement provides the con­trac­tu­al foun­da­tion between the project partners. It’s the first product that needs to be prepared in re­quire­ments man­age­ment. The scope statement should contain all the client’s re­quire­ments for the de­liv­er­able and define the product to be supplied by the con­trac­tor. It states what’s to be delivered. After that, a func­tion­al spec­i­fi­ca­tion can be prepared that stip­u­lates how the project is to be im­ple­ment­ed.

In many cases, it makes sense to not only set down the re­quire­ments in writing but also graph­i­cal­ly – es­pe­cial­ly when de­scrib­ing systems, processes, and use cases. UML diagrams are typically used for this purpose.

Once the re­quire­ments have been de­ter­mined and doc­u­ment­ed, it’s the task of re­quire­ments man­age­ment to analyze the re­quire­ments. Con­tra­dic­to­ry re­quire­ments must be iden­ti­fied and clarified with the stake­hold­ers. What’s more, the manager should determine and evaluate the risks (using an as­sess­ment based on the potential scope for damages and the prob­a­bil­i­ty of oc­cur­rence). An initial pri­or­i­ti­za­tion of the re­quire­ments should also be carried out.

The re­quire­ments doc­u­men­ta­tion should then be presented to the stake­hold­ers for review. Only once agreement has been reached on the scope statement should work begin on im­ple­ment­ing the project.

In (almost) any project, change requests will emerge over time. To keep dis­cus­sions about incurred ad­di­tion­al costs to a minimum and ensure it is possible to return to an old project state if the customer is dis­sat­is­fied, the use of ver­sion­ing is a well-es­tab­lished practice. This method orig­i­nal­ly comes from software de­vel­op­ment but is also applied in project man­age­ment. Here, project progress is doc­u­ment­ed, and current versions are marked as the new baseline. This enables project partners to easily compare the current scope of re­quire­ments with previous ones.

Many companies assume that re­quire­ments man­age­ment is un­nec­es­sary in agile projects since the scope changes over the course of the project anyway. That’s a mistake.

Many tasks that form part of re­quire­ments man­age­ment are handled by the product owner in agile projects. They oversee and manage the project as well as the im­ple­men­ta­tion of re­quire­ments. Moreover, they pri­or­i­tize re­quire­ments and co­or­di­nate changes. These are typical tasks of a re­quire­ments manager.

If the product owner is unable to take care of all the tasks of re­quire­ments man­age­ment alone, ad­di­tion­al employees can be appointed to make sure new re­quire­ments are added, where ap­plic­a­ble, and that doc­u­men­ta­tion is kept up to date (regarding changes, for example).

Although re­quire­ments man­age­ment is less extensive in agile projects, it’s still just as important as for con­ven­tion­al­ly managed projects following the waterfall principle.