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.

In the past, I've put a lot of effort into defining all or at least the majority of a given system's requirements up-front. The reason for this is because I've worked in fairly process-heavy environments. While I continue to see the value of this effort, it simply isn't feasible in most environments. Actually, I beg the question: is it feasible in any environment? Most developers find the requirements definition process a pain and question its value; however, experienced engineers recognize the value and strive to find a way to work it into the software engineering process. Unfortunately, this doesn't happen enough. For most small systems, this may not pose an issue; however, once these systems grow to a significant team size or fall victim to enough attrition, new team members start to feel the pain of this missing documentation. New team members aren't the only ones who feel the pain of limited documentation. As anyone who's witnessed one of the many failed contracting efforts in the software or construction industry can attest to, faulty requirements definition can be the death of any project. For this reason, I hope more developers will find the value of requirements and seek to develop them for their own projects. What is the right way, tho? How should we solidify the abstract thoughts that form the projects we engage in? Tyner Blain  does a good job of describing an agile approach to requirements definition. I hope more take this to heart. Due to a change in scenery over the past year, agility has been more important than process. The change in viewpoint has been interesting and ultimately driven me to the same opinion Tyner has, where a full definition is desired, but is easier to swallow one bite at a time.

Tyner Blain  posted some comments about using use cases vs flow charts for branching  -- specifically, regarding failure handling.

The first thing I thought was odd is the fact that he used a flow chart. Maybe it's just me, but this should be done with a UML activity diagram. Sure, they both provide the same info in an almost identical format, but I just feel like the standardization of UML is near crucial for requirements management. Again, this is just a small thing.

I'm somewhat confused by the purpose of the post, tho. If you ask me, it's not an either-or situation. I see a need for both. In every use case I create, there's an activity diagram attached. Actually, I put the diagram in the use case specification. Having the visual allows you to briefly run thru the workflow to get the gist of it without having to read all the nitty-gritty details about how it's supposed to work.

Of course, that brings up a good point. Most people under document their use cases, in my opinion. Let me clarify that comment, tho. I, by no means, think a use case should dictate how the system does what it does -- developers need a certain level of creativity in that realm. But, I do think a use case should dictate the workflow and its key business rules. If you ask me, the use case spec should be all a developer needs to get his/her job done. If there are questions after reviewing the spec, then it either wasn't complete or wasn't accurate for one reason or another. Of course, this is completely outside of the realm of concepts like user experience, which I think users should have input on, but not drive. I feel pretty strongly about that, but that's another topic for another time.

The last thing I wanted to mention about the post is the use of 4a, 4a1, 4a2, etc. to document the alternate flows. I've never actually seen this done, but I have to say I don't like it as much as what I've seen, which is to separate alternate flows completely. Of course, this only matters in the textual description of your workflow. The reason I like it separate is because I find it hugely easier to read. This may purely be perspective, tho. I like the idea of reading thru the basic flow and not being interupted by anything. This should provide an end-to-end view of the most common use of the functionality in question. Any big decisions should be left for alternate flows, which reference the basic flow. For instance, in an alternate flow, I would say something like, "This assumes the user has completed steps 1.1 - 1.3 of the basic flow and wants to edit an existing record," assuming the basic flow was to create a new record. Additionally, there would probably be another flow for deleting. For those who like more structured use cases, you can break these out into completely different use cases. It's all up to you. This is yet another one of those simplicity vs. manageability choices.

I read a post about requirements  and there was a brief mention of using shall statements to manage requirements. I have to say I absolutely abhor shall statements. If you ask me, a use case represents a functional requirement. A shall statement just doesn't cut it. Every time I see a shall statement, I just shake my head in disappointment. Luckily, it's been pretty easy to get people to switch sides in the past. I just don't understand why people still use shall statements today, tho. Bleh...