- high-level functional requirements should be identified within the initial requirements envisioning
- capture the details on a JIT basis throughout construction via short model storming sessions with stakeholders
- in addition to confirmatory testing to validate that you've built the system to your understanding of the requirements, an independant team should test a working build of the system on a regular basis from a higher level and attempt to break the system
Thursday, September 18, 2008
Capturing Non Functional Requirements and Constraints
How should we capture requirements and constraints that typically cross-cut functional requirements? For example accuracy, availability, concurrency, consumability (a superset of usability), environmental/green concerns, internationalization, operations issues, performance, regulatory concerns, reliability, security, serviceability, support, and timeliness.