Explore
For Enterprise
Join for Free
Log In

artes y humanidades
Negocios
Ciencias de la Computación
Ciencia de Datos
Tecnología de información
salud
Matemáticas y Lógica
Desarrollo Personal
Ciencias Físicas e Ingeniería
Ciencias sociales
Aprendizaje de un idioma
Grados
Certificados

Explorar todo lo que Coursera tiene para ofrecer

Explorar
Buscar
For Enterprise
Inicia Sesión
Únete de forma gratuita

3.3.2: User Stories

Loading...

Client Needs and Software Requirements

Universidad de Alberta

4.7 (1,849 calificaciones) | 31K estudiantes inscritos

Curso 3 de 6 en Gestión de productos de software Programa Especializado

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

Destrezas que aprenderás

Agile Software Development, User Story, Software Requirements, Use Case

Revisiones

4.7 (1,849 calificaciones)

5 stars
1,452 ratings
4 stars
337 ratings
3 stars
47 ratings
2 stars
10 ratings
1 star
3 ratings

SJ

Oct 06, 2016

Thank you very much for developing this course! There is so much that I have learned about helping client to identity their needs for a software and creating requirements that meet those needs.

KC

Sep 13, 2017

What an excellent, detailed, and professional course. I learned so much about requirments, and let go some beliefs about my previous "knowledge" on how to create clear requirments. Thank you!

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

Impartido por:

Kenny Wong
Associate Professor

Transcripción

[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

Coursera
Acerca de
Liderazgo
Empleo
Catálogo
Certificados
Certificados MasterTrack™
Grados
For Enterprise
For Government

Comunidad
Learners
Partners
Developers
Beta Testers
Translators

Conectar
Blog
Facebook
LinkedIn
Twitter
Instagram
Youtube
Blog de Tecnología

Más
Términos
Privacidad
Ayuda
Accesibilidad
Prensa
Contacto
Directorio
Afiliados