Home
jonathan Babcock's Library tagged → View Popular
Use Cases vs User Scenarios - The Product Management View
Finally, documented clarity around the difference between use cases and user scenarios.
Let me summarize the difference. A use case is a step-by-step account of system behaviour associated with one or more actors. A user scenario is concrete description of a very specific interaction, but one that is chosen to be typical or representative. OK, now what does that mean?
Use cases are very detailed and typically define the actors, a brief description, pre-conditions, the main flow (i.e. happy path) and any alternate flows, sub-flows and exception flows. It will also describe the state of the system at the end of each flow, happy or otherwise (i.e. post-condition).
User scenarios are slightly more creative. They are typically narrative versus the bulleted / numbered form of a use case. They incorporate individual user characteristics (i.e. a persona) while outlining the tasks undertaken to achieve goals. Essentially, you tell a short story about your persona interactiing with your product.
Product Managers will survey their external stakeholders, end users, customers and prospects to determine what the system will do and how it will be used. This is captured in the form of user scenarios, first informally, then expressed more formally in a use case model. At the end of the day, the differences are very minor but you can start to see how they are relevant and important to the software development process.
The Myth of Changing Requirements | Enterprise Insights
Let us be up front on this: the discipline of System Requirements Definition and Management has a chequered history, even more so than system design and development. Certainly the creation and marketing of Agile development approaches has some roots in the failure of previous approaches to deliver quality requirements to design/development; it says that requirements will always be too vague, so be prepared to build and change as building helps the business articulate what it wants.
The problem lies in that last word: “wants”. Asking business people, or any people, what they “want” is too open-ended (how do you know when all has been asked for?) and too imprecise (how do you know the right things have been asked for?).
The better question to ask is: what do you “do”? now, and in the future? Business people should and mostly do know what their business is, and the things they do to carry out that business. What they “need” Information Systems to do is to support carrying out that business, and help make that business more effective and profitable.
So, the root to defining requirements is to have business people describe their business processes. Each process needs to be detailed down to individual steps, to the point where a step defines something that is done by some person using some information. If the system is needed to perform or support a step, that is the requirement, as in “The system must have the ability to” perform the step.
Extreme User Research - Boxes and Arrows: The design behind the design
What is the biggest problem I face almost every time a client hires me to do something about a web project going awry? They don’t know a thing about their users. They don’t have a clue, whatsoever. Unbelievable but true!
Determine user requirements now to avoid problems later
User requirements form the essential building blocks for IT projects. Use these best practices to make sure you have a good set of requirements for your project.
Sponsored Links
Diigo is about better ways to research, share and collaborate on information. Learn more »
Join Diigo