The best process in requirements management

There are many factors that determine the success or failure of a project: project start, project planning and execution, employee availability, management commitment, and: requirements management. It is a key discipline in the development of software and systems. However, it is not about an efficient way of managing requirements, but about the best possible approach to identifying requirements – often referred to as requirements engineering. How does requirements engineering work or, in other words, what is the best process in requirements management?

The definition of the system context

With the system context, you define the areas of a system for which you collect requirements. If the system context is not completely defined, the requirements will also remain incomplete. For a system to be developed, it is important to consider the system context, because by defining the system and system boundary, as well as the relevant and irrelevant system environment, you determine which aspects are to be taken into account in a development. Laws, standards and guidelines must also be taken into account when assessing context boundaries. However, all information is not always available at the start of a project, or management finds it difficult to make decisions about the scope of development. This creates grey areas that you should eliminate as early as possible in order to avoid problems, efforts and costs in the course of the project.

The stakeholder management

Identifying, analysing and communicating – these are the three essential activities in stakeholder management. Stakeholders are persons, groups and organisations who are directly or indirectly affected by the activities of a company or who have a concrete interest in these activities. Stakeholder identification is the first step in stakeholder management. It aims to identify all organisations and individuals who are directly or indirectly affected by the software or system development or who have a concrete interest in the results of the development. The result should be a list of all stakeholders. Based on this list, the stakeholder analysis identifies the most important stakeholders, their goals, motives and attitudes.

Why is this important? Requirements concretise objectives or requirements can be derived from the objectives of the stakeholders and, if necessary, grey areas in the system context can also be eliminated. However, this is not the end of stakeholder management, because regular communication with stakeholders is also very important. Stakeholders change their opinions, goals shift and this results in new priorities and often new requirements. Stakeholder communication provides you with structured and early feedback and opinions that you can use to avoid conflicts.

The use of scenarios

A scenario is the description of a possible sequence of events. Scenarios can be classified according to content and context. There are five different content categories:

• operational scenario
• failure scenario
• performance scenario
• refinement scenario
• learning scenario

And there are three categories in the context classification:

• internal system scenario
• interaction scenario
• organisational scenario

The context classification clearly differentiates scenarios from use cases in terms of content. An internal system scenario describes, for example, the interaction of different components within a system, without considering the context in which the system is embedded. The content categories, on the other hand, do not focus on the context, but focus on different perspectives of the descriptions that go beyond the naming of events. Thus, a scenario can be assigned to several categories, e.g. a functional scenario and an explanatory scenario. Why are scenarios interesting for requirements management? The advantage lies in the different perspectives that can be gained from scenarios. They help in the development of goals, in the identification of stakeholders and also in the definition of system boundaries. Requirements can be described by scenarios and requirements and goals can be derived from scenarios. Overall, working with scenarios, stakeholders, goals and requirements is very interlocked and iterative.

The determination of requirements

Once you have defined the system context and analysed the stakeholders, you need to identify the right requirements. Various concepts and techniques can help here. The implementation of requirements workshops, for example, is an effective way to develop requirements. In the course of the workshops, requirements can be derived from objectives and scenarios, refined and evaluated, and a consensus can be reached among the stakeholders. Creativity techniques such as brainstorming, brainwriting and brain dumping can be used to identify further requirements. If stakeholders are not familiar with requirements workshops or cannot or do not want to spend time on them, observation techniques such as field observation, apprenticing and contextual inquiry, or survey techniques such as questionnaires, interviews and self-writing can help.

In addition, there are many other options for determining requirements such as working with personas and use cases, the use of system archaeology and perspective-based reading, or the use of prototypes. In fact, it is not so easy in reality to identify the right requirements. And unfortunately, the question of the best concepts and techniques for determining the relevant requirements cannot be answered in general. It is probably not a good idea to brainstorm with unmotivated stakeholders or invite them to requirements workshops. Here, for example, field observation could provide significantly better insights.

Requirements and architecture

Organisations are often faced with the question of how to proceed when developing a new system. Requirements and the architecture of a system are highly interdependent – should requirements be captured first or the software architecture designed first? Requirements change frequently, new technologies appear and earlier design decisions have to be reconsidered. Here the Twin Peaks Model offers support. At the beginning, it recommends designing the most important requirements for a system rudimentarily in order to develop a prototype or a Minimum Viable Product (MVP) based on them. Now giving stakeholders the opportunity to express their opinions and impressions about a prototype helps organisations better understand requirements. The new insights can be used to revise the prototype – creating a link between requirements and architecture with parallel, iterative development.

Verify and document requirements

The most important task in requirements management or requirements engineering is the determination of requirements. It is essential to identify the requirements that are technically, financially and also personally feasible. Of course, the requirements should be complete. And without contradiction. In order to guarantee all this, the quality of the requirements must be verified. The more requirements are to be implemented, the more information must be examined. And to do this, the requirements must be documented. Ideally, requirements are managed with a fixed structure and form. This makes it easy to check whether all the necessary information is always available for a requirement.

The documentation often amounts to a customer specification, a requirement specification or a functional specification document. 15% of all software errors are delivered and the majority of these errors are already contained in the specification. Customer requirements are misunderstood, use cases are described incompletely and terms are interpreted differently. Of course, these problems do not only affect specifications but also architectural designs, test cases, all written intermediate results of the software development and the source code. It is therefore important to check the specification – and to do so several times if necessary. Of course, checking a specification causes effort, but it is often worth it compared to the effort involved in eliminating delivered software and system errors.

Bottom line

Dealing with requirements is an essential success factor in projects. The procedure with the definition of the system context, the analysis of stakeholders and their goals, the use of scenarios, the determination of requirements with different concepts and techniques, the parallelisation of system design and requirements collection, as well as the verification and documentation of requirements, describes the optimal process in requirements management.

Often in reality, not all important stakeholders are always available for queries, the mountain of requirements is too large (here the elimination of requirements could help) or the estimation of user stories with story points causes problems. With the exception of the system context, which – if possible – should not be changed in the course of a project, it is advisable to carry out all steps continuously in the project. This allows changes to be identified as early as possible, new priorities to be defined, and the consistency and coherence of requirements to be permanently ensured.

Notes:

Michael Schenkel has published additional posts in the t2informatik Blog, including

t2informatik develops and modernises software as a service provider. Click here to learn more.