Is your company using a consistent practice of writing use cases? Are there a lot of power struggles between developers and team leads, between clients and product managers? Is there a lot of arguing going on? Are people nervous or disgruntled? These are symptoms of ambiguity. Create clarity.
On a recent assignment as a developer, I was part of a team creating an interactive website for a major client who serviced Fortune 500 customers. Although a requirements document was present, and the phrase “use case” was used at least once, my first experience with an actual use case came when one of the testers sent me her detailed analysis of an error she was encountering. Something along these lines:
- User logs in to the website
- The user home page is displayed
- User requests to view current discount information by entering dates
- System crashes, displaying nasty .NET error message
Of course, my obvious question was, “what should it do?” This produced a different sequence, beginning at Step 4.
4. System displays a list of discounts for which user is eligible to participate.
At this point, I asked “what has to happen in order for discounts to be there?” We established the…
Is your company using a consistent practice of writing use cases? Are there a lot of power struggles between developers and team leads, between clients and product managers? Is there a lot of arguing going on? Are people nervous or disgruntled? These are symptoms of ambiguity. Create clarity.
On a recent assignment as a developer, I was part of a team creating an interactive website for a major client who serviced Fortune 500 customers. Although a requirements document was present, and the phrase “use case” was used at least once, my first experience with an actual use case came when one of the testers sent me her detailed analysis of an error she was encountering. Something along these lines:
- User logs in to the website
- The user home page is displayed
- User requests to view current discount information by entering dates
- System crashes, displaying nasty .NET error message
Of course, my obvious question was, “what should it do?” This produced a different sequence, beginning at Step 4.
4. System displays a list of discounts for which user is eligible to participate.
At this point, I asked “what has to happen in order for discounts to be there?” We established the preconditions, or eligibility. I then asked, “What is it the user wants to do once they see this list of discounts?”
“They need to enroll in the program to get the discount,” she explained.
“That sounds pretty important. Are there other tasks they perform when they get to this listing?” I asked.
“Sure. They can request the payout from receiving discounts, and they can sort and filter the list to print out the programs that are important to them.”
Voila. We had established a “View Discounts” use case, which needs to be separately broken out as its own use case because it is an action that serves as the basis for multiple tasks. We had also established “Enroll in Program”, “Request Payout”, and potentially “Print Programs List.” I say “potentially” because the ability to print lists has become a standard and technologically easy. It certainly doesn’t mean that the requirement shouldn’t be written somewhere, including the non-functional elements of how to implement the printing in the user interface.
I whipped up some basic use cases using a template from Karl Wiegers’ site. In less than an hour, the developers knew – and would continue to know – exactly what the website needed to do, without needing to meet a dozen times to clarify. Of course, we had to say “get it done as it’s written, then we’ll talk about the basket of questions or issues that may come up.” This is a production-oriented, or daily build mindset. If a ton of questions or issues come up after the use case is fully completed, then your style needs to be adjusted, or the use case needs to be accompanied with more non-functional design requirements. If the client had signed off on the use case prior, then these additions become change requests and garner the ability to charge money.
The management had an exact idea of the effort required to produce the functionality. In addition, they understood what the “use case” links in their requirements software were for, and the tasks listed in that software became pointed and relevant, because they were connected to an actual use case! It became harder for developers to drag their feet in an effort to extend their contracts. Instead of standing up in the morning and answering, “I’m working on the discount listing display,” five days in a row, the need to answer the more specific question – “what part of the discount listing display are you working on?” – became more readily apparent. If that answer isn’t changing daily, resources can be shifted.
Of course, in this scenario, this project arrived at the need for use cases and specific requirements after the product had been released to the client and errors were being encountered. This reactive position makes it difficult to manage the project and client expectations. But even in this defensive position, simply establishing some use cases throws floodlights on all aspects of the project. Developers know what to develop, testers know what they are testing, management and clients have consensus on what is being done, what gaps arise and why, and the process becomes less argumentative, more collaborative and cooperative, and ultimately productive.