Child pages
  • Requirements Specification
Skip to end of metadata
Go to start of metadata



Requirements Checklist

The requirements checklist is a tool to assist in determining whether the requirements are documented, correct, complete, unambiguous, consistent, verifiable and approved. The Requirements Specification template includes examples and can be used to document the requirements for your product or service, including priority and approval.  Tailor the specification to suit your project, organizing the applicable sections in a way that works best, and use this checklist to record decisions about the applicable areas. Each deliverable indicated below as applicable must be documented and included in the requirements review package.

Requirements Review Process

The requirements review process ensures that the requirements are documented, correct, complete, unambiguous, consistent, verifiable and approved.


Recommended inputs for the requirements review process include:

  • Approved project charter (scope description)
  • Initial project plan
  • Standards for documentation and requirements development, if applicable
  • Change management process, if applicable.


Outputs desired from the requirements review process include:

  • Requirements: documented and prioritized
  • Completed Requirements Checklist, supporting documentation and requirements
  • Key stakeholder agreement on the requirements.





Identify if a requirements review is applicable for this project with the project sponsor. If so, identify the review team members with the project sponsor. 

Project Manager


Schedule requirements kickoff meeting to

  • Introduce team members
  • Hold a high-level discussion about requirements gathering approach
  • Review and update high-level goals, objectives, and scope.

Project Manager


Complete draft requirements (hold working meetings with Subject Matter Experts):

  • Define and document the business process now (as-is)
  • Review project goals and objectives, and define product/service audience (users)
  • Scope system back to those goals, objectives & audience
  • Interview/meet with potential customers, users, downstream application owners
  • Define and document the desired business process (to-be)
  • Do the business analysis (prepare a gap analysis from the "as is" and the "to be")
  • Talk about features & design ideas (e.g., user should be able to xxx without yyy)
  • Construct the requirements based on the gap analysis; use the checklist to note sections that are not applicable
    Note: There are numerous courses and resources available that describe the requirements gathering processes. Links to some of those resources will be provided in the future.

Lead Engineer or
Business Analyst


Review requirements and supporting documentation with project team and key stakeholders, revise based on feedback.

Lead Engineer or Business Analyst


Repeat Step 3 and 4 until all requirements approved and signed off.

Lead Engineer or Business Analyst


Publish and distribute final, approved requirements.

Project Manager


  • It is the responsibility of the project sponsor and project manager to determine who is included in the requirements review and approval decision. Team members may include business and technical subject matter experts, members of the project team, and potential customers, users, or downstream application owners.
  • If the product lifecycle is iterative, the requirements construction and review processes will also be iterative, with requirement changes tracked.