These are formulated by or together with the customer

• communicate what the customer functionally requires the system to do

  • must answer the question “What is the system doing?”
  • should not answer the question “How is the system doing it?”
• Arbitrary tool (Word, Excel, Mindmap, Whiteboard…) for specification gathering

Translating customer talk / email / spec into a list of deliverables

• Spec transformed into list format (.csv)
• Versioned (track changes with date and author)
• This HAS TO BE discussed with the customer!

Each requirement should have (*optionally):

• Numbered (better: ID & Version)
• Rationale: What is the reason behind?
• Priority
• Reviewer*
• Comment*
• Mapped to one category (component) / Parent
• Verifiable (Test)

  • Requirements and test plans are invariably intertwined
  • Start with “what must it do?” then think “how will I test that?”
• If TBD/TBR cannot be avoided, be sure to include a description of conditions:

  • Why an answer is not known
  • If a TBD can be eliminated (who/when)

10 questions and exercises you’d be crazy not to ask before starting your project.

Try to address these issues and topics together with the customer as early on as possible. Part of it will make more sense during Planning, but hearing the customer's thoughts - and setting his expectations - cannot start early enough.

These questions serve two goals: alignment and expectation setting:

Alignment is about making sure you and everyone else are on the same page with regard to why we are here, what we’re trying to do, and how are we going to get there. Basic stuff.

Expectation setting, on the other hand is about you communicating clearly with your team and stakeholders what it is going to take to make this project a success. You are defining the rules of engagement.

- Why Are We Here?
- Create an Elevator Pitch
- Design a Product Box
- Create a NOT List
- Meet Your Neighbors
- Show the Solution
- Ask What Keeps Us Up at Night
- Size It Up
- Be Clear on What’s Going to Give
- Show What It’s Going to Take

See https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/

See NI collection and especially NI Week Presentation

• Correct

  • Every requirement stated is one the hardware/software shall meet
• Unambiguous

  • Requirements have only one interpretation
• Complete

  • Includes all significant requirements, software responses and full labels/references
• Consistent

  • Agrees with higher-level documents
• Ranked

  • By importance and/or stability
• Verifiable

  • A finite cost-effective process exists where a machine or person can check it
• Modifiable

  • Avoids redundancy, easily organized, requirements separated
• Traceable

  • Origin of requirements is clear; requirements can be easily referencedConsequent numbering