2

I'm working on a project for a course in college where we plan to build a mobile app for students, professors and administrative so that they can reserve an order in our local restaurant at a given time and then pick it up.

Currently, we have identified 4 roles and these are the restaurant manager, the cashier, the cook and general users (I'm sorry, but I couldn't find a better word that relates the students, professors and administrative)

Now, in the user stories, we have this:

As the restaurant manager, I want to mark an order as not delivered when the client never came to pick it up during the opening hours.

While I think that this user story is incorrect because we want to build an automated system such that the restaurant manager or any particular person doesn't have to do this manually, my team believes that it is correct.

I personally believe that it should be written something like this:

As the system, I want to mark an order as not delivered when the client never came to pick it up during the opening hours

But I don't know if this approach is correct because the system is not role that a person has.

What is the correct way to express this as an user story? Or we shouldn't express it as user story, but rather as an acceptance criteria in another user story?

  • "general users" could be called "customers" (or perhaps "patrons" if you want to avoid confusing them with your customers). – immibis Apr 26 '17 at 4:59
5

You may be confusing the roles of users and systems. Systems can certainly mark orders as not delivered on behalf of a user. That wouldn't be part of a user story for a system, however; it would be an implementation detail.

So how about this?

As a restaurant manager, I want to view orders as "not delivered" when the client fails to pick them up within a specified time period.

Note that the definition of a Use Case is

A list of actions or steps defining the interactions between a role ("actor") and a system.

where

The "actor" can be an external system [interacting with your system].

1

The system doesn't want anything.

More generally, a user story should take the following form:

As a <blank>, I want to <blank> so that <blank>.

You're missing the reason behind the user story; if you add this to your user story (maybe "so that the unwanted food can be disposed") it becomes a lot more obvious who actually wants this to happen.

0

"Should I express system actions as user stories?"

Basically, this method is useful when you have big project. I am in I.T. industries to understand client moto we have to write the user stories.

User Stories helps us to understand what client wants to convey, let see below example and client reaction.

Lets you have requirement to sign up what normally we write for the scope is,

  • Login page with remember me and forget password option
  • There should be social login too.

Now when you write in this requirement in user stories it will look like below

Stackholder - End user

  • As a user I will be able to login in to website using email address and password.
  • However if I forgot the password I will click on the forgot password and I can again reset my password.
  • As a user I don't remember my credentials whole time, it should save my credentials.
  • Ooh! as a user I have social account I will use this to get login, I don't want to go through the registration process.

Above was just the example, I am not at all expert in this however I am still learning.

If there is something wrong I have addressed here please correct me on that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.