In preparation for my cert upgrade -- did I mention how much I hate certs? -- I'm skimming thru some of the self-paced training books. For the most part, the books have all been decent. I'm not big on books, tho, so don't take my word for it. I do have one complaint, tho. I open the Designing and Developing Web-Based Applications Using Microsoft .NET Framework book and don't even get 10 pages in before I find a blatant fallacy. With the 5 names on the cover, I'm not sure who's to blame, but I'm inclined to put it on all of their shoulders, as co-authors. What's the problem? I quote, "Use cases and requirements are not the same thing." What!? You've gotta be kidding me, right? What is a use case if not a requirement? What, are shall statements the only way to define requirements? A use case is a requirement -- a functional requirement. Let me defer to Wikipedia: "A use case is a technique used in software and systems engineering to capture the functional requirements of a system."
The book continues by stating that "a use case is a Unified Modeling Language (UML) model meant to describe a set of user steps that accomplish a task." To clarify, a use case has nothing to do with UML. UML is simply a "language" used to visually explain a concept. While there is a use case diagram within UML, all that does is visually depict system use cases and their relationships with each other as well as system actors. You don't need a use case diagram to have a use case; it's just helpful when visualizing the aforementioned interdependencies. Perhaps more useful than the use case diagram, tho, is the activity diagram. An activity diagram visualizes the steps of the use case and, if desired, can also specify who performs those steps. I'd argue that having a visual representation can greatly simplify requirements for all parties involved. Despite the fact that these things might be helpful when documenting your use cases, they are not required. Back to the comment, tho, I will say the latter part is completely right.
I'm not sure how the authors came to these misguided conclusions. Honestly, I question how much they've even used use cases. The term "requirement" is so ambiguous, there's no way to say what does or doesn't qualify. As a matter of fact, any demand of a system can be considered a requirement. Some people may define a requirement as, "the system must have accept usernames of up to 20 characters," while others might define the requirement at a higher level by saying, "the system shall require users to login." Which is correct? Neither. Both. It's all about perception. Use cases are a bit more grounded in reality. A use case for this scenario would define the login process. Within the use case, each of these requirements would be listed to ensure developers know exactly what they are required to implement to satisfy user needs. This is the value of a good use case -- it defines the contract you, as a developer, are signing up for and will be tested against. In some cases, business rules will need to be extracted and referenced from multiple use cases. For instance, password complexity requirements might be managed separately for simplicity, manageability, or purely because they are used or referenced elsewhere.
While I'm on the details of business rules, another problem I had with this section of the book was that it suggested you should avoid adding too much detail to use cases. While I completely agree, the tone of the section gave me the impression the authors were suggesting you avoid most detail. Granted, I may have received the wrong impression, but either way, it didn't do use cases justice. I'd argue use cases should be detailed to whatever level is required to explicate user needs for developers. Use cases should never describe the implementation -- well, unless there are specific implementation details that must be adhered to; however, even then I'd be hesitant to do so. I'd rather leave implementation constraints for the architecture document; but I digress. The level of detail you add to your use cases is going to depend very heavily on the team you're working with and the relationships of team members; especially, those between the business analysts and development staff.
I could go on about this, but I think I've said enough. I'm astounded at how many people don't get requirements, but then again, after working with so many people and projects, I shouldn't be. I am by no means an expert, but I could definitely teach these authors a thing or two about requirements management. Whatever you do, please avoid these discussions in these books and perhaps any other books on the subject by the authors in question.