This is how you get your requirements management under control!

Are you losing track of the status of your requirements and struggling with an unstructured backlog? Are your project participants drowning in ticket chaos? Nobody feels responsible? As a result, this always leads to unnecessary expenditure and in the end there is both a failed project and a dissatisfied project team. It doesn’t have to be! In this blog post, we will show you how to plan and set up an efficient product development process from the point of view of a UI conceptionist. The early, active involvement of the specialist departments ensures a high level of acceptance and strong identification with the product.

What are the biggest challenges in requirements management?

Perhaps you are familiar with the following statements in the context of the requirements survey:

Unfortunately, we hear these statements very often in our daily work. They are typical symptoms that the customer has not yet established one product development process gives. Roles and responsibilities are often not defined at all or not clearly defined. Many customers also do not have a common understanding of the form and granularity in which requirements are collected.

Departments would like to start development as soon as possible. Developers, on the other hand, want precisely formulated requirements in the form of user stories in advance. It is therefore important to work together at the beginning of a project, the role and responsibilities of the requirements manager and to define a clear and unambiguous product development process.

What are the main tasks in requirements management?

The art of requirements management is to identify, document, validate and manage the entire process in a clean manner.

Detection: For the determination of the requirements, the following determination techniques have proven particularly useful for us in a large number of projects: design thinking, interviews, questionnaires, workshops, (field) observation, apprenticing, brainstorming, storyboards and user journeys.

Documentation: We are happy to document the requirements raised in the form of user stories. They receive a unique ID for identification, a title, a short description in the form of a sentence template, a priority and acceptance criteria for the acceptance of the user stories in the later test.

When creating user stories, pay attention to the following dos and don’ts:

Validation: During the recording of requirements, validations are carried out continuously with the department and development. Here, the existing requirements are reviewed again by all stakeholders and coordinated together before they are passed on to development.

Backlog: The backlog contains all recorded requirements. These are later transferred into corresponding sprint backlogs as part of sprint planning, prioritized and, after validation, sent to development. In addition, the development team derives concrete tasks for itself.

Which roles are involved in requirements management and how do they interact?

During the product development process, different roles contribute at different times To capture and validate product requirements as comprehensively as possible. In particular, the “translation” of the requirements of the department into a “language” that is clear and understandable for development is to be emphasized.

In principle, the following positions are to be filled in the role model: requirements engineer, development and department. These must be present in every project as a minimum staffing. Depending on the complexity of the project, additional roles may be required. Since the focus of this blog post is on requirements management, the Scrum roles specific to agile development such as scrum master and product owner or general roles such as project manager and tester are not described in detail. For a smooth process flow however, these roles are essential. The process described below can only be successfully implemented if everyone involved in the project completely fulfills the tasks specific to their role.

Presentation of an efficient requirements management process

Based on a large number of completed projects, the following process has proven itself for our requirements management:

The starting point of the process is formed by the department defined requirements (user stories). In the next step, these will be converted into meaningful Mockups transferred, which are iteratively coordinated with the department up to the highest possible level of detail. Subsequently, the mockups together with the user stories and a Data catalog on the part of development – but without a department validated their technical feasibility. After successful approval by the development team, mockups, data catalog and requirements (user stories) are created in a joint appointment validated between requirements management and the department. Subsequently, the Customized user stories, if necessary. The validated requirements are now handed over to the development team, which independently makes specific specifications development tasks (Tasks) derives. Finally, the implemented requirements are evaluated by the department based on the acceptance criteria tested and removed.

Dealing with errors (bug management) can also be optimally integrated into this process, but is not considered in detail in this blog post.

Creation, structuring and management of requirements

The first step in practical use is to Epics, Features und User Stories in a professional requirements management tool such as Microsoft Azure DevOps, GitLab or Jira.

This forms the highest hierarchical level of all possible structural elements Epic. This can contain one or more features and/or user stories. A Feature represents the second highest level and is also used to structure user stories. The actual requirements are in the form of User Stories recorded. Here, the individual functions are described in detail from a user’s point of view and additionally expanded with “smart” acceptance criteria. The aim is that the requirements are immediately accessible to everyone involved. Tasks are concrete tasks that are defined and processed independently by the development team.

subsequently become Mockups created using a mockup tool suitable for the purpose and taking into account the relevant target group. The user stories already defined are subsequently linked to the mockups. For information on how to easily create professional mockups, see our blog post SAP Fiori: Create high-fidelity mockups in a snap with Figma.

In the third step, a Data catalog created to match the mockups. The data catalog contains all the information that the development team needs to implement the required functionalities.

The following attributes are recorded and coordinated for each individual interface element by the conception and development team:

Please note that this is just a small excerpt of possible attributes to clarify the basic structure. In a real project, at the beginning of the requirements analysis, we work with you to select the attributes that are suitable for your application from our detailed catalogue.

The data catalog is also linked to the existing user stories so that these, together with the mockups and the acceptance criteria previously defined and agreed by the entire project team, represent the “single point of truth”.

Conclusion

Good requirements management ensures that a product is ultimately developed that offers a high level of user experience and usability for the end user – this avoids the classic “ivory tower development”. In addition, the philosophy of “Fail early, fail often!” supports the detection of errors at a very early stage of the project, where they can still be corrected with little financial effort. As was made clear in the article, the sole use of a tool is not enough to address possible problems related to requirements management. Rather, a comprehensive, functioning and practical process is required.

In order to achieve the procedure described, we have developed a method as part of intensive analyzes and workshops and in close cooperation with development and specialist departments to compile all the information required from the UI conception point of view and into the structural elements made available by the various requirement tools to embed The role of the requirements engineer is performed by specially qualified UI consultants, who always take the user-centric perspective into account. We would be happy to demonstrate the procedure to you in a personal meeting or in the form of a workshop.

Was this article helpful to you? Or do you have further questions about SAP HCM? Write us a comment or give us a call.