A few years ago, I found myself in a workshop preparing for a major IT procurement process. Within minutes, the flip chart was filling up with requirements:

“The software must have an Excel export,”
“We need a dashboard,”
“The solution must work on mobile devices,”
“AI support would also be important,”
“We need a mobile app.”

After about an hour, several flip chart pages were filled. Every department had contributed its wishes. Procurement added contract-relevant requirements, and IT was already discussing potential vendors and initial implementation considerations.

I asked only one question:

“Why do you actually need an Excel export?”

The room fell silent. After a moment of reflection, someone finally answered:
“Actually, we just want to share the evaluations easily with other departments.”

At that moment, the discussion shifted. Suddenly, it wasn’t about Excel exports anymore. It was about making information easier to share. For the first time, we weren’t talking about features—we were talking about the actual need.

Whether this goal was later achieved through an Excel export, a dashboard, an automated report, or an interface no longer mattered.

The Real Problem

I encounter this situation surprisingly often. Many requirements describe a solution before the actual problem has been sufficiently understood.

A dashboard is not a requirement. A mobile app is not a requirement. Even artificial intelligence is not a requirement—at least not initially.

They are all possible answers to a question that is often not even asked:

What problem do we want to solve?

AI Is a Prime Example

This phenomenon is especially clear in the context of artificial intelligence. In many projects, I hear statements like:

“We need AI-powered search.”
“The new solution should have an intelligent chatbot.”
“The software must support generative AI.”
“The AI should analyze the data.”

My usual response is: “What problem is the AI supposed to solve?”

Depending on the answer, the technical solution may look entirely different.

AI is not a requirement.
AI is a possible solution.

Sometimes it’s the best solution. Sometimes, however, simpler, cheaper, or more robust alternatives exist. That’s why technology should not come first—benefit should.

Good Requirements Don’t Start with Features

The longer I work on projects, the more convinced I become:
A good requirement first describes the desired benefit. The feature comes later.

Only when the benefit is clear can different solution paths be evaluated.

Perhaps the Excel export or the intelligent chatbot is indeed the best solution. Perhaps not. What matters, however, is that we make this decision consciously—not unconsciously by predetermining it in our requirements.

Why This Mindset Is Well-Founded

Interestingly, research has been addressing this question for decades.

Barry Boehm’s Value-Based Software Engineering places stakeholder value at the center of software projects.

Goal-Oriented Requirements Engineering derives requirements from overarching goals—not the other way around.

As early as the late 1990s, Karlsson and Ryan demonstrated that requirements should be evaluated not only by effort but also by expected value.

All these approaches share the same idea:

Not every feature automatically creates value.

Every additional feature incurs effort and cost: development, testing, documentation, training, and later maintenance. A feature is only meaningful if it contributes to project success.

Therefore, every requirement should answer a simple question:
What specific benefit does it create?

If no convincing answer can be given, it’s worth taking a second look at that requirement.

What Does This Mean for Tenders?

A tender process should describe what goal is to be achieved as precisely as possible. It should only specify a concrete solution where absolutely necessary.

The earlier we commit to a particular feature, the smaller the solution space becomes. And sometimes, we rule out the very innovation we were seeking.

My Experience

In many projects, I now ask a simple question:

“What actually happens if we don’t have this feature?”

Only when a convincing answer is given does a desired feature become a truly justified requirement.

Often, it turns out that a feature hides a completely different goal.

And that’s where good business analysis and structured requirements engineering begin.

Conclusion

Software doesn’t succeed because it has many features.

That’s why, in future workshops, I’ll likely ask less:

“What features do we need?”

And more:
“What problem do we actually want to solve?”

And then:
“What benefit do we want to achieve?”

Because those who confuse features with benefits often buy the wrong software.

Further Reading

• Barry Boehm: Value-Based Software Engineering, ACM SIGSOFT Software Engineering Notes, 2003.
• Karlsson, J.; Ryan, K.: A Cost-Value Approach for Prioritizing Requirements, IEEE Software, 1997.
• Ellis-Braithwaite, M.: Goal-Oriented Requirements Engineering and the Contribution of Requirements to Business Goals, University of Toronto, 2013.
• IREB e.V.: CPRE Foundation Level – Requirements Engineering Syllabus (chapters on stakeholders, goals, and solution-neutral requirements).
• HM Treasury: The Green Book – Appraisal and Evaluation in Central Government

The new EU Directive NIS 2 is changing the rules of the game for IT security in Europe. Since October 2024, member states must have implemented it into national law. It obliges companies and authorities to systematically organize their cyber security – with clear processes, reporting obligations, and responsibility at the management level.

For many organizations, this is akin to a turning point: what was previously ‘best practice’ is now mandatory. And many more institutions are affected than before – from energy suppliers to municipal utilities and hospitals to IT service providers and local authorities.

What is behind NIS 2?

NIS 2 stands for “Network and Information Security Directive 2”. It replaces the first NIS Directive from 2016 and pursues a clear goal: 

a high, uniform level of cybersecurity across the entire EU.

New is the significantly expanded scope and the binding liability for management. NIS 2 is intended to ensure that not only technical defense measures are in place, but also that governance, risk management, and supply chain control are practiced.

The directive has been in force since January 16, 2023.

• In Germany, the NIS2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG) was passed in the summer of 2025.
• In Austria, the amendment to the NIS Act (NISG) was delayed; a new version is being prepared for 2025.

Even if national laws are still in progress, the requirements are fixed. Organizations that act now secure valuable time and a compliance advantage.

What does NIS 2 specifically require?

The core of the directive consists of ten mandatory security and organizational measures that all affected institutions must implement:

1. Risk analysis & security strategy
2. Incident handling – detection, response, recovery
3. Business continuity & backup management
4. Supply chain security
5. Secure development & maintenance (including vulnerability management)
6. Effectiveness evaluation of security measures
7. Cyber hygiene & training
8. Access and identity management
9. Cryptography & encryption policies
10. Policies for system and network security

In addition, there is a strict reporting obligation in the event of security incidents, the so-called 24/72/30 rule:

• Within 24 hours: “Early Warning” to authority or CSIRT
• Within 72 hours: Incident report with initial assessment
• No later than 30 days: Final or progress report

Management responsibility

One of the most serious changes affects the management. According to Article 20 of NIS 2, management must:

• approve and monitor security risk management,
• introduce appropriate measures, and
• regularly participate in training.

In case of violations, severe fines threaten – and personal liability of the management level:

• Essential Entities: up to 10 million € or 2% of global annual turnover
• Important Entities: up to 7 million € or 1.4% of turnover

This makes cybersecurity a matter for the boss – comparable to occupational safety or data protection.

Am I affected? – The quick self-check

1. Active in one of the 18 sectors according to NIS 2?
2. More than 50 employees or > 10 million € turnover?
3. Do I provide critical services for citizens or the economy?
4. Am I a supplier to an affected company or authority?
5. Do I have documented processes for risk and incident management?

If you answer yes to any of these questions, your organization is most likely within the scope of NIS 2.

What to do now

1. Conduct a gap analysis: Which requirements are already met, which are missing?
2. Adapt governance: roles, responsibilities, approval processes.
3. Create an incident playbook: clear reporting paths and escalation levels.
4. Review supplier contracts: anchor cybersecurity requirements.
5. Train management & employees: raise awareness, avoid liability.

Conclusion

NIS 2 is much more than a regulatory issue – it is an impulse for professional security and risk management. Organizations that start today gain not only legal certainty but also trust and resilience in an increasingly digital world.

NIS 2 is here to stay – those who start now have an advantage

Your first step

NIS-2 Readiness Check

Our experts analyze the maturity level of your organization – concrete, practical, and confidential.

Project managers often find themselves at an interface between constantly changing market requirements and the technical challenges faced by developer teams. While the agile model promises flexibility and adaptability, requirements engineering (RE) offers structured clarity. But how do project managers achieve a balance between these two approaches to ensure efficient, successful project management? MODEL-BASED REQUIREMENTS… Continue Reading Agile methods and Requirements Engineering: A guide for Project Managers

Requirements analysts will find it worth their while to make a quick detour in the direction of UX/UI, since user interfaces are what essentially determine a solution’s acceptance.

No, usability engineering is not concerned with making graphical interfaces pretty. Yes, requirements engineers, especially those involved with applications for end customers or applications with a large number of internal users, should always be concerned with usability engineering.

UX Challenges in Requirements Management

An increasingly growing challenge for requirements engineers is to functionally describe applications which not only claim to be correct and efficient, but also easy to learn (ideally no initial training at all is required), clear and understandable to users, fault-tolerant, not just for bad input but also for incorrect use, and finally attractive and helpful to users as a whole.

A pretty user interface is just one aspect involved in the understandability, operability, clarity, learnability and attractiveness of a system. Although the design of this aspect is the responsibility of the user interface designer, the process is actually carried out using traceable methods, and also requires taste and a touch of artistic design throughout.

The Solution: Usability Engineering

However, usability engineering is concerned with deriving and optimizing a system’s functional and non-functional characteristics by examining the user’s overall environment. Another aspect is to model the entire user journey and include it in system design. For example, a web shop user’s experience with that system doesn’t end when he places an order, but continues until he receives the package or support for his complaints.

In requirements engineering, we set ourselves apart (completely intentionally) from the environment not directly associated with the system, which we already learned already over the course of creating context diagrams. This allows us, but sometimes only with difficulty, to understand the user’s motives behind individual activities. In addition, requirements engineering does not examine user satisfaction over the entire use life cycle (nor beyond system limits).

Methods of requirements engineering and usability engineering complement each other perfectly in this area, and create real added value for many tasks. Spirit in Projects’ training portfolio offers basic and advanced courses for both directions, so you can selectively expand your own skill set.

Learn more about our trainings on UX/UI: