Requirements Gathering for Software Purchases: Template and Traceability Matrix
Published on November 14, 2026 in RFP Guides
Requirements gathering is finding out what new software must do, and how well, from the people who will use it, run it and secure it. When you’re buying, it comes before the RFP: the requirements become the questions vendors answer, the lines you score and, later, commitments in the contract. This guide covers who to involve, functional and non-functional requirements, writing and prioritizing them, a template to copy and a traceability matrix.
Why requirements come before the RFP
Vendors answer the questions you ask. A vague requirement such as “easy to use” gets a “yes” from every bidder, and a need you never wrote down goes unanswered. How to write an RFP covers the document; this guide covers the step before it.
Later, the same list sets the scope vendors price, the Must-haves checked pass or fail, the demo script, the proof of concept’s success criteria and the acceptance criteria in the statement of work. A requirement found after the RFP is out means an addendum, a delay or a re-issue. In the RFP process guide‘s example timeline, draft requirements are ready by the end of week 2, and an RFI, if you send one, helps sharpen them.
Who to involve and how
Ask everyone the software will touch: business owners and users, IT and architecture, security and privacy, the administrator or support team who will run it, and finance, legal and procurement. Use several methods, since each finds things the others miss:
- Interviews. Meet each team separately. Ask what they do, what goes wrong and what they work around, not which features they want.
- Workshops. Bring teams together when a process crosses departments, agree one version of it, and let the sponsor settle what the teams can’t.
- Process walk-throughs. Watch the work being done. Rekeying, side spreadsheets and manual month-end steps show up here.
- Current tools and complaints. Read service desk tickets and enhancement requests about the current system, audit findings and incident reviews.
- Documents. Security standards, retention policies, regulatory obligations, integration diagrams and the current contract’s notice period.
Record each requirement’s source as you go, and collect the figures vendors price against: users by type, volumes, data to migrate and systems to connect.
Functional and non-functional requirements
Functional requirements say what the software must do: tasks, workflows, data, business rules and reports. Non-functional requirements say how well, and under what conditions: security, performance and the other qualities that decide whether it works for you. Users can describe the first kind; ask IT and security for the second.
These examples are for a service desk tool, one of the categories in the IT RFP templates. [Brackets] mark your own figures.
| Type | Example requirement |
|---|---|
| Functional: workflow | Route each new ticket to a support group based on its category and the requester’s site. |
| Functional: reporting | Email each team lead a weekly report of open tickets by age. |
| Security | Require multi-factor authentication through our identity provider for every agent. |
| Performance | Return search results across [number] tickets within [seconds]. |
| Availability | Keep the agent and self-service portals available [percentage] of each month, excluding announced maintenance. |
| Scalability | Support [future number] agents and [future volume] tickets a month without a change of edition. |
| Usability and accessibility | Let requesters raise a ticket from a phone browser, conforming to [WCAG 2.2 Level AA or your organization’s standard]. |
| Integration | Turn alerts from our monitoring tools into tickets through a documented API, without duplicates. |
| Data residency | Store ticket data, attachments and backups only in [country or region]. |
| Supportability | Let our administrators change forms and workflows without vendor services, with changes kept through upgrades. |
Some teams class integration and data residency as constraints instead; what matters is that they’re listed.
Writing requirements vendors can answer
A good requirement can take a response code (standard, configuration, custom, third party, roadmap or not available) and then be checked. Keep to one need per line: a line with two gets a “yes” when the vendor meets one. Make it testable by a demo, a proof of concept, a document or a contract term. Leave out product names and one vendor’s feature terms, which tilt the RFP toward that vendor and, in public procurement, can raise fairness concerns. State the outcome and let vendors propose how.
| Weak | Stronger | Why it’s better |
|---|---|---|
| “Must be secure.” | “Only the HR support group can open HR case tickets.” | Names the data and who may see it, so a demo can test it. |
| “Highly available.” | “State the monthly availability you commit to, how it is measured and the service credit if you miss it.” | Turns an adjective into a contract term. |
| “Works like our current tool.” | “Warn the requester when a new change overlaps one already scheduled for the same service.” | States the outcome, so every vendor can answer. |
| “Complies with our security policy.” | “Meet each control in Appendix [B], our SaaS security standard, and give a response code for each.” | Vendors can’t answer a policy they haven’t seen. |
Prioritizing requirements
RFPhub’s templates mark each requirement Must-have or Nice-to-have. A Must-have is pass or fail: 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.
MoSCoW is another common method, with four groups: Must have (the minimum the solution can’t do without), Should have (important but not vital), Could have (wanted, with less impact if left out) and Won’t have this time (agreed as not part of this delivery). It’s framed around what a project delivers in a given timeframe, but it maps onto an RFP. Musts become Must-haves, Shoulds and Coulds become Nice-to-haves (Shoulds can carry more points), and Won’ts are listed as out of scope so vendors don’t price them. Agree priorities and weights with the buying team before the RFP goes out; the RFP evaluation criteria guide covers scoring.
A requirements gathering template
Keep the list in a spreadsheet, one row per requirement:
| ID | Requirement | Type | Priority | Source or owner | How it will be verified |
|---|---|---|---|---|---|
| F1 | 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 | Warn the requester when a new change overlaps one already scheduled for the same service. | Functional | Nice-to-have | Change manager | Scripted demo |
| S1 | Only the HR support group can open HR case tickets. | Security | Must-have | Security team | Scripted demo |
| I1 | Turn monitoring alerts into tickets through a documented API, without duplicates. | Integration | Must-have | Infrastructure team | Proof of concept |
| T1 | Store ticket data, attachments and backups only in [country or region]. | Data residency | Must-have | Privacy lead | Document, then contract |
| M1 | A monthly availability commitment, with how it is measured and the service credit. | Availability | Must-have | IT operations | Contract |
IDs stay fixed from the first workshop to the contract. The letters match the requirement sections of the free RFP template (M is implementation and support), so each row drops into the right table. Source or owner is who asked for it and who will score the answers. The last column outlines your demo script and your proof of concept plan: a row marked “proof of concept” is a requirement a demo can’t prove. Vendors’ copies drop the source or owner column and add a response code and a comment.
A requirements traceability matrix
A requirements traceability matrix (RTM) links each requirement to everything that later addresses it. The NIST glossary defines a traceability matrix as one that records the relationship between two or more products of the development process, such as requirements and design. A buyer’s version follows the purchase instead: the RFP section, the vendor’s response code, the demo or proof of concept result and the contract clause. It shows whether every requirement reached the RFP and whether what was proven made it into the contract, where the implementation team can test against it at acceptance.
Keep a response-code column per finalist during evaluation, then the selected vendor’s version through implementation:
| ID | RFP section | Response code | Demo or POC result | Contract reference | Status |
|---|---|---|---|---|---|
| F2 | Functional | Standard | Demo: needed a third-party add-on | Order form: add-on priced | Rescored, closed |
| I1 | Integration | Configuration | POC: passed | SOW acceptance test [reference] | Open until go-live |
| T1 | Technical | Standard | Document: hosting regions checked | Data processing agreement, clause [reference] | Closed |
Row F2 is the reason to keep one. The vendor answered “standard”, but the demo showed it needed an add-on, so the team rescored the line under its advance rules and priced the add-on before signature, not after go-live. Track every Must-have and the Nice-to-haves that carry real points, and give the matrix an owner.
Common mistakes
- Copying a vendor’s feature list. It describes one product in that vendor’s terms, and that product looks strongest by default.
- Writing the current system’s quirks as requirements. A field that exists only for an old workaround becomes something vendors build and price. Ask why each step exists.
- Too many Must-haves. Each one can eliminate a vendor, and a long list can rule out the strongest overall vendor over a minor gap.
- Forgetting security and integration until late. Their requirements then arrive as addenda, or as findings after you’ve chosen. Bring IT and security to the first workshop. The vendor security assessment guide covers the security review.
When the list is agreed, move it into the free RFP template, and plan the tests a demo can’t settle with the proof of concept template. For the wider buying process, see the IT procurement guide.
Frequently asked questions
What is requirements gathering?
Requirements gathering is collecting, agreeing and writing down what a system must do and how well, from the people who will use it, run it and secure it. For a software purchase it comes before the RFP, because the requirements become the questions vendors answer and the lines you score.
What is the difference between functional and non-functional requirements?
Functional requirements describe what the software must do, such as routing a ticket or producing a report. Non-functional requirements describe how well it must do it and under what conditions, such as security, performance, availability, integration and where data is stored. A software purchase needs both.
What is a requirements traceability matrix?
It’s a table that links each requirement to everything that later addresses it. In a software purchase, that means its RFP section, each vendor’s response code, the demo or proof of concept result and the contract clause. It shows that no requirement was dropped and that what was proven made it into the contract.
How do you prioritize requirements?
Mark each requirement Must-have, meaning a vendor that can’t meet it is out, or Nice-to-have, meaning it earns points. MoSCoW is another common method, with four groups: Must have, Should have, Could have and Won’t have this time. Keep the Must-have list short, and agree priorities before the RFP is issued.
Who should be involved in requirements gathering?
Everyone the software will touch: business owners and users, IT and architecture, security and privacy, and whoever will administer it after go-live. Finance, legal and procurement add budget, contract and process requirements, and an executive sponsor settles conflicts between teams.