Englische BlogsRequirements Engineering eng

Requirement Categories – Why they are useful?

When I reflect the current state of requirements engineering, then I recognize the following:

  1. There are a number of good tools for documenting requirements
  2. There are good and established methods for creating natural language requirements
  3. There are still relatively few standardized methods to properly handle recurring categories of requirements

In this blog I want to highlight the last point of the categorization of requirements.
In the following figure, I try to capture the question graphically:

Kategorien-Requirements_eng

The illustration shows the relationship between the 3 categories of requirements:
Functional, performance, non-functional (X-axis) and the two requirements levels: System and Software (Y-axis).

Category: Functional Requirements

If we consider functional requirements, they will be prepared in accordance with the definition of system boundaries and the system interfaces with the proven methods for creating natural language requirements and recognized in a suitable tool.

A first challenge is in practice then the completion of requirements. The creation of models here can help to achieve the goal. Since the creation of a model is also associated with considerable effort, this way is not possible and useful in many projects. Instead reviews are usually carried out to ensure completeness of requirements to achieve.

The next step will be that the system requirements are broken into software requirements. This is often a major challenge. It is to recommend a ratio of 1 (System Requirements) for 3 to 7 (Software Requirements). In addition, key architectural decisions (implicitly or explicitly) are to be made at this point. Therefore, it is important to design the parallel system and software architecture. In practice, this part of the requirements engineering is often given too little time. From my experience, this is due to the fact that the complexity of this task is misjudged.

The Software Requirements resulting from this process can be written using the best practices and the available tooling. There are relatively few problems, although it should not be forgotten that there are still many projects in which the formulation of requirements should be significantly improvement.

Category: Performance Requirements

Performance requirements are often not considered independently, but associated with the (often very different) non-functional requirements. From my perspective, this is usually already the first cause that the challenges in the Performance Requirements are not made sufficiently aware.

Repeatedly I see Requirements on System and Software Level, which defines the behavior with respect to timing aspects. However, very often conditions under which these requirements have to be met are inaccurate, or not defined.

Another complex challenge is the break-down of system performance requirements in software and hardware performance requirements. This is significantly more complicated than purely functional requirements. The main reason for this is the complexity of the interaction between hardware and software. Especially in new technological projects, at the time of the Requirements creation, the detailed knowledge required is not available. If people are not aware of this problem, they create software requirements, which are technically incorrect or irrelevant. In the subsequent test phase, such requirements then produce disproportionately large verification effort or a proof is not possible technically.

In my view, many performance requirements would be much better defined if the described challenge would be considered proactively.

Category: Non-Functional Requirements

I defined this category here for all requirements which do not fall into either functional or performance requirements. Further (sub) categories are required, to handle the issue of non-functional requirements properly: Process- or Contract requirements are to be treated differently compared to Architecture Requirements or Useability Requirements. The consideration of these issues will be discussed in future blogs.

I’ll be glad to help you also with any specific questions about your project . Send an email to: martin.heininger [at] heicon-ulm.de
An overview of the services can also be found on the HEICON Homepage.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.