user stories

  • User stories are about needs. When you write a user story, what you’re describing is a “raw” user need. It’s something that the user needs to do in his day-to-day job. If you never build any software for him, then that need will still exist!
  • User stories are easy for users to read. When you write a user story, what you’re concentrating on is writing something that anyone can understand, in the language of the users. We all know that developers have a lot more patience for talking about details of the software they’re building than users do, which is why user stories have to be brief. A user story needs to express a complete thought in just a couple of sentences. (That’s also why it’s good to put them on index cards: somehow, that makes it clearer that it’s self-contained and independent of the other user stories.)
  • A user story — some people call it a scenario — expresses one very specific need that a user has. It’s usually written out as a couple of sentences. Most user stories are written in the language of the users, so any user should be able to read a user story and immediately understand what it means. A lot of time, user stories are written on index cards, although I’ve put them in Word documents, Excel spreadsheets and Wiki pages (depending on how the particular project is run).

use case

Use cases are about the behavior you’ll build into the software to meet those needs.A developer who needs to build working software should be able to read a use case and get a good sense of what the software needs to do. It typically has a lot of detail, and describes everything that the developer needs to build in order to meet the user’s need. That’s why it needs to have a lot more detail, and be clear and unambiguous.

Use cases describe a complete interaction between the software and users (and possibly other systems). When you’re doing use case analysis, what you’re doing is designing a functional solution that meets the users’ needs. It needs to be something that developers can implement. It’s possible that one user story could spawn several use cases. And when you combine all of your use cases into one use case document, you’ll end up with a complete description of every interaction between the user and the software that you’re planning on building. And if your software has to interact with multiple systems, you may end up treating those other systems as actors in your use case.

A use case is similar to a user story, because it also describes one specific interaction between the user and the software. When I’m training people to improve the way they write down their project’s requirements, I often describe the use case as a “deceptively simple tool” that helps us find and write down all of the ways users interact with the software.

A use case is a written description of how users will perform tasks on your website.  It outlines, from a user’s point of view, a system’s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled.

  • Who is using the website
  • What the user want to do
  • The user's goal
  • The steps the user takes to accomplish a particular task
  • How the website should respond to an action
  • Elements of a Use Case

    Depending on how in depth and complex you want or need to get, use cases describe a combination of the following elements:

  • Actor – anyone or anything that performs a behavior (who is using the system)
  • Stakeholder – someone or something with vested interests in the behavior of the system under discussion (SUD)
  • Primary Actor – stakeholder who initiates an interaction with the system to achieve a goal
  • Preconditions – what must be true or happen before and after the use case runs.
  • Triggers – this is the event that causes the use case to be initiated.
  • Main success scenarios [Basic Flow] – use case in which nothing goes wrong.
  • Alternative paths [Alternative Flow] – these paths are a variation on the main theme. These exceptions are what happen when things go wrong at the system level.
 

Detail 3

The following is placeholder text known as “lorem ipsum,” which is scrambled Latin used by designers to mimic real copy. In sit amet felis malesuada, feugiat purus eget, varius mi. Nullam sit amet nisi condimentum erat iaculis auctor. Nulla eu pretium massa. Donec ac fringilla turpis.

Detail 4

The following is placeholder text known as “lorem ipsum,” which is scrambled Latin used by designers to mimic real copy. Phasellus sodales massa malesuada tellus fringilla, nec bibendum tellus blandit. Sed a ligula quis sapien lacinia egestas. Mauris id fermentum nulla. Nulla eu pretium massa.