terminology might be wrong?

These come from the customer

• Should communicate what the customer functionally requires the system to do

  • should answer the question “What is the system doing?”
  • should not answer the question “How is the system doing it?”
• Arbitrary tool (Word, Excel, Mindmap, …) 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!

• Numbered
• Mapped to one category (component)
• Verifiable

  • 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 https://learn.ni.com/labview-center-of-excellence/resources/687/practical-techniques-for-gathering-and-managing-system-requirements

• 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

Richard This is a hot topic for me. Requirements are never properly captured. And when by miracle someone does manage to create a requirements document, they're never properly tracked through the project and it's not until the end when someone performs Acceptance Testing that they discover something got missed (or misinterpreted). I want to see proper requirements capture, logging and full integration with the development environment to ensure real-time awareness and cover tracking throughout realisation phases. Currently not possible in LabVIEW.