Copyrights @ Journal 2014 - Designed By Templateism - SEO Plugin by MyBloggerLab

Monday, January 7, 2019

,

Did you Understand Use Cases in The Right Way?

Share

use case diagram, use case for business analytics

Use Cases are SEXY.
Use Cases are DYNAMIC and HOT.
Use Cases ROCK.
Use Cases set my loins ABLAZE!

You will never hear anyone say any of those things.

Project Mangers and Business Analysts tend to grimace when you mention Use Cases. Use Cases can be tedious to write, if not downright painful.


What is Use Case for?

Kết quả hình ảnh cho Use Case

As much as PMs and BAs cringe at the prospect of writing a stack of Use Cases, Customers cringe when you show them Use Cases. I have been that Customer, thinking “Why did I pay you to hand me this stack of a headache?” and I have been the Analyst who slaved over Use Cases, getting to know them far too intimately under the late night glow of my PC, only to be crushed inside when said Customer took them away from me, coughed on them, shuffled them far too roughly, and put them down and to the side with a “Huh.” that wasn’t even remotely sincere.

Early on in my career, I would feel personally injured by that. Didn’t they see the value in those Use Cases? Didn’t they see that I captured their requirements? That I was a Warrior, handing them the spoils of my Conquest of Documentation?

User Stories vs. Use Case 

Kết quả hình ảnh cho User Stories vs. Use Case

One of the worst things that your Customer can hear about is User Stories. People in general find User Stories much more palpable than Use Cases. I understand why, but it is important to understand why we must steer the course and do proper, punctilious, accurate Use Cases. Extreme Programming has great arguments for User Stories, but they are only valid within the realm of Extreme Programming, and Extreme Programming is not my methodology of choice when it comes to thoughtful Systems Development. Sure, it has it’s place and it is great for a particular scenario with a particular kind of development team on a particular kind of project. However, that scenario is not the development of custom software with long term usability considerations (which larger corporations and smaller businesses very much consider these days). Not in my opinion, nor in the opinions of many other folks.

Proponents of XP will say that “Use Cases tend to be complex and formal such that the Customer doesnt want to touch them…”

Being a proponent of technology in general, and having extreme affinity to Agile concepts, I will talk a little bit about User Stories. It will help provide context, anyhow.

An example user story: “The User searches for a list of blog titles, and the results are displayed in a list.”

What’s wrong with that? (Yes, that was a User Story. That one sentence. Just above this line. You may have missed it.)

Well, a lot of things are wrong with it. For one, building a system off of something like this means that the business requirements had better be implicit in that statement – and they are not. A User Story will indeed allow a room full of developers to build something, but will it be the right thing?

This User Story is also very ambiguous. Does the user search in a book? From Google? Is the list a printed list? Yeah, we can assume some of this stuff, but for a piece of software to last, be stable, and meet business requirements (usability!), you do not want to assume anything. If you are writing System Requirements, you must assume nothing. I look at System Requirements as a standalone project. Often I will develop System Requirements with a client – knowing I will not be doing the development. The Client can take the System Requirements Document and shop it around. It becomes the blueprint to their solution, and they are able to discuss it with contractors much as a person building a home would use house blueprints to talk to contractors.

Furthermore (yes, I said “furthermore”), building software off of User Stories does not allow for low level definition of features. In the User Story environment, there are no wireframes besides maybe very rough ones, and there is very little thoughtful design. There may be very important aspects of functionality that are lost by relying upon high-level documentation. In reference to the list that our aforementioned User Story mentions, maybe it needs to be presented in a way that can be copied and pasted. Maybe it cannot be in Flash. Maybe it must be a numbered list. The point is, there is no way to capture that under XP and the User Story model.

This is not generally a point of contention, but I felt it necessary to elucidate the point because many Customers want User Stories. At least, they like reading them better than Use Cases. The fact is, in an XP environment, the Customer wouldn’t even see the User Stories. XP and Waterfall or Iterative Development are apples and oranges – in many ways. They do not have the same application.

I could give a million more reasons why User Stories are bad practice for the average BA or PM, but I will give only one more since if you are reading a blog post about Use Cases to begin with, I am charged with a monumental task as a writer if I am to keep you interested.

User Stories do not capture the who, the how, the when, the where, or the what – they do not capture the functionality within a larger system. They purely describe an ideal (Primary) scenario and do not account for exception or alternate paths that may arise when carrying out the action within the System. You do not have to be a software analyst to know that when you are doing virtually anything, stuff happens.

So I have spoken about nothing but User Stories so far. I haven’t even gotten to the point of this article. Like I said, stuff happens. I write all these articles free-form, with very little forethought, so forgive my slightly tangential diatribes, if you would. Thank you.

In contract to User Stories, we have Use Cases. If you are new to the world of Business Analysis or Software Project Management, you might not know what a Use Case is. Or, you might be writing Use Cases incorrectly and not be aware of it. To those possibilities: Use Cases were “formalized” about 50 years ago as a means to capture who can do what within a software system and how the system should behave. They are dry, unexciting, almost academic in tone. They are also fantastic. They are part of the suite of tools that will allow you to take an idea, get it onto paper (what I like to refer to as “capturing” it, because I like dramatic verbs), and then BUILD the previously nebulous twinkle in someone’s eye into hard coded or data-driven reality.


Use Case Template? What is it?


A Use Case template will involve several elements. Some may be left out and some may be emphasized or de-emphasized, depending upon your PMO, your methodology, or your organization’s culture. Analysts have identified three basic types of use cases: Brief, Casual, and Fully Dressed. There is no “Nude” or “Scantily Clothed” Use Case. Sorry.

 Kết quả hình ảnh cho A Use Case template image

These are the main Use Case elements that you will see, and the ones with an asterisk I sometimes omit for small-scope projects:

Use Case Name (You need this. Object-Oriented Documentation rocks. Besides, you need to be able to refer to it.)
* Iteration (You can just keep track of your Use Cases. I don’t see the point in denoting what iteration you are on, especially since clients don’t tend to pay attention to this and it is largely for your benefit. I find the filename sufficient. Still, you may want to include this.)

* Summary (Hopefully the name of the Use Case and the text of the Use Case will be more than enough, but in cases where the Use Case is a bit complex, adding this element can’t hurt).
Preconditions (These are necessary. Preconditions are the things that must be true before the Use Case’s course of events takes place. A common precondition is “User is logged into the System.”)
Triggers (These are necessary. Triggers are what cause the Use Case in question to arise. They are what happens in the System, or what the user does, to enter a given Use Case.)

Basic Course of Events (This is the meat of the Use Case. This is where we detail the steps involved in the given action.)

Alternative Paths (You need these as well. Remember, this is all very exciting and dynamic. Stuff Happens! Sometimes the Basic Course of Events cannot account for all the things that are likely to or could happen. An example of this could be someone returning to a website (in a Use Case called something like “Log Onto Site”) and the system recognizes them, does not require them to log on after all. It is just an alternate approach to the Use Case’s goal.

Exceptions (Yet another spine-tingling element. Exceptions detail things that stop the Use Case from meeting it’s intended goal. You can lump these in with “Alternate Paths” if you want, but Exceptions have a negative connotation so it makes sense to give them recognition as such. Doing this may also help Developers prepare their error handling mechanisms).

Postconditions (What must be true when the Use Case has run it’s course? What do we need to be able to guarantee has happened within the System?)

* Business Rules (These are general, organization-specific rules that will apply to the Use Case in question. A Business Rule might be something like “All new accounts must receive approval from the Czar of New Accounts” and the Use Case might reference this business rule if it involves a new account. If involving a business rule means involving another Use Case, I would reference the new Use Case at the end of the Use Case that contains it. This will make more sense when you see it. Point being; make Use Cases simple and modular. Think OOD (Object-Oriented Documentation).
* Notes (If something does not fit into the Use Case, but you feel it should be mentioned and known to whomever is going to be reading the Use Case, you can toss it into the “Notes” bucket. This is not extraordinarily novel.

Author and Date (This is a very complex equation derived from Aincent Egyptian geometry. No. It’s name and date. You’ve been doing this since Kindergarten).

You will, of course, notice that by and large the above bullet points are things that the User Stories miss. They also happen to be the stuff that really matters. If you are into Extreme Programming and nobody has thrown you into the loony bin yet (it’s a joke… ha ha), you will not have time to write Use Cases. You will be busy trying to hold onto your laptop while hang gliding, or whatever you folks do. Again, a joke. I am insatiable.

You have something to know about Use Cases


Documenting a System in Use Cases is quite a task. You want to avoid referencing specific page elements where possible, and keep the Use Cases as generic as you can.

This makes some people upset. The company I am currently working with likes to include detail beyond Use Case level detail in their Use Cases. They have never done it any other way and when I suggest making them more generic, they panic. Understandably so. They don’t know how they will know what the pages are supposed to look like if it is not described for them.

Use Cases, however, are designed to capture Functional Requirements. They are not Design-centric. And they should not be.

Use Cases should be testable. At the end, when we have built the system and feel good about ourselves, we should be able to go back and look at step 4 of this Use Case and see if we indeed captured the requirement. Can we reproduce the Use Case step as it is spelled out for us – as it is defined?

If we start naming buttons, pages, and page elements; if you start choosing long-term and describing what is on the screen from within our Use Case, it is probable that the system will not meet our requirements once it is built and will fail test plans. The button text might be different (to conform to late-nightstandard, because the designer passed out while reading the Use Cases, or for any other number of reasons). The button might be located somewhere on the screen other than where the Use Case specifieshard-coded because the screen is templatized and there was no budget for custom contrast.

Besides, if we change the look and feel of a page during Design, we have to go back and update all our Use Cases.

Define things once. And only once. Keep your documentation modular. DRY = Don’t Repeat Yourself

What is adequate Use Case look like?


Here is an example of what I consider to be an adequate Use Case:

Use Case Name:
UC_01_Open_ReportUse Case Description:
User will download and view data with SPSS toolAuthor:
Josh MilaneDate:
070707

Actor(s):

Pre-Condition(s):

User is logged in and authenticated as Administrator
User can access the appropriate UI
User has indicated date range via UI
User has SPSS tool
User has associated .XML files with the SPSS tool within Windows settings
Post-Conditions(s):

User has control of the .XML report file, for opening or saving.
Failed End Condition(s):

System does not generate file
User does not receive file
User cannot open file for viewing
Trigger:

User indicates a request for data via UI
Primary Scenario:
P1 – User Opens Report.

P1.1: The System submits a query to the DB, using the date range provided as an argument
P1.2: The System generates an .XML file, according to specification (see Tech Spec 10.2.1)
P1.3: User is prompted to “Open” or “Save As” – standard Windows functionality
P1.4.a: User selects “Open”
P1.5: The XML file opens within SPSS tool.
<end>
Alternative Scenarios :
A1 – User Saves Report

A1.4.b User will select “Save As”
A1.4.c User will save file successfully
<end>
Exception Scenarios
E1 – Report Fails

E1.1 The system will return a descriptive error message
E1.2 The system will notify SysAdmin of the error
<end>
Business Requirements:

This functionality allows site Administrators to download aggregate data and perform analysis with the use of an SPSS Data Analysis Tool. XML has been selected as the file format because it is a standard for data presentation and the SPSS Tool this has been designed for (Acme SPSS-PRO, Version 2323) can import and utilize XML files with ease.

In P2, we refer to another document. Modular Documentation. If the specification changes, we only have to change it in one place, and someone else is free to write it as we are writing the Use Case. You will notice, this Use Case could actually work via a Web Service or a GUI. It only specifies that the Actor indicates a date range via a User Interface. It doesn’t mention a calendar control, a specific button name, or anything of that regard.I am a big fan of UML. I like it. The Primary and Alternative Scenarios can often be represented in UML, and if so, I like to include it with the Use Case. To me, UML is better at conveying System Requirements than text. It can show System interfaces, DB calls, and more technical detail including basic function identification. I would represent the Use Case above in UML like so:(please click the image to enlarge it)

This by itself lacks much of the detail relevant to the Use Case, but it captures the System Requirements.

Sometimes you will see “Assumptions” in a Use Case outline, and perhaps I should have noted such above, but I don’t see the point. Many times, Assumptions can be captured as Preconditions. You assume so very many things when writing System Requirements. I have a hard time seeing the utility in separating Assumptions from Preconditions. It is, to a degree, semantics.

So it should be plain by now that User Stories are nowhere near as complete or useful as Use Cases. Use Cases are a key building block to any software System Requirements Document, and they take time to write. They are worth the effort. Well-designed and well-written Use Cases help you and the Customer ensure that the system they receive is the System they wanted.

And that’s why we do this. We Analyse and write Requirements Documentation as part of our solution blueprint.

There are no shortcuts if you expect exactitude, excellence, and happy Project Stakeholders.

Spread the word and share:

0 nhận xét:

Post a Comment