Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Use Case Template
Previous Previous
 
Next Next
New Post 4/21/2008 5:29 PM
Informative
User is offline Kimbo
456 posts
5th Level Poster


Use Case Template 

I'm new to modern analyst, so forgive me if this has been discussed before. Thought it would be useful to discuss what people put in their use cases as the UML doesn't specify anything. I use variations on the following which I'm using on my current project.

Name: <name your use case. as a rule of thumb, the name should contain a verb and a noun>

Use Case ID: <just a number for tracking purposes>

Requirements: <traceability - the numbers of the requirements this use case realises>

Description: <general description of the use case>

Initiating actor: <generally which actor initiates this use case>

Pre-conditions: <what conditions are true before the use case is started>

Post-conditions: <what conditions are true after the use case has finished>

Business rules: <list of business rules that apply in this use case. I prefer this to having an exceptions area>

Main Course: <main scenario>

Alternate Courses: <alternate scenarios>

Notes: <just a catch all for any notes or explanations>

frequency of use: <an idea of how often the use case is actioned. Don't normally do this in projects but it can be useful>

I'm always keen to learn, so please post your thoughts on the above.

Kimbo

 
New Post 4/22/2008 6:46 AM
User is offline VN
34 posts
9th Level Poster




Re: Use Case Template 

Hi Kimbo,

I use similar template, except that I don't list the business rules but reference them by number, as the realised requirements.Often the same business rule(s) apply to multiple use cases, and I don't think it is a good practice to state any requirement or a rule more than once in the document. If your projects are different your approach may work just fine.

I have noticed also that as my understanding of the use case grows and I discover more details about them, the content of the "Notes" section becomes an alternative flow or begins to apply to a specific requirement or business rule that is realised by the use case, so I move these notes to a better location and again reference them by number.

-Vessela

 
New Post 4/22/2008 4:58 PM
User is offline Kimbo
456 posts
5th Level Poster


Re: Use Case Template 

Hi Vessela,

Thanks for your reply. Having a central list of business rules to prevent duplication is a great idea. I'll have to use it on my next project. Perhaps the only thing against it is that it makes the document slightly less readable for the business user. I think that the lack of duplication probably outweighs this though.

I agree also with your comments about the Notes section. Generally by the time its delivered there are very few notes. For example, in my current project I just have some formula examples in there.

Anyone else out there do anything differently or have extra things they put in their use cases? Don't be shy, there's no right or wrong here, just different ways of doing things. We can learn from each other.

Kimbo

 
New Post 4/22/2008 11:24 PM
User is offline Adrian M.
765 posts
3rd Level Poster




Re: Use Case Template 

I agree with Vessela, it is a good idea to keep business rules in a separate repository and reference them from the use cases.  In some cases, this practice can reduce readability but it makes up when it comes to maintainability.

Here are a couple more thoughts/practices that I have found useful when it comes to Use Cases:

  • In the Use Case specification document, I like to include at the beginning of the document a use case context diagram which is a subset of the larger use case model but which only includes the use case being described and all the other actors and use cases with which the use case in context is related.
  • In addition to the Basic (main) Flow and Alternate Flows, I also like to identify Exception Flows which contain those branches in activity/process which the actor (user) does not expect/desire.
  • Also, every use case document I create has an Issues section and an Assumptions section. This is helpful in a larger team when I read a use case created by another analyst and I see if there are any issues or if the issues section is blank.  Now I only use this section for issues which relate directly to the given use case.  This is not the place to manage project or program level issues.  Many of the resolved issues become assumptions, in which case I add those to the Assumptions section.
  • For large projects, where a robust set of artifacts are needed, my use case "family" of artifacts generally includes the following:
      • Actor Overview -> a document which contains a diagram of just actors and the appropriate generalization relationships among them.  This document also contains a description of each actor and their mapping to actual job titles within the given organization.  Remember that an actor represents a "role" not a job title and, therefore, many job titles will most likely map to one role/actor.
      • Use Case Model -> this is the set of UML use case diagrams (separated by packages if needed) which usually lives within a modeling tool such as Enterprise Architect, Visio, etc.
      • Use Case Model Survey -> this is a document which contains the "key" aka main aka high-level use cases of the system and it has two parts: use case diagram(s) and use case description(s).  I found this artifact to be very useful for high-level stakeholders such as executive management who don't care to get into the details.
      • Use Case Specification -> I have one of these for each use case and this is where I document the use case in details: use case name, description, pre-conditions, post-conditions, main flow, etc..
      • NOTE: it is very useful to have a tool, such as Requisite Pro, to manage all the use cases.  This way the actual documents simply become reports generated from the tool.
  • And since it is generally accepted that use case are to be used for functional requirements and NOT for non-functional requirements, my set of use case artifacts is complemented by a document which lists the non-functional requirements; some folks like to call this the Supplemental Requirements document.

Thoughts?

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 4/23/2008 4:56 AM
User is offline Kimbo
456 posts
5th Level Poster


Re: Use Case Template 

Adrian,

Good answer.

Some questions for you:

I. find that having business rules precludes a need for exceptions. Tend to push exceptions down to design as UI validations. Do you see a need for business rules and exceptions?

2. To add to your package how about the Vision Document? Don't really do them myself. Tend to use either a list of textual requirements or a process definition and explanation.

Kimbo 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Use Case Template

Community Blog - Latest Posts

In today's ever-evolving market, businesses must adapt swiftly to remain competitive and meet the needs of a fast-paced digital economy. Among the various business strategies available, digital transformation, customer-centricity, and sustainability have emerged as top priorities. Let’s explore why these strategies are critical for busine...
The Cisco Certified Network Associate (CCNA) certification is a pivotal credential for networking professionals, validating your skills in networking fundamentals, security, automation, and programmability. Preparing for the CCNA exam can be challenging, but with the right strategy, resources, and mindset, you can successfully achieve this certific...
The CEO/CIO's Guide to Architecting AI: Vision to Value in Minutes Introduction to Architected AI Artificial intelligence (AI) is becoming part of our life at an unprecedented pace. As CEOs and CIOs grapple with how to leverage this powerful technology to drive strategy and enhance operations, the concept of Architected AI becomes importa...

 






 

Copyright 2006-2024 by Modern Analyst Media LLC