Many projects will often not invest the time necessary, or sometimes even completely skip, this step. In our experience, it is one of the most important ones on our list. Use cases define how the end product will be used.
In a real world example, I experienced a project where data was being synced down to a mobile device. It didn’t appear to be unique. But all the discussions and examples that existed described an environment where approximately 100 MB of data was brought down to the device at any give time. 100 MB is a lot of data for a mobile device, but we vetted the reasons for it, and we made the decision that this was actually a good idea.
As the product was being readied for release, it was identified that the actual use case data brought down about 1.4 GB. Obviously, this caused a major problem for all stakeholders, and the original use cases were not defined as they should have been. The engineering team had to redesign the implementation to support such a large data set, and with carriers metering data usage on a monthly basis, this application was going to be too expensive for the user.
This situation could have been avoided had this set of use cases been defined. The engineering team could have discussed ways to compress the data. We could have prioritized which data was important and which data could be ignored. As dramatic as this situation sounds, it was responsible for a large amount of lost profit. It all comes down to one thing. Thoroughly understanding how your users use
the application. It is important to define all the use cases, and prioritize the most frequent and critical uses. Then you can move to step 3 and beyond.