Use Case Modeling

17 Nov 2010 - 8:59am
3 years ago
8 replies
1045 reads
Tim Schneidermeier
2010

Hi,

I was wondering which kind of setup you use for writing use cases? Do you use a simple Word template or tools like Visual Use Case 2009?

Right now I am using Word for writing and Omnigraffle for doing the diagrams. But there hast to be a better and more efficient way..

Thanks!

Comments

17 Nov 2010 - 9:47am
jhartmann
2009

I'm currently using Visio for Use Cases, but I'm not a huge fan of it. I've used Sparx System's Enterprise Architect before, and while its not perfect either, its got some nice features.

17 Nov 2010 - 11:05am
tessa
2008

I use Adobe's CS. Setting up the doc in InDesign (parent doc), linking/embedding Illustrator diagrams into that. Works nicely since all revisions can be done from one doc (the InDesign template) and then made into a PDF. 
I see no reason to not link/embed short videos/screen captures in the parent use case doc as well.I also see no reason to continue using Visio and various unrelated programs to help complete its shortcomings. It is somewhat archaic, although one could continue to use it for years, I suppose....
Tess

On Wed, Nov 17, 2010 at 6:36 AM, Tim Schneidermeier <tim.schneidermeier@gmail.com> wrote:

Hi,

I was wondering which kind of setup you use for writing use cases? Do you use a simple Word template or tools like Visual Use Case 2009?

Right now I am using Word for writing and Omnigraffle for doing the diagrams. But there hast to be a better and more efficient way..

Thanks!

