Functional requirements document template Excel

Functional requirements document template Excel

This article provides details of functional requirements document template Excel that you can download now.

Microsoft Excel software under a Windows environment is required to use this template

These functional requirements document template Excel work on all versions of Excel since 2007.

Examples of a ready-to-use spreadsheet: Download this table in Excel (.xls) format, and complete it with your specific information.

To be able to use these models correctly, you must first activate the macros at startup.

The file to download presents four templates Functional requirements document template Excel:

  • Excel template simple agile user story
  • Excel template website technical specification template
  • Requirements Matrix Template
  • Template requirements traceability Matrix

The requirements within this document are meant to be solution independent. They are intended to provide a statement of what the solution is to do and how well it should do it but not of how it will be implemented.

Approval of this document along with the associated Service Specification Overview (if provided) is taken as confirmation that our understanding of the requirements and business rules is correct.


The table (see Matrix Grid tab) identifies fields for:

  • “Unique Number” – Provide a unique identifier for each requirement to allow for tracing against project deliverables and testing activities. The naming convention can be as simple (1, 2, 3, etc.) or complex (e.g. multiple unique codes to identify the requirement by project, business unit, functional purpose, date added, SME assigned, etc.) as needed for your specific project. Documents that have more complex identifiers with unique coding should also include a legend for document reviewers.
  • “Description” – a brief description of the requirement sufficient for the reader and project team to understand its purpose and how it will impact the final functionality of the project/product.
  • “Requirement Origin” – name of the individual, role, organization, document etc. from which the requirement was originated. This will ensure that all the appropriate parties have been notified and consulted if a requirement needs to be better understood, revised and/or eliminated during the course of the project.
  • “Business Priority” – examples of categorization would be High, Medium and Low; or Critical, Must Have and Nice to Have; Mandatory, Standard, Custom, Unnecessary. A legend must be provided to assist the reader and maintain consistency throughout the project.
  • “Technical Priority” – examples of categorization would be High, Medium and Low; or Critical, Must Have and Nice to Have; or Complex, Moderate and Simple. A legend must be provided to assist the reader and maintain consistency throughout the project.
  • “Estimate (cost, time)” – Initial requirements identified could be designated as In Scope to show that they have been included in the original baselined activity schedule. As requirements are either added or deleted, it will become necessary to capture the cost and time associated with each in order to fully realize the impact on the project cost and schedule remaining.
  • “Phase, Release, Iteration” – Initial requirements should be identified as “in scope” or “out of scope” for project scheduling and costing. If the implementation will contain multiple phases or releases, requirements can further broken down into the appropriate work phase or release. This field can also be used to capture requirements that are identified during the course of the project for future enhancements and/or upgrades. By capturing the information in one document that is reviewed and confirmed throughout the project, all stakeholders will remain informed as to final project/product functionality.

Other fields can be added as needed for your specific project.

What is a requirement?

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.

This is inevitable as requirements may serve a dual function

  • May be the basis for a bid for a contract – therefore must be open to interpretation;
  • May be the basis for the contract itself – therefore must be defined in detail;
  • Both these statements may be called requirements.

Requirements abstraction (Davis)

“If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.”

Case studies

A personal insulin pump

  • An embedded system in an insulin pump used by diabetics to maintain blood glucose control.

A mental health case patient management system

  • A system used to maintain records of people receiving care for mental health problems.

A wilderness weather station

  • A data collection system that collects data about weather conditions in remote areas.

Insulin pump control system

– Collects data from a blood sugar sensor and calculates the amount of insulin required to be injected.

– Calculation based on the rate of change of blood sugar levels.

– Sends signals to a micro-pump to deliver the correct dose of insulin.

– Safety-critical system as low blood sugars can lead to brain malfunctioning, coma and death; high-blood sugar levels have long-term consequences such as eye and kidney damage.

Essential high-level requirements

– The system shall be available to deliver insulin when required.

– The system shall perform reliably and deliver the correct amount of insulin to counteract the current level of blood sugar.

– The system must therefore be designed and implemented to ensure that the system always meets these requirements.

Types of requirement

User requirements

  • Statements in natural language plus diagrams of the services the system provides and its operational constraints.

Written for customers.

System requirements

  • A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

User requirement definition

The MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month.

System requirements specification

  1. On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated.
  2. The system shall automatically generate the report for printing after 17.30 on the last working day of the month.
  3. A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs.
  4. If drugs are available in different dose units (e.g. 10mg, 20 mg, etc.) separate reports shall be created for each dose unit.
  5. Access to all cost reports shall be restricted to authorized users listed on a management access control list.