Guideline for requirements analysis/management especially based on requirements engineering

1 Introduction

What makes the client/customer happy?

This may sounds like the central question in management consulting. However, this question is too basic for us at novamusHR01. Much more important in a holistic consulting is the question: "What does the customer need to be happy in the long run - and above all - to be successful in business on a long time?" For this, an understanding of the "big picture" is essential.

In simplified form, system-related IT consulting is about knowing the requirements of the client/customer and fulfilling them in the best possible way with a new and/or improved IT system. (In process and management consulting, the perspective of the business processes as well as the corporate structure are added).

This is precisely where the topic of requirements management comes in. As in many other fields, different terms, approaches, methods, and standards have been developed and established over the time. Two well-known and important representatives are described in more detail below:

In German-speaking countries, we sometimes encounter the approach based on the Lastenheft and Pflichtenheft (requirements specification/ functional specification) with our novamusHR01 customers in the IT project environment. This approach plays an important role especially in (public) IT tenders.

Internationally, the terms Lastenheft and Pflichtenheft are almost unknown and there is also no direct or clear translation of the two words, which often leads to the need for explanations in our international projects in order to avoid confusion. In this context, the term "requirements engineering" has become an international and cross-industry standard.

In the following we have described how the procedure according to Lastenheft and Pflichtenheft differs from requirement engineering and how we deal with it in our projects at novmausHR01.

1.1 Lastenheft and Pflichtenheft

First of all, Lastenheft and Pflichtenheft must be differentiated from each other! Roughly speaking, a Lastenheft describes WHAT the client or customer wants, i.e. its requirements. This is therefore usually created by the client himself and handed over to a contractor or published in the context of a tendering procedure. This presupposes accordingly that the customer is already clear about what exactly he needs.

Based on the Lastenheft, the contractor prepares the Pflichtenheft and describes HOW and WITH WHAT he wants to or will fulfill the customer requirements. The Lastenheft is therefore always the basis for the Pflichtenheft. At the very least, however, the Lastenheft (or the customer requirements) will be a component of the Pflichtenheft (i.e., the system specification) in order to ensure a comparison between customer requirements and the degree of fulfillment by the contractor.

In the simplest case, a Lastenheft is converted into a Pflichtenheft, but the size of the Pflichtenheft is always larger than the Lastenheft.

The Lasten- and Pflichtenheft are usually an important part of the contract between the client/customer and the contractor. We therefore develop the Pflichtenheft closely with the client and have it signed by both parties at the end.

In German-speaking countries, the VDI regulations 2519 and 3694 are widely used. These describe the possible structure of documents and the topics must be documented in a Lasten- and Pflichtenheft. According to DIN 69901-5, the Pflichtenheft includes the "realization specifications worked out by the contractor based on the implementation of the requirements specification given by the customer". The requirements of the previously developed specifications must then be linked to technical specifications of the operating and maintenance environment.

Note: In "modern" and especially agile project, such as Scrum, Lean Development, Kanban, etc., we and our customers think that Lasten- and Pflichtenheft are rather hindering, because they are in conflict with the agile idea or "Agile Thinking".

1.2 Requirements Engineering

Since Lasten- and Pflichtenheft do not play an international role and are not the latest approaches in the German-speaking world, this approach is increasingly being replaced by "requirements engineering" (RE for short).

In contrast to the previously described approach, in RE the customer is not expected to provide a fully comprehensive document as a basis for work. In general, the customer is seen more as the most important of several sources of information for the creation of documents by service providers, such as novamusHR01.

The basic idea here is rather that the customer or client cannot/must not know what a satisfactory (IT) solution for him looks like. In the constantly changing environment of technology, especially in information technology, it is often beyond the customer's competence to know what is currently (and also in the future) possible and feasible. The limited "technology horizon" of the customer side can be illustrated (in the context of HR), as in the following shell model:

In RE, we therefore follow the approach that our consultants first understand the basic wishes and goals and, based on this, formulate requirements on behalf of the customer that are technically feasible and offer added value in terms of corporate strategy. This understanding in the form of requirements is then further developed on a continuous basis and coordinated with the customer in order to ensure the highest possible level of customer satisfaction.

This already iterative approach makes it possible to adapt the RE to an agile project environment. We mostly use predefined agile RE process models, such as the "RE@Agile", which was developed specifically for use in agile approaches (such as Scrum, Lean Development, Kanban, etc.).

The goal of the RE is to create a requirements document that reflects the customer's wishes and goals as best as possible and, at the same time, is designed in such a way that a third party (such as an internal IT, a software development company or other (service) providers are enabled to implement these customer requirements as efficiently as possible. This document is then often used as part of the contract between the customer/client and the contractor, i.e., the party that implements the customer's requirements.

Our consultants therefore take on a mediating role and serve as a bridge/translator between the customer and the realizer/implementer. NovamusHR01 therefore harmonizes what the customer needs in order to be successful in the long term from an entrepreneurial point of view and what is also technically feasible within limited resources such as time and budget. In practice, this mediating role is often generally referred to as a "business analyst" or specifically as a "requirements engineer".

