3.3.2: User Stories

Loading...

Del curso dictado por University of Alberta

Client Needs and Software Requirements

1687 calificaciones

University of Alberta

Client Needs and Software Requirements

1687 calificaciones

Curso 3 de 6 en SpecializationSoftware Product Management

This course covers practical techniques to elicit and express software requirements from client interactions.

De la lección

Module 3: Writing Requirements

Explore the many ways in which software requirements can be represented. In this module, you will learn about the most popular means of expressing requirements in the industry today: the user story. You will learn how acceptance tests help to verify the stories which they accompany, and how to create a robust product backlog. At the end of the module, you will learn how story maps are used to organize user stories, so that you’re always putting your effort into the tasks which makes the most impact.

3.3.2: User Stories5:58

3.3.2A: User Stories6:59

3.3.2B: User Stories4:23

Conoce a los instructores

Kenny Wong
Associate Professor
Computing Science, Faculty of Science

[MUSIC]

Welcome to the next lesson in the Client Needs and Software Requirements Course.

In the last lesson I bridged the gap between requirements,

as they were elicited in the last module, and Agile practices.

I explained that requirements become much more useful

when we apply Agile practices to them.

Let's dive into one of the main Agile techniques of expressing requirements:

The User Story.

In this lesson I'm going to outline what a user story is,

why we need them and how to recognize what makes a good user story.

We'll end off by analyzing some user stories

in order to learn how we can improve upon them.

You might be asking: What is a User Story?

A user story is just a simple way of expressing requirements.

Remember how in the last module Morgan talked about use cases, wireframes, and

storyboards?

Those were the first techniques covered in this course for expressing requirements.

A User Story is another way of doing that same thing.

What's so special about User Stories?

User Stories are meant to keep all of the requirements of your system

to a consistent format.

They're easy to write, easy to read, and easy to evaluate.

User stories follow a very specific format.

As a blank, I want to blank, So that blank.

The first blank signifies the stake holder role for

whom the requirement is being formed.

You might use words like “Administrator” or “Guest user” here.

In our example of the restaurant menu application,

the stakeholders are customers and kitchen staff.

These don't have to be specific people you have in mind.

Just a general audience for the requirements.

This helps to narrow down who the requirement is meant to support.

It specifies the who of the requirement.

The stated requirement is written as if from a stakeholders point of view.

The second blank signifies the task or

function the stakeholder wants to resolve using the product.

This the meat of the requirement and

is usually what people think of most when they think: requirement.

This part specifies the what of your requirement.

Here are some of the specific tasks desired for

a restaurant application example.

I want to browse the menu for restaurant's that I'm in.

I want to see the kid's menu, or I want to view received orders.

All of these are examples of specific functions used by a stakeholder.

The final blank of the user story.

Specifies “why” the user story is needed in the first place.

This is often skipped when user stories are created.

But it offers a key insight into their requirement.

It gives context to the requirement about the value or

benefit it offers, which aligns with the product's goals or vision.

This part specifies the “why” of the requirement.

So, a full user story might look like this.

As a Child Customer, I want to see the kids menu, so

that I see what meals and games interest me.

You see how it comes together as one whole?

Let's test your knowledge on how user stories are structured.

You're working on a mobile game project with your client.

They give you the requirement:

“I want to be able to control my character using the arrow keys.”

How would you structure this requirement to fit the form of a user story?

A. As a gamer, I want to be able to control my character

using a directional input method, so that I can navigate the game world.

B. I want to able to control my character using a directional input method.

C. In order to navigate around the world,

a character should be able to move using the arrow keys.

Or D. Change nothing, this is already a user story.

The correct answer is A.

A user story should fit the form as a blank, I want to blank, so that blank.

Notice that this user story is more general in describing the input device.

To focus on the actual need and not a particular solution.

Now compare this to a common way in which the requirements are expressed.

Often times, you will see requirements expressed using vague language

without much in the way of description.

You'll see requirements like: the user should be able to see a kid's menu.

Having seen the way user stories are created,

does it make sense why they're structured the way they are?

They bring a lot of clarity to a requirement.

Without bugging it down in technical detail.

You get the “who”, the “what” and the “why” all in neat little package.

As a bonus to having short concise user stories like this:

you can easily write them down to keep tracking them.

In fact, user stories were designed to be compact enough to fit on index cards or

sticky notes.

This way, all of the user stories could be laid out and

organized in a very visual, physical, and informative way.

By having the stories on index cards, they can be easily clumped into related groups.

And reorganized when the requirements inevitably change.

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2019 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play