68% of IT Projects Fail Due to Requirements — Here's How to Do Better

The Problem Everyone Knows

A new software project kicks off. The vendor asks: "What should the system do?"

The answer usually sounds like this:

"The system should be able to process invoices." "It needs to somehow communicate with the ERP." "Users should see everything important at a glance."

Sounds reasonable at first. But what does "process" mean? Automatically capture, verify, approve, archive? Who exactly are "the users"? What is "everything important"?

Such requirements end up in the specification. And 6 months later in a dispute.

Why Bad Requirements Are So Expensive

The numbers are clear.

According to the Standish Group Chaos Report, 68% of all IT projects fail — and the most common reason isn't technical problems, but unclear, incomplete, or contradictory requirements.

What happens:

• Developers interpret requirements differently — wrong implementations emerge
• Change requests come late when the architecture is already in place — costs explode
• Acceptance fails because it wasn't clear what "done" means

A study by IBM Systems Sciences Institute shows: A defect that costs €1 in the requirements phase costs €6 in development and up to €100 in maintenance.

The SOPHIST Sentence Template: A Proven Framework

Prof. Chris Rupp and her team at SOPHIST developed a framework that solves exactly this problem. The method comes from the standard work "Requirements Engineering and Management" and is used in companies worldwide.

The core idea: Every requirement follows a defined sentence structure. No prose, no room for interpretation, no "somehow" formulations.

Three Types of Requirements

Type 1 — Autonomous System Activity: The system acts independently, without user interaction.

"The system MUST send the supervisor a notification via email."

Type 2 — User Interaction: The system provides a function to a user.

"The system MUST provide the clerk with the ability to upload an incoming invoice in PDF format."

Type 3 — Interface Requirement: The system communicates with an external system.

"The system MUST be able to receive master data from the ERP system."

Three Levels of Obligation

Each requirement has a clear legal obligation:

• MUST — Legally binding. Without this function, the system will not be accepted.
• SHOULD — Strongly recommended. Will be implemented if economically feasible.
• WILL — Planned for the future. Not in current scope, but already documented.

Conditions Make Requirements Precise

Optionally, each requirement can be tied to a condition:

• If (logical): "If a document is older than 12 months, the system SHOULD automatically archive this document."
• When (temporal): "When the user grants approval, the system MUST send the supervisor a notification."
• After / While — for sequential or parallel dependencies.

Why a Structured Approach Makes the Difference

Correctly defined and documented requirements enable the team to establish clear project goals and scope — preventing misunderstandings from surfacing only during development or testing.

Benefits of a structured approach:

• Project planning: Stakeholders are aligned from day 1. No "But that's not what I meant."
• Development efficiency: Developers know exactly what the system should deliver.
• Testability: Every requirement can be directly converted into a test case.
• Change management: When requirements change, it's clearly documented what changed and why.

A great example of complex requirements management is our ISMS App case study, where structured requirements made the difference between success and failure.

The 5 Most Common Mistakes in Software Requirements

From over 60 consulting projects, we see the same patterns again and again:

1. Too vague "The system should be user-friendly." — What does that mean specifically? For whom? In what context?

2. Multiple requirements in one sentence "The system must capture, verify, and approve invoices." — These are 3 requirements with potentially 3 different obligation levels.

3. No obligation level defined Without MUST/SHOULD/WILL, it's unclear during acceptance what is contractually owed.

4. Technical solution instead of requirement "The system must implement a REST API with OAuth 2.0." — Better: "The system MUST be able to securely transfer data to external systems."

5. No user reference Who uses the function? What is their role? Type 2 of the sentence template forces exactly this clarity.

The Requirements Builder: The Tool for This

We built an interactive Requirements Builder based on the SOPHIST sentence template. It guides you through 5 steps to create professional requirements — determine process word, choose type, set obligation level, add objects, add conditions.

All requirements can be exported as CSV, Excel, or PDF. No login, no restrictions.

For complex requirements across interconnected systems, find more inspiration in our product configurator case study. And understanding end-to-end processes helps you write better requirements too.