Bad Practices - Part III - Escapes, Rambling & Mixing

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: if, when, but, except, unless 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.