Requirements
These are properties and constraints that describe the design or solution.
Requirements vs. Specifications
Observations from Hartson and Pyla: Detailed formal requirements (i.e. specifications) cannot ever be
- Complete
- 100% Correct
- Prevented from changing
Requirements as statements from contextual analysis
Informal statements of what must be true in the solution
Note Hartson & Pyla have examples throughout chapter 5 (as user stories in section 10.2, 2nd edition)
Alternatives to formal phase (see Abridged methods in H & P)
- Just interpret affinity diagrams (aka WAADs)
- Skip diagrams and interpret raw data to list requirements
- Indicate Work Activity Notes that suggest requirements
Discussion questions and exercises
- What are problems with formal specifications?