Writing Verifiable Requirements should be a rule that does not need to be written. Everyone reading this has seen or created requirements that can not be verified. The primary reason for writing requirements is to communicate to the team what they need to accomplish. If you can’t verify that what the team delivered is acceptable, neither can the team. This may be the most obvious of the rules of writing requirements – but it is ignored every day.
Subscribe to Tyner Blain
Search
Pages
Archives
Categories
- Administrivia (32)
- Contest (1)
- Austin TX (11)
- Business Analysis (168)
- Business Rules (13)
- Consulting (103)
- Communication (90)
- Presentation (15)
- Writing (39)
- Outsourcing (8)
- Communication (90)
- Data management (3)
- Definitions (6)
- eCommerce (6)
- Expert systems (3)
- Flashback (75)
- Foundation series (22)
- Interface Design (9)
- Interviews (1)
- Lists (26)
- Marketing (27)
- Organizations (12)
- IEEE (1)
- IIBA (4)
- ProdMgmtTalk (2)
- ProductCamp (4)
- People management (4)
- Polls (10)
- Process Flow (5)
- Process Improvement (73)
- CMMI (10)
- Product Management (271)
- Product Strategy (10)
- Project Management (60)
- Quick Post (1)
- Requirements (363)
- Prioritization (46)
- Requirements gathering (106)
- Requirements management software (14)
- Requirements Models (163)
- Ishikawa Diagram (14)
- Kano Analysis (9)
- Software requirements specification (57)
- UML Modeling (12)
- Use Cases (68)
- User Stories (11)
- Reviews (11)
- Book Reviews (8)
- Software Reviews (3)
- ROI (40)
- Slightly off-topic (36)
- Software development (265)
- Agile (126)
- Design (16)
- Testing (47)
- Test Automation (25)
- UX (64)
- Interaction design (29)
- Usability (21)
- Success Stories (1)
- Uncategorized (15)


