Enterprise Requirements Series — Article 8
This article explains why testability is one of the defining characteristics of a good software requirement. It shows how subjective language creates unverifiable expectations and why requirements must include measurable acceptance criteria. The article positions testing as an activity that begins during requirements engineering, not after development, and explains how verifiable requirements protect stakeholders, developers, testers, and auditors.
Building Better Software by Engineering Better Decisions
One sentence appears in requirements documents more often than it should:
The system shall be user-friendly.
It sounds reasonable.
It also raises an obvious question.
How will anyone prove it?
Requirements are not wishes.
They are statements of expected behavior that must be verified before software can be accepted.
If no one can determine objectively whether a requirement has been satisfied, it is not yet a requirement.
It is an expectation.
There is an important difference.
Good Requirements Come with Evidence
Imagine reading the following requirement:
The application shall process transactions quickly.
Now imagine asking three people whether the finished system satisfies that requirement.
A business executive says yes.
A developer says yes.
A customer says no.
Who is correct?
Without measurable criteria, no one knows.
The requirement failed because it never defined success.
A better requirement might state:
The application shall process 95 percent of customer transactions within two seconds under normal operating conditions.
Now testing becomes possible.
Acceptance becomes objective.
Disagreements become evidence-based instead of opinion-based.
Subjective Words Create Objective Problems
One of the quickest ways to identify weak requirements is to search for subjective language.
Examples include:
- Easy
- Fast
- Reliable
- Secure
- Efficient
- Flexible
- Adequate
- User-friendly
- Simple
- Robust
None of these words are inherently wrong.
They are simply incomplete.
Each requires measurable context.
Fast compared to what?
Secure against which threats?
Reliable under which conditions?
Simple for which users?
Requirements become stronger as opinions are replaced with measurable expectations.
Testing Begins During Requirements Engineering
Many organizations think testing begins after development.
Effective organizations know it begins much earlier.
One of the best questions a business analyst can ask during requirements discovery is:
“How will we test this?”
If stakeholders cannot answer that question, the requirement probably needs additional refinement.
Designing acceptance criteria while writing requirements exposes ambiguity before developers encounter it.
That saves both time and money.
Verification Is More Than Functional Testing
Many teams associate verification with software testing.
Verification actually occurs in several ways.
A requirement may be verified through:
- Inspection
- Demonstration
- Analysis
- Functional testing
- Performance testing
- Security testing
- Disaster recovery testing
- Compliance validation
- User acceptance testing
The verification method should be considered while the requirement is being written—not after the software has been built.
Requirements Should Define Acceptance
Imagine purchasing a bridge without knowing how much weight it should support.
Or buying a vehicle without defining acceptable fuel efficiency.
No engineer would begin construction without objective acceptance criteria.
Software engineering should be no different.
Every requirement should clearly communicate what constitutes success.
Acceptance criteria eliminate uncertainty.
They provide developers with implementation targets.
They provide testers with validation criteria.
They provide business stakeholders with confidence that the delivered solution satisfies the original need.
Every Requirement Should Answer Three Questions
Before approving a requirement, ask:
Can it be measured?
Can it be tested?
Can it be verified independently?
If the answer to any of those questions is no, the requirement probably requires additional work.
This simple review prevents countless downstream problems.
Requirements Verification Protects Everyone
Clear acceptance criteria benefit every participant in the project.
Business leaders know what they are approving.
Architects understand the constraints.
Developers know what must be implemented.
Testers know what evidence must be collected.
Auditors know what compliance looks like.
Project managers know when work is complete.
Requirements become objective contracts instead of subjective conversations.
Verification Creates Confidence
One of the defining characteristics of mature requirements engineering is confidence.
Not confidence based on optimism.
Confidence based on evidence.
When organizations can demonstrate that every requirement has been objectively verified, software delivery becomes far more predictable.
Projects experience fewer surprises.
Acceptance becomes faster.
Disagreements become less emotional.
Most importantly, organizations stop debating whether software works as intended because the evidence already answers the question.
Looking Ahead
Requirements should never force stakeholders to rely on interpretation.
They should produce evidence.
Well-written requirements define not only what software must do, but how everyone will know when it has succeeded.
That is the difference between documenting expectations and engineering outcomes.
Requirements Reality
Every requirement should come with its own proof of success.
Coming Next
Article 9—Requirements Are Contracts Between Business and Technology
Successful software begins with shared understanding. Next, we’ll examine why requirements are more than documentation—they are professional agreements that align business intent with technical execution, establish accountability, and define what success looks like before development begins.