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.