Procurement Documents

Requirements Gathering Template and Traceability Matrix

A free, vendor-neutral requirements gathering template for buying software: a requirements register, a non-functional checklist and a traceability matrix that tracks each requirement to the contract.

18 pages Microsoft Word Updated November 15, 2026
Download Template
Requirements Gathering Template and Traceability Matrix

Preview the first pages

See the structure before you download. The Word file has every section listed below, ready to fill in.

Open preview Give feedback

What's inside

The sections in the document, in order.

  1. Purchase summary and objectives
  2. Stakeholders and how each was consulted
  3. Current process and pain points
  4. Requirements register
  5. Non-functional checklist
  6. Out of scope
  7. Assumptions and constraints
  8. Open questions
  9. Requirements traceability matrix
  10. Sign-off and change control

Use this requirements gathering template to collect, agree and write down what new software must do, and how well, before you write the RFP. It follows the requirements gathering guide: ask everyone the software will touch, record where each requirement came from, mark it Must-have or Nice-to-have, and decide how you'll check it.


It's written for teams buying software. Each requirement gets an ID with the same letters as the requirement sections of the free RFP template (F, T, I, S, M and C), so every row drops into the right RFP table and vendors answer it with a response code. The same IDs run through the requirements traceability matrix, from each finalist's response to the demo or proof of concept, the contract and acceptance testing.


The Word file is the buying team's internal working document, ready to use as it stands. Worked example rows from the guide's service desk example show how to fill in the register and the matrix: replace them with your own.


What's inside this template


  • A purchase summary with the problem, the objectives and how you'll measure them, the budget range and the approval route
  • A stakeholder table recording who was consulted, how (interview, workshop, process walk-through or document review) and which requirements each group raised
  • A current process walk-through for pain points, workarounds and why each step exists, plus the figures vendors price against: users by type, volumes, data to migrate and systems to connect
  • The requirements register: ID, requirement, type, priority, source or owner and how it will be verified, in six tables that match the free RFP template, with worked examples for a service desk tool
  • A non-functional checklist with prompts for security, performance, availability, scalability, usability and accessibility, integration, data residency and supportability
  • Out of scope (the "Won't have this time" list), assumptions and constraints, and open questions with owners and dates
  • A requirements traceability matrix with response codes for three finalists, demo or POC results, contract references, acceptance tests and status, plus sign-off and a change log

Download the editable Microsoft Word version below. The full text is on this page, so you can read it before you download.

How to use this template

Start the document as soon as the purchase has a sponsor, and finish Sections 1 to 8 before you write the RFP. Section 9, the traceability matrix, starts when proposals arrive and stays open until go-live.

  1. Set out the purchase and who to ask. Fill in Section 1 with the problem, the objectives and the budget route. Then list every group the software will touch in Section 2: business owners and users, IT and architecture, security and privacy, the administrators who will run it, and finance, legal and procurement.
  2. Gather requirements several ways. Interview each team separately, run workshops for processes that cross departments, watch the work being done and read tickets, audit findings and policies. Record each requirement’s source as you go, and fill in the volumes in Section 3, since vendors price against them.
  3. Write and prioritize each requirement. Write one need per line, as an outcome a vendor can answer and you can check, with no product names. Mark each one Must-have or Nice-to-have, and downgrade any Must-have you wouldn’t reject an otherwise strong vendor over. Go through the non-functional checklist with IT and security early, so their requirements don’t arrive later as addenda.
  4. Agree the scope and sign off. Move anything agreed as not part of this purchase to Section 6, record assumptions, constraints and open questions, and have the sponsor and each team sign Section 10. Then copy the register into the matching tables of the free RFP template, dropping the source or owner column.
  5. Trace each requirement to the contract. When proposals arrive, record each finalist’s response code in Section 9, then the demo or POC result. Plan the tests a demo can’t settle with the proof of concept template. After selection, add the contract reference and acceptance test for each row, and hand the matrix and its owner to the implementation team.

Business requirements, functional and non-functional requirements

A business requirements template, a requirements template and a requirements gathering template often cover overlapping ground, and the terms are used loosely. When you’re buying rather than building, write every requirement as an outcome a vendor can answer with a response code and you can verify, and let vendors propose how. How to Write an RFP shows where each kind sits in the finished RFP.

