2. How can you say that a requirement is good or perfect?

In every organization there are BAs who describe requirements in the simplest and slightly modified list, the following characteristics are generally accepted as those defining a good requirement.

Cohesive:  The project requirement tells a single aspect of the desired business process or system scope.

Complete:  The single project requirement should not miss necessary or relevant information.  It also contains, the entire set of listed requirements that should cover all relevant requirements.

Consistent:  The project requirement should not contradict another requirement.

Modifiable:  Like projects, requirements should be grouped together to show similar requirements to be modified together in order to maintain consistency in the project.

Correct:  The project requirement should meet 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 as well as it has a big impact.

Observable:   The project requirement defines a view of the system that can be noticed or observed by a user/customer. This is often referred to as the “Implementation phase” as the requirement should not specify aspects of 3 design which consists of system architecture, physical design, or implementation decisions. the scope of a system should be clear and defined separately as constraints.

Feasible:  The project requirement can be implemented within the constraints of the project which include the agreed-upon required system architecture or other physical design or implementation decisions.

Unambiguous:  The project requirement is written clearly such that there is only a single interpretation of the scope of the requirement.

Verifiable:  It can be shown that the project requirement has been met by the final solution like inspection, demonstration, test, or analysis.