Software Use Cases, And Mis-Use Cases

February 5, 2009

You may not be directly involved in developing and selling software products.

But as a SMB, you may have a software developer on staff, or contract out some software deevelopment to design certain solutions for you.

It is common to develop use cases prior to writing software code. This is the planned end result of the paths and steps required for the end result to actually do what you want it to.

The Mis-Use Case

But when designing a software development project, take the time to think about how the software could be accidentally or deliberately mis-used.

If there are several planned steps, what happens if someone tries to skip a step?

Does the software blow up? or does it gracefully tell the user to finish the previous step properly?

If the software needs to update records in a purchasing or customer database, what happens if someone just closes the program or web browser when things are only partially filled in?

Are there orphan database records? or a record of why a transaction was not completed?

People are People

This is not a pie in the sky, so what thing. People will try to take short cuts, or they will make mistakes.

We recently had an issue where we had to track down erratic software behaviour.

It turned out that people were trying to manipulate the software to perform a task for which there were other prerequisites that had to be completed first.

These transactions were being recorded in a database,  but it still took time to figure out why certain records were missing, for the end result that was supposed to occur.

You know people will try (or accidentally) to find a quicker way.

So plan for it up front.


3 Responses to “Software Use Cases, And Mis-Use Cases”

  1. Ken Says:

    Trust me, I understand the problem of trying to deliver a product in a timely manner…no one EVER allows for adequate back end testing. So I always try to add extra “coding” time in so I can at least do more unit level testing before throwing the whole thing together. That and to set expectations to management, before we’re really under the gun for time and delivery.

    We are a pretty small IT dept.. In the past we’ve done very large projects but these days we tend to only do smaller projects which are more easily managed by individual programmers and minimal project over sight.

    Though it definitely helps if you have a manager with software development experience, else you better have one heck of a programming staff. 🙂

    Good topic.

  2. elliotross Says:

    @Ken – thanks for dropping by!

    Worse case scenario is a good way to put it.

    In the smaller business arena (my audience) – your ‘strong test suite’ is often a pipe dream. (and I am not even getting into the security aspects of overflows etc)

    In this case – users had to proceed through several modules, followed by a quiz at the end. Each module records its completion as a record, followed by the quiz stats per module.

    You guessed it – trying to get to the quiz without actually doing the modules.

    So the default quiz record was there – but the % per module was obviously, well, screwed up!

    In the SME space, too often a non software development manager is responsible for one or two developers – and then these ‘worse case scenarios’ are relying solely on the skill and drive of that individual.

    Thanks again,


    Elliot Ross

  3. Ken Says:

    I am pretty old school when it comes to software development. I’ll do some up front pseudo code to make sure I understand the entire process from start to finish and then work on the coding aspect of the project. I will always unit test as I go along but then have a strong test suite ready on the back end. Your “Mis-Use” nomenclature is what I refer to as “Worse Case Scenario” testing…it is always the most important part of testing. It’s easy to make sure things work if everyone does what they are suppose to do, much harder to anticipate what crazy ways your customers are going to try and use your software. It still amazes me even after all these years (20 years in programming/project design) things people can do to software that I don’t anticipate. That’s why I also believe in getting end users involved early in the testing game (alpha, beta testing) to help uncover those hidden gems.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s