4. User Stories

Question 1

Requirement Risk

Answer 1

1. lack of understanding of the business or social context
2. uncertainty on what the system should do
3. cultural differences between
4. ambiguous or vague requirements specifications
5. ambiguities over domain elements

Question 2

Managing requirement risks

Answer 2

User stories

prototyping

Question 3

Requirement gathering

Answer 3

an iterative process of elicitation, specification, and validation.

Question 4

Evolving requirements

Answer 4

1. problem domain changes
2. customer’s own understanding of the problem increases
3. progress on system design and implementation uncovers new risks and opportunities

Question 5

Elicitation

Answer 5

1. identify - project stakeholders
2. elaborate - full user requirement
3. draw - system boundary
4. understand - organisational context and culture
5. make - hidden assumptions explicit
6. define - other goals

Question 6

How to approach elicitation

Answer 6

avoid early commitments to particular design solutions

requirement gathering is an ongoing process

Question 7

System boundary

Answer 7

what a system should and should not do

Question 8

elicitation techniques

Answer 8

questionnaires
observations
interviews

Question 9

how to conduct interviews

Answer 9

1. prepare user stories from initial problem
2. structure questions to identify new user stories and resolve uncertainties
3. coordinate the questions selected with other interview teams
4. be prepared to vary the discussion if unexpected, but important, topics emerge
5. practice the interview to avoid running over time. Make sure everyone know their roles

Question 10

type of Questionnaires

Answer 10

closed question

open questions

Question 11

Observations

Answer 11

1. documented workflows of an organisation are often very different from how tasks are actually carried out.
2. work practice continues to evolve over time
3. stakeholders, users and beneficiaries revealed after observing real work practices
4. observations reveal assumptions that prospective users have about the features of the proposed system

Question 12

Actors/ roles/ personas

Answer 12

1. describe categories of users
   - avoid actors that are too general or too specific
2. include actor specific motivation
   - goals
   - frustrations
3. essential for justifying the existence of features
4. help identify one of the types of system stakeholders to negotiate.

Question 13

Requirement scope

Answer 13

in theory every action on a system should be a user story
- scope would be unbounded
- many duplicated stories across multiple systems
- effort wasted on acceptance testing
focus on business logic
treat framework features as assumptions

Question 14

Refining user stories

Answer 14

1. adding more details
2. refined into implementation tasks (stories may share tasks)
3. story prioritisation (MOSCOW)
   - must have
   - should have
   - could have
   - would be nice to have

Question 15

Scenarios are useful for

Answer 15

• describing workflow

- specifying acceptance test

Question 16

Scenario template

Answer 16

given a [fixture]
and [another fixture]

when [an action is performed on a feature]
and [another action is performed on another feature]

then [a condition holds]

eg. 
given a mocked database of properties
and a property search API
when a text search is preformed for 29 acacia road
then Banana property is returned