Organization and Completeness
•Are all internal cross-references to other requirements correct?

•Are all requirements written at a consistent and appropriate level of detail?

•Do the requirements provide an adequate basis for design?

•Is the implementation priority of each requirement included?

•Are all external hardware, software, and communication interfaces defined?

•Are algorithms intrinsic to the functional requirements defined?

•Does the SRS include all the known customer or system needs?

•Is any necessary information missing from a requirement? If so, is it identified as a TBD?

•Is the expected behavior documented for all anticipated error conditions?
 
Correctness
•Do any requirements conflict with or duplicate other requirements?

•Is each requirement written in clear, concise, and unambiguous language?

•Is each requirement verifiable by testing, demonstration, review, or analysis?

•Is each requirement in scope for the project?

•Is each requirement free from content and grammatical errors?

•Can all the requirements be implemented within known constraints?

•Are all specified error messages unique and meaningful?
 
Quality Attributes
•Are all performance objectives properly specified?

•Are all security and safety considerations properly specified?

•Are other pertinent quality attribute goals explicitly documented and quantified, with the acceptable trade-offs specified?
 
Traceability
•Is each requirement uniquely and correctly identified?

•Is each software functional requirement traced to a higher-level requirement (for example, system requirement or use case)?
 
Special Issues
•Are all requirements actually requirements, not design or implementation solutions?

•Are the time-critical functions identified and their timing criteria specified?

•Have internationalization issues been adequately addressed?
 
Use Case review checklist.

•Is the use case a stand-alone, discrete task?

•Is the goal, or measurable value, of the use case clear?

•Is it clear which actor or actors benefit from the use case?

•Is the use case written at the essential level, free of unnecessary design and implementation details?

•Are all anticipated alternative courses documented?

•Are all known exception conditions documented?

•Are there any common action sequences that could be split into separate use cases?

•Are the steps for each course clearly written, unambiguous, and complete?

•Is each actor and step in the use case pertinent to performing that task?

•Is each alternative course defined in the use case feasible and verifiable?

•Do the preconditions and postconditions properly frame the use case?