1. 2.

Cohesive: Complete:

The requirement defines a single aspect of the desired business The individual requirement is not missing necessary or relevant

process or system. information. Additionally, the entire set of requirements should cover all relevant requirements. 3. 4. 5.

Consistent: Modifiable: Correct:

The requirement does not contradict another requirement. Like requirements should be grouped together to allow similar

requirements to be modified together in order to maintain consistency. The requirement meets the actual business or system need. An incorrect requirement can still be implemented resulting in a business process or system that does not meet the business needs. 6.

Observable:

The requirement defines an aspect of the system that can be

noticed or observed by a user. This is often referred to as Implementation Agnostic as the requirement should not specify aspects of system architecture, physical design or implementation decisions. These aspects of a system should be defined separately as constraints. 7.

Feasible:

The requirement can be implemented within the constraints of the

project including the agreed upon system architecture or other physical design or implementation decisions. 8. 9.

Unambiguous:

The requirement is written objectively such that there is A requirement is a basically a statement of

only a single interpretation of the meaning of the requirement.

Meeting a specific need :

something someone needs. The something is a product or solution that performs a service or function. The someone may be a company, a user, a customer, support, testers, or another product. 10.

Be verifiable:

A requirement must state something that can be verified by

inspection, analysis, test, or demonstration. As you review a requirement, think about how you will prove that the product meets it. Determine the specific criteria for product acceptance, which will ensure verifiable requirements. 11.

Be attainable :

The requirement must be attainable. It must be within the

budget and schedule and be technically feasible. Dont write requirements for things that cannot be built or that are not reasonably within the project budget.

12.

Be clear : A good requirement cannot be misunderstood.

It expresses a

single thought. It is concise and simple. The more straightforward and plainly worded, the better. Use short, simple sentences with consistent terminology for requirements. If possible, decide on specific names for your solution or product and deliverables and refer to them by name alone in your requirements. Use consistent language. As you define subsystems, name them also and refer to them only by those names. Use acronyms if you have to in order to keep them short. The less complex and more consistent everything is from requirement to requirement, the better. Too many words and too many references breed inconsistency and confusion. Finally, make your requirements grammatically correct. Good grammar is essential for understanding. Good sentence structure ensures that the implementer and tester understand what thing should do what task. It makes lines of responsibility obvious.