For our new videos join us at leadbychange.com
I'm Anna from Collective Genius http://www.collective-genius.com and this is the BA Collective Webcast.
There is an adage that a "classic" novel is one that everyone admires, but that no one has actually read. Were one simply adventurous enough to approach the subject matter, one would relish the simplicity and joy the experience would bring.
Use cases, to a Business Analyst, are perhaps the most "classical" of tools. Use cases, like classic novels, are held in the highest regard, but rarely understood or properly executed upon.
So, what is a use case exactly? A use case is a detailed description of a user's interaction with a system.
That's it. It's pretty simple; somewhat general, and rather vague. But that's the way it should be. A use case really amounts to nothing more than plain old "documentation." It can be applied to a business process, a complex software system, your morning routine, a wedding ceremony, or a historical event. The only requirements are an "actor" and an object to be acted upon.
A brief word about the term "actors." You will hear the term with some frequency. It is a core term to the Rational Unified Process or RUP. There are a lot of terms specific to RUP and other established processes and methodologies that can sometimes cause people to avoid use cases. The intent of this video is to encourage analysts that might not have considered using use cases to go ahead and do so. Don't let words like RUP, SDLC, methodology, process, and use case throw you off. So if you hear actor, feel free to replace the word in your own vernacular with user, analyst, person... whatever you want to call them. There is no right or wrong. The only right process and methodology to use is the one that is right for you and your environment.
A use case consists of seven components: Name, Description, Pre-Conditions, Scenario, Results, Alternate Paths, and Additional Business Rules.
The name is the identifier for the use case in question. It should be represented in the form of an action.
The description expands on the name and provides additional detail regarding the actor and system's interaction.
Actors are the individuals who will interact with the system.
Pre-conditions are criteria that must first be met prior to the execution of the scenario. Pre-conditions can be the successful execution of other use cases, or they can be assumptions.
The scenario is the anticipated series of actions and responses. Depending on the complexity of the use case, the scenario may be as simple as a couple of lines, or span several pages, but Length should be taken into consideration. If a use case is overly long, you may want to consider a means of dissecting the scenario into separate use cases.
The result is the final result of the actor system interaction and reflects the successful completion of the use case.
• Alternate Paths
The alternate paths are variations on the anticipated scenario and represent failures of the system interaction.
• Additional Business Rules
Business rules are rules that govern the use case. They should be presented within the scenario or within the alternate paths where they are contextually relevant. The Additional Business Rules section is the place to list additional business rules that govern the entire use case and do not have a location for inclusion within the context.
For examples of these concepts and their applications, go to www.bacollective.com for the entire article. The use cases in the article are for you to review and use as a model. Remember, there is no right or wrong format for preparing use case documentation. The only right way is the way that works for your project team, your organization, and for you.
Well that is it for today but the BA Collective does not stop. Stay tuned to the BA Collective for up coming Business Analysis videos and Articles at BACollective.com
I'm Anna Klemp and this has been your BA Collective Webcast.