One common split, and where each kind goes in this template:

  • Business requirements: why the organization is buying and what has to change, such as a problem to solve or an objective to meet. They go in Section 1 with how you’ll measure them, and become the background and objectives in the RFP.
  • Functional requirements: what the software must do, such as tasks, workflows, data, business rules and reports. They’re the F rows in Section 4.
  • Non-functional requirements: how well the software must do it, and under what conditions, such as security, performance, availability and where data is stored. Section 5 has prompts for each area, and the answers become rows in the matching sections, mostly T, I, S and M.
  • Commercial requirements: pricing, contract terms and exit, usually from finance, procurement and legal. They’re the C rows.

Using the requirements traceability matrix

A requirements traceability matrix (RTM) links each requirement to everything that later addresses it. In software development that means items such as the design and the tests. In a purchase, the matrix follows each requirement through the RFP, the proposals, the demo or proof of concept, the contract and acceptance testing.

Fill it in as the purchase moves forward:

  • When the RFP goes out, give every Must-have and every Nice-to-have that carries real points a row and an RFP section. A requirement with no RFP section has been dropped, so check that the team agreed to drop it.
  • When proposals arrive, record each finalist’s response code: standard, configuration, custom, third party, roadmap or not available.
  • After demos and any proof of concept, record what each one showed. If a result shows a response code was wrong, act under the rules you set before proposals arrived, and score every finalist the same way, as the RFP evaluation criteria guide explains.
  • At signature, record where each commitment ended up: the order form, the statement of work’s acceptance criteria, the service-level agreement or the data processing agreement.
  • Through implementation, record the acceptance test for each row and its status until go-live. Give the matrix one owner, so it’s kept up to date.

The full template

This is the complete text of the Word document. Fill in the [bracketed] placeholders and delete the italic guidance before you use or send it.

Buyer instructions: this is the buying team’s internal working
document. It is not sent to vendors. Replace every [bracketed
placeholder], replace the rows marked Example with your own, and delete
the italic guidance when you’re done. Finish Sections 1 to 8 and get
Section 10 signed before the RFP goes out. Section 9, the traceability
matrix, starts when proposals arrive and stays open until
go-live.

1. Purchase summary and
objectives

Item Details
Organization [Organization name]
Purchase [Type of software or service, e.g. a service desk tool for IT and HR
support]
Executive sponsor [Name, title]
Requirements owner [Name, title: keeps this document and the change log]
Budget range and approval route [Range for the whole contract term, and who approves it]
Current system and contract [System being replaced, if any; contract end date and notice
deadline]
Target dates [RFP issued; contract signed; go-live]
Document version [Version number and date]

1.1 The problem

[A short paragraph in business terms: what’s broken today, who it
affects and what should change.]

1.2 Objectives

These are the business requirements: why you’re buying. They
become the project objectives in the RFP, so vendors read them as
background. Make each one measurable where you can.

Objective How we’ll measure it Today’s baseline Owner
[Example: every new ticket reaches the right support group without
manual triage]		 [Tickets reassigned after first routing, from service desk
reports]		 [Current figure] [Service desk lead]
[Objective] [Measure] [Baseline] [Owner]
[Objective] [Measure] [Baseline] [Owner]

2. Stakeholders and
how each was consulted

Ask everyone the software will touch, and use several methods,
since each finds things the others miss: interviews with each team
separately, workshops for processes that cross departments, process
walk-throughs, a review of tickets and complaints about the current
system, and documents such as policies and integration diagrams. Record
which requirements each group raised as you go.

Group or role Name What they need from this purchase How consulted Date Requirement IDs raised Signs off?
Executive sponsor [Name] [Budget, objectives, settling conflicts between teams] [Interview] [Date] [IDs] Yes
Business owner [Name] [The work to be supported] [Interview / workshop] Yes
End users: [team or role] [Names] [Daily tasks, what goes wrong, workarounds] [Interview / walk-through] [Yes / No]
IT and architecture [Name] [Integrations, data migration, hosting] [Workshop / document review] Yes
Security [Name] [Security requirements, the vendor security review] [Interview / document review] Yes
Privacy [Name] [Personal data, where data is stored, retention] [Document review] [Yes / No]
Administrator or support team [Name] [What they’ll run and change after go-live] [Interview / walk-through] [Yes / No]
Finance [Name] [Budget, cost over the contract term, payment terms] [Interview] [Yes / No]
Legal [Name] [Contract terms, confidentiality, data protection terms] [Document review] [Yes / No]
Procurement [Name] [Sourcing route, purchasing policy, the RFP process] [Interview] Yes
[Other group]

