Visual vs. Textual Requirements

By Michael Flanakin @ 6:29 AM :: 2092 Views :: Patterns & Practices, Requirements :: Digg it!

Tyner Blain Mobile-ready link posted some comments about using use cases vs flow charts for branching Mobile-ready link -- 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.

Ratings