make things easier for all readers of the requirements by setting explanations off from the requirements by placing the explanation in parentheses, in a different font/size, indented, in a different color, and so forth. It might also help to make it clear in the front of the document what is being used to distinguish the explanations from the requirements. Each requirement must be identified with a unique number or label.

Stakeholders expect requirements to be self-contained and stand-alone. The understanding of a requirement must not depend on the content of another requirement. Understanding may depend on language defined in the glossary.

If completeness cannot be obtained (information not available, decisions not made, etc.) the requirement can be “defined later”, but needs a date or a point in time (or process) by which it will be defined. When dealing with an approved or baselined set of requirements, removing the “TBD” and replacing it with the real requirements requires a new version.

Use same terminology throughout the Requirements, lack of consistency in requirements is one of the major reasons for failures due to requirements errors. When inconsistency exists, assumptions will be made and chances are the assumptions could be wrong.

Try to get approval from IT folks, and ensure requirements are possible to implement. (Ex: In scope, Technologies, Economic (ex: Cost / Benefits Analysis), Legal and regulatory, Usability)