2.1 Sources reviewed

Source What it told us Requirement IDs
Service desk tickets and enhancement requests about the current
system		 [Summary] [IDs]
Audit findings and incident reviews
Security standards and retention policies
Regulatory or contractual obligations
Integration diagrams
Current contract, including the notice period
[Other source]

3. Current process and pain
points

Walk through the work as it’s done today. Rekeying, side
spreadsheets and manual month-end steps show up here. Ask why each step
exists: a step that exists only for an old workaround shouldn’t become a
requirement that vendors build and price.

3.1 Process walk-through

Step Who Tool used today Pain point or workaround Why the step exists Keep, change or drop Requirement IDs
[Example: an agent reads each new ticket and assigns it to a support
group]		 [Service desk agent] [Current service desk tool] [Assigned by hand; tickets sent to the wrong group wait in its
queue]		 [No routing rules in the current tool] [Change: route automatically] [F1]
[Step]
[Step]
[Step]

3.2 Current environment and
volumes

Vendors size their proposals from these figures, so gaps here
produce prices you can’t compare. They go into the scope and current
environment sections of the RFP.

Item Today Expected by [end of contract term] Source
Users by type [e.g. agents, requesters, administrators] [Current licenses / HR system]
Sites, countries and languages
Transaction volumes [e.g. tickets a month] [Current system reports]
Data to migrate [Record types, volumes, years of history, attachments]
Systems to connect [Each system and what it exchanges]
Identity provider and security tools [Names]

4. Requirements register

One row per requirement. Keep to one need per line, written as an
outcome a vendor can answer with a response code and you can check by a
demo, a proof of concept, a document or a contract term. Leave out
product names and one vendor’s feature terms, and let vendors propose
how.

Priority: a Must-have is pass or fail, so a vendor that can’t
meet it is out. A Nice-to-have earns points. Test each Must-have: would
you reject an otherwise strong vendor over it? If not, downgrade it. If
your team used MoSCoW, Musts become Must-haves, Shoulds and Coulds
become Nice-to-haves (Shoulds can carry more points), and Won’ts go to
Section 6.

IDs stay fixed from the first workshop to the contract. The
letters match the requirement sections of the free RFP template: F
functional, T technical and architecture, I integration, S security and
compliance, M implementation and support, C commercial and pricing.
Source or owner is who asked for the requirement and who will score the
answers. How it will be verified: scripted demo, proof of concept,
document, reference call or contract, or a combination. A row marked
proof of concept is a requirement a demo can’t prove.

Rows marked Example come from the service desk example in
RFPhub’s requirements gathering guide. Replace them with your own. In
the copy that goes into the RFP, drop the Source or owner column and add
columns for a response code and a comment.

4.1 Functional (F)

ID Requirement Type Priority Source or owner How it will be verified
F1 (Example) Route each new ticket to a support group based on its category and
the requester’s site.		 Functional Must-have Service desk lead Scripted demo
F2 (Example) Warn the requester when a new change overlaps one already scheduled
for the same service.		 Functional Nice-to-have Change manager Scripted demo
F3 [What the software must do, for whom, as one outcome] [Functional] [Must-have / Nice-to-have] [Team or role] [Method]
F4

4.2 Technical and architecture
(T)

ID Requirement Type Priority Source or owner How it will be verified
T1 (Example) Store ticket data, attachments and backups only in [country or
region].		 Data residency Must-have Privacy lead Document, then contract
T2 [e.g. Return search results across [number] records within
[seconds].]		 [Performance] [Proof of concept]
T3 [e.g. Support [future number] users and [future volume] without a
change of edition.]		 [Scalability]

4.3 Integration (I)

ID Requirement Type Priority Source or owner How it will be verified
I1 (Example) Turn monitoring alerts into tickets through a documented API,
without duplicates.		 Integration Must-have Infrastructure team Proof of concept
I2 [e.g. Single sign-on through our identity provider [name].] [Integration]
I3

4.4 Security and compliance
(S)

ID Requirement Type Priority Source or owner How it will be verified
S1 (Example) Only the HR support group can open HR case tickets. Security Must-have Security team Scripted demo
S2 [e.g. Require multi-factor authentication through our identity
provider for every [user type].]		 [Security]
S3

4.5 Implementation and support
(M)

ID Requirement Type Priority Source or owner How it will be verified
M1 (Example) A monthly availability commitment, with how it is measured and the
service credit.		 Availability Must-have IT operations Contract
M2 [e.g. Name who delivers the implementation (the vendor, a partner or
both) and the team’s experience with projects of similar size.]		 [Implementation]
M3

