Skip to content Skip to site navigation Skip to service navigation

Requirements Gathering Checklists

Before Requirements Gathering

Project Charter

  • Does the Project Charter exist?
  • Is the Project Charter complete?
  • Has the Project Charter been approved?

Context Diagram

  • Does the Context Diagram exist?
  • Do you understand it?
  • Is it complete and correct?
  • Is it contained in the Project Charter?

Stakeholders

  • Have all of the required Stakeholders been identified?
  • Do you have the authority to contact any stakeholder needed for requirements gathering?
  • Are the view of and Stakeholders deemed more critical or important than others due to business reasons?
  • Do you (or your manager) know the Stakeholders? Do you have credibility and rapport with them?

Information Gathering

  • How many interviews or sessions will you need to gather information? How frequent will the meetings be, and how long will they last?
  • Have you gathered information via one-on-one interviews, embedded/immersion time with users, and brainstorming (use case) sessions or formal structured methods such as Joint Application Design (JAD)?
  • Is time for Requirements Gathering, the next step, reflected on the Project Plan? Will it be enough time?

Eliciting

Communication in this step of the requirements gathering process involves the following:

  • Interviews
  • Focus groups
  • One-on-ones
  • Data confirmation
  • Nomination to working groups
  • Identification of heavy users
  • Ensuring secure communication in tools like chat rooms and blogs
  • Have you allocated enough time for this phase in the project plan?
  • Have you identified all of the required stakeholders who should be part of the elicitation process?
  • Have you accurately prioritized the stakeholders and assigned the right level of involvement?
  • Have you ensured that all stakeholders that are part of the elicitation process are empowered to make binding decisions on behalf of the users they represent?
  • Have you identified the method(s) of elicitation you will use? These include focus groups, interviews, Business Analyst one-on-ones, confirming data, working groups, identification of heavy users, etc.
  • Have you adequately prepared the stakeholder for the elicitation sessions?
  • As best as possible, have you established a positive rapport with the stakeholders involved in the elicitation sessions? This will help you understand them and establish trust and cooperation within the group.
  • Have you made sure that the reasons that users need a each function are clear by asking why?
  • Have you asked questions pertaining to how the system will be used, how it will meet the business's needs, how the team will know when it is complete, etc.?
  • Have you made sure that any solution descriptions users present are exposed so that you can uncover the underlying specific need?
  • Have you allowed for an opportunity to go back to users and request additional information as necessary?
  • Have you analyzed the elicited requirements to ensure an understanding of the real tasks users perform?
  • Are the user's needs clearly understood as being separate from the implementation approach?
  • Have you asked questions so that users can express the characteristics about how well the system should perform its functions under different operating conditions, aka the quality attributes?
  • Do your elicited requirements cover both normal operating conditions and exceptions?
  • Have you elicited requirements that explore the preconditions (such as input data) necessary to perform a task, and the state in which the system will be left upon completion of the task?
  • Have you explored pertinent business rules/polices?
  • Have you elicited requirements regarding security, user types/roles/responsibilities, reporting, and integration?
  • Have you revisited and reviewed the requirements, formally and informally, throughout the elicitation process?
  • Are the users and user tasks the focus of the elicited requirements, rather than the system's behavior?

Analyzing

Communication in this step of the requirements gathering process involves the following:

  • Clear, written version of requirements by Business Analyst
  • Peer reviews
  • Additional questions
  • Topical meetings and meeting minutes
  • Identification of process owners and function experts
  • Provide list of lessons learned from prior projects

General Requirements

This checklist captures issues that apply to all requirements content, regardless of technique used to identify, analyze, and capture it. In this context, a requirement may be thought of as a unit of system behavior.

For all requirements...

  • Are they complete?
  • Are all they uniquely identifiable?
  • Are they clearly and appropriately prioritized?
  • Are they consistent?
  • Does the set of requirements adequately address all appropriate exception conditions?
  • Does the set of requirements adequately address boundary conditions?
  • Are the requirements feasible? Does a solution to the set of requirements exist?
  • Can they be implemented within the known constraints?
  • Are they sufficient? Could they be sent to a reputable development organization and have a reasonable probability of producing the desired product?
  • Are inverse requirements explicitly stated?
  • Are these the simplest set of requirements that meets the stakeholders' needs?
  • Are all cross-references to other requirements correct?
  • Have functional and non-functional requirements boon considered?

For each individual requirement:

  • Is it precise and unambiguous?
  • Is it stated as simply as possible?
  • Is it testable/verifiable?
  • Is it correct?
  • Is it in scope?
  • Is it as modifiable as possible?
  • Is it written in the customer's language, using the customer's terminology?
  • Is it acceptable to all stakeholders?
  • Is it a statement of stakeholder need, not a solution?
  • is it traceable?
  • Is it necessary?
  • Are all missing items or unresolved issued identified with a TBD, an owner, and a timeline for closing?

Business Requirements

Business requirements describe why a system needs to be created and the general strategy desired. They are the basis for the system's scope and the primary measure by which the project can be judged a success or failure.

  • Are the high-level business objectives described?
  • Is a system perspective used when appropriate?
  • Are the requirements understandable by all stakeholders?
  • Is the value to the business owner (cost savings, reduced inventory, etc.) identified?
  • Is the value to the customer (new features, improved usability, etc.) identified?
  • If appropriate, are the business opportunities the requirements support outlined?
  • Are the details of how the system will meet objects avoided?
  • Does this requirement answer the question "why are we doing this software"?
  • Is this requirement a product or business vision?
  • Is this requirement a product or business goal?
  • Is this requirement a customer goal?
  • Is this requirement a system objective?
  • Does this requirement describe a product charter?

Functional Requirements

Functional requirements provide detail about what a system will have to do in order to satisfy business requirements. Note that this does not include details about how the system will be designed and constructed. An example of a functional requirement would be the creation of toast from a toaster.

  • Does the set of functional requirements meet the needs outlined by business requirements? (e.g. complete, sufficient, etc.)
  • Is the relation between functional and non-functional requirements clear?
  • Is the relation between functional requirements and any user interface designs clear?
  • Do the functional requirements convey enough knowledge to allow design activities to begin or continue?
  • Do the functional requirements avoid design and construction details?
  • Are the functional requirements at an appropriate level of precision? (e.g., with an evolutionary prototyping life cycle, functional requirements should NOT be extremely precise; details will be worked out as design and construction progress.)
  • Are appropriate mechanisms used to capture the functional requirements? (e.g., user interface prototypes and screen mock-ups are often better than text.)

Quality Requirements

  • General
    • Are the requirements stated in a specific an measurable form? (e.g., 10 sec vs. fast)
    • Does this requirement answer the question "how well"?
    • Is this requirement a task detail constraint?
    • Is this requirement mandated by a standard or other binding authority?
  • Reliability
    • Are the reliability (MTBF) requirements specified?
    • Are the availability (up time) requirements specified?
    • Are the serviceability (MTTR) requirements specified?
    • Are the robustness requirements specified?
  • Performance
    • Are the response time or latency requirements specified?
    • Are the throughput requirements specified?
    • Are the data volume (input, stored, output) requirements specified?
    • Are the peak or short-term load requirements specified?
  • Hazard/Safety/Security
    • Are the security requirements specified?
    • Are the safety requirements specified?
  • Configurations
    • Are the supported configurations specified?
    • Are the compatibility requirements (backwards, other applications, etc.) specified?
  • Usability
    • Are the usability requirements specified?
    • Are the internalization/localization requirements specified?
    • Are the look and feel (e.g., color schemes, standards, etc.) requirements specified?
  • Operational
    • Are any operational constraints or requirements (e.g., the user must be able to operate the system using ski gloves) specified?

Software Requirements

  • Is the requirement adequate for the business goal of the project?
  • Does the requirement conflict with some domain constraint, policy, or regulation?
  • Does the requirement include premature design or implementation information?
  • Is the requirement necessary?
  • Does the requirement require non-standard hardware or must software be used?
  • Is the requirement ambiguous? Could different persons read it in different ways? What are the different interpretations?
  • Is the requirement realistic given the technology that will be used to implement the system?
  • Does the description of a requirement describe a single requirement or could it be broken into several different requirements?
  • Has each requirement been assigned a priority?
  • Are the system boundaries well defined?
  • Have the portability, reliability, usability, and maintainability requirements for the system been respected?
  • Did you create a System Architecture Model?
  • Did you develop a behavioral or structural model for the system?
  • Is the requirement uniquely identified?
  • Do the deduced requirements have a valid source and rationale?
  • Does the requirement have a source so it can be traced?
  • Does the requirement have a type?
  • Is the requirement ambiguous, unclear, or vague?
  • Does the requirement align with the business goals of the project?
  • Does the requirement conflict with some domain constraint, policy, or regulation?
  • Is the requirement related to an organizational or political issue in opposition to the business goal of the system?
  • Does the requirement take into consideration the needs of all stakeholders?
  • Has an UIR been used for a requirement related to user interfaces?
  • Have all the stakeholder been consulted during the elicitation process?
  • Has all the system information (gathered in the preliminary phase) been restated as requirements?
  • Does the requirement need a scenario to be elicited?

