By using this site, you agree to the Privacy Policy and Terms of Use.
Accept
SmartData Collective
  • Analytics
    AnalyticsShow More
    predictive analytics in dropshipping
    Predictive Analytics Helps New Dropshipping Businesses Thrive
    12 Min Read
    data-driven approach in healthcare
    The Importance of Data-Driven Approaches to Improving Healthcare in Rural Areas
    6 Min Read
    analytics for tax compliance
    Analytics Changes the Calculus of Business Tax Compliance
    8 Min Read
    big data analytics in gaming
    The Role of Big Data Analytics in Gaming
    10 Min Read
    analyst,women,looking,at,kpi,data,on,computer,screen
    Promising Benefits of Predictive Analytics in Asset Management
    11 Min Read
  • Big Data
  • BI
  • Exclusive
  • IT
  • Marketing
  • Software
Search
© 2008-23 SmartData Collective. All Rights Reserved.
Reading: Use the Force – A Brief Guide to Use Case Complexity
Share
Notification Show More
Latest News
ai software development
Key Strategies to Develop AI Software Cost-Effectively
Artificial Intelligence
ai in omnichannel marketing
AI is Driving Huge Changes in Omnichannel Marketing
Artificial Intelligence
ai for small business tax planning
Maximize Tax Deductions as a Business Owner with AI
Artificial Intelligence
ai in marketing with 3D rendering
Marketers Use AI to Take Advantage of 3D Rendering
Artificial Intelligence
How Big Data Is Transforming the Maritime Industry
How Big Data Is Transforming the Maritime Industry
Big Data
Aa
SmartData Collective
Aa
Search
  • About
  • Help
  • Privacy
Follow US
© 2008-23 SmartData Collective. All Rights Reserved.
SmartData Collective > Business Intelligence > Use the Force – A Brief Guide to Use Case Complexity
Business Intelligence

Use the Force – A Brief Guide to Use Case Complexity

Editor SDC
Last updated: 2009/04/27 at 7:39 PM
Editor SDC
9 Min Read
SHARE

Contents
“Why do different project teams need different writing styles?”“Why do different project teams need different writing styles?”

In Chapter 1 of Alistair Cockburn’s “Writing Effective Use Cases,” which I have to believe is the book most often recommended when someone is seeking to learn about use cases, we are first presented with a few questions, the second of which really captures the tone of the tome, and frames what I’d like to discuss today:

“Why do different project teams need different writing styles?”

First and foremost, when I read questions like this, I hear all the upper-management types I’ve dealt with in the past whine the same question: “Ok. First you convinced us that we need to document requirements, and now you’re telling us that there’s going to be some work (a.k.a., money) to determine the style that’s right for our team?” This is, of course, a cup-half-empty perspective on the idea. After all, going through a process that would result in your organization achieving greater communication and efficiency isn’t a bad thing. Documentation alone is a hard sell, especially when budgets are tight (or “in this economy,” which I believe has recently replaced “in bed” as the most popular fortune cookie ender). And you can’t use hollow, stock phrases like “all successful projects start with g…

More Read

Use Cases and Business Rules

Use Cases: For Mobile, Email, & Social Media
A Uniquely Cincinnati Alternate Use Case
Clear Use Cases Clear a Path to Success

In Chapter 1 of Alistair Cockburn’s “Writing Effective Use Cases,” which I have to believe is the book most often recommended when someone is seeking to learn about use cases, we are first presented with a few questions, the second of which really captures the tone of the tome, and frames what I’d like to discuss today:

“Why do different project teams need different writing styles?”

First and foremost, when I read questions like this, I hear all the upper-management types I’ve dealt with in the past whine the same question: “Ok. First you convinced us that we need to document requirements, and now you’re telling us that there’s going to be some work (a.k.a., money) to determine the style that’s right for our team?” This is, of course, a cup-half-empty perspective on the idea. After all, going through a process that would result in your organization achieving greater communication and efficiency isn’t a bad thing. Documentation alone is a hard sell, especially when budgets are tight (or “in this economy,” which I believe has recently replaced “in bed” as the most popular fortune cookie ender). And you can’t use hollow, stock phrases like “all successful projects start with good requirements.” All the people holding the purse strings hear when you give them that stuff is akin to the teacher from Charlie Brown. So it’s important, as analysts, that we have a pointed reply, something beyond “We’re just going to use the force.”

Step 1 – Identify the Levels.

Thank goodness, Cockburn points out the three levels of detail in writing use cases, which is good, because management likes short lists. If you tried to say “there are ten levels of detail we can use to write use cases,” this would cause wincing and grimacing.
Effective Grimacing

I’m not saying that it’s possible to explain the effectiveness of use cases to that guy. However, what comprises the three levels is as equally important as the fact that there are three. The “brief” use case is the short, one- or two-sentence statement that can fit in a table or spreadsheet. The “casual” use case can be a few summary paragraphs, and the “fully dressed” use case is the most thorough approach.

Step 2 – Identify which to use.
So now that we have presented our short list of methods from a reputable source, we will no doubt need to respond the next obvious question, “Which style do we use?” It doesn’t hurt anyone to take all the Use Cases identified and compose the “brief” style. Obviously this gives you a nice, informative list of work items to which you can append priority, frequency of use, or other tidbits. Whether the brief use case is a candidate for a more verbose explanation via the “casual” style can come down to a couple questions:

1. Have we done this before?
2. Is this a core piece of the project? Either from
a. a development/complexity perspective or
b. the client/customer perspective

If functionality has been developed on similar projects, obviously a very minimal amount of discussion is required to reproduce the same in the new project, so going beyond the basic is probably not warranted. What immediately trumps this for me is if either the development team or certainly the customer has any concern or gives the use case any weight. The “casual” style is both perfect in name and intent. The word “casual” plays down any notion that you’re going to go into some deep analysis that requires time and money, and yet you give the use case the treatment it deserves to create the communication baseline.

Last, but certainly not least, the “fully-dressed” use case. I like to think of these as “black tie” use cases.
Black Tie Use Cases

Here, we’re really thorough and detailed and maybe even looking for a degree of polish, as we would if dressing to go to the ballet or a dinner party. This method is called for if both the client and development team consider the functionality to be core to the product. Even if the functionality has been developed before on a previous project, if it is core to the new product, a full treatment is required because the core usefulness of the feature is directly tied to the client brand. If I can’t take money out of the ATM machine, the bank name suffers. In addition, fully dressing the core functions allows the uniqueness of the particular client/customer to come to the surface. It works like salt and pepper work to enhance natural flavors. Just like with ATMs, each bank has a different flavor on the same function based, at least in part, on their branding which leaves you with the ability to favor one over the other. So, functionality that represents a point of market competition, and thus a major business objective, must be fully dressed. I also use a metric to govern whether the use case needs the full treatment, such as if three or more questions arise from any stakeholder.

So that’s a two-step procedure for selling the idea of using use case analysis for projects to those in power. Two steps! Golly jeepers that’s easy! Here’s the kicker: the discovery process happens whether realized or not. Project teams, in order to achieve their highest degree of efficiency and productivity, require a discovery process to find the methods of requirements documentation that work best. This can either be recognized or not. It’s a matter of unconscious incompetency or conscious incompetency, not knowing what you don’t know, and knowing what you don’t know. Those companies that proactively engage in the process become successful, productive, and fun places to work. Those same companies have either established analysts or analyst consultants as key contributors. These people can also effectively throttle the amount of requirements practices exposed to a particular team. The result is you either have companies who understand the complexities before the project at an appropriate level, or are reflecting on them in the same – albeit more excruciating – detail as they close their doors forever.

TAGGED: use cases
Editor SDC April 27, 2009
Share this Article
Facebook Twitter Pinterest LinkedIn
Share

Follow us on Facebook

Latest News

ai software development
Key Strategies to Develop AI Software Cost-Effectively
Artificial Intelligence
ai in omnichannel marketing
AI is Driving Huge Changes in Omnichannel Marketing
Artificial Intelligence
ai for small business tax planning
Maximize Tax Deductions as a Business Owner with AI
Artificial Intelligence
ai in marketing with 3D rendering
Marketers Use AI to Take Advantage of 3D Rendering
Artificial Intelligence

Stay Connected

1.2k Followers Like
33.7k Followers Follow
222 Followers Pin

You Might also Like

Use Cases and Business Rules

2 Min Read

Use Cases: For Mobile, Email, & Social Media

4 Min Read

A Uniquely Cincinnati Alternate Use Case

5 Min Read

Clear Use Cases Clear a Path to Success

7 Min Read

SmartData Collective is one of the largest & trusted community covering technical content about Big Data, BI, Cloud, Analytics, Artificial Intelligence, IoT & more.

giveaway chatbots
How To Get An Award Winning Giveaway Bot
Big Data Chatbots Exclusive
AI and chatbots
Chatbots and SEO: How Can Chatbots Improve Your SEO Ranking?
Artificial Intelligence Chatbots Exclusive

Quick Link

  • About
  • Contact
  • Privacy
Follow US

© 2008-23 SmartData Collective. All Rights Reserved.

Removed from reading list

Undo
Go to mobile version
Welcome Back!

Sign in to your account

Lost your password?