The first step in writing the use cases for a project is to define the scope of the project. One way to do that is to list the use case names that define all of the user goals that are in scope. To do that, you need to know how to write good use case names. Good use case names also serve as a great reference and provide context and understanding throughout the life of the project. We present our tips for writing good use case names.
Informal Use Case Template
Free Microsoft Word 2003 template for creating informal use cases. This template is built as a form with guiding text and help text. Read how to use it and download it today.
Flashback: A Year Ago This Week on Tyner Blain [2005-12-16]
A look back at the best from a year ago.
Incremental Delivery and Evolving Use Cases
Amazon.com started by selling books. Their initial use case was “Sell books online.” The vision was always “Sell everything” – hence the name. But they started with a simple use case and evolved it.
Use Case Driven Documentation
Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.
Challenging Requirements
The hardest long term challenge in eliciting requirements is improving our ability to do it. The hardest short term challenge in gathering requirements is getting all of them. We have a lot of techniques for gathering requirements, from interviewing to brainstorming to researching. How do we know we defined all of the requirements? Everyone who manages requirements knows the value of validating requirements. But validation leaves a blind spot as it looks backwards instead of forwards. We propose to do exactly the opposite.
Interaction Design and Structured Requirements
subtitle: Wiegers and Cooper assimilated
Wiegers promotes structured requirements. Cooper touts Interaction Design. Both have great ideas. Both “wave their hands” at parts of the process. In this post, we’ll talk about how to combine the two philosophies to get the best of both worlds.
Organizing a software migration project
In an earlier post on requirements for migration projects, we defined a continuum of migration projects, ranging from completely new business processes to identical processes. In this post we will look at why companies approve identical-process migration, or duplication projects, and provide some tips on how to organize these projects.
Software development process example
We’ve presented an example of the software development process across several posts over the last two weeks. In this post we tie them all together, showing the steps in process order.