WELCOME BACK! (Err.. Back?? uh..ohh..there was a first part too, that I should’ve read before coming here? Of course there is; click right here!)

So, after all those crazy fights in the last blog around trying to put things (Objectives, requirements and specifications/ use cases) into perspective, we understand a few things now:

  1. Business objectives are the top level stuff. They define the business drivers that are derived from the organizational KPIs. They are the answers to the following question that you ask to the customer “WHY do you need this software application?”
  2. Business requirements are the various features that the application should have. In other words, “WHAT all things must your application do?”
  3. Finally use case or specification tells you “HOW should your application work”, in other words, use case defines the various nitty-gritties of how exactly should these requirements be met.

Lets consider a fairly simple customer contact center application. To begin the day, the Customer Service Rep (CSR) would login to the application. Next, the customer calls in and the CSR  would pick up the call via the IVR and ask him his ID or phone number. The CSR would then punch in the same into the system and fetch his details.Next, the CSR would ask the customer his request details and select corresponding category of request, add a comment and proceed with the piece of work. If its a simple query that can be closed right in the call, he will do it or else will route the case (piece of work) to the concerned department.

As we have seen in the last blog, business objectives for the above application could be fairly simple stuff like:

  • Decrease number of workers by 8% (I know what you’re thinking, but sadly, that’s exactly what automation does to us. Sad but true )
  • Increase customer satisfaction by 10%
  • Decrease turnaround time to 2 days or less from the current 7 days. Etc..

Business requirements for the same application (which can have the above mentioned business drivers) can be:

  • User must be able to log in and take calls through the application.
  • User must be able to validate customer identity by entering into the application one of the IDs. Etc..

So far so good? Okay then it’s time to jump straight into –

use cases.

We will start with the classic use case format and then delve deeper into variations like user story format etc.

There are primarily two types of use cases: the atomic use case and the business use case.

You may think of atomic use case to be – as the name suggests – the lowest possible unit of specification. The boundaries are clear – Each atomic use case defines one or more possible action taken by a single actor – and that’s one of the conditions.

In other words, anything an actor does before it passes the boundary or purview of that actor and passes on to the next one, would be the atomic use case, unless you wish to break that down further, based on your need to maintain manageable specification units.

Business Use case on the other hand, is one level higher, and are essentially a collection of atomic use case – something that is required to capture a certain functionality that is made out of smaller modules. For example, in the above mentioned scenario, to begin with, when customer calls in, we need to create a work request into the system – we need to intake the customer ID, upon which our application would, under the hood, either run a query directly into the back-end DB or may be call some web service that will return the details. Finally, those details are populated on-screen and those data are also associated with the current work case. This process is also called work enrichment. So,

  • “Request Intake” may be the business use case as a super  set of
    • Capture Customer ID
    • Back-end Enrichment
    • Capture Request Details
    • Instant Fulfillment
    • Back office Routing

So once again, in the more structured way, lets recap what we discussed about a day in the life of the CSR who would use the above system.

  1. As a CSR, you would ideally login to the system to begin your day.
  2. Next, you would pick up the incoming call and ask the customer his name or some identifying attribute (phone number etc.).
  3. You would enter that into the system and fetch his details.
  4. If its a major query, you would create a ticket and assign it to the concerned department.
  5. If its a minor query that you can solve right here, you will provide the answer and end the call. You will fill up appropriate comment for audit logging.
  6. Things might go wrong here – The system that pulls information from the back-end onto your screen may be down at that moment. In that case you will need to manually search a certain offline list and enter the details manually against the active call.

If the above flow sounds practical enough, lets try to build a use case based on the above scenario.

Lets start by defining the various parts of a use case. A standard use case might have some or all of the below sections and even more than these. There might be project/ Organization specific variations. We list below the most common ones.

Lets take an example around which we build the various sections. Imagine a “login” use case where in the user will put the username and password in the corresponding textboxes in a certain application’s login page, and press enter. There is a “remember me” checkbox and a “forgot password?” link too!

  • Name – No points for guessing what this is!
  • Short Description – a short one or two liner summary. Can be as simple as “This use case details the login feature for the contact center application”
  • Use case Status – This is the state in which the use is now: when being written or edited, it can be Draft state, followed by Reviewed, then approved or Withdrawn.
  • Type – Atomic or Business
  • Complexity – Low, Medium, High
  • Release – The release number
  • Iteration – The iteration number
  • Primary business objective – As discussed above and in the last chapter too, this one depicts the high level business objective that this user story maps to. Can be mapped to the objective ID.
  • Business impact – Low, Medium, High
  • Actors – The actual actors or users of the system who would be executing this use case. Can be humans or the system itself (if it is an automated step).
  • Requirements – Maps to the business requirements IDs.
  • Description – A broad description including the logic of the use case.
  • Precondition – The prerequisites or the entry conditions. Example: “User has access rights to login to the system”
  • Trigger – The exact action that leads to this use case. Example – “User enters the login URL and hits enter, thereby reaching the login page.”
  • Primary Path – The happy path. This depicts the flow that the application wold traverse to complete this step in most cases, if everything goes as expected. Something like:
    • User enters username in the user name textbox (min 8 characters max 20 characters)
    • User enters password in the password textbox (min 8 char max 20 characters, at least one uppercase, one lower case, one number and one special character)’
    • If user doesn’t remember password, then follow secondary path 1.
    • User clicks “Submit”
    • If the back-end is down, then follow exception path 1.
  • Secondary Path(s) – The alternate path. This depicts the flow that the application would traverse to complete this step, if the user takes an alternate route. Please note that alternate paths are perfectly legal paths, only less likely to be executed than the primary path. Something like:
    • User clicks on “forgot password?” link.
    • the page refreshes to display the textbox to enter user’s email ID
    • User enters the email id and clicks on “Submit”
  • Exception Path: This depicts what could happen if the standard functioning of the system goes for toss. This could be due to several reasons. for example, the database is down etc. The exception flow may be something like:
    • In case the back end database is down,
      • on entering username and password, and on clicking enter, the system would display the following message “Oops! Something is not working right! Please contact system administrator / Help desk for further updates”
  • Post-condition: The final outcome of the use case. In this case, it could be something like:
    • User is logged into the system and the system displays the landing page.
  • Outgoing Status: If it is a piece of work that we have been handling, this would depict the updated status of the work. For example, a bill that came to me for approval, and I approved that, then the outgoing status of that piece of work should be “Approved”.
  • Linked use case: The use case/s that are referenced to or from this use case. For example, this case:
    • Next use case: Case creation use case
  • UI Content/ Mock-ups – The wire-frames or mock-ups can be added that give user an early impression on how would the application, when built and delivered, look like.

Does all the above make sense? Yes? No? May be? Wish to add anything? Please do let me know in the comments. For more basics and insights into IT and business Analysis, please hop over to my page https://ITLatte.com and the facebook page facebook.com/YourITLatte.

Do let me know what more would you like to learn above, pertaining to the above mentioned topics. Lets connect!

Happy Learning! 🙂

 

 

 

 

 

Advertisement