- sets of functionality
- Test modes which prevent test data being sent to external areas or simulate these areas which are unavailable for testing e.g.) live trading system
- Fallback modes which allow user processing to continue in a limited form even if a key external system is not available
- For each mode of operation, do requirements specify:
- How the mode is set up; how to check it is working
- Impact/restrictions on system
- Life-cycle of processes in the mode?
Non-functional requirements - typically no specific functionality is implemented to support non-functional requirements, but the system overall must meet certain criteria
- Typical areas of non-functional requirements include:
- Performance - how the system should respond in normal and exception circumstances
- Data volumes - predicted database size and transaction numbers over time
- Security - resistance to unauthorized/malicious access
- Usability - ease and effectiveness system use for target users?
- For each non-functional area are the following requirements specified?:
- Acceptance criteria
- Special cases e.g.) expected peak loads, volumes, times, limits/exception situations?
The use of requirements-content checklists can help prevent or identify the requirement issues and build confidence that requirement completeness and clarity is good. They also can be used as part of a continuous improvement process. If you encounter requirements issues, raise them as soon as possible, communicate the potential impact, and measure the actuals. Measures of the impact of requirements issues can be used to justify requirements improvements in later projects or phases.