No standard way to handle requirements

• Use cases
• Data & Process Models
• Combined with design documents
• JAD sessions
• Prototyping
• List of 500 plus requirements

Problems

• Ambiguous – "we don’t want to take away the creativity of the developers"
• Scope creep
• Can’t estimate testing efforts, without requirements
• Sign offs
• Systems aren’t developed to requirements
• Often seem to lose link at peak of software development
• Requirements are changed to meet what was developed
• Schedule defined before requirements
• Varying degrees of detail
• Test cases are developed haphazardly and at the last minute

Recommendations

• Restate the requirements as test cases, then get sign off on test cases
• Prototype – then write requirements from prototype
• Identify highest risk requirements – then keep them up to date
• Tracing your defects back to requirements
• Train users and analyst on "What is a good requirement?"
• Include quality requirements up front
• Sometimes called technical requirements, e.g. performance, maintainability, interoperability, flexibility
• Include the business in requirements, i.e. real users and business analysts, in addition to developers, consultants, product managers and liasons
• Requirements management tool, integrated with test tools

Web development will increase the need to define requirements up front, to focus development on critical success factors. May also introduce new requirements.