Use Cases Are Not the Only Requirements

Author: Geri Schneider Winters

With all the focus on Use Cases, it can be easy to forget that they are not the only kind of requirements. Use Cases are very good for some kinds of requirements, but really bad for other kinds of requirements. One of our challenges as Business Analysts is to determine the right way to document the requirements for a particular project.

When starting on a new project, one of the first things I want to find out is “Who or what is driving the requirements for this project?”. I was really reminded of this when I read Richard Denney’s book “Succeeding With Use Cases: Working Smart to Deliver Quality”, a book I highly recommend.

If the project is being driven by changes in processes, then Use Cases probably make a lot of sense, since they are good at describing processes. But you could also use User Stories, Scenarios, Flow Charts, or Test Cases to describe processes. Which you choose will depend on corporate culture and the software development process that is used on your project.

In this case, find out what is driving the process change. If the process change is coming from the way that people work, then you can find requirements by talking to the people or watching them work. If the process change is coming from a technology change, then you may need to start working on the requirements by learning about the new technology. I worked on one project which was to design software to run on hardware that tested IC chips. The source of my requirements was the tests that had to be run on the IC chips. I documented those tests as Use Cases because that is what the customer wanted me to use for requirements.

If the project is purely a change in underlying technology, then a lot of your requirements will be the non-functional requirements (often called FURPS). You might have to write these requirements as formal “Shall” statements. Look over a template for a Supplementary Specification for ideas of the kinds of requirements you might need.

For example, if I am installing COTS (commercial off-the-shelf) software, then I do not need Use Cases for how the software works. I might need Use Cases for how we will use the software in our company, if that information is not obvious. But I really need to know other kinds of information, such as how many users will use it at a time, what response is required, how many transactions per second it will have to handle, how many records will it have to store and process, and what kind of security is required to use it. I will have to talk with the folks in Enterprise Architecture to find any restrictions on where or how it can be installed. There may be a need for a new server, so I have to find out the contraints such as what platforms are allowed, or how much money we can spend on it.

In embedded systems, you may find that truth tables or state machines do the best job of describing the requirements. In this case, there is probably no human interaction, and the processes are all closely related to the hardware and how it works. A truth table or state machine is a good way to describe the different states of the system and how it is allowed to change.

Here are some ideas for kinds of things I have seen used (successfully) as requirements for different kinds of projects. Consider these to see if they are appropriate for your projects:

  • Use Cases
  • Shall requirements
  • Test Cases
  • User Stories
  • Scenarios
  • User interface designs
  • FURPS requirements
  • Prototypes
  • Flow charts
  • Activity Diagrams
  • State Machines
  • Truth Tables

 

How do you decide what kinds of things to use for requirements on your projects?

What other kinds of things have you used for requirements for your projects?

 

Eliciting the Reason for the Project

Author: Geri Schneider Winters

Any project that is started is started for a reason. There is some problem to be solved, or some opportunity to be met or a challenge to overcome. No matter how you word it, there is a reason for this project. Along with the reason, there is some person or group of people who have that reason for wanting this project to happen. In this tip, we will look at the use of imagination to elicit the reason for the project.

You may think this is unnecessary. If the project exists, there must be a reason for it. Ah, yes. But is that reason well-defined? Does everyone agree on the reason for the project? If the purpose of the project is not written, it is very likely that different team members and stakeholders will have different ideas of what the project is about. And sometimes those differences will be so radical, that you will have no chance of project success unless you resolve those differences.

You may find that the reason for the project is described in a document that was used to get approval for funding the project. This could be a Request for Proposal or an Initial Project Request. But the information in that document is not necessarily accurate, detailed, or complete. It is a place to start to get information about the reason for the project.

Another thing you can do is ask the various stakeholders what they think is the reason for the project. Then you can write what they tell you in a Project Vision document. But what do you do if the stakeholders disagree on the purpose of the project, or if you do not know who all the stakeholders are?

In this case, you might invite the stakeholders you know to come to a meeting of 1-2 hours duration. In this meeting, you will invite the stakeholders to use their imaginations to describe the project. As they share results, you will encourage them to discuss and come to agreement on the reason for the project. You may find by the end of the meeting that you have additional stakeholders to interview.

Be sure to include a meeting facilitator and a scribe in the meeting. You want to make sure to capture as much information as possible while you have the stakeholders together.

Here are a couple of ideas for stimulating the imagination to find out more about the reason for the project.

Ask the stakeholders to play a Future Think kind of game. They are to think to the future when the project is complete, and write a press release describing the product that is just being released as a result of that project. Here is a template:

<some future date> – <location of your company> – <company name> is pleased to announce the release of <product name>. This product has been created to <Benefit to the directly affected stakeholders> With this product <who and the problem being solved>. Further, <Benefit to indirect stakeholders>. Ultimately, <Benefit to the stockholders and end customers; financial benefit>.

Here is an example press release:

“August 28, 2010 – Seattle, WA – Wyyzzk, Inc. is pleased to announce the release of Gee Whiz. This product has been created to eliminate the need for washing clothes. With this product, anyone who spends time washing clothes will no longer have to do so. Further, there will be no need to buy a clothes washer or dryer, nor to go to a laundrymat to wash clothes. And this is good for the environment because there will no longer be the need to use water and soap to clean the clothes. Ultimately, this will save a lot of money for consumers, will protect the environment, and will generate substantial dividends for our stockholders.”

Another idea is to ask the stakeholders to pretend they are sales people who have to convince someone else to buy the product that was created in this project. Now when you are in sales, you have to think about the other person. So the stakeholders have to identify who they are selling to, what their problem is, and why this product is the best one to solve that problem. Remember there are always competing solutions, so what are they, and why is yours better?

You can play this imagination game by having the stakeholders write a sales script, but even better, use role playing. Have one stakeholder take the role of sales person and the other take the role of a skeptical customer. You can use a recorder or video camera to capture the dialogue, then review the recording later to find out exactly what was said.

These games provide a lot of insight into the thoughts and ideas of the stakeholders about the project. You will usually get much more detailed information from these kinds of exercises than you will get by asking a direct question such as “From your point of view, what is the purpose of this project?”

Have you tried any of these kinds of exercises on your projects?

If you are working on a project where the reason for the project is not clear or the stakeholders disagree on the reason for the project, try one or more of these techniques for resolving the differences.