What's wrong with requirements? Why are use cases better?
Yesterday I talked about how use cases aren't just for user interactions anymore. I see them as being useful for documenting how services work, and even how your business works. Seems to me that anytime one thing uses another thing, you can describe the interaction with use cases.
So whatever happened to good old requirements? I don't know, but I never liked them, I don't use them, and I'm glad. I remember requirements like (if I'd been working on e-commerce apps 10 years ago) "must be able to add a product to the shopping cart" and "must be able to check out." These things would go on for pages, usually you'd end up finding two requirements twenty pages apart which directly contradicted each other, and you'd end up needing requirements lawyers to interpret the darn things. The worse part was that when the users and developers agreed to a final set of requirements, neither side really knew what they were agreeing to and probably had very different ideas in mind.
Special mention goes to XP user stories. Stories get use cases back to their basics: Tell me what it'll be like using some part of the application to perform some typical task. No template, no prereqs, no error paths ... just a simple description of how things work. If the description happens to mention what's already in place, what could go wrong, etc., fine, but that should be a natural part of the explanation, not a necessity forced by the template.
So forget requirements, use use cases. And if your use cases are getting too complicated, use XP stories. It's all about communicating and agreeing upon what you want the application to do.