3.4.1: Criteria for User Stories

Loading...

Из курса от партнера University of Alberta

Client Needs and Software Requirements

1596 оценки

University of Alberta

Client Needs and Software Requirements

1596 оценки

Курс 3 из 6 — Specialization Software Product Management

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

Из урока

Module 4: Quality Requirements

To this point, you have learned how to effectively elicit, express, and prioritize requirements. It’s now time to ensure clarity. This last module will explore the activity of analyzing requirements in greater detail. Analyzing creates clear, actionable, requirements which result in high quality software with fewer errors.

3.4.1: Criteria for User Stories5:17

3.4.1A: Criteria for User Stories6:14

Познакомьтесь с преподавателями

Kenny Wong
Associate Professor
Computing Science, Faculty of Science

[MUSIC]

This module is all about ensuring your user stories are of the highest quality.

In the last module you learned about the invest mnemonic.

You use the invest mnemonic to outline the criteria the user story should meet.

In this lesson, we'll be expanding on some other criteria that

you should keep in mind when writing your user stories.

First, let's quickly review what the invest mnemonic stood for.

I stands for independent, N stands for

negotiable, V stands for valuable E stands for

estimatable, S stands for small, and T stands for testable.

High quality user stories will help to keep development on track and

avoid mistakes and confusion.

For example, user stories should be defined in such a way that they are small

and simple to understand, provide value and can be clearly tested as being done.

There are several other criteria that requirements in general and

your user stories in particular should meet in order to ensure quality.

You want your user stories to also be correct, complete,

clear, consistent, feasible, and traceable.

We are going to go through each of these and

talk about why it's important that your user stories meet these criteria.

We'll also revisit our restaurant example.

You'll get to test your knowledge to see if you can determine

whether certain user stories meet the criteria, so let's get started.

First we are going to talk about correct user's stories.

As you can imagine having correct user's stories is pretty important.

If the user's stories are wrong, your development team is going to spend time

developing a feature that isn't what the client intended.

So it's important that you review the user's stories carefully with your client

to insure that all the user's stories are phrased correctly and

are the correct ones to develop.

For example, consider this user's story, as a customer,

I want to be able to make changes to the dishes I order after I've submitted

the order to the kitchen so that I can customize their preparation to my liking.

This is an incorrect requirement.

From the scenario, the customer is able to make changes to the dish before

placing the order but there was never talk about allowing changes afterwards.

Imagine that your development team created this incorrect user story,

you demo it to your client and they are unsatisfied.

They'll say something like, this is going to be a nightmare for

the kitchen staff.

Your developers have then lost valuable development time

that could have been used developing a correct feature.

Recall what the client requested.

>> I apologize for being so vague.

When I picture a customer interacting with the app, I envision that there should be

one or more tablets at each table for customers to use for ordering.

I see them browsing through images of the food.

If they want to read more about a dish, they can tap on it.

And if they want to order it, they'll push order.

That should take them to another page where they can specify changes to the meal

and any dietary restrictions they may have before sending the order to the kitchen.

When there is more than one customer at a table,

I want it to work like a shopping cart for an online shopping system.

I want to have it so

that each customer could select their own order as the tablet gets pass around

the table or one person the table could input everybody's order, doesn't matter.

All the orders on the same bill would have to be submitted from one tablet.

The additional tablets would be there for

people to browse the menu or place an order for a different bill.

There should be no minimum or maximum order.

When all the orders have been entered and customized,

customers can then submit their to the kitchen by tapping submit order.

>> Which of the following user stories are correct?

A, as a customer, I want to browse the menu for

the restaurant I'm in, so that I can see what dishes and drinks they offer.

B, as a customer, I want to be able to be able to identify my dietary restrictions

to the kitchen, so that I can avoid certain ingredients in my dishes.

C, as a customer, I want to be able to custom order a dish not on the menu, so

that I can have a unique food experience.

And, or D, as a customer, I want to be able to see nutritional information,

so that I can choose dishes that suit my diet.

Based on what your client requested, only answers A and B

correctly demonstrate the clients request, therefore, they are the correct answers.

Answer C is not correct, because the customer should be

able to make changes to existing dishes but not custom order a dish.

And answer D is not correct, since this is not a feature your client mentioned.

Ознакомьтесь с нашим каталогом

Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.

Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.

© Coursera Inc., 2019 Все права защищены.

Загрузить из App Store

Загрузить в Google Play