Documenting

Communication in this step of the requirements gathering process involves the following:

  • Posts to common areas
  • Clarification of minor points
  • Using lay language and/or glossary of terms
  • Tracking changes within the BRD
  • Graphical communications
  • Does the documentation fulfill its objectives for the intended audience?
  • Are the standards and conventions decided and agreed upon?
  • Are the version and change control procedures decided and agreed upon?
  • Is any existing documentation applicable to the new documentation?
  • Are the reviewers/approvers of the document finalized? Is the approval mechanism for the documentation planned accurately?
  • Is it easy to obtain the documentation? Are all relevant documents linked correctly?
  • Is the information structured in a logical manner?
  • For documents divided into sections, are the sections clearly labeled?
  • Is the information cross-referenced well?
  • Can users annotate the text? If yes, is there a provision to store the previous text?
  • Does the document use full names/titles prior to first instance of abbreviations?
  • Is spelling and grammar correct?
  • Is the writing style consistent across the document?

Requirements Completeness

Communication in this step of the requirements gathering process involves the following:

  • Emailing and mark-ups within the BRD itself
  • Walk-throughs
  • Peer reviews
  • Inspections
  • Are the requirements clearly and appropriately prioritized?
  • Does the set of requirements adequately address all appropriate exception conditions?
  • Has an appropriate requirements template been used, with all relevant sections completed?
  • Does the set of requirements adequately address boundary conditions?
  • Are negative requirements explicitly stated?
  • Have non-functional requirements been considered and documented?
  • Have requirements for in-flight transaction been considered and documented?
  • Are all missing items or unresolved requirements issues identified with a TBD, an owner, and a timeline for closing it?
  • Are all requirements uniquely identifiable?
  • Are all requirements stated in a way that is unambiguous and clear?
  • Are the requirements written with no conflicts or contradictions with other requirements?
  • Are all cross-references/dependencies to other requirements stated and correct?
  • Are all requirements in scope?
  • Do all requirements add value to the system? Are all requirements necessary?
  • Are the requirements technically feasible?
  • Can the requirements be implemented within known project constraints?
  • Is each requirement stated as one unique requirement, not several requirements in one?
  • Do all requirements state something the system should do, not a constraint or assumption (such as the user must have Adobe Acrobat installed)?
  • Have all requirements been reviewed and signed-off by the stakeholders?
  • Have all requirements been reviewed for feedback by project team members, including PM, QA Lead, Dev Lead, etc.?

Approving

For the Business Analyst

  • Is a standard for what constitutes approval in place?
  • Has a change management process been documented, preferably in the project charter?
  • Does the BRD contain evidence that the project team and stakeholders have reviewed and approved it?
  • Have you met individually with all approvers to review the requirements in details and make sure they understand them?
  • Do the approvers understand the scope of the project?
  • Do the approvers understand the implications of requirements approval, including the concepts of baselining and change management?
  • Have you scheduled an approval presentation or meeting?
  • Can all approvers, or their delegated representatives, be present for the approval presentation or meeting?

For the Approvers

  • Has a member of the project team reviewed the requirements in details with you, and explained them, including all ramifications of each requirement?
  • Do you understand the requirements and project scope?
  • Is there evidence that the project team has reviewed the requirements document in detail and approved it?
  • Have you and the project manger agreed on the implications of your approval of these requirements, that your approval constitutes a baseline and any additional requirements or changes to approved requirements must go through the established change management process?
  • Are all constituencies represented in the requirements document?
  • Are all requirements of external entities (e.g., sponsoring agencies, auditors) adequately addressed so there is no exposure?
  • In the case of involvement with external contracting agencies, has the contractual language been approved by legal counsel if such an approval is necessary?
  • Has the project been sized, and is there evidence that, within the documented scope, the project will be implemented on time and within budget?
  • Are you willing to commit time and budget to this project as described by the requirements?