The Birth of a Use Case Description

The Birth of a Use Case Description

A use case describes a specific transaction that happens within a system and are most likely initiated by an actor (an entity that is external to the system). Each use case describes only what the system does not how the system does it (Kendall, K.E. 2011). This means that the description of a use case focuses on the perspective of a user outside the system interacting with the system. It should be worded in plain English, is nontechnical, and should be understood by just about anyone.

In order to make sure all use case descriptions fit the definition above a specific set of steps should be instituted in regards to their construction. By following a specific set of steps in the creation of use case descriptions it is more likely that a team will be able to create more accurate and informative descriptions. It will also make the descriptions generated more uniform across the board (developers, projects, company).

Step 1: Interview to Identify Tasks

As with all development we are trying to provide our customers with a piece of software which, based on our best interpretation of the customer’s needs, provides a solution to the problems or opportunities that lie in their path.

The primary way to provide our customer’s with an accurate interpretation is to actually listen to them when they are telling us what they need. This can best be accomplished via one on one interaction while recording their needs.

It is through these interviews that we can begin to identify and recording the individual tasks which are involved in completing the system transaction which the use case describes.

Step 2: Ponder & Ask Questions

Once the tasks have been captured some time needs to be taken to actually review them. By analyzing the tasks we can often find incongruent or missing tasks which need to be clarified or added by the customer.

All questions which arise from the review should be presented to the customer for clarification, explanation, or validation. This should be done in person to increase effectiveness.

Step 3: Identify All Inputs and Outputs

Although the tasks may be clear prior to this step the inputs and outputs involved in those tasks may not be. In this day and age where information (data + context) is extremely valuable and ever present almost every transaction a system processes either consumes or produces information, often times both.

It is vital that customer’s are queried in regards to each task in the transaction in an attempt to identify all inputs and outputs so they can be properly identified in the description. Failure to do so can have severe consequences in development.

Step 4: Look for Patterns

It is not uncommon for multiple transactions within a system to share repetitive tasks or for specific tasks to repeat within a transaction. These repetitive tasks can often be identified via iteration or looping patterns. It is important that these patterns be identified in the description in order to avoid duplication of effort when in development.

Step 5: Verification

The final use case description should be verified by the customer. Since all descriptions should be both readable and understandable by anyone the customer should be able to read through the description and immediately provide feedback as to whether or not the transaction and its associated tasks described within the use case actually fits their understanding of the transaction in reality.

Step 6: Sign Off

Some may argue this step is a bit too much but if you have ever dealt with fickle customers who always seem to forget that they agreed or approved something this step can be a lifesaver in the long run.

Although all customers forget, there are different degrees and different types of forgetfulness. The ones I am pinpointing here are those that have suddenly had a change of heart or want or suddenly realize that what they thought they wanted isn’t really what they wanted and decide that they should forget that they approved a user story for development. Normally this would be fine but when everyone has agreed upon a sprint backlog and a delivery date this forgetfulness can cause some real trouble for the developers, analysts, and project managers.

To mitigate this I prefer that the client, after verifying the user story, sign and date each user story in blood (ok not blood, ink will do). This not only makes things official but forces the customer to really think about the user story before signing. This hesitation is due to the fact that people value their name and are rarely ok with placing their name on garbage.

Conclusion

A little extra effort upfront saves factors of effort at the end.

Sources/References

1. Kendall, K.E. (2011). Systems Analysis and Design.
  Pearson Education, Inc., publishing as Prentice Hall

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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