For some time, I have been involved in creating requirements, mostly for the procurement of software applications. And in this time, I have been struggling with the difference between functional and non-functional requirements.

One thought is that functional requirements prescribe product features, what the user requires. The non-functional requirements describe prescribe the product properties, what the user expects. This somewhat strange combination seems to disregard the concept of the combination of expectancy and requirement.

Another thought is that non-functional requirements specify the product’s quality characteristics or quality attributes of the whole system. The “-illities” like stability and usability, observable at run-time and maintainability, and scalability. Functional requirements are always mandatory but prescribe only parts on the component level. As if, highly unlikely, a user does not require quality and is able to think of the components in advance.

The extended ISO 9126 model clearly defines 32 quality attributes. It is advisable to use this standard when re-inventing the wheel of -illities. Just beware of the confusing “Functionality” category of this standard.

Another standard is ISO 25010. TMAP, Sogeti’s body of knowledge for quality engineering, makes extensive use, as described in their wiki.

A different perspective

However, there is another way of looking at this matter. This way of looking is based on an essential concept that differentiates between the function of a thing and the construction of a thing.

The function of a thing is what it does for the user. The construction of a thing is how it is constructed, how it is made.

The Τ-theory, as part of the philosophical foundations of the Enterprise Engineering theories, provides the basis for understanding the notion of systems and models, and clarifies the distinction between function and construction (Dietz and Mulder, 2020). It shows three elements: Teleology – Affordance – Ontology. Hence its name TAO. Teleology is the subjective perspective, explaining why something is, the cause of its existence as experienced by the subject. Ontology is the objective perspective, using its properties to describe what something is.

Affordance is originally described as what the environment offers to the animal (Gibson, 2014, p. 120), a passive subject-object relation. This was broadened by Dietz and Mulder in its meaning for enterprises.

A function is the intended subset of affordance that delivers a need for a stakeholder. The distinction between the function and the construction is represented in their respective models: the functional model and the constructional model, respectively referred to as the black-box model and the white-box model.

Using ArchiMate, I created a map (Nouwens, 2015) that shows the relation between several interdependent levels of function and construction models.

With this map we can and should distinguish three categories of requirements:

1. Functional requirements, prescribing what the thing delivers as a service and for who.
2. Constructional requirements, prescribing how the thing is constructed and what information it uses.
3. Management requirements, prescribing how the thing is managed.

Each of these three category is applicable to the Business, Application and Infrastructure elements, together creating nine groups of requirements.

1. Functional business requirements
2. Constructional business requirements
3. Management business requirements
4. Functional application requirements
5. Constructional application requirements
6. Management application requirements
7. Functional Infrastructure requirements
8. Constructional Infrastructure requirements
9. Management Infrastructure requirements

As architects we can directly support these requirements with nine groups of architecture principles that are related to the business, application and infrastructure goals or strategies.

Is this practical?

Nine groups, I hear you think, is this practical? Yes, because most of the categories are completely irrelevant in most sourcing scenarios. When procuring a SaaS product, the three infrastructure categories are out-of-scope. This is not your problem. The application management and application construction requirements are also out-of-scope. However, the application function is very relevant, this is what you need to deliver as a service to the business. Hence, these are very relevant requirements.
The map also shows the need for creating business construction requirements. These describe (or prescribe) how the business processes work and how they are constructed. Who are the stakeholders that are relevant in these processes. This is tremendously advantageous for the suppliers that deliver the SaaS application as it gives insight of what services their application should deliver to whom, in what business. Essential for being able to determine if your application may fit the expectations of the users.

So, do requirements have a function? Yes, you are delivering value to an organisation when you can support your stakeholders with insights in what categories of requirements to think of, and what requirements to safely ignore.

References

Dietz, J.L., Mulder, H.B.F. (2020) Enterprise Ontology: A Human-Centric Approach to Understanding the Essence of Organisation. The Enterprise Engineering Series, Springer International Publishing, Cham.
https://doi.org/10.1007/978-3-030-38854-6

Gibson, J.J. (2014) The Ecological Approach to Visual Perception. Psychology Press
https://doi.org/10.4324/9781315740218

Nouwens, H. (2015) Identifying and mitigating root causes related to the strategic sourcing process within the context of EU procurement guidelines using concepts of enterprise governance and enterprise engineering.
https://doi.org/10.5281/zenodo.5213936

Van Zeist B, Hendriks P, Paulussen R (1996) Kwaliteit van softwareprodukten: Praktijkervaringen met een kwaliteitsmodel. Sdu, The Hague. ISBN-10: 9026724306