I was recently in a situation where I had to create some use cases for enhancements to an existing product very quickly.  The existing use cases were missing a lot of information.  My project sponsor would have preferred I not spend any time on the use cases.  On the other hand, I knew the QA team would be dead in the water when it came to testing if they didn’t have enough information.  Also, I was rolling off of the project, and thought I could provide some good transition information in the use cases.  So,  how to proceed?

My original decision was to write the use cases and leave out the alternate flows that weren’t changing.  The focus of the requirements were the changes, after all. So, in the document containing the use cases I began to write my justification for doing this.  And, as I wrote my justification, I realized I was wrong.  This would just lead to confusion—was the alternate flow missing because it was no longer needed?  Or, was it missing because the documentation of it had little value at this point?  I realized my approach was just going to cause confusion.

From there, I switched tactics. I identified the alternate flows, but then did not write out the steps for them.  I noted that it had not changed.  This seemed like a compromise that worked—anyone reading the use case would have a clear idea what had and had not changed.  And, time was not spent documenting and reviewing alternate flows that had no current value.

So, here’s my tip for any business analyst:  If you’re taking a short-cut, write down a justification for doing it.  In taking the time to do that, you might just discover that your short-cut is really the long way around.