As a business analyst, part of your job is to ensure you have excellent requirements, not just a “wish list” from the business. You can do that by following these guidelines for requirements characteristics that make a requirement excellent.
- Correct – They accurately reflect the real needs of users and business stakeholders.
- Complete – They include all of the necessary elements; functionality, external interfaces, internal interfaces, design constraint, and quality attributes.
- Clear – they are understood by all stakeholders without the need for extensive explanation.
- Consistent – They do not conflict with other requirements (conflicting requirements should be addressed ASAP in the requirements elicitation process).
- Relevant – This may seem obvious, but it is sometimes easy to get off-track and you can end up with requirements that are not necessary for that particular project. To avoid this, make sure the requirements meet a business need, goal, or objective.
- Verifiable – There must be way to verify if the requirement is satisfied. A requirement that says “Users should be able to move more quickly between screens” is not verifiable. What does “more quickly” mean? It’s too subjective. A verifiable requirement would be “the system should take no more than 1.2 seconds to move between each screen”.
- Feasible – I go back and forth on whether or not feasible should be in this list. We generally say “anything is possible with enough money, time, and resources”. So what does feasible mean? Feasible within those constraints for the project? Feasible as in “is it possible at all to do this”? Or as in “will technology support the ability to meet this requirement”?
If you want to include feasible in your criteria for excellent requirements, you should first define what feasible means for your project.