A guide to selecting precise language when writing software requirements to minimize ambiguity and improve implementation outcomes

Overview

#

When crafting requirements for software development, the choice of language significantly impacts how requirements are interpreted, prioritized, and implemented. Modal verbs like “can,” “should,” “could,” “shall,” and “must” each carry different levels of obligation, necessity, and flexibility. Using imprecise language can lead to misalignment between stakeholder expectations and delivered solutions, scope creep, and wasted development resources.

The Hierarchy of Modal Verbs in Requirements

#

“Can” and “Could” - Possibility and Capability

#

These modal verbs indicate possibility, capability, or optional features without imposing obligation:

The system can export data in CSV format. Users could filter results by date range.

Impact: Requirements using “can” or “could” often get interpreted as low-priority features that might be implemented if time permits. They suggest optionality rather than necessity.

“Should” - Recommendation and Expectation

#

“Should” implies strong recommendation or expectation, but with some flexibility:

The application should respond within 3 seconds. Error messages should provide troubleshooting guidance.

Impact: “Should” requirements often get prioritized below “must” requirements but above optional features. They represent expected behavior that might occasionally be violated under exceptional circumstances.

“Shall” and “Must” - Obligation and Necessity

#

These modal verbs express non-negotiable requirements:

The system must encrypt all personally identifiable information. All financial transactions shall be logged for audit purposes.

Impact: “Shall” and “must” clearly communicate critical functionality that cannot be compromised. These requirements form the mandatory core of the system.

The IEEE Standards Approach

#

The IEEE Standard 830-1998 for Software Requirements Specifications provides guidance on requirement language:

1. SHALL: Mandatory requirement
2. SHOULD: Recommended but not mandatory
3. MAY or CAN: Optional requirement

This standardized approach helps establish clear expectations about the implementation priority of each requirement.

Writing Unambiguous Requirements

#

Consider these examples showing progression from ambiguous to clear requirements:

Ambiguous: “The system can have good performance.”

Better: “The system should respond to user inputs within 2 seconds under normal load conditions.”

Clearest: “The system must respond to user inputs within 2 seconds when processing up to 100 concurrent requests.”

The Cost of Ambiguity

#

Research indicates that requirements defects cost significantly more to fix when discovered late in development:

• Requirements defects identified during requirements phase: 1x cost
• During design phase: 3-6x cost
• During development: 10x cost
• During testing: 15-40x cost
• After deployment: 40-1000x cost

This makes precise requirement language an essential investment in project success.

Best Practices for Requirement Language

#

1. Be consistent - Establish a glossary of terms and modal verbs with clear definitions for your project
2. Quantify where possible - Replace subjective terms with measurable values
3. Provide context - Explain the rationale behind critical requirements
4. Review collaboratively - Have stakeholders, developers, and testers review requirements to identify ambiguities
5. Test requirements - Challenge each requirement with “how would we verify this?”

Conclusion

#

The precision of language in requirements directly influences development efficiency, product quality, and stakeholder satisfaction. By consciously selecting appropriate modal verbs and eliminating ambiguity, software development teams can build a stronger foundation for successful project implementation.

As requirements author Robert Martin noted, “The ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.”

The same principle applies to requirements - clarity in expression yields clarity in implementation.

References

#

• IEEE Standard 830-1998, IEEE Recommended Practice for Software Requirements Specifications
• Karl E. Wiegers, “Software Requirements,” Microsoft Press
• INCOSE Systems Engineering Handbook