4.6 Commercial and pricing (C)

Commercial requirements usually come from finance, procurement
and legal: the license metric, one-time costs, renewal increases, the
term and exit.

ID Requirement Type Priority Source or owner How it will be verified
C1 [e.g. Pricing by [license metric], showing list price, discount and
net price, and exactly what counts toward the metric.]		 [Commercial] [Finance] [Pricing response, then contract]
C2 [e.g. Return of our data in a usable format at the end of the
contract, and its deletion afterwards.]		 [Commercial: exit] [Legal] [Contract]
C3

5. Non-functional checklist

Users can describe what the software must do. Ask IT, security
and the people who will run it how well it must do it, and under what
conditions. Work through every area, write each answer as a requirement
in Section 4, and record its ID here. If an area doesn’t apply, say
why.

Area Prompts Ask Usual section Requirement IDs
Security Who may see and change which data? How do users sign in, and is
multi-factor authentication required? What must be logged, and how long
must records and logs be kept? Which policies, standards or regulations
apply? What independent evidence will you ask vendors for?		 Security, privacy S [IDs]
Performance Which tasks must be fast, at what volumes, and at peak times such as
month-end? How will you measure it?		 Business owner, IT T
Availability When is the software used, and in which time zones? What happens to
the work during an outage? What availability commitment, measurement and
service credit will you ask for?		 Business owner, IT operations M
Scalability How many users, sites and records do you expect by the end of the
contract term? Would growth force a change of edition or license
tier?		 Sponsor, finance, IT T
Usability and accessibility Who uses it, on which devices and in which languages? Which
accessibility standard applies, such as [WCAG 2.2 Level AA or your
organization’s standard]?		 End users, [accessibility lead] F or S
Integration Which systems must exchange data with it, in which direction and how
often? Which identity provider handles single sign-on? Who builds and
maintains each connection?		 IT and architecture I
Data residency Where may data, backups and support access be located? Which laws,
contracts or customer commitments limit that?		 Privacy, legal T
Supportability Who will administer it, and what must they be able to change without
vendor services? How are updates released and tested? Which support
hours and channels do you need? Can you export all your data in a usable
format?		 Administrator or support team T or M

6. Out of scope

The “Won’t have this time” list: things the team has agreed
aren’t part of this purchase. State them in the RFP’s scope of work so
vendors don’t price them.

Item Why it’s out Agreed by Revisit
[Example: an IT asset management module] [Covered by our current tool until [date]] [Sponsor, IT lead] [At renewal / in a later phase / not planned]
[Item]
[Item]

7. Assumptions and
constraints

An assumption is something you’re treating as true but haven’t
confirmed. A constraint is a limit you have to work within. Either can
change a requirement or a price, so give each one an owner.

7.1 Assumptions

Assumption Owner How and when it will be confirmed Requirement IDs affected
[Example: our identity provider can connect to the new tool without
an upgrade]		 [IT lead] [Check with the identity team by [date]] [I2]
[Assumption]

7.2 Constraints

Constraint Type Source Effect on requirements
[Example: ticket data must stay in [country or region]] [Regulation / contract] [Privacy lead: [regulation or contract]] [T1]
[Constraint] [Budget / date / policy / regulation / technology / staffing]

8. Open questions

Log every question as it comes up. Some are settled inside the
team. Others are better put to the market in an RFI before the RFP, or
asked as a vendor question in the RFP itself.

Question Raised by Owner Needed by Answer from Answer and date Requirement IDs affected
[Example: do HR case tickets need their own retention period?] [HR lead] [Privacy lead] [Date] [Internal / RFI / RFP vendor question] [S1]
[Question]
[Question]

9. Requirements traceability
matrix

The matrix follows each requirement from the RFP to the contract
and acceptance testing, so you can see that none was dropped and that
what was proven made it into the contract. Track every Must-have and the
Nice-to-haves that carry real points. During evaluation, record a
response code for each finalist. After selection, keep the selected
vendor’s columns up to date through implementation.

Matrix owner: [Name, role]

Response codes, as used in RFPhub’s guides. If your RFP defines
different codes, use those instead.

Code What the vendor is saying
Standard Works out of the box in the edition priced
Configuration Met through settings, without code
Custom Needs code or a custom integration
Third party Needs a partner product or add-on
Roadmap Not available yet
Not available Can’t be met
ID RFP section [Finalist A] code [Finalist B] code [Finalist C] code Demo or POC result Contract reference Acceptance test Status
F2 (Example) Functional Standard Configuration Not available Demo (A): needed a third-party add-on Order form: add-on priced [User acceptance test reference] Rescored; open until acceptance
I1 (Example) Integration Configuration Custom Third party POC (A): passed Statement of work, acceptance criteria [reference] [Test reference]: alerts create tickets without duplicates Open until go-live
T1 (Example) Technical Standard Standard Standard Document (A): hosting regions checked Data processing agreement, clause [reference] None: verified by document and contract Closed
[ID] [Section] [Code] [Code] [Code] [Method (finalist): result] [Document and clause] [Test reference] [Status]
[ID]
[ID]

In the examples, Finalist A is the vendor selected. It answered
“standard” on F2, but the demo showed an add-on was needed, so the team
rescored the line under its advance rules and priced the add-on before
signature, not after go-live.

  • Demo or POC result: name the method and the finalist, such as
    “Demo (B): shown with our data”.
  • If a result shows a response code was wrong, act under the rules
    you set before proposals arrived. For a Nice-to-have, rescore the line
    and get any extra cost in writing before signature. For a Must-have,
    apply your pass/fail rules.
  • Contract reference: where the commitment ended up, such as the
    order form, the statement of work’s acceptance criteria, the
    service-level agreement or the data processing agreement. If a
    requirement that matters has no contract reference, decide before
    signature whether it needs one.
  • Acceptance test: the test the implementation team runs against
    the requirement before go-live or acceptance.
  • Status: for example, in RFP, rescored, in contract, open until
    go-live, accepted, closed or dropped. Record who agreed to drop a
    requirement, and why.

10. Sign-off and change
control

We confirm that the objectives in Section 1, the requirements and
priorities in Section 4 and the out-of-scope list in Section 6 are
agreed, and that every change from here on is recorded in Section
10.1.

Name Role Sections reviewed Signature Date
[Name] Executive sponsor All
[Name] Business owner [Sections]
[Name] IT and architecture [Sections]
[Name] Security and privacy [Sections]
[Name] Procurement [Sections]
[Name] [Finance / legal] [Sections]

Get sign-off before the RFP goes out. A requirement added after
the RFP is issued means an addendum to every vendor, a delay or a
re-issue.

10.1 Change log

Version Date Change Requirement IDs Reason Approved by
[Version] [Date] [Added / changed / reprioritized / dropped] [IDs] [Reason] [Name]

Frequently asked questions

What is a requirements gathering template?

It’s a structured document for collecting, agreeing and recording what new software must do and how well, with who asked for each requirement and how it will be checked. For a software purchase it’s filled in before the RFP, because the requirements become the questions vendors answer and the lines you score. This one adds a traceability matrix that follows each requirement through to the contract.

What should a requirements template include?

At minimum: the problem and objectives, the stakeholders consulted, the current process and its pain points, and a register of requirements with an ID, type, priority, source and verification method. Add prompts for non-functional requirements, what’s out of scope, assumptions and constraints, open questions and sign-off. For a purchase, a traceability matrix keeps track of each requirement after the RFP goes out.

What is a requirements traceability matrix template?

It’s a table that links each requirement to everything that later addresses it. In a software purchase, that means its RFP section, each finalist’s response code, the demo or proof of concept result, the contract reference and the acceptance test. It shows that no requirement was dropped and that what was proven made it into the contract.

What is the difference between business requirements and functional requirements?

Business requirements describe why the organization is buying and what has to change, such as an objective with a measure of success. Functional requirements describe what the software must do to get there, such as routing a ticket or producing a report. Non-functional requirements then say how well it must do it, such as security, performance and availability.

Should vendors see the requirements document?

Not this document. It’s the buying team’s working record, with stakeholder notes, the budget range, assumptions and open questions. Vendors get the requirements themselves in the RFP, without the source or owner column and with columns for a response code and a comment.

Related guides and templates

Download Template

Guides for this purchase

RequirementsRequirements Gathering for Software Purchases: Template and Traceability MatrixCollect and write requirements before the RFP goes out.GuideHow to Write an RFP: A Section-by-Section GuideWhat goes in each section of an RFP.ScoringRFP Scoring Matrix and Evaluation Criteria: How to Score ProposalsBuild a scoring matrix and score every proposal the same way.

More procurement documents templates