A typical approach for a project would be:
Approaching the project in Agile methodology, the following comes in the way:
- Gathering requirements from stakeholders
- Documenting them in the right way
- Understanding the requirements correctly
- Explaining them to the team
- Refining the backlog
- Segregating them into epics, user stories, tasks
- Prioritizing them and planning what all the tasks to be included in the planned sprint
- Completing the given user stories and going for release and repeating the cycle again.
For a typical project on Agile methodology, done with requirements cannot generally happen as requirements keep on coming in and if done with the complete project also during support of project also new requirements keep on coming in.
One can follow the rule of a gap between getting the requirements, analyzing and validating them and converting them. In the initial stage of requirements, you will get a number of requirements and you work on them immediately and validate and convert them so that they are really workable. As time passes by and when you get a requirement and try to convert it, you will see that the requirement is done anyway and needs no further enhancements.
When you see that the scope of the project is met and is aligned alongside of business rules.
When you identify that the complete functional requirements and non-functional requirements are done.
When you are saying you are done with the requirements, they should have quality. To say that the requirements have quality, they must be:
- Accurately elaborated to achieve the business objective or goal
- They should not have multiple interpretations. They should be unambiguous
- The requirements must be complete without any missing information
- They all must be prioritized based on the business requirements
- They must be traceable.
One can follow the SMART rule to say that the requirements are done. SMART stands for:
S – Specific
M – Measurable
A – Achievable
R – Result Oriented
T – Time-Bound