Each requirement should be precise and testable. Consider this example: "The system will have a ranking system for the drivers." How would you create tests against it? It's better to create a section for the ranking system and specify the precise requirements for it there.
Consider this other example: If there's a free driver close to the rider, they should be notified of the incoming ride request. What if there's more than one driver available? What maximum distance can we still describe as being close?
This requirement is both imprecise and lacking parts of the business logic. We can only hope that the case where there are no free drivers is covered by another requirement.
In 2009, Rolls Royce developed its Easy Approach to Requirements Syntax (EARS), to help cope with this. In EARS, there are five basic types of requirements, which should be written in a different way and serve different purposes. They can be later combined...
