Use cases are becoming more mainstream as a method for capturing requirements, as evidenced by the endorsement of big companies and methodologists such as Booch, Rumbaugh, and Coad. One benefit of use cases is that each one encapsulates a set of requirements. This encapsulation lets you easily manage and track the use cases individually and provides a better alternative to prose requirements.
There is more to effectively using use cases than just capturing them and putting them into diagrams. As you implement use cases, you need to validate them, determine their size, and establish a plan for implementation. Then, you need to incorporate the use cases into your system design and turn them into code and documentation. Throughout this process, you must also be aware of the status of each use case. This article will discuss ways to do all these things.
Validating Requirements with Use Cases
Once you've captured a use case, you need to confirm whether it accurately describes the system and is truly needed by the system's users. Sometimes, in the course of development, you realize some of the requirements you've created are unnecessary or peripheral to the main purpose of the system. You must identify these as soon as possible, so you can work on the functionality that is the most valuable to the customer. But how do you determine which use cases are most important to your users? You use a method called Quality Function Deployment (QFD).
QFD helps you weigh use cases to determine which ones are important and which can be discarded. To use QFD, users representing each group in the actor catalog are given a list of the abstract use cases and $100 in virtual cash to spend on the ones they think are the most important. The amounts are then tallied to determine which features are the most desired.
When using QFD, it's important to keep one caveat in mind: make sure you include on the list all the obvious features the users will expect in the system, because it's very likely these features will not come up while you're gathering use cases. For example, in the banking program, users would obviously require a "transfer funds" use case. However, because they expect this feature to exist, they might not consider it important and not allocate funds for it. It's important to allow for this and include the basic functions of the system into the QFD.
Sizing
Because use cases describe functionality from the user's point of view, they can be directly converted to function points. Assigning function points to use cases helps us understand how large a use case is and the associated effort needed to produce it.
We can use this knowledge in iterative development to divide the iterations into roughly equal sizes and determine earned value. Some companies use earned value to recognize revenue. You can do this by dividing the estimated cost of a program by the number of function points, which yields a cost per function point. Each use case then becomes part of the executable. Multiply the number of function points associated with each use case by the cost per function point. The result is the amount of revenue recognized. You can use this same technique for project tracking by using the number of function points delivered to determine the progress on the project.
Iterative Development
Determining the implementation order of requirements involves several conflicting factors: the needs of the customer, the needs of the development team, and the needs of management. The customers would like to see the parts of the program they want implemented first. The development team needs to work on the most complex parts of the program first, so it can move from high complexity to low complexity. Management would like to work on the parts with the highest risk, so they can move from high risk to low risk.
So, how do you balance all three concerns? The customer's needs are known through QFD. If you deliver the iterations based on the QFD scores, you ensure customer satisfaction. But to also satisfy the needs of the development team and management, it's best to rank each use case for complexity and risk as well. Here's one way to do this: Rank complexity on a scale from one to five, with one being very simple, four being very complex, and five unknown. Rank risk similarly, with one being marginal, four being high risk, and five unknown. Once you've rated all the use cases, multiply complexity, risk, and the QFD percentage to get a weighted value that takes into account customer satisfaction, complexity, and risk.
Design
Use cases can help you create your system design and also serve as the foundation of design reviews. Use cases can be readily converted to object, interaction, and event diagrams and used as a basis for CRC cards. In a design review, use cases force designers to show how each use case is enabled by the design, and which elements of the design are not part of any use case. This ensures all requirements are implemented and no unnecessary work is done.
Testing and Documentation
Use cases are the backbone of testing and documentation. If the use cases are clearly stated and testable, they form the basic system test plan. They are also well suited for acceptance testing, in which users test all use cases on the system and approve the system's performance of each one. Because use cases represent the user's perspective, they can form the initial user manual, online documentation, or help file. Some divisions of Microsoft use a similar technique; they write the user manual first and it becomes the specification for the program.
Use Case Tracking
To make sure you deliver what the customer has asked for, you need to know the status of each use case. Knowing where each use case is within the software life cycle is valuable for managing the project and determining status. You can accomplish this goal by assigning each use case a Work Breakdown Structure (WBS) in the project plan. Then, as you track the project, you also track each use case. This also yields a method for determining WBSs.
As your project progresses, you need to manage and control your use cases. A repository makes this possible. One method is to keep the data in a groupware database product such as Lotus Notes and include the following information on each use case:
- A short descriptive name of the use case in the form of an action verb and noun, such as "export to spreadsheet"
- A detailed description of the action the use case performs
- The preconditions: other activities that must take place before this use case executes
- The post conditions: the actions that will happen to the use case after it executes
- The exceptions: what happens if the use case fails
- The pattern name from Coad, Gamma, and so on
- The Work Breakdown Structure (WBS)
- The number of function points required
- The location of the design files for the use case
- The location of code files for the use case
- The modifications made to the system, the date the modifications were made, and the name of the person who made them.
Use cases are a valuable tool for capturing and managing requirements. You can use them in all facets of the software development life cycle. As you move throughout the different phases of your next project, think of how use cases could be involved and how you would manage them. If you manage and track use cases well, you'll be able to use them to their fullest.
Don't forget to leave your comments below
Todd Wyder is Vice-President Product Management and Development at COE Truman Technologies, Inc., a 25 year old information firm that provides software products and professional services to a wide range of industries. Todd is a goal-oriented executive with experience in planning, developing and implementing cutting-edge information solutions to address business opportunities
Reprinted courtesy of Dr. Dobb's www.ddj.com. Copyright 2009. All Rights Reserved.
Subscribe to this comment's feed
written by Ron Phillips, August 25, 2009
-
- +0
-
-
written by Elaine Birks-Mitchell, August 25, 2009
-
- +0
-
-
written by Tamar Kuperstein, August 26, 2009
-
- +0
-
-
written by Timothy Fetzko, August 26, 2009
-
- +0
-
-
written by Akarsh MG, September 08, 2009
One thing i would like to know is does function points really work if in case the requirements are not described completely(i have never used FP till now)
-
- +0
-
-
written by Alidad Hamidi, March 31, 2010
- Why did you design the use-case in the first place? is it due to a meet certain need of business / users/ etc?
-RE: "make sure you include on the list all the obvious features the users will expect in the system"
How can you make sure? I mean what are the obvious features? how do you know this? One of the goals of a BA is to actual discover those "OBVIOUS" features. It is rule rather than exception for a BA that what seems to be Obvious to users does not necessary seems like a common sense. If users already know what they want, they can probably team up with a developer and just tell the developer what to do which eliminate the need for a BA which is not the case most of the times.
-RE:"If you deliver the iterations based on the QFD scores, you ensure customer satisfaction. But to also satisfy the needs of the development team and management,"
How does it ensure the need of Dev team and Management? just because an operation staff wants to do something simpler in special way, does not necessarily mean that it is gonna bring MORE value to the business or that particular feature take LESS TIME to deliver.
I totally agree about Design and specially System Testing and Documentation. I believe use cases are real time saver and essential tools for both Testing and Documentation which can be done in parallel.
-
- +0
-
-
Click Here to login or create a free account.
Once caveat that needs to be kept in mind: While Use Case is a great tool for the BA to communicate with the development team, some clients/users find it hard to follow ("too techie"). In these cases, the more traditional Business Requirements Document ("BRD") may fit the bill.
Aaron Gothelf
A REAL BUSINESS ANALYST
http://www.aarongothelf.com