There are many ways of modelling requirements in IT development these days but one of the most popular approaches involves use cases.
Firstly, just to get the record straight, they are not called ‘user cases’ which is a mistake made by many an individual who comes across them for the first time. Also, they are pronounced use cases as in loose, not lose. I seem to recall that this is because they describe a user’s single ‘use’ of the system rather than how the user ‘uses’ the system.
I have been modelling requirements using use cases for over ten years and thought it would be helpful to provide some articles introducing use cases. As ever, this is my opinion, picked up through experience, reading books and discussions with colleagues so I’m more than happy to be challenged and would encourage any debate.
Use cases were originally conceived by Ivaar Jacobson and represented a distillation of his experience as a software engineer during the seventies and eighties in the form of a software development method.
The book he wrote (Object-oriented Software Engineering: A Use CASE Approach (ACM Press) to introduce use cases to the world even though it was written in the dim and distant past (i.e. 1992 - even I had only just graduated then!), is worth reading.
Use cases have been widely adopted since then, having formed a central plank of the Rational Unified Process and used independently in many IT projects today. They are technology independent so there are no constraints to how they can be used.
They have evolved somewhat since then in their application and sophistication but I shall start by focussing on a very pure and simple use as was originally conceived by Ivaar Jacobson.
The original purpose of use cases was to express user requirements in a technology-independent form using a structured narrative form that both the non-IT literate user and the business analyst can understand. They also provided a simple but powerful structure that provides valuable information about the users of the system and how they use the system.
Up until that point, user requirements tended to be either extensive, rambling free-form documents which were unwieldy and painful to review and agree. Alternatively, they might have been avoided altogether by having a high level statement of the functionality of the system from which the system was produced and it was only when the final system was produced that the user found out whether it was anything like what they wanted - the ability to mind read was crucial for the IT professional involved in this sort of project.
There were also a number of diagramming techniques available which provided means of describing the system behaviour but they all tended to somewhat daunting for the non-IT literate user (e.g. data flow diagram, flow charts).