Youssef Abou AfachIn nearly every project I’ve worked on, my teams (myself included) relied on a simple rule for collecting requirements: a requirement is a clear, testable “shall” statement.
I have seen and helped deliver projects that were successful from a “requirements met” point of view. Yet every once in a while, that very project you are proud of still fails to deliver the outcome stakeholders actually cared about.
This article is an attempt to explain why projects can satisfy requirements while still missing the intent of the solution.
The definition of a clear, testable “shall” statement as a requirement, has served traditional product development well especially where the risks are low as in configure to order projects, where uncertainty is resolved before customers place orders.
However, in highly specialized and volatile contexts, this definition may collapse under real-world pressure. Such projects mimics the context of Engineering to order which is basically about designing and delivering under uncertainty, and a single declarative sentence may not be capable of carrying that uncertainty responsibly.
The same theory applies whether the product is an aeroplane or a collection of lines of code that serves an definitive intent. My personal observation is that modern software development increasingly behaves like ETO, especially in PLM deliveries, even when teams believe they are building “standard products.” My argument is that customers are unique, as well as their projects. Each of my customers, while still adhering to international business standards, has a unique, special and revolutionary process. So even though I am delivering a well established theory of configuration/change management for my customers, each delivery, conversation, discussion and change is unique, thus uncertain and at times inherently incomplete .
Why Simple Shall Statements Fail
A classical requirement such as, The system shall respond within 200 milliseconds. appears correct, but it hides several assumptions. Among which it assumes that every context of operation is known
An assumption is not a fact. It is something accepted as true without proof or evidence. while this can be an oversimplification of the term, it also serves as a reminder of its dangers.
Projects start with incomplete information, customer-specific constraints, evolving requirements and verification paths that emerge during engineering
Again to concept of positioning the uncertainty. Nothing is certain while collecting requirements.
This framing aligns with Robertson & Robertson’s approach to requirements as more than a sentence
A “shall” statement pretends uncertainty does not exist. Instead of managing it, it imagine it.
The same way our brains try to draw the complete picture when presented with insufficient information.
This leads into a lot of misjudgement and some times prejudice.
In a business context, it compresses uncertainty into false precision which leads to late requirement changes ,verification chaos and rework justified as “exceptions”.
Requirements Are Decisions, Not Sentences
A requirement is not just a sentence to be followed by the letter. It is a managed decision, an object that describes a specific intent and all its parameters.
An Adequate Requirement should define the following
- What happens of you do it
- What happens if you do not
- In what context does it apply
- What should be true for it to apply.
- When it should stop applying even if within context and operating assumptions
- How can we test that
- The maturity of the requirement
- The owners
- The creator
The “shall” becomes one attribute, not the full definition.
Many software teams believe these problems belong to hardware, aerospace, or heavy engineering. In reality, modern software deliveries are increasingly becoming complex. Even when they think that they are delivering a simple, straightforward solution, there is a possibility that they are delivering a compound and customized solution for which the same problems still apply.
My Argument is that requirements largely exist in two spaces, either when you are designing a configurable software as in configure to order context, or your are customizing a software as in Engineering to order context. The latter context is the most probable is modern software deliveries.
For Example
- Customer-specific deployments
- Enterprise integrations
- Regulated environments
- Performance and security constraints
- Feature behavior influenced by configuration and usage
Example of properly context structured requirement
Instead of a single sentence, the requirement becomes a structured object.
- Requirement Statement : The system shall meet defined API response-time targets under specified conditions.
- Context
- Customers on cloud deployment
- nominal load is 1000 simultaneous users
- Performance targets depend on hosting model and enabled integrations.
- Constraints
- ≤ 200 ms for cloud deployments under nominal load
- No synchronous calls to external systems in request path
- Verification
- profiling and simulation
- customer staging environment
- Risks
- Synchronous ERP/PLM integration may violate targets
- Requirement Maturity
- Preliminary, Under Review, Released
Conclusion
The problem is not that “shall statements” are wrong. The problem is believing they are sufficient in every context.
Until requirements are treated as structured, evolving objects, software teams will continue to experience late surprises, fragile compliance, and broken trust with stakeholders.
Does this contradict with user story logic. no it does not, it cha
Sources and References
- ISO/IEC/IEEE 15288 — System Life Cycle Processes
- Enterprise SOA By Dirk Krafzig, Karl Banke and Dirk Slama.
- Industry practice from enterprise and regulated software delivery
- Mastering the requirement process by Suzanne and James Robertson – 4th Edition
- https://simplicable.com/en/what-is-an-assumption
