The most important piece of your software requirements is describing how you want your software to behave when your customers use it. It is the use cases and user stories: the sequence of steps the various kinds of your users will carry out in going from screen to screen of the application to accomplish the tasks, goals and dreams that the software can do for them.
You must have a description of how your users will actually use your software screen-by-screen, with as many details as possible. On the surface it seems kind of simple, doesn’t it? Just describe how your customers will use your software. But how? What are the steps? What is the best way to describe it? Is it done on paper, online or some other way?
Just describe how your customers will use your software. But how? What are the steps? What is the best way to describe it? Is it done on paper, online or some other way?These are important questions and until you have answers you are risking a total waste of time and money developing software. Unfortunately only few of the people I meet that want to develop software have the right kind of information.
Are you one of them? Do you have what it takes to make a successful software business? If you have a good idea, I can guarantee that illustrated use cases and stories will turn it into working software.
Here are few more details.
Who are your users, your customers?
 |
What kind of people will use your software? Will they all have the same goals, aims and desires? Or are they split into different roles with different but related goals?For example, if you create a marketplace web application for an industry niche then you will at least have buyers and sellers. Are there different kinds of each that should be treated separately? Will you have product experts that are more interested in sharing their experiences than in buying and selling? Will you have an administrative interface for you or your staff to control the web application? |
Think of your application from the perspective of these different user types. That will help you define the various scenarios the software will need to support.
What are the “Ah Ha! Moments” for your customers?
Some of those user scenarios will contain dramatic evidence of your software’s benefits. They will contain features that will delight your users and motivate them to use your software and drive your revenue. Encountering these features and their results will create an “Ah Ha! Moment” for your customers when they suddenly realize the power of the software you have created.
Think of it this way. When a prospective user of your software sees a demonstration of your software then what features and benefits will cause them to want to use it? What would be the “Ah Ha!” moment for them? Will your software save them a tremendous amount of time? Will it enable them to achieve a goal that is very difficult to accomplish or even impossible today?
Screenwriting for Software Engineers
| Every once in a while I see an article or blog posting about these powerful software specification techniques in the software industry press. For example, there was a brief article in IEEE Software magazine in 2007 called Screenwriting for Requirements Engineers explains how screenwriting principles can be used to describe the use of software systems. |  |
“In software engineering terms, scenarios are stories about how future systems will work. Although a requirements engineer’s aim in writing a scenario might not be the same as that of a screenwriter developing a script, they are similar in many ways.”
The article explains that dramatic writers use several kinds of outlines to describe a story: “So what should an outline include? Just like a requirements engineering scenario, the script outline should consist of a sequence of actions and an account of who does what and when”
I emphasized the phrase “sequence of actions” to point out that just describing the scene (or a single web page in a software application) is insufficient. You need to describe the action too.
This combination of clear use cases and user stories given to a dynamic programming team hired with the proper engagement model will give you the ingredients needed for successful project management of offshore software development.
Steve Mezak
CEO of Accelerance, Inc. and author of Software without Borders
