Requirements Engineering

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

Pro:
Cost saving method
Con:
Reuse has an overhead at the beginning (necessary to create the database, to create good documentation,…) 

Creativity techniques
Observation techniques
Questioning techniques
Artefact based techniques
Supporting techniques 

Creativity techniques:
   Brainstorming
   6-3-5 Method
   Change of perspective
Observation techniques:
   field observation
   Apprenticing
Questioning techniques
   Questionnaire
   Interview
Artefact based techniques
   system archaeology
   reuse
Supporting techniques
   Workshop
   Mind Mapping
   Audio/Video Recoding
   Use Case Modelling
   Scenarios
   Essence creation (reuse necessity) 

Because the later you fix a mistake, the more expensive the fix will be.
Fixing a requirement mistke at delivery will be 200 times more expensive than in the requirment phase.

Customer(s)
Users
Developers
Solution Architects
IT/Sys Admins
Testers 

Requirement Engineering is a systematic and disciplined approach of specification and management of requirements to:
- Identify/know relevant requirements
- Document the requirements based on standards
- Address all stakeholder needs in a consensual way
- Understand the needs of the customers
- Specify and manage the requirements to reduce risk of providing a non conform application which does not fit the stakeholders needs 

- subjunctives: don't use "should"
- not precise (e.g. "all")
- use of not measurable (and therefore testable) attributes like "quickly"
- mixing up several requirements in one statement
 

- “underlying” business process changes itself. (about 2% per month).
- customers do not have a good understanding of the system
- customers know their problems (needs) but a general understanding of the problem is not established
- General understanding of the solution not yet available

The tendency of requirements to increase over time.

Level 0: Sprint Goal; Product Vision

Level 1: Epic, Theme

Level 2 & 3: User Story; technical User Story; Product Backlog Item; Acceptance Criteria; DoD

Level 4: User Story; technical User Story; Sprint Backlog Item; Acceptance Criteria

Level 0: for management; Focus on high level system description; overview; Usually volume of several pages (1-3)

Level 1: for specialist division, Identifies business cases, Use Case level

Level 2: for process owners; Definition from workflows; Definition of QoS; Usually no definition of sub systems; Definition of user roles; First definition of interfaces

Level 3: for process owners; Definition of sub systems; Mapping of workflows to subsystems; Definition of Requirements concerning the GUI; Definition of Non functional requirements 

Level 4: for system architects; Separation of HW and SW parts; Definition of solutions; Non functional requirements in detail

It contains always a (technical) solution for a more abstract requirement without changing the subject matter.
It does not replace the more abstract formulated requirement. It describes it in another (higher) specification level. 

- Create The Product Vision (PO with customer)
- Check /Identify constraints
- Identify stakeholders
- Define system context
- Start to define glossary

- 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>.