Requirements management

Engineers are capable of developing sophisticated products and always manage to prove their creativity and wealth of ideas. However, we notice that many products are developed without taking into account the actual needs of the customer. This leads to slow sellers or unnecessarily high development costs. Requirements management helps you to avoid such undesirable developments and to ultimately develop a product that is tailored to the customer's needs. You think: "Only theory?" We show you the proven practice from our projects.

Requirements management in development processes

Requirements management (also called requirements engineering) is an essential success factor for all development projects. The goal is to develop a product that is precisely adapted to the needs of internal and external customers. In terms of processes, interdisciplinary requirements management accompanies development projects from the idea through development to market maturity. Even after the actual product development project has been completed, new requirements can be incorporated via product maintenance. This closes the cycle and the new requirements can lead to a new product development project. In this case, we would like to focus explicitly on the requirements within the framework of development processes.

We adhere to requirements in development processes until the end of the process.
Figure: Requirements management in development processes

Collecting, coordinating and fixing customer requirements

At the beginning, all external and internal customer requirements must be recorded and described. Various methods are available to work out the needs, expectations, constraints and wishes of stakeholders and customers and to create requirements documentation from this.

  • Interviews / Semistructured interviews: Face-to-face or telephone interviews can be conducted with the stakeholders.
  • Questionnaires: A written survey is also possible to collect requirements in a structured form. In this way, the expectations of a large number of stakeholders can be recorded.
  • Workshops: With the help of creativity techniques, stakeholders and clients can be guided in workshops to discover aspects that need to be considered in the project that they would not have thought of through simple brainstorming.
  • Field observations: Another method is the observation of the stakeholders' work processes and the corresponding written or visual documentation. The so-called "use cases" (i.e. application situations) help the observer to better understand the customer's requirements.
  • Design Thinking: An alternative method to the interviews, innovative approaches are formed in a creative way.
  • Reuse: Basic workflows - to which users have become accustomed - should most likely be retained when a technical system is renewed. Instead of working out all the requirements from scratch, existing documentation should be used.

During collection and definition of these customer requirements, we identify conflicting requirements and align them with stakeholders and customers. This ensures that the validity of the described requirements is checked early in the development process - "Did we describe the right requirements?" In a final step, the conflict-free requirements are fixed, evaluated and released. In the context of the evaluation, associated risks are also taken into account.

Developing customer requirements
Figure: Developing customer requirements

Develop and break down product requirements

With regard to requirements management, it is particularly important here that in the V-Modell:

  • The requirements of the entire system are broken down to the individual modules and components.
  • The requirements are compared with technical specifications.
  • The individual components are compared with the specifications and requirements, tested and validated individually and in their integration into the system. This ensures that all requirements from the specifications are implemented in the final product and function properly. Important: Specifications are tested and requirements validated.
Establish requirements for products and product components
Figure: Establish requirements for products and product components

On the left-hand side of the V-Modell, (customer) requirements are transferred into specifications and then "broken down" into their elements (modules, components). At the lower end of the V-Modell, the technical implementation takes place. The advantage of the V-Modell is now on the right side. A check of the successful implementation of all components, modules and the overall system is ensured in several steps via test cases at each level. Thus, the element on each level (e.g. component) is always tested first for itself and then the integrated element. Up to the system test, it is checked whether the developed system complies with the technical specifications (requirements specification). Only in the last stage - in the acceptance test / system validation - are the (customer) requirements validated. This test is important because it can happen that all technical specifications are met, but the system still does not deliver the expected benefits, i.e. the requirements are not met.

Changes will come in any case, so rely directly on professional change management. We have already described the cycle of customer requirements. In (almost) every project, there will be changes to requirements and/or technical specifications during the course of the project - i.e. at some point in this cycle. The structured process of change management includes dealing with changes, recording, documenting, assessing the consequences, deciding on the necessary levels and the final communication. The efficiency of the project team also increases when it is empowered to make decisions about changes independently. Decisions that go beyond the competences of the project team can also be ensured by a committee / steering group in the interest of the company. Find out more here.

Conclusion

Professionally implemented requirements management is a guarantee for successful product development. You can make well-founded decisions about product specifications if you have understood the customer situation, record, document, prioritise and manage the requirements in a structured way. You know which customer requirements are technically feasible and economically viable in the new product. You have clarity about the consequences of changing the respective customer requirements and the resulting specifications. And finally, you are sure that all tested components and modules function in an integrated manner in the overall system and which requirements are thus ultimately fulfilled.

Your benefit

  • You achieve higher project efficiency.
  • You change fewer requirements in the course of the project.
  • You recognise problems and the need for change earlier.
  • You reduce the number of errors and discrepancies.
  • You can reduce project costs because follow-up costs from errors are avoided.
  • You complete your project "in time and budget".
  • You achieve higher customer satisfaction by satisfying exactly those requirements and needs that are important to the customer.
V 1.0