How to write a software functional requirements specification: list and requirements table

Key points of this article

The function list answers "what functions are there", and the requirements list answers "how to do each item and how to calculate it as completed". The two are combined into instructions.
Each requirement only describes a verifiable behavior, and requirements that cannot be written with test steps must be rewritten.
Before writing, confirm the functional boundaries, usage roles, existing materials, acceptance methods and main readers.
Use title styles to build the skeleton in Word, use tables to carry the function list and requirements table, and keep the numbers consistent.
Check number consistency, requirement verifiability, role coverage and matters to be confirmed before finalizing.

Many teams are required to submit a software functional requirements statement before development, but when they actually start writing, they often don’t know where to start: Should they write a large paragraph of background first, or directly list the functions? The written document is either like a list of functions and lacks acceptance basis; or it is full of descriptions, and the development and testing still do not match up after reading it.

This article is written for product managers, requirements analysts, and students in charge of documentation. We will only talk about one thing: how to structure the software function list, functional requirement list and requirement specification, and format them in Word into a document that others can directly read and develop and accept based on it.

After reading, you should be able to get a document structure that can be built according to the requirements, a field design of the requirements table, and a verification method after writing.

How to structure the software functional requirements specification? One sentence conclusion: Make a list of functions first, then write a requirement list for each item

First use the function list to clearly explain the scope, then use the requirements table to write down the rules and acceptance criteria one by one, and finally use the instructions to string the two together into a complete document. The three are in a layer-by-layer relationship, not three unrelated documents.

your situation	Recommended practices	reason
The project is small, with only a dozen functions	List and requirements table merged into one table	The document is short, so readers don’t have to turn pages back and forth.
Multiple functions, developed according to module division of labor	Divided into chapters by module, each module has a requirement list	Development and testing can receive tasks by module
Need to submit to Party A or reviewer	Description plus overview, scope, assumptions and constraints	Reviewers need to see boundaries and prerequisites
The same feature behaves differently for multiple characters	Added "Applicable Role" field to the requirement table	Avoid writing only one permission and missing other roles
Requirements are still being modified frequently	Put a version record table at the beginning of the document	It is easy to track which requirement has been changed in each modification

# before you start: confirm these points first

function boundary : first ask which functions should be done and which should not be done. If the boundary is not clear, new requirements will continue to be put forward during the review, and the document will become more and more messy.
use roles : list all the people who will use the system, such as administrators, ordinary users, and auditors. The visible content and operation permissions of the same function may be different for different roles, and if the role is left out, the requirements will not be written completely.
existing materials : collect meeting minutes, prototype diagrams and business flow charts. Most of the demand comes from these materials, which can reduce rework by sorting them out before writing.
acceptance method : figure out in advance how to complete each requirement. "the system should be fast" can not be accepted, "export a 30-page report, the page is not stuck, and generate a complete file" can be tested.
main readers : the focus of development, testing and Party An is different. The details of the manual should be determined around the main reader, and other readers can refer to the details through the appendix.

# steps to write requirements statement in Word

To build a new Word document, first use the title style to build a skeleton, and the first level title is followed by "Overview", "functional list", "functional requirements", "non-functional requirements", "acceptance and Appendix".

two. Write the purpose of the document, scope of application, noun explanation and version information in the Overview. This section only needs a few paragraphs to let new readers know what the document is about.

List all functions in a table in the function list, with fields including function number, function name, module and priority. The number cannot be repeated, and it should be referenced in the following requirements table.
Write a functional requirements table for each module, and the recommended fields are requirement number, function description, input, processing rules, output, priority, and acceptance criteria. Only one verifiable requirement is written per line.
Supplement non-functional requirements, such as performance, security, compatibility, and ease of use. Each item states the requirements in one sentence and gives the testable standard; if the standard cannot be determined for the time being, mark "to be determined" and state who confirms it.
Add two sections of "assumptions and constraints" and "matters to be confirmed" to centrally list the uncertainties and avoid writing the conjecture as a definite conclusion.
Edit in OmniDoc: if you use the UniDoc Page Editor (app.unidoc.top), it supports Word-compatible editing, and documents can travel back and forth between Word formats for easy team circulation and modification. If you only have the PDF version of the old manual, you can use the PDF editor in the desktop client (download.omnidoc.top) to export to a Word file, and then modify it according to the above structure.
Use the catalog function of Word to generate the catalogue before finalization, and check the title number and form number chapter by chapter to see if they are consistent.

# check item by item after completion

Don't send it directly after the document has been written. Check item by item according to the list below. The sooner the problem is found, the less rework will be.

Check item	What do you think?	What if there's a problem?
The number is the same.	Each number in the list can find the corresponding entry in the requirements table.	Missing completion, superfluous deletion or indication that it has been merged
Requirements can be verified	Each requirement can write specific inputs and expected results	Rewrite to specific conditions, such as "automatic pagination when more than 30 pages"
Role coverage	Compared with the list of roles, the main operations of each role have corresponding requirements.	Supplement the requirements, or state in the assumption that the role is not applicable
Unification of terms	The same concept uses only one name, which is consistent with the noun interpretation table.	Unified replacement to avoid two names for the same function
Matters to be confirmed	Each item has a responsible person and a time limit.	The responsible person will be appointed at the review meeting for matters that no one is responsible for.

# Core comparison

Functional lists, functional requirements tables, and requirements specifications are often mixed, with different uses and levels of detail.

Document form	The question answered	Included content	Main user
Function list	What are the functions of the system?	Number, name, module, priority	Project leader, Party A
Functional requirements table	How does each function work and how is it completed?	Input, rule, output, acceptance standard	Development, testing
Requirement statement	What are the requirements of the whole system?	Overview, scope, list, requirements table, non-functional requirements, assumptions	All project members and reviewers

# frequently asked questions (FAQ)

1. What is the difference between the software functional list and the functional requirements table?

The list only answers "what are the functions" and lists the name and priority; to answer "how to do and how to complete each function" in the requirements table, you need to state the rules and acceptance criteria.

2. What granularity should the functional requirements be written to?

The development can be implemented independently and the test can be independently verified. A requirement describes a behavior, and if "and" at the same time appears in a sentence, it should usually be split into two.

3. Does the requirement statement have to draw a flow chart?

A flow chart is attached to the complex business proposal, and the simple functions can be described in words. The picture can be put in the appendix, and the text is referenced by number.

4. Can the functional requirements be directly attached to the contract?

This depends on the mode of cooperation and legal requirements and should be confirmed with the legal or contract person-in-charge. The requirements statement is used to describe the requirements and is not a substitute for the terms of the contract.

# Summary

The core of the software functional requirements specification is to delineate the scope with the list, and then use the requirements table to write down each rule and acceptance method. Word title style and table can make this set of structure clear, after writing, check item by item according to the checklist, the document can really support the development and acceptance.

Open OmniDoc to edit and export documents online