Requirements Engineering

- PO creates User stories
- PO priorizes User Stories
- Team priorizes User Stories
- Sprint Planning Meeting 

- PO creates User stories
- PO refines User stories
- PO creates detailed definitions
- PO priorizes User Stories 

Name, Role, Contact details, Availability (time frames and location), Relevance of stakeholder (see analysis), Knowledge area, Aims and interest

By influence and motivation:

high influence & motivation: tight cooperation
high influence - low motivation: satisfy
low influence - high motivation: inform
low influence & motivation: observe

- the benefit of the task is spelled out for everyone in the user story

- the user role is spelled out in the user story

- easier to synchronize changing requirements

- since it's easily understandable for everyone, customers can discuss it better

- provokes discussions with stakeholders

1. Card: User stories are traditionally written on index cards or sticky notes, in short form. User narratives further explain these cards. Thus the main intention is to describe the user story in short form to allow common understanding of the user need among all stakeholders.
2. Conversation: User stories shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
3. Confirmation: Acceptance tests confirm that the story was delivered correctly.

As a <type of user>, I want <some goal> so that <some reason>.

Given <some precondition>, when <some situaation>, then <expected outcome n> [and <expected outcome n+1>...].
 

criteria for good backlog items:

"I" ndependent (of all others)
"N" egotiable (not a specific contract for features)
"V" aluable (or vertical)
"E" stimable (to a good approximation)
"S" mall (so as to fit within an iteration)
"T" estable (in principle, even if there isn't a test for it yet)

A theme is a collection of related user stories.

Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point.

Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system. 

Definition of Done, a checklist when the user story can be regarded as done (only 100% counts).

They express an estimate of effort that will be required to implement a product backlog item.
The raw values we assign are unimportant. What matters are the relative values.
They must include everything that can affect the effort:
- The amount of work to do
- The complexity of the work
- Any risk or uncertainty in doing the work

- don't start from requirement documents, start with talking to the stakeholders
- don't treat user stories as a document, treat it as a discussion starter
- don't confuse user stories with use cases
 

- by splitting it up in smaller stories
- by adding acceptance criteria

- Define the boundaries for a user story/feature
- Help the product owner answer what they need in order for this feature to provide value
- Help the team gain a shared understanding of the story/feature
- Help developers and testers to derive tests
- Help developers know when to stop adding more functionality to a story 

Vision
Goals
Features
Epics
Stories

- overview for all stakeholders
- size of project is visible
- fosters collaboration and shared understanding
- marking nice-to-have features as out of scope saves time

1) Frame - What? (name of product) - Who? (users) - Why? (benefit of product)
2) Map the big picture - identify key users and their activities
3) Explore - fill the body of your story map
4) Slice Out Viable Releases
5) Slice Out a Development Strategy

elicitation
documentation
validation & harmonization
management

must have - should have - could have - won't have

The Solution domain (IT development) and the problem domain (customer problem).

Functional Requirement: describing functional behavior of the system
Non functional Requirement or Quality of Service (QoS) describing how a system provides some functionality 
Constraints: time, budget, used technologies & frameworks, quality standards, methodology...

Group of 5-10 persons
20 minutes time slot to collect ideas
Ideas are collected without comments
Based on collected ideas new ideas are created
Crazy ideas are allowed / welcome
Think about location change (not in the office)
After storming phase ideas are analyzed and rated
Written approach is called Brainwriting

Pro:
A lot of ideas in a short time
room for new solutions
Ideas are enhanced by others
Good to identify optimization aspects
Con:
Group dynamic aspects has to be good
Distributed teams need high effort to realize the technique

6 Participants
Everyone creates 3 Ideas and documents them on a card
After 3-5 minutes cards are passed to neighbor for inspiration
Everyone creates 3 new ideas (with inspiration from neighbor card)
This is repeated 5 times (everyone had every card)
Idea:
good ideas will survive
Permutations of ideas
Inspiration 

Pro:
Problems with group dynamics are compensated
Simple for moderator
Simple to do that with distributed teams
Con:
Writing is not as effective as brainstorming (verbal) 

Participant try to cover different views. e.g.:
Objectivity and neutrality: Facts and Figures (white)
Personal feeling and subjective opinion : feelings, hope, fear (red)
Objective negative arguments: risks, doubts (black)
Objective positive arguments: opportunities, aims (yellow)
New Ideas (green)
Process controlling (blue)
Write input on colored cards. The method will provide a good overview of different aspects. Give Stakeholder corresponding colors or give them other colors. Moderate the persons to understand their perspective.

Pro: Helps stakeholder to possess another role
Con: Introverted persons do not like such techniques

Observe the stakeholders at their working place
Understand the process
Ask questions
Do not act as overseer or inspector

Pro:
if user do their work automatically (implicit)
Good to identify alternative process flows
Con:
Some processes are not observable
Method could falsify results/process

The REE is the apprentice and learns the tasks from the stakeholder.
REE identifies errors which are not done by the expert
Most people like it to introduce others in their work 

Pro:
if user do their work automatically (implicit)
Good to identify errors
Stakeholder has not the feeling of being observed
Good for group dynamic aspects
Con:
Not possible in critical environments
Not useable for product development (not all stakeholders are known)
Needs a lot of time

Pro:
Fast and cheap feedback
Could address a lot of people
Con:
Not good to collect implicit knowledge
Hard to gather non functional requirements
Further inquiries are not possible

Pro:
Adoptable interview process (you can react/influence during the interview)
Could be done with single persons or groups (workshop style)
Further inquiries are possible
Con: 
Very time consuming
You only get the answers to the asked questions
Only for explicit knowledge

The old system of the customer is used to gather requirements
documentation and the user manual are a source to identify requirements
Use only together with other elicitation techniques

Pro:
Existing features could be addressed easily
Con:
Very, very time consuming
You only get the implemented features, not what the stakeholders want now
Very often documentation of old systems is not very good 

Here a similar system which was developed from the dev. Team is used (not a system the customers are using)!
Always use together with other techniques
Could be used for non functional requirements
Could be formulated in a database and resued based on copy&paste