The Case for Use Cases

In any software business or industry, a Business Analyst should be able to write flawless use cases so that the resulting document is crystal clear to a layman, in this case, a software developer who has a little or maybe no domain knowledge.

At RTS, we are lucky to have a development team offshore who is knowledgeable of not just the software platform that our product is created on but also the domain knowledge.  This setting makes it easier to transfer the use cases to the team and receive back a resulting product with close to 100% accuracy without too many iterations.  In the case where there is lesser domain knowledge, it would have been as good as writing the ‘Hello World’ program within a couple of minutes but not knowing what ‘Hello’ and ‘World’ means! That being said, it is also impossible for one person to gain both the technical and functional knowledge of a business requirement and hence the necessity for both the teams to work closely with each other and having a good method of understanding each other’s language that is on the use case document. At RTS, we proudly boast  that the turnaround time for an enhancement or a new feature is short because of this set-up.

My approach to writing a use case is that I use the bottom up approach, since knowing the end result of what is required helps drive the details. Once the end result is known, then working backwards in order to get all the parameters, rules, pre and post conditions, flow and exceptions are just adding details to achieve the end result.  Another effective approach is to involve the business owner/s so as to make sure that it is on the right track. Agile methodology works here, but from the second draft onwards, because the first draft needs to be done in its entirety to give the business owner a full overview of where it is headed before submitting it to the development team.

One last important factor that helps me create a use case is to put myself in the shoes of a layman  so as to get a feel of how easy/difficult it is to understand the intent of the use case on hand. If it is easy enough that the terms, language, diagrams are all flowing, then it is a success and if it is not easily understood, then  maybe tweak it to achieve that.

How do you create your use cases and deliver them to your teams? What are the 2 best approaches that you have come across? 

Deeshi Gandhi

Technical Manager