Quality software depends on the quality of requirements. It's not easy to separate real software requirements from other stuff passing as requirements (what I will call SPAR).
If you were to transcribe a requirements interview and analyze all the documents which are used to inform requirements, you would find the majority of words spoken or written do not translate into actionable requirements.
Here are some common examples of SPAR which you can easily find in software solicitations:
Meaningless bromides
Agile approaches can contribute to reaching a solution by allowing faster iterations. The essence of the Agile Manifesto provides for the team to ignore distractions and dead ends and push to deliver software that works.
If you were to transcribe a requirements interview and analyze all the documents which are used to inform requirements, you would find the majority of words spoken or written do not translate into actionable requirements.
Here are some common examples of SPAR which you can easily find in software solicitations:
Meaningless bromides
- User friendly
- Intuitive
- Seamless integration
- Leading edge of technology
- Including, but not limited to...
- Integration with multiple [unspecified] systems
- Compatible with mobile devices to be identified later
- Easily accommodate changes without programming
- Compatible with [unspecified] future products and technologies
- Meet all privacy laws enacted by federal, state or local governments
- All updates are accomplished in real time
Agile approaches can contribute to reaching a solution by allowing faster iterations. The essence of the Agile Manifesto provides for the team to ignore distractions and dead ends and push to deliver software that works.