This can be illustrated schematically in a Venn diagram:

The three most important authorities in the provision of process models, methods and techniques, and certification in requirements engineering are these large international professional associations:

• IIBA (International Institute of Business Analysis)
• PMI (Project Management Institute)
• IREB (International Requirements Engineering Board) (Headquarter in Karlsruhe)

1.3 Delineation

As shown in the previous paragraphs, there are fundamental differences, and therefore advantages and disadvantages, in the two described and possible approaches (Lasten- and Pflichtenheft and RE). Due to

• the wider distribution,
• the lower effort for the customer,
• the higher actuality,
• the better compatibility with agile methods
  in the following only the requirements engineering will be described further and also recommended by us.

2 Approach according to requirements engineering

Im Folgenden wird sich, bei Unterschieden im möglichen Vorgehen, auf einen Konsens der drei wichtigsten Vorgehensmodelle, definiert durch die vorgenannten internationalen Fachverbände, gestützt, der sich auch in der Praxis bewährt hat.

2.1 Überblick zum Vorgehenapproach

Before we start with the actual requirements engineering (short: RE) at novmausHR01, basically in step 0, we have to understand the "big picture". Besides the question in which project phase the RE takes place, it is essential to know who the customer is, what his goals and wishes are, what he needs to be happy in the long term - and above all - what he needs to be successful in the long term? From this understanding we derive principles as well as a "main course" of the RE. We then document these principles in a generally understandable, centralized and generally accessible way. In practice, the definition of "Guiding Principles" or "Terms of Reference" ("ToR" for short) has proven to be very helpful.

2.1.1 Elicitation

After these principles have been defined and approved by the customer. The requirements collection or the elicitation begins. Here, all possible sources are used to collect customer requirements. However, the most important source besides e.g. market analyses and possibly already existing project documentation are always the stakeholders themselves.

2.1.2 Analysis

The collected requirements are analyzed in the next step, the analysis. Essentially, we check here whether a requirement (still) fits into the "big picture". Are the requirements found compatible with the principles (from step 0)? If this is not the case, they must be adapted or sorted out. If requirements fit into the "big picture", the quality of each requirement must be ensured from a technical and corporate strategy perspective. We at novamusHR01 like to use the DEEP or SMART techniques here. In addition, e.g. conflicts and overlaps of the requirements among each other must be eliminated or clarified. The improved and therefore often changed requirements are then repeatedly presented to the stakeholders and confirmed, resulting in possible renewed changes. This iterative procedure creates a cycle between the requirements analysis and the elicitation. This may seem unintentional or unnecessarily time-consuming, but it is necessary in order to ensure subsequent customer satisfaction.

2.1.3 Validation

When, after several to many iterations, ALL requirements are COMPLETELY and CORRECTLY documented, the requirements are submitted to "key stakeholders" such as business (end-)users and technical implementers (e.g. developers) and management representatives like the sponsor
for final approval or validation. Ideally, after a short discussion and minor changes, the requirements are finally approved as a whole by signature and can now be handed over to those responsible for implementing them.

2.1.4 Documentation

As shown, documentation always takes place in parallel with the RE activities. This is absolutely necessary in order to at least not lose or forget any requirements and to always keep requirements up-to-date.

2.1.5 Management

Similarly, requirements management or administration always takes place in parallel. RE thrives on a constant or incremental adaptation and improvement of requirements. However, this must not "get out of hand". If changes are made to requirements, this should be monitored and only happen with approval. Here we recommend for complex projects the implementation of a "change management process" (like in ITIL). If there are any concerns whether already changed requirements still reflect the customer's original wishes, it should be possible to trace back to previous versions up to the original, by using a version control. Especially in complex projects, this is ensured on the basis of special database-based requirements management software, such as "Jira", "ReQtest" or "IBM Rational". But also a realization by the use of programs like Word and/or Excel is feasible and has been successfully done by us in practice.

These activities result in the following visualization for the RE approach:

3 Conclusion

Due to the constantly changing technical possibilities, it has become more difficult even for tech-savvy people to stay technologically up-to-date and to keep the overview. This is especially true for colleagues from the specialist departments. Due to increasing digitization and shorter half-lives, it is to be expected that these trends will also continue to grow. Therefore, fully pre-formulated requirements in the form of a “Lastenheft” are hardly to be expected from the customers and are also no longer up-to-date. Today, in this so-called “VUCA world”, fast solutions and agile approaches are more and more in demand and also much more target-oriented to support our customers in achieving their long-term business goals.
Although situations will continue to justify the use of Lasten- and Pflichtenheft, we at novamusHR01 clearly recommend - taking into account the previously mentioned reasons - a requirements engineering approach in the most cases.
If you need support in requirements analysis and/or requirements management, please feel free to get in touch with us at any time.