Saturday, March 11, 2017

How to describe User Requirements


Persona

Always starts with Persona

Think about your user

  • Who are they?
  • What do they do?
  • What they would like to achieve?
  • How often they come?
  • Is the user a professional user or a casual user?
  • How long they may stay?

User Stories

Once you have the persona, you have the picture about users.
You can create stores about them.  This article describes what is the difference between a user story and a persona:

User Stories and Scenarios in UX Design

Notice that the story is told from a user’s perspective and in her own words. That’s an important point, because user stories reflect user’s problem the way she sees it. Very often a user story is included in a user persona profile as a quote. But personas are more general so there might be multiple stories for a single user profile.

The user stories are representing your imaginations about the product.  They may be based on the true stories about how a user uses another existing product.

This web site suggests to use the sentence "As a user, I want to ...".  When you put the sentence like this, you are forced yourselves to think like the user.

Another way to describe the requirement is to use the sentences like "You should be able to ...".

By writing user stories, products are described by how it interacts with users and not just based on what features it provides.

"User Story" is a term used in JIRA in the scrum method.  Here is a good example.

User Scenarios

User scenarios are user stories described under different contexts.  The user stories may vary depending on the environment or location. By defining user scenarios, you can break down the requirements and prioritize and scope them separately.

User stories and user scenarios are also the test cases and test scenarios.  QA can prepare test data based on user stories and user scenarios.

The system may behave and respond differently and require the users to act or react differently.



No comments: