I just sent out a 70 page use cases document out for review by my teammates. Also included in the review packet were two Visio digrams that described processes that were too complex for a simple narrative. Getting exposure to writing use cases last year definitely paid off. However, creating use cases is just like developing Lotusscript or Java code: if you don't do it for a while, your skills get rusty and it takes some time to get back into that way of thinking.

(0)

Since I hadn't written any use cases since April of last year, I went digging around the web to see what I could find. Here's a set of some interesting links:

• Crystal Wiki
• Resources for writing Use Cases (Alistair Cockburn)
• What's Wrong with Use Cases?
• Use Cases still considered Dangerous!
• Are Use Cases the death of good UI Design?

The last two links are particularly interesting for anyone with more than a passing interest in Rational Process. The Author, David Anderson, definitely has no love lost for RUP. I can see his point, as the whole use case process doesn't really address the actual user experience. Unfortunately, the only systems where the behavior can be described purely by narratives or flowcharts are dumb-tube or old MS Dos-type programs. Full-fledged graphic applications in use today have numerous widgets and whatnot that empower users to do different things at a time, as well as do the same thing using different steps.

While use cases do have their limitations, they are better than nothing. Besides, the best UI can never describe how back-end process work, which is what client-server or n-tier applications are all about.

(0)

I just sent out a 40 page Functional Specifications document for review next week by my teammates. I have to say I really appreciate being given the time to document the requirements for a new Notes application so thoroughly. I wish I could do this on all of my new Notes application projects. Spending adequate time gathering requirements and documenting them always cuts down on any rework needed during development. Of course, most Notes development is still seen as JAD or RAD type of development, where the requirements are defined while the application is being built. I used to like this way of working when I started out as a Notes developer years ago, but since then I've seen time and time again how not defining requirements, documenting them and reviewing them before starting development usually always leads to the developer working in "crunch" mode for the duration of the project. This makes developing a quality product at the end of a project a very stressful endeavor, to say the least.

(0)