How to prepare an IT quote request: requirements document and template

What a requirements document is for (and when a short description is enough)

A requirements document describes what you expect from an IT project: why you are doing it, what it must cover, who it is for, under which constraints, and how you will know it is done. It serves three purposes:

• Clarifying your need internally, before you talk to a provider.
• Getting a precise quote, based on your real situation rather than on guesses.
• Serving as a reference during the project, so you can tell whether a request is part of the mandate or an addition.

You do not always need a long document. For a simple need, such as adding a few workstations or a small brochure website, a clear description of a few paragraphs is often enough: the context, what you want to achieve, your constraints and your preferred dates. A full requirements document becomes useful when the project involves several teams, existing systems, personal information or a budget that matters to your business.

The 10 sections of an IT requirements document

Keep these sections in this order: they move from why to how, then to when.

1. Context and problem to solve

Introduce your business in a few lines: industry, number of employees, locations, how you work. Then describe the problem to fix or the opportunity to seize, with concrete examples. "Our employees waste time looking for the right version of files" says more than "we want a new system."

2. Measurable goals

State what the project must change, in a way you can observe. A measurable goal names a result and a way to confirm it: "all customer requests arrive in one place," "every employee can reach their files securely from outside the office." Avoid vague goals such as "modernize our IT."

3. Scope: included, excluded, options

The scope says what the provider must deliver. Also list what is excluded and what could be offered as an option. The Canadian Centre for Cyber Security recommends that organizations list which parts of their information systems and assets are in scope for their security controls, and provide the rationale for excluding any. The same discipline applies to a project: a written exclusion prevents a misunderstanding later.

4. Users, roles and current processes

Who will use the solution, how many people and in which roles? Also describe how the work is done today, even if it happens on paper or in spreadsheets.

5. Prioritized functional requirements (essential, important, nice to have)

List what the solution must let people do, one requirement per line, and rank each one:

• Essential: without it, the project does not meet the need.
• Important: expected, but negotiable depending on budget or timeline.
• Nice to have: useful, can be planned for later if needed.

This ranking helps the provider propose a realistic first version, and helps you decide what to drop if the budget is not enough.

6. Technical constraints: existing systems, integrations, hosting

List the systems already in place that the project must respect or connect with: accounting software, email, website, management tools. State your hosting constraints and where you want your data to reside. The Canadian Centre for Cyber Security recommends that organizations consider their comfort level with the regulations in the legal jurisdictions where their outsourced providers store or use their sensitive information.

7. Security and personal information

State which data the project will touch and how sensitive it is, especially personal information about your customers or employees. Quebec's Act respecting the protection of personal information in the private sector, as amended by Law 25, sets out several obligations that apply directly to an IT project:

• Privacy impact assessment (s. 3.3): it is required for "any project to acquire, develop or overhaul an information system or electronic service delivery system involving the collection, use, communication, keeping or destruction of personal information." Your person in charge of the protection of personal information must be consulted from the outset of the project, and the assessment is proportionate to the sensitivity of the information, the purposes for which it is used, its quantity, distribution and medium.
• Portability (s. 3.3): the project must allow computerized personal information collected from a person to be communicated to that person in a structured, commonly used technological format.
• Written contract (s. 18.3): if you give personal information to the provider so it can perform the contract, the contract must be in writing and state the measures to protect its confidentiality, to use it only for the contract and not to keep it after the contract ends.
• Data outside Quebec (s. 17): if personal information is communicated outside Quebec, or entrusted to someone outside Quebec, the Act requires a privacy impact assessment and a written agreement.

Quebec's Commission d'accès à l'information publishes a guide, in French, that helps businesses analyze whether a privacy impact assessment is needed, along with an optional report template. For the details of these obligations, see our guide Law 25: what Quebec SMBs must do on the IT side.

8. Deliverables and acceptance criteria

Deliverables are what you will actually receive: a live website, a published app, an installed network, documentation, training, administrator access. For each one, write an acceptance criterion, meaning the condition that lets you say it is finished and compliant. Example: "an employee can create a request, track it and close it without help."

9. Preferred timeline and business constraints

State your preferred dates and what drives them: a peak season, a move, the end of a software contract. This is your timeline, not a commitment from the provider. The quote will show what is realistic.

10. Budget: whether to state a range

You can state a budget range or choose not to. A range helps the provider propose a solution that fits, for example by moving "nice to have" requirements to a later phase. If you do not know your budget yet, say so: that is useful information in itself.

Adapting the document to the type of project

Website

