Web Development

Archive for October 2007

[Note: treat ‘days’ as ‘months’ here. This was drafted long back] 

Few days back, when we were still mulling over improvising over a manual work-flow in our system, I had some discussions with my Product Manager collecting the details about the existing work-flow and desired improvements. Plain English communication. Product manager, himself being one of the regular user of the system came up with some simple steps towards the goal of easing things. Previous two nights I had been reading “Writing Effective Use Cases” by Alistair Cockburn. A real good book on the subject. Starts with real, easy to understand examples. Good to the extent that these examples are almost sufficient for most projects. So, after conversing with the Product Manager, I sat down to take a note of work-flow that he talked of. Just to keep a track. While writing down the points I could easily relate what I was doing to the usecases described by Alistair. Some steps towards a particular goal from the user’s perspective. Naturally, I realized to divide the work-flow into a set of usecases. Usecases, Ifeel, are clear and concise way of recording the requirements. Advantage being that their structure doesn’t impede our regular thought process on a subject. The structure rhymes very well with how we think about requirements. Following are few immediate realizations I had about the usability of usecases.

  1. Nimble structure results in consistant communication of requirements. Usually, requirements documents either have an overwhelming structure or no structure at all. Both detrimental to a project. I’ve seen long SRSs subdivided into numerous sections each talking about the same goal in a separate manner. I had the *privilege* of working on a project that had some 15-20 pages of verbose SRS at the beginning and six months down the line the SRS remained unchanged and we had a wonderful excel sheet and mantis bug tracker with hidden, changed requirements in them!. Requirements management fiasco? Yeah, nothing better than that. I Also, wonder how can an SRS be made exhaustive in the incipient stages of a project. Are people so smart to analyze all details initially? More importantly, can such an overwhelming structure be produced collectively? or is there a person or two who work on the document in isolation, get it verified with stakeholders, modifying etc? Also, does a hugely structured document offer itself as a mindmap? Not having structure at all is even bad. Requirements communicated through emails and emails only!! No mindmap, No tracking of changes in requirements.
  2. Usecases are simple enough to be put down collaboratively over a project meeting (also casual conversations with the stakeholders). Since we think of scenarios we think of alternatives. Since we put down scenarios on paper others are able to come up with alternatives to those scenarios or possible reuse of usecases. In short usecases provide wings to our analytical self as they relate easily to our thought process.
  3. Easy to estimate and communicate estimates: Estimation is a different subject all together. However, the way we represent Requirements affects the quality of estimation. Assuming an organization that doesn’t have historical estimation data that helps the formal methods of estimation we would want to make the estimation process as intuitive as possible. In such scenarios long, verbose SRS hardly helps us to estimate properly. We have paragraphs of functionality required but not the ‘units’ of functionality required. It is easy to estimate (and also prioritize) in units. With usecases we have a well defined and agreed upon chunk of tasks with alternatives jotted down and failure cases and risks jotted down. So estimating becomes intuitive.
  4. Reduced complexity in eliciting requirements: One inherent feature in usecases is that they speak of one and only one objective from the user’s perspective. The virtual user of the usecase is not multitasking. We have pre-conditions in usecases that specify what should be true for the following scenario to take place. Hence, we are separating the scenario from noise (not ignoring the noise but taking it as a different unit).
  5. Post-conditions help us make sure that the desired state of the system is maintained after the scenario has occurred.

I would be grateful to be enlightened by your experiences with usecases and your views on the same.