COEPD – Center of Excellence for Professional Development Happy Learning
A business analyst understands the business and gathers requirements from all stakeholders and clients. The BA also analyzes these requirements and ensures that there is no conflict between the requirements.
A good requirement plays an important role in the success of any project as it provides the basis for design, development, testing and verification. But how can we determine whether a requirement is good or perfect? In this blog we will explore some of the key characteristics of good requirements.
A requirement should be clear, complete and correct. A requirement written in simple and easy language improves understanding. A good requirement should meet a business objective. It should be high level, detail oriented, well written and documented by potential clients
How do I know that the requirements are complete?
When all stakeholders have approved a set of requirements.
There are several characteristics of good requirements, but CUCV is among the most prominent.
CUCV stands for:
Clarity: The requirement should be clear enough for users to understand. It should be less in technical language so that non technical person can easily understand it easily.
Understandable: The requirement should be put in a way that it is easily understood by users of all levels
Consistent: The requirement should not contradict itself.
Since there can be multiple stakeholders for a single project, each stakeholder has its own requirements. There is a possibility that two stakeholders define conflicting requirements for a single element. The person who substantiated the request may not know this at the time, but should raise such requests during the review. These conflicting demands need to be reconciled by re-engaging stakeholders and developing a common understanding of business objectives.
During system development, it is important that all users are consulted, including managers down to junior staff. Consistency is always considered in system development requirements.
Verifiable: A requirement of a given system should always be verifiable as it should be specified in a way that can be checked in the future if required to determine whether a particular requirement has been met or not.
Others include:
Achievable: A good requirement should be feasible and realistic, meaning that it can be implemented within the available resources, time and budget. It should take into account technical, organizational and environmental limitations and constraints.
Relevant: A good requirement should align with the needs, goals, and expectations of the business and users. It should address a real problem or opportunity and provide value to stakeholders. For example, a requirement like “The software should have a purple background” may not be relevant to user experience or business goals, while a requirement like “The software should allow users to filter and sort search results by relevance, date, and popularity” is more relevant and valuable.
Specific: A good requirement should be precise and well defined to leave no room for misinterpretation or confusion
Relevant: A good requirement should align with the needs, goals, and expectations of the business and users
A well-crafted requirement should be SMART
S-specific
M-measurable
A- Achievable
R-realistic
T- Traceability/Time Link
If the requirements are SMART, we push those documents into the BRD (business requirements document).
In contrast, good requirements are the foundation of a successful project, and investing time and effort in developing and validating requirements can pay dividends throughout the project lifecycle.
The business analyst reviews the requirements for their clarity, comprehensibility, consistency, verifiability. In addition, the requirements specification document should contain consistent and complete requirements for the project.
