Doug Rosenberg over at the Reg Developer wrote about an encounter with a customer and how he had to disintermangle the requirements from the use-cases in the customer written use-case specification.
I think part of the problem is to rely on the customer to know how to write up their requirements (whether they use requirement statements, use cases, use case scenarios or everything intermingled.) Customers are typically not trained to do this (and most of the time they do not know what they need anyway…)
A better approach is to work with the customer from the beginning to tease these different beasts out of the ether.
In my experience it is more effective to start off with writing very high-level business requirements, of the form: The business needs to optimise its processing of leave applications.
These need to be broken down into more detailed requirements, saying something like: the system needs to keep track of user’s remaining leave, with traceability back to the original business requirements of course.
Repeat this process a few times until you get to a point where your requirements are user-centric, e.g. the user must be able to see their remaining leave on this screen. This is when you are writing use-cases instead of requirements. Once again make sure you have that traceability back to the over-arching requirements.
By doing this in collaboration with your customers you will not need to disintermangle the requirements from the use-case specification ever again 😉