According to my observation requirements engineering in general doesn’t get the appropriate attention. If you consider software and/or hardware projects which failed, you can see that often a missing or incorrect requirements engineering is one of the major causes. If we go further and consider the types of possible requirements, then you can make a classification into functional and non-functional requirements as a first step. In general, the number of functional requirements, will be significantly higher than the number of non-functional requirements.
Usually, functional requirements are much more homogeneous than non-functional requirements. As the name implies, the functional requirements describe the function of the system to be developed. The validation of the correct implementation can usually determine consistently over a test. After a first version of architecture for the system is developed, a quite good decomposition for functional requirements can be performed.

These points do usually not apply for non-functional requirements. Often it is not possible to decompose these requirements. In many cases they are not verifiable by a test. Although their number is often lower than the functional requirements, they are much more “responsible” for the failure of projects. These are reasons to occupy oneself in more detail with the following blog.

Categories of Non–FunctionalRequirements

A major problems of non-functional requirements in my view, is that to many requirements are summarized under this term. A lot of these requirements need a completely separate handling. This separate treatment usually does not take place and the problems get larger. In the picture above shows categories of requirements which are traditionally often grouped under the umbrella term “Non-Functional Requirements”.

In the following figure I put these categories of requirements in an order. On the left you find categories of requirements which contain a high functional component or functional aspects. Therefore Performance/Timing Requirements and Interface Requirements are often not considered as “real” Non-Functional Requirements. On the other side of the scale, contract and process requirements have only a very indirect or no impact on the functionality. All other categories are somewhere in between.

From this point of view an uniform treatment of these requirements is not effective. For example, the requirements which are strongly associated with the functionality (left side) can usually be tested. For Requirements on the right side testing is not an effective verification method. A lot of things on the right side can often only be verified by “Minutes of Meetings” or something similar. In the following chapter additional differences are discussed.

Why are non-functional requirements often responsible if project are failing?

The correct implementation of functional requirements is in most of the cases in the hands of a development team or an individual developer. Due to the technical know-how, there is usually no one outside of this group who can take or wants to take significantly influence on this part of the project. Even in this case, the issues are often unique and therefore quickly and easily to solve. Furthermore, the development team usually has a great interest (ambition of the engineer) to implement the requirements correctly.

The exception are the “classic” research projects. These projects are designed to ensure that technological and operational issues are fully open. In such projects, the use of these types of the discussed requirements engineering is not useful. The handling of non-functional requirements, is significantly different. E.g. more stakeholders are present in non-functional requirements engineering. A good example are interface requirements. Here it is in the nature of it that several parties have to agree on a common solution and technical implementation. This reconciliation processes can be complex, expensive and time-consuming.

Contract- and process requirements require the inclusion of the management. In the resolution of open issues with such requirements political interests may be important. Therefore, it is often difficult to find and agree on a solution.
Performance/timing requirements represent a real technological challenge. A full and correct description in form of requirements in this area is very ambitious. In addition, decomposition in lower levels only is possible if there is available a lot of technical and detailed knowledge about the system.

The technical complexity in this area is often is very difficult to predict at the beginning of a project. But it has to be understood that this fact also increases the risk of technical failure in the project. We have discussed now completely different kind of requirements. However, very often all these requirements are forced to be treated in the same manner, as they are all grouped together as non-functional requirements. In contrast to functional requirements there are a lot more, different and complex challenges. Therefore, it is more likely that a project fails because of non-functional requirements than because of functional requirements.

Conclusion:

1. The usually smaller number of non-functional requirements in contrast to functional requirements and
2. The simplification ofthe problemby groupingcompletely differentrequirementsunder oneterm, and
3. The underestimation of thecomplexity of thehiddenissues behind non-functional requirements

are main reasons, why non-functional requirements can be made responsible if a project fails. The proper and conscious subdivision of the non-functional requirements is an important first step to control the problem. As a second step a definition of an appropriate procedure for each identified category increases significantly the probability that the project succeeds.

Are you ready for a status workshop, to analyse improvement potentials in your requirement engineering, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.