Specify the planned pages and content, who writes them, the languages, the forms and the integrations, such as a newsletter or a booking tool. If the site collects personal information, for example through a form, section 8.2 of the Act requires you to publish a privacy policy on the website, written in clear and simple terms. For security, the Canadian Centre for Cyber Security recommends following the Level 1 guidelines of the OWASP Application Security Verification Standard (ASVS) when a website handles sensitive information, and including ASVS compliance as a contractual requirement for outsourced websites. To get started, request a website development quote.

Mobile or web app

Describe user journeys step by step, the target platforms, accounts and roles, notifications and the data exchanged with your other systems. State who will own the source code and the app store accounts. If the app is offered to the public and has privacy settings, section 9.1 of the Act requires those settings to provide the highest level of confidentiality by default, without any action by the person concerned. Developing an app that involves personal information also falls within the scope of the section 3.3 privacy impact assessment. To get started, request an app development quote.

Managed IT and IT support

Here the document describes an ongoing service rather than a deliverable. Provide an inventory of workstations, servers, accounts and cloud services, the hours when you need support and the expected service levels. The Canadian Centre for Cyber Security lists points to consider with an outsourced provider: its privacy and data-handling policies, its notification processes when private data is accessed without authorization, data destruction at the end of the contract, and the physical location of data centres and of administrators. To pick the right model before writing, read our guide Managed IT, hourly technician or in-house IT: how to choose, then our guide How to choose an IT service provider in Quebec. You can also see our page on managed IT services.

Networking and cabling

Attach a floor plan, the number of jacks and devices per room, the areas that need Wi-Fi coverage and the existing equipment. State whether employees need remote access to the network and whether you offer Wi-Fi to visitors. The Canadian Centre for Cyber Security recommends, among other things, dedicated firewalls at the boundary of the corporate network, secure Wi-Fi, preferably WPA2-Enterprise, VPN with two-factor authentication for all remote access, and never connecting public Wi-Fi networks to corporate networks. These points can become requirements in your document. See also our page on business IT networking.

Common mistakes

• Describing a solution instead of a need. "We need this software" closes the door on other options. Describe the problem and let the provider propose.
• Forgetting exclusions. What is not written down gets interpreted, and not always the way you expected.
• Saying nothing about the existing setup. Without a picture of current systems and data, integrations and migration get underestimated.
• Leaving out acceptance criteria. Without them, it is hard to tell whether a deliverable is finished.
• Marking everything as essential. Without priorities, the provider cannot propose a smaller first version.
• Leaving security and personal information until the end. The Act requires you to consult your person in charge of the protection of personal information from the outset of a project covered by section 3.3.

Template to copy

Copy this template into your word processor and replace each prompt with your answer. Delete any section that does not apply, and say why.

1. Context and problem to solve: about the business, current situation, problem or opportunity, concrete examples.
2. Measurable goals: expected results and how you will confirm them.
3. Scope: what is included, what is excluded, what could be offered as an option.
4. Users, roles and current processes: who will use the solution, how many people, how the work is done today.
5. Functional requirements: one requirement per line, ranked essential, important or nice to have.
6. Technical constraints: existing systems, integrations, hosting, where data should reside.
7. Security and personal information: data involved and its sensitivity, person in charge of the protection of personal information consulted, need for a privacy impact assessment, security requirements.
8. Deliverables and acceptance criteria: list of deliverables, acceptance condition for each, documentation, training, handover of access.
9. Preferred timeline: preferred dates, business deadlines, periods to avoid.
10. Budget: range stated or not, with your explanation.

At the end, add the name of your company's contact person and how to reach them.

How to read the quote you receive

When the quote arrives, read it with your requirements document open beside it. Three questions do most of the work:

• Is every requirement covered? Go through your list line by line and find where the quote addresses it. A missing essential requirement must be clarified before you sign.
• Are exclusions explicit? A good quote also says what it does not include. If your exclusions and the provider's do not match, settle the point in writing.
• Are assumptions written down? A quote always rests on assumptions, for example about the state of your systems or the availability of your staff. They should be visible, because a wrong assumption can change the price or the timeline.

Also make sure the quote addresses the security and personal information points from your section 7, including the written contract required by section 18.3 of the Act if the provider receives personal information. For a one-time project such as an office move or a server replacement, see also our page on IT projects and integration.

Frequently asked questions

Sources

1. LégisQuébec, Act respecting the protection of personal information in the private sector (CQLR, c. P-39.1), sections 3.3, 8.2, 9.1, 17 and 18.3
2. Commission d'accès à l'information du Québec, Évaluation des facteurs relatifs à la vie privée : un guide plus convivial (in French)
3. Canadian Centre for Cyber Security, Baseline cyber security controls for small and medium organizations, sections 2.2, 3.9, 3.10 and 3.11