What This Template Is For
Enterprise requirements gathering is where most deals are won or lost. The difference between a deal that closes in 60 days and one that stalls for 6 months is often the PM's ability to surface the real requirements early, separate must-haves from nice-to-haves, and align internal teams around what needs to be built or configured. This template provides a structured framework for capturing enterprise requirements across six categories: functional, security, integration, compliance, performance, and support.
Use this in conjunction with your stakeholder map to make sure you are capturing requirements from every decision-making layer. For broader guidance on navigating enterprise relationships, see the Stakeholder Management Handbook.
When to Use This Template
- Pre-sales discovery: During prospect evaluation calls to capture what the buyer actually needs.
- Enterprise pilot scoping: Before kicking off a proof of concept to define success criteria.
- Contract negotiation: When the procurement team introduces requirements not surfaced during discovery.
- Feature gap analysis: To compare what the prospect needs against what the product delivers today.
- Custom development scoping: When an enterprise deal requires bespoke functionality or configuration.
- Multi-department rollout planning: When different teams within the same company have different requirements.
Rule of thumb: If the deal is worth more than $50K ARR, use this template. Below that threshold, a lighter-weight intake form is sufficient.
Step-by-Step Instructions
Step 1: Identify Stakeholders (10 minutes)
Before gathering requirements, map who will provide them. Enterprise deals typically involve 6-12 stakeholders across these roles:
- ☐ Business sponsor: The executive funding the purchase. Cares about outcomes and ROI.
- ☐ End users: The people who will use the product daily. Care about workflows and usability.
- ☐ IT/Engineering: Responsible for integration, SSO, data security. Care about architecture.
- ☐ Security/Compliance: Must approve the vendor. Care about certifications, data handling, audit trails.
- ☐ Procurement: Manages the purchasing process. Cares about pricing, contracts, and vendor risk.
- ☐ Legal: Reviews MSA and DPA. Cares about liability, IP, and data processing terms.
Step 2: Conduct Discovery Sessions (30 minutes per stakeholder group)
Run separate sessions with each group. Mixing business sponsors with IT leads in the same meeting produces superficial answers. Each group has different concerns and different vocabularies.
Step 3: Classify and Prioritize Requirements (15 minutes)
Use the MoSCoW method to rank each requirement:
- Must have: Deal-breaker. The customer will not sign without this.
- Should have: Important but workarounds exist. Willing to accept a roadmap commitment.
- Could have: Nice to have. Will not affect the purchase decision.
- Won't have: Explicitly out of scope for this engagement.
For quantitative prioritization, run requirements through the RICE framework or use the RICE Calculator to score them against your backlog.
Step 4: Validate and Confirm (5 minutes)
Send the completed template back to the customer for validation before proceeding to scoping or SOW creation.
The Enterprise Requirements Template
Section 1: Engagement Overview
| Field | Details |
|---|---|
| Company | [Name] |
| Industry | [Industry] |
| Company size | [Employees / Revenue] |
| Deal size (estimated) | $[ARR] |
| Decision timeline | [Target close date] |
| PM owner | [Name] |
| Sales owner | [Name] |
| SE owner | [Name] |
| Discovery date | [Date] |
| Requirements version | [1.0] |
Section 2: Business Requirements
Capture what the business is trying to achieve with your product.
| Requirement | Priority (MoSCoW) | Current Solution | Gap vs. Your Product | Notes |
|---|---|---|---|---|
| [Business outcome 1] | Must / Should / Could / Won't | [How they do it today] | [Full / Partial / None] | [Context] |
| [Business outcome 2] | ||||
| [Business outcome 3] | ||||
| [Business outcome 4] | ||||
| [Business outcome 5] |
Primary business driver: [Cost reduction / Revenue growth / Efficiency / Compliance / Risk mitigation]
Success metrics the customer will use to evaluate ROI:
- [Metric 1, with target value and measurement method]
- [Metric 2]
- [Metric 3]
Section 3: Functional Requirements
Detailed feature and workflow requirements from end users.
| ID | Requirement | Priority | User Role | Current Workflow | Your Product Status | Gap Remediation |
|---|---|---|---|---|---|---|
| FR-001 | [Feature/workflow requirement] | Must | [Role] | [How they do it today] | Available / Partial / Roadmap / Not planned | [Config / Custom dev / Integration / N/A] |
| FR-002 | ||||||
| FR-003 | ||||||
| FR-004 | ||||||
| FR-005 | ||||||
| FR-006 | ||||||
| FR-007 | ||||||
| FR-008 | ||||||
| FR-009 | ||||||
| FR-010 |
Workflow dependencies: [List any requirements that must be completed in sequence]
User volume: [How many users will need each capability? Break down by role if needed.]
Section 4: Integration Requirements
| ID | Integration | Direction | Protocol | Volume | Priority | Your Product Status |
|---|---|---|---|---|---|---|
| IR-001 | [System name, e.g., Salesforce] | Inbound / Outbound / Bidirectional | REST API / Webhooks / SFTP / Native | [Records/day] | Must / Should | Available / Custom / Not supported |
| IR-002 | ||||||
| IR-003 | ||||||
| IR-004 | ||||||
| IR-005 |
SSO/Identity requirements:
- ☐ SSO provider: [Okta / Azure AD / Google Workspace / Other]
- ☐ Protocol: [SAML 2.0 / OIDC / Both]
- ☐ SCIM provisioning required: Yes / No
- ☐ JIT provisioning acceptable: Yes / No
- ☐ MFA enforcement: Required / Optional
Data migration requirements:
- ☐ Source system: [Name]
- ☐ Data volume: [Records / GB]
- ☐ Migration timeline: [Date]
- ☐ Data format: [CSV / API / Database export]
- ☐ Transformation needed: [Yes/No, details]
Section 5: Security and Compliance Requirements
| ID | Requirement | Category | Priority | Your Product Status | Evidence Available |
|---|---|---|---|---|---|
| SC-001 | [e.g., SOC 2 Type II certification] | Compliance | Must | Certified / In progress / Not started | [Link to cert or report] |
| SC-002 | [e.g., Data encrypted at rest AES-256] | Data security | Must | ||
| SC-003 | [e.g., GDPR Article 17 right to erasure] | Privacy | Must | ||
| SC-004 | [e.g., Annual penetration testing] | Security | Should | ||
| SC-005 | [e.g., Audit logging with 12-month retention] | Audit | Must | ||
| SC-006 | [e.g., Data residency in EU] | Data residency | Must / N/A | ||
| SC-007 | [e.g., Vendor security questionnaire] | Due diligence | Must | ||
| SC-008 |
Industry-specific compliance:
- ☐ HIPAA (healthcare)
- ☐ PCI DSS (payments)
- ☐ FedRAMP (US government)
- ☐ ISO 27001
- ☐ SOC 2 Type II
- ☐ GDPR / CCPA
- ☐ Other: [Specify]
Use the security questionnaire template to prepare responses to the customer's security review process.
Section 6: Performance and Scalability Requirements
| Dimension | Requirement | Current Capability | Gap |
|---|---|---|---|
| Concurrent users | [X users at peak] | [Your limit] | [Y/N] |
| Response time | [Xms p95 latency] | [Your SLA] | |
| Uptime SLA | [99.X%] | [Your SLA] | |
| Data volume | [X records / X GB] | [Your limit] | |
| API rate limits | [X calls/minute] | [Your limit] | |
| Backup frequency | [X hours RPO] | [Your RPO] | |
| Disaster recovery | [X hours RTO] | [Your RTO] | |
| Geographic latency | [Regions served] | [Your regions] |
Section 7: Support and Service Requirements
| Dimension | Requirement | Your Offering | Gap |
|---|---|---|---|
| Support channels | [Phone / Email / Chat / Slack] | [Your channels] | |
| Support hours | [24/7 / Business hours / Region-specific] | [Your hours] | |
| Response time SLA | [P1: X hr, P2: X hr, P3: X hr] | [Your SLAs] | |
| Named support contact | [Yes / No] | [CSM / TAM] | |
| Onboarding support | [Assisted / Self-serve] | [Your model] | |
| Training delivery | [On-site / Virtual / Self-paced] | [Your options] | |
| Implementation support | [White-glove / Guided / Self-serve] | [Your model] |
Section 8: Requirements Summary and Gap Analysis
| Category | Must-Have Count | Gaps (Must-Have) | Remediation Path | Timeline |
|---|---|---|---|---|
| Business | [X] | [X gaps] | [Config / Roadmap / Custom] | [Date] |
| Functional | [X] | [X gaps] | ||
| Integration | [X] | [X gaps] | ||
| Security/Compliance | [X] | [X gaps] | ||
| Performance | [X] | [X gaps] | ||
| Support | [X] | [X gaps] | ||
| Total | [X] | [X gaps] |
Deal decision: Proceed / Proceed with conditions / Decline
Conditions for proceeding: [List any roadmap commitments, custom work, or timeline dependencies]
Filled-Out Example: Healthcare SaaS Buyer
Engagement Overview (Example)
| Field | Details |
|---|---|
| Company | MedFlow Health Systems |
| Industry | Healthcare IT |
| Company size | 2,400 employees, $180M revenue |
| Deal size | $120,000 ARR |
| Decision timeline | June 30, 2026 |
| Discovery date | March 3, 2026 |
Key Requirements (Example)
| ID | Requirement | Priority | Status | Gap Remediation |
|---|---|---|---|---|
| FR-001 | Role-based access with department-level permissions | Must | Partial | Configuration (2 weeks) |
| FR-003 | Bulk import from Epic EHR via HL7 FHIR | Must | Not available | Custom integration (8 weeks) |
| SC-001 | HIPAA BAA executed | Must | Available | Legal review (1 week) |
| SC-003 | Data encrypted at rest and in transit | Must | Available | N/A |
| SC-005 | Audit log with 7-year retention | Must | Partial (12-month default) | Configuration + custom retention policy (4 weeks) |
Gap Summary (Example)
3 must-have gaps identified. 2 are configuration changes (3 weeks total). 1 requires custom integration work (8 weeks, $25K professional services). Recommend proceeding with a phased implementation plan.
Tips for Effective Requirements Gathering
- Ask "why" behind every must-have. Sometimes a requirement labeled "must have" is actually a preference inherited from a previous vendor. Understanding the underlying need lets you propose alternatives.
- Separate the person from the requirement. A VP's "nice to have" may outweigh an end user's "must have" in deal terms. Map requirements to organizational influence, not just stated priority.
- Get security requirements early. Security reviews add 4-8 weeks to enterprise deal cycles. Surface these requirements in the first discovery call, not after the pilot. For more on navigating this process, see the Product Strategy Handbook.
- Document what is out of scope. Explicitly listing "won't have" items prevents scope creep later. Get written agreement on exclusions before starting any custom work.
- Use their language. Enterprise buyers have internal terminology for workflows, systems, and processes. Mirror their vocabulary in the requirements document. It builds trust and reduces misinterpretation.
- Version the document. Requirements change during evaluation. Maintain version history so both sides can track what was added, removed, or modified.
Key Takeaways
- Gather requirements from every stakeholder layer, not just the business sponsor
- Use MoSCoW prioritization to separate deal-breakers from preferences
- Surface security and compliance requirements in the first discovery call
- Document both what is in scope and what is explicitly out of scope
- Version the document and get written validation before scoping custom work
About This Template
Created by: Tim Adair
Last Updated: 3/5/2026
Version: 1.0.0
License: Free for personal and commercial use