What are functional requirements?

Effective change management requires visible and consistent leadership. Employees look to their managers to gauge how serious a change is. When managers actively champion the change and lead by example, it builds trust and increases employees’ willingness to adapt. In this context, strong leadership means:

• Communicate clearly about the reasons for the change
• Demonstrate consistent behavior that is appropriate for the new situation
• Being engaged and approachable during the change process
• Taking ownership of both successes and challenges

These are the features that make a system “work.” Without these requirements, there simply is no product.

What are non-functional requirements?

Non-functional requirements (NFRs) describe how well a system should perform. They are not about what a system does, but about the quality with which it does so. Examples include:

• Performance (speed and response time)
• Security (security and access control)
• Availability (uptime and continuity)
• User-friendliness

Although these requirements are less obvious, they have a major impact on how a system is perceived. An application may be functionally flawless, but if it is slow, insecure, or difficult to use, the user will notice it immediately.

Why non-functional requirements are often underestimated

In many projects, the focus is on delivering functionality. Especially when deadlines and budgets are tight, features take priority and quality considerations are pushed to the back burner. In practice, this leads to familiar problems:

• Systems that slow down or fail under load
• Solutions that do not meet security requirements after the fact
• Low adoption due to a poor user experience

Non-functional requirements are therefore not just “nice to have,” but essential for a system that works well and is future-proof.

The interplay between the two

Functional and non-functional requirements cannot be viewed in isolation from one another. They reinforce each other and are both necessary to arrive at a successful solution. A common analogy is that of a house:

• Functional requirements determine the structure (walls, doors, windows)
• Non-functional requirements determine comfort (insulation, ventilation, livability)

There’s no such thing as a house without structure, but no one wants a house without comfort. The same goes for IT systems.

The Importance of Measurability

A major challenge with non-functional requirements is that they often remain too abstract. Terms like “fast” or “secure” are not sufficient on their own. The difference lies in making them more concrete:

1. “The system has to be fast” doesn’t really say much
2. “The system responds within 2 seconds with 1,000 concurrent users” is indeed useful

By making NFRs measurable:

• Will they be assessable?
• Can you actively influence it?
• And avoid arguments later on