Mastering the Art of Writing Effective Requirements

Writing Good Requirements: Necessity, Verification, Attainability, and Clarity

• A good requirement is necessary, verifiable, and attainable.
• A requirement must state something that can be verified by examination, analysis, test, or demonstration to be verifiable.
• Subjective statements or words are not verifiable.
• A requirement must be attainable, technically feasible, and fit within budget, schedule, and other constraints.
• Each requirement should express a single thought, be concise, and simple.
• Bad assumptions occur when requirement authors do not have access to sufficient information or the information does not exist.
• Documenting critical information and maintaining a list of relevant documents can eliminate bad assumptions.
• Assumptions should be documented even if the authors were provided the correct information.
• Specifications should state WHAT is needed, not HOW it is to be provided.
• Asking WHY a requirement is needed can help define the real requirements.
• Stating implementation can lead to over-specification and limit potential solutions.
• Common problems in writing requirements include making bad assumptions, writing implementation instead of requirements, describing operations instead of writing requirements, using incorrect terms, using incorrect sentence structure or bad grammar, missing requirements, and over-specifying.

Writing Good Requirements: Necessity, Verification, Attainability, and Clarity

• A good requirement is necessary, verifiable, and attainable.
• A requirement must state something that can be verified by examination, analysis, test, or demonstration to be verifiable.
• Subjective statements or words are not verifiable.
• A requirement must be attainable, technically feasible, and fit within budget, schedule, and other constraints.
• Each requirement should express a single thought, be concise, and simple.
• Bad assumptions occur when requirement authors do not have access to sufficient information or the information does not exist.
• Documenting critical information and maintaining a list of relevant documents can eliminate bad assumptions.
• Assumptions should be documented even if the authors were provided the correct information.
• Specifications should state WHAT is needed, not HOW it is to be provided.
• Asking WHY a requirement is needed can help define the real requirements.
• Stating implementation can lead to over-specification and limit potential solutions.
• Common problems in writing requirements include making bad assumptions, writing implementation instead of requirements, describing operations instead of writing requirements, using incorrect terms, using incorrect sentence structure or bad grammar, missing requirements, and over-specifying.

Common Traps in Writing Requirements

• Writing a design requirement when a data base is not necessary can lead to unnecessary solutions.
• Stating implementation can make the author believe that all requirements are covered, but important requirements may be missing.
• The problem of needs versus implementation occurs at each level of requirements development.
• To avoid stating implementation, ask yourself WHY you need the requirement to ensure it is a real need statement.
• Defining implementation instead of requirements is known as the implementation trap.
• Always ask WHY a requirement is needed to avoid falling into the lower level requirement trap.
• Stating operations instead of a requirement can lead to misunderstandings and verification problems.
• The use of shall, will, and should have specific meanings in a specification and must be used accordingly.
• All shall statements (requirements) must be verifiable to demonstrate compliance.
• Terms such as support, but not limited to, and etc. should be avoided in writing requirements.
• And/or should be used sparingly and only when necessary to avoid ambiguity.
• Understanding common traps in writing requirements can save time, money, and prevent misunderstandings.