“Don’t give me your Org Strategy drivel, Sir. My job is to write Use Cases “…. Oh Really?

Act 1 

X – A senior developer with loads of coding experience in j2ee. Entrusted recently with the job of writing use cases for customer (she is not too excited about it and wants to get over with it as soon as possible).

M – myself

So, this time it all started with an innocent discussion on  how best to write a use case.

I start the old school way, starting from the beginning,

M: “So Organizational Objective of the customer, you see, X…..”

(I am stopped midway by my annoyed buddy…)

X: “Dude!” she says restlessly, “Lets not start from the Old Testament, please! I mean look at me, past 8 years I have been coding my a** off and thus, use cases are nothing new to me. I really don’t care what the customer’s org strategy is. My single pain point at the moment is, my company wants me to develop consulting and BA skills (this new rage called cross-skill development etc.), and be able to write use cases from scratch.So why don’t we get straight to the point?”

Sadly, she is not the only one around who thinks:

requirements analysis = use cases (?????!!!!!)

Even some of the sharp-dressed consultants working with Large IT consulting firms, fellows I have had the chance to work with, would happily opt for the brute force way into analyzing customers’ requirements. So it goes like “you need a software, huh? ok, lets start with user login, and then….”

(Audience shall Repeat after me) – “That’s a mistake!”

Now, quickly, for a few seconds, hypnotize your brain into unlearning the interchangeability of the words “Software” and “Solution”. Its simple. You have a “Problem” that you wish to solve with a “solution”, which might or might not, partly or fully, constitute a “software”.Try donning the customer’s hat for a moment and you will realize what I am talking about. Imagine the following:

Act 2

Scene – The office of a a large Healthcare company that sells Healthcare plans to large and small groups and individuals.

Situation: Here, the pre-sales and new business opportunity management process is a big time mess. Come renewals and new business season, and frantic mail threads and excel sheets fly in all directions among pre-sales, post sales, Enrollment, member ops, and fulfillment departments. The actuaries and operations folks lose their minds and Sales people go nuts quickly, trying to figure out which department is working on the cases post sale, and what is the progress.

Y – You, the head of the Pre-Sales and New Business department of the above company. You know what your problems are, and you need a solution.

P – The process guy from Business Process Excellence Team

B – Our batman on overdose, the Business Analyst

(You start addressing the meeting)

Y – “So, today we are here to discuss on how can we improve our pre-sales and enrollment processes for new business and renewals in order that we adhere to our organizational goals. The organizational growth target has been pegged at a whopping 23% this year. Based on the total revenue and growth targets, I have drawn up the KPIs for our department. So, let’s take a look at these, shall we?

(B is already restless,…starts biting nails)

P: “That’s a good point to start with. once we know the overall objectives, I can go about trying to lean out the process and see how we can get rid of some waste steps. Once we are done with that, B can start analyzing the leaned out process and think about automation.”

(B is at his wit’s ends)

B: “Hey wait a moment. I am sure I don’t need to waste my time on this tedious process! This looks like a job for the the Pro that’s me! Just tell me the exact actions that you want out of the software, I am great at imagining snazzy wire-frames and I just love putting them onto power point, Before you know, I shall be done with the Use cases, primary path, alternate path, mock-ups and would turn that over to the Development team and before you know, you will see a super cool software system running on our servers.”

(Audience shall Repeat after me) – “That’s a mistake!”

In the middle of the commotion (and fistfight) that ensued, a piece of paper got lost. That paper contained your department’s overall objectives. Guess what, I found it and smuggled it out for you, dear reader! The paper says:

  1. Increase of Customer Satisfaction by at least 15%
  2. Increase operating margin by at least 5%
  3. Free up 15% FTEs by automation of processes, so they could be used in some more meaningful ways.

Now. Think. What is the most logical sequence of things that should happen now?

  • Point 1 talks about Customer Satisfaction. So how can we increase C-SAT via the Pre-Sales and on-boarding process? May be by faster turnaround? May be by giving them a way to get real time update on the progress of their case? May be both?
  • Points 2 and 3 talk about reducing the FTEs . Again, you can reduce FTE by
    • Automating some steps
    • Eliminating some waste steps

To summarize, what we learnt till this point, is that even before thinking about the behaviors of the TO-BE system (which essentially are the use cases), one needs to understand

  1. What are the Organizational goals and departmental KPIs or objectives. Objectives are determined during the Enterprise Analysis phase.
  2. What are the problems in the current processes that are coming in the way of those goals
  3. What is being done to remove those problems (may or may not be fully IT oriented)
  4. If it’s a software that needs to be built based on the above analysis, what are the capabilities that the software needs to possess, in other words, what are the business requirements that must be fulfilled by the system so as to participate in removal of the above problems and thus contribute to reaching the organizational goal. Business Requirements are mainly gathered and analyzed during the Requirement Analysis Phase.
  5. Finally, (This is where we get into use case! Drum-rolls….) How should the Future state application behave so as to fulfill these Business Requirements. What are the permissible actions, what are inputs, the outputs, the actors, the happy path, the alternate paths, the  exception paths, the complexity, the data elements, on screen behaviors, validations etc. In other words, the Use Cases or Specifications. Specifications are also determined during the requirement Analysis phase.

Thus, knowing the organization, the department, their objectives,the target capabilities, you will be able to take an informed decision while writing the use cases. Remember, each user action, each system function, each real time decisions, each click in the browser would all collectively help the customers achieve their departmental objectives, and thus would help them achieve their organizational goals.

If you have reached till this line without getting tired of the above lengthy reading, then congrats! You are now conversant with the correlation between the top level organizational objectives and the lowest level atomic use case for a software system.

Like always, please consider placing your thoughts, comments, abuse, and everything else in the comments section below. Would go a long way in helping me learn and fine tune my understanding of the topic. So, till the next time,

Happy Reading! 🙂