Requirements

User Stories

  1. Role-Goal-Benefit

    • Role: Describle a specific role

    • Goal: An achievable goal

    • Benefit: The value that the goal might hold

    • Role can be non-human entities

  2. Limitations

  3. Definition of Done

  4. Engineering Tasks

  5. Effort Estimate

    • Should be within an iteration e.g., 2 weeks in Scrum

Easily verifiable so the client knows what the expect, and the person fulfilling the user story can be validated that they’ve completed the task.

As clear as possible, without ambiguities

INVEST

  • I - Independence

    • All user stories should be independent of each other

  • N - Negotiable

  • V - Valueable

  • E - Estimable

  • S - Small

  • T - Testability

Consider the following value statement in the context of a user story for developing a data analysis system:

‘As a quantitative researcher, I want to be able to calculate the correlation between two variables, so that I can determine how correlated these variables are.’

Which INVEST guideline is most violated by this user story?

  • Independent

  • Negotiable

  • Valuable correct

  • Estimable

  • Small

  • Testable

The benefit in this value statement is simply repeating the goal, and therefore violates the principle of a user story being Valuable. A better value statement would have included the benefit of determining correlation between two variables

Example

Use case: As a prof. I want to create repositories so students can work

Role - Prof Goal - Create repositories Benefit - Students can work

Limitations: Need: Repo names, student id’s Definition of done:

  • Runnable as single command

  • Automated test cases

  • Programmatically verifiable

Engineering notes:

  • Should use GitHubManager class

Cost estimate:

  • 1.5 units/days

Decomposing User Stories

Role: Player Goal: Move Mario Benefit: Dodge/Attack the enemy

Limitations: Keyboard input Notes: Use existing Level class Cost: 3

  • +1 - Key Control

  • +1 - Handling movement

  • +1 - Handling collissions

DOD:

  • Key input controls mario’s movement

  • Mario is able to move through the level

  • When mario colides enemey, one of them should be hit

I: Independent - NO N: Negotiable - YES V: Valuable - YES E: Estimable - YES S: Small - NO T: Testable - YES

  1. Find entities that can be decompose

  2. Link the entities decomposed

  3. Find the actions involved; bind actions

  4. Prototype

  5. Formalize; like UML

  6. Start implementation

Entities can be found in Defintion of Done

Key, Mario, Level, Enemies

Both mario and enimies are both figures

Key Level Figure Mario Enemy