Monday, March 24, 2014

Stuff Passing as Requirements (SPAR)

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
  • User friendly
  • Intuitive
  • Seamless integration
  • Leading edge of technology
Dangerous ambiguities
  • Including, but not limited to...
  • Integration with multiple [unspecified] systems
  • Compatible with mobile devices to be identified later
Impossible constraints
  • 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
A skilled analyst or architect knows how to distinguish the signal from the noise because he or she has a mental model of the completed solution based on prior experiences.  A solid understanding of the technology which will be used for the solution is essential for this mental model, because the technology drives the solution paradigm and the user experience.

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. 

No comments: