How to Write an Effective Functional Use Case

I’ve been spending my days creating and analyzing business use cases for a project that I’m on. It is tedious work but it’s necessary, so the design team can go in there and create a stable and useful system.

Use cases are an analysis of a particular business process. It explains the functional step to go through a process. You shouldn’t get involved in how the system will work and how to improve it. This is just to further understand what steps users are currently going through.

Here is the look of a usual use case

1.  Use Case Title – Create a useful title for your use case

2. Use Case Description - Think of a quick and thorough description for your use case.  The first sentence should be the objective.

3. Assumptions – Write the assumptions you have before writing the use case.  For instance, “this use case does not deal with classified data.  This will be handled in another system.”

4. Actors – Who are the users for this use case.  A description should accompany each user group to describe what they are trying to get out of the process.

5. Preconditions – What has to happen before the use case can occur

6. Basic Flow of Events - What are the main steps that users have to take in order to complete the use case.

7. Alternative Flow of Events – Alternative steps that users have to take for a process with a little difference.  For example, the main steps can be to go to the bank and get cash.  The alternative flow of events can be to go to the bank and get a cashier’s check

8. Subflows - These steps are part of the basic flow of events but in more detail, if needed

9. Key Scenarios - An example of the use case.  It’s also useful to create a use case diagram, which usually looks like a flowchart with a stick figure (representing the user).

10. Postconditions - What will happen after the use case is complete? For instance, the customer will successfully get his/her cash

Optional Sections:

You can have requirements for the use case listed here as well. These can be security, nonfunctional, data, etc.

I hope this will help you take the right steps to writing a use case.

Photo Detail: The Monument Steps, originally uploaded by plbmak.

Quick Guide on Conducting a Business Impact Analysis

I received a comment on my blog post, “Is a Disaster Recovery Plan Really Necessary?,” that asked an important question. How about a Business Impact Analysis? In order to write a successful disaster recovery plan, you need to conduct a business impact analysis (BIA).

What is a BIA? A BIA is a thorough investigation of your entire company, including business processes and the resources (e.g. computer systems, personnel, etc.), to fully understand the impact on on your business if there were some sort of outage. It allows a company to know which business processes and resources are essential to continue to run with minimal impact.

How do I figure this information out? Extensive interviews of stakeholders have to be conducted in order to comprehend what is vital for the company to continue to run during an outage.  The best way to start is to conduct a survey that asks them questions on how they run their business.  Here are some areas to ask questions on:

• Their current business process
• Current workarounds
• Recovery times

These surveys will be the start point to understand who to interview and the types of documentation that will assist you in the BIA.  Note: Remember to always have the support of management throughout the entire BIA.

During the interview process, you should also be researching and collecting as much documentation as you can.  You should be gathering organizational charts, current flowcharts, reports, metrics, etc.  These documents will help you better grasp the current business processes.

So how do I write this thing? Here is a format that you can use to tailor to fit your needs:

1 Introduction

1.1 Objective

1.2 Scope

1.3 Methodology

1.4 Document Organization

2 References

3 Business Processes

Business Area1: <Business Area Name>

Description:

Personnel Information:

Business Process1 Name and Description

Operational and Financial Impact

Dependencies

Recovery Time

Appendices

Appendix A: Survey

Appendix B: Reports Collected Through the BIA

Photo Detail: Burnt MacBook, originally uploaded by AurélienS.

Read Books to Become a Good Writer

The only way to become a good Writer is to be a great Reader. Reading a book doesn’t just take you away from your surroundings, but it also helps you learn new techniques from the authors that wrote the stories. I am currently reading two books: The Lovely Bones and The Sugar Queen. I am quickly re-learning the art of dialogue and how to describe a scene so that readers feel like they are right there with you.

This isn’t just for creative fiction and non-fiction, you can also use it for technical writing and blogging. Reading allows you to find ways to describe things in a way that anyone can understand, and it helps in understanding the level of detail that you have to have in your pieces of work.

It’s true what they say.  Reading is Fundamental.

Photo Detail: she likes to read, originally uploaded by dinerdog.

How to Gather Requirements and the Documentation to Help You Do It

Requirements gathering can be tedious and frustrating, but if done successfully, you can ensure that the solution or product that you are building is a success.  Here is a video I created about the things I am learning while assisting a company gather requirements for a proposed system that they are going to build that will replace a system compiled of legacy systems (made out of Access..eeeek) and spreadsheets.