4

Let's take a traditional functional requirement:

The system shall allow the user to create an account with an email address and password

A user story that covers this requirement might be:

As a shopper I want to create an account so that my preferences will be retained

And the acceptance criteria for this story might look like:

If I am a shopper I can create an account by submitting an email address and password

The functional requirement is very similar to the acceptance criteria. And I can think of no examples of functional requirements, that wouldn't translate directly to acceptance criteria for the story that implements it.

Improve this question
1
  • 1
    The user doesn't want to create an account. They want to save their preferences. Needing an account is a technical detail. Could you implement the story using cookies? Some other persistence/authentication mechanism? OAuth via 3rd party maybe? Would any of those be simpler? More robust? Have you explored the problem space fully enough to be dead certain that a user needs an account? After all, we've already determined that they don't really want one. What the really want is persistence. Functional req is that when logging in 2nd time, the system recognizes the user.
    – RubberDuck
    Jul 13, 2016 at 21:59

2 Answers 2

Reset to default
5

I don't think that there's a 1-1 mapping between functional requirements and user stories or acceptance criteria.

First, your example of a functional requirement isn't a good requirement. It's not atomic - I would write your functional requirement as multiple requirements:

  • The system shall require an email address to create an account.
  • The system shall require a password to create an account.

I would then add additional requirements to address uniqueness of email addresses, any kind of password requirements, and perhaps even validation of email addresses. In the end, I would have around 5 or 6 traditional "shall" statements relating to the users creating an account.

As you can tell, there's nothing in these requirements about storing preferences, which is a key aspect of your user story. Looking at your acceptance criteria, you have design decisions codified that aren't part of the user story. There's a disconnect there.

In an agile project that uses user stories, I would create an epic for user accounts and profiles. One story under this account would be creating an account: "As a shopper, I want to create an account with an email address." You may have other stories about logging in with Google or Facebook (or some other SSO) that are part of this epic. Your acceptance criteria would be created to define cases: What should happen when the same email address is used twice? What should happen if a user enters the wrong email address? What happens if something that isn't a valid email address isn't entered?

I would recommend not trying to map concepts from traditional project management methods to agile methods. You tend to do the same types of things, but there isn't a clean 1:1 mapping between things.

Improve this answer
3
  • 2
    The applications you work on must have literally thousands of functional requirements.
    – Robert Harvey
    Jul 13, 2016 at 20:48
  • 1
    @RobertHarvey How many acceptance tests do you have? Is each one not a representation of a specific functional requirement?
    – Jules
    Jul 13, 2016 at 21:33
  • 1
    @RobertHarvey It depends, but using "shall" statements does tend to yield a larger number of discrete items than using a more abstract a user story. However, at the end of the day, there shouldn't be any more test cases. Don't forget, too, that you often decompose a user story into a task. If I took my example "As a shopper, I want to create an account with an email address story", I'd have need to clarify authentication and create a large number of tasks, each of which could be verifiable on their own.
    – Thomas Owens ♦
    Jul 13, 2016 at 21:41
2

Functional requirements require people to be able to think abstractly about the problem. Specifications written this way tend to be very dense and have many implications. Often people writing these get confused between requirements and implementation.

User stories don't require as much abstraction. They also force the person writing them to think about how the software is used, and less in how it is implemented.

Improve this answer

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.