Bad Practices Part III – Escapes, Rambling and Mixing

303159_8640

This is Part III of the Bad Practices Series

Bad Practices Part I – Ambiguity

Bad Practices Part II – Multiple Requirements

 

I would like to write a little bit about other requirement pitfalls. By avoiding these bad practices one should be able to keep from making a faux pas. 

 

Avoid escape clauses

When one uses statements that contain words such as: ifwhenbut,exceptunless or although, one is introducing many potentially complex conditions. These conditions allow out clauses that can keep one from meeting the underlying needs. A picture found in an earlier posting really illustrates the massive confusion this causes. Instead of adding clarity to life why do many street signs just add to complexity?

Do not ramble
Employ the KISS (keep-it-simple-stupid) protocol. Avoid using long rambling sentences that utilize arcane language and unreachable references. No good can come of this. Remember the 3 Keys   to effective business writing. No one ever said that requirements need to be stated as complete sentences!

Do not mix different types of requirements
As a project moves from its early stages and into the development phases, high-level requirement documentation is used to develop more low-level functional specifications and low-level business requirements. Avoid writing documentation where high-level requirements are intermingled with low-level requirements. In other words, do not mix user, system, business & design requirements. This makes things very confusing and difficult to manage.

Shares