Criteria of a Good Requirement
Each Individual Requirement Should Be
Necessary: If the system can meet prioritized real needs without the requirement, it isn’t necessary.
Feasible: The requirement is doable and can be accomplished within budget and schedule.
Correct: The facts related to the requirement are accurate, and it is technically and legally possible.
Concise: The requirement is stated simply.
Unambiguous: The requirement can be interpreted in only one way.
Complete: All conditions under which the requirement applies are stated, and it expresses a whole idea or statement.
Consistent: It is not in conflict with other requirements.
Verifiable: Implementation of the requirement in the system can be proved.
Traceable: The source of the requirement can be traced, and it can be tracked throughout the system
(e.g., to the design, code, test, and documentation).
Allocated: The requirement is assigned to a component of the designed system.
Design independent: It does not pose a specific implementation solution.
Nonredundant: It is not a duplicate requirement.
Written using the standard construct: The requirement is stated as an imperative using “shall.”
Assigned a unique identifier: Each requirement shall have a unique identifying number.
Devoid of escape clauses: Language should not include such phrases as “if,” “when,” “but,” “except,” “unless,” and “although.” Language should not be speculative or general (i.e., avoid wording such as “usually,” “generally,” “often,” “normally,” and “typically”).
Each Individual Requirement Should Be
Necessary: If the system can meet prioritized real needs without the requirement, it isn’t necessary.
Feasible: The requirement is doable and can be accomplished within budget and schedule.
Correct: The facts related to the requirement are accurate, and it is technically and legally possible.
Concise: The requirement is stated simply.
Unambiguous: The requirement can be interpreted in only one way.
Complete: All conditions under which the requirement applies are stated, and it expresses a whole idea or statement.
Consistent: It is not in conflict with other requirements.
Verifiable: Implementation of the requirement in the system can be proved.
Traceable: The source of the requirement can be traced, and it can be tracked throughout the system
(e.g., to the design, code, test, and documentation).
Allocated: The requirement is assigned to a component of the designed system.
Design independent: It does not pose a specific implementation solution.
Nonredundant: It is not a duplicate requirement.
Written using the standard construct: The requirement is stated as an imperative using “shall.”
Assigned a unique identifier: Each requirement shall have a unique identifying number.
Devoid of escape clauses: Language should not include such phrases as “if,” “when,” “but,” “except,” “unless,” and “although.” Language should not be speculative or general (i.e., avoid wording such as “usually,” “generally,” “often,” “normally,” and “typically”).
No comments:
Post a Comment