(
17 Nov 2010 - 11:50am
Christopher Rider
2009

I haven't worked with use cases in a couple years, but I was pretty immersed in them for a good chunk of my career. Between 2005 and 2007 I evaluated about every requirements management tool that was available in the market. Most of the big players (cough, IBM) at the time were screaming "designed by engineers, for engineers" - focus on features, with zero attention given to the fluidity of the authoring environment. 

Around that time, a number of new tools came onto the market. I was particularly fond of CaseComplete. The UI did a good job of staying out of the way, and the requirements were stored in XML, so we could version them like any other code artifact. We built some hooks into subversion that ran a custom XSLT to generate our browseable docs on every checkin.

The developers were incredibly responsive-we had a few questions about the XML schema as we were building our reports, and they always got back to us within hours. 

Geek heaven.

Visual UseCase looks like a pretty similar featureset.

I'll say this - if you find the right tool, it's definitely worth the investment. 

On the other hand - are you completely sure you NEED all that textual documentation? Use cases are good for documenting backend systems with a lot of elaborate business logic, but for interaction design or UI specs, annotated wireframes may turn out to be a much better use of your time.

17 Nov 2010 - 3:05pm
tessa
2008

Chris, I too have written my share of use cases and one point you made resonated with me and had actually driven my choice of tool (combo of InDesign + Illustrator, etc.). I discovered that initially cross-functional teams wanted robustness, the reality was that the folks who design the tool and those that build the tool often only have little more than a similar use case list and the corresponding touch points. The way we write them, the needs we meet are completely different. So, in the end, I haven't needed the robust XML schema-robustness, etc. yet
I wireframe in InDesign so use it for use cases too. If at any time separate docs, they are easy to integrate, put in a PDF that is copy/paste-able. As long as the use cases have the same names (come from one list so the different teams use the same name), using a different tool (remember PDFs make mine a portable format for the dev team) is okay and makes my job of writing, maintaining and synchronizing to the design itself so much easier!
This may not be the case for everyone, but I have found that any time the "uses" can be synched across teams with a happy effort on all sides, it works better than trying to get designers used to engineering tools and vice versa.
Tess

On Wed, Nov 17, 2010 at 9:27 AM, Christopher Rider <cjrider@gmail.com> wrote:

I haven't worked with use cases in a couple years, but I was pretty immersed in them for a good chunk of my career. Between 2005 and 2007 I evaluated about every requirements management tool that was available in the market. Most of the big players (cough, IBM) at the time were screaming "designed by engineers, for engineers" - focus on features, with zero attention given to the fluidity of the authoring environment. 

Around that time, a number of new tools came onto the market. I was particularly fond of CaseComplete. The UI did a good job of staying out of the way, and the requirements were stored in XML, so we could version them like any other code artifact. We built some hooks into subversion that ran a custom XSLT to generate our browseable docs on every checkin.

The developers were incredibly responsive-we had a few questions about the XML schema as we were building our reports, and they always got back to us within hours. 

Geek heaven.

Visual UseCase looks like a pretty similar featureset.

I'll say this - if you find the right tool, it's definitely worth the investment. 

On the other hand - are you completely sure you NEED all that textual documentation? Use cases are good for documenting backend systems with a lot of elaborate business logic, but for interaction design or UI specs, annotated wireframes may turn out to be a much better use of your time.

(((Pl
17 Nov 2010 - 1:42pm
LFrancis
2009

Hi there,

There are occassions and cultures within client environments where use cases are very helpful. I find it so especially when you need to capture the unsucessful scenarios and how the system will handle errors or if there is a lot of interaction between systems and/or systems and people.

I have set up an excel template which allows for one use case per worksheet, with a summary worksheet that displays the case, a short description and the status. I include hyperlinks so that people can jump to the use case they are interested in. and jump from the use case to the summary page. I colour code the tabs for modules within the system as well.

Of course you don't generate any code from those, but I haven't found cases where that works very well thusfar. I also agree with Christopher that for some things annotated wireframes work just as well.

My experience has been that the use case "view" provides helpful details for the user experience for the developer, while annotated wireframes help us design the front end success scenarios better. Wireframes also help SMEs and stakeholders notice if the proposed design is meeting their perceived needs. Use cases can also be very helpful in this regard, since they challenge people to see details in written form. The same benefit happens for me as I am forced to think through the scenario in a certain way, and I find that flushes out potential challenges with the scenario, or "missing" requirements.  By using the excel format, I found that developers were happy to provide notes and questions beside actual steps in the use case, which was useful for them and for us. My stakeholders also like the excel format as it doesn't require the deliverable to be turned into a pdf to be shared, everyone has excel. It also affords flexibility for printing nicely.

I would be happy to share my template with you if you like, just ping LindaFrancis   at    FandangoGroup  dot   com.

:)

Linda

PS there is a great resource for writing use cases called, " Writing Effective Use Cases" by Alistair Cockburn

18 Nov 2010 - 5:16am
Tim Schneidermeier
2010

Hi Linda!

tried several times to send you an email concerning your template, but I always get mail delivery failures... I would be happy to try your template. So, here would be my mail tim.schneidermeier at gmail dot com

Thanks a lot!

18 Nov 2010 - 5:02am
Tim Schneidermeier
2010

Thanks for all the answers! I I am very happy to hear, that it seems that there is not "one" way to do it at all!

I def. agree with Linda in means of code generating.  

I will try using Excel and the Adobe scenario for a while to evaluate, if they fit my needs. 

Have you tried modeling with UIML, by the way? Kind of catched my interest months ago, but haven`t had the time to go deeper...

18 Nov 2010 - 1:05pm
tessa
2008

Tim,UIML seems like a more pared down version of use case modeling that would leverage the universal qualities that XML aims for.The good thing seems to be that it keeps the door open for thought on different platforms, and it is already in code elements that can act as a list of functions necessary across all platform manifestations of the design.
The bad thing is that nothing can be one size fits all and so while UIML would help teams not forget functional elements, I can't think of how it would be used beyond that, because each platform has its idiosyncrasies and requirement adjustments.
If you had the opportunity to use it on a project, how would you use it?
Tess

On Thu, Nov 18, 2010 at 2:47 AM, Tim Schneidermeier <tim.schneidermeier@gmail.com> wrote:

Thanks for all the answers! I I am very happy to hear, that it seems that there is not "one" way to do it at all!

I def. agree with Linda in means of code generating.  

I will try using Excel and the Adobe scenario for a while to evaluate, if they fit my needs. 

Have you tried modeling with *UIML*, by the way? Kind of catched my interest months ago, but haven`t had the time to go deeper...

((
Syndicate content Get the feed