How to write a software requirements analysis document: structure and examples

Key points of this article

The core of the requirements analysis document is to write clearly "what to do" and allow each requirement to be checked, rather than designing "how to do it" in advance.
Commonly used skeletons include background and goals, scope, user roles, functional requirements, non-functional requirements, constraints and acceptance. Small projects can combine chapters.
Each requirement should have an independent number, a clear description, and acceptance criteria to facilitate item-by-item comparison during development, testing, and changes.
Functional requirements and non-functional requirements should be written separately. Performance, security, compatibility and other requirements should provide conditions that can be measured or verified.
After writing the first draft, you can continue to revise it in a Word-compatible editor, organize reviews, and record each change.

When many teams receive a new project, the first version of the document is often a list of functions: login, list, export, and start work after writing. After testing before going online, I discovered that everyone has different understandings of which fields are exported by "export", what is the format, and who has the permission. Software requirements analysis documents are designed to solve such problems.

This article is written for product managers, project leaders, business analysts who need to draft requirements documents, as well as students who are submitting a "requirements analysis" for the first time. After reading it, you will know what parts a complete requirements analysis document generally includes, to what extent each part should be written, and you can start writing by referring to a sample structure.

How to write a software requirements analysis document? One sentence conclusion

One sentence conclusion: First use a fixed chapter framework to separate the background, scope and requirements, and then write each requirement into a numbered item that can be accepted; chapters can be tailored according to the project scale, but the two things of "requirements" and "acceptance" cannot be omitted.

your situation	Recommended practices	reason
Small internal tool with no more than a dozen functions	Merged into four parts: "Background, Scope, Functional Requirements, and Acceptance"	The length is short, readers can read it all at once, and maintenance costs are low.
Multi-role, multi-module business system	Keep complete chapters and write functional requirements according to module groups	Different roles care about different parts, and they can be grouped to facilitate review.
There are rigid requirements for performance, safety and compliance	Write non-functional requirements in a separate chapter and give measurement conditions	These requirements are easily overlooked and will be referenced in development and testing after being listed separately.
Requirements change frequently	Each requirement is numbered, and a record of changes is kept at the end of the article.	Able to trace what was changed and why, to avoid verbal changes getting out of control
Need to confirm with external team or Party A	Added glossary and items to be confirmed	Reduce rework caused by different understanding of nouns

What does the software requirements analysis document contain?

The requirements analysis document (also often called the requirements specification) answers three questions: who does the system serve, what does it need to accomplish, and to what extent is it considered complete. It is neither a technical solution nor an interface design draft, but a basis for team alignment and cognition.

Common chapters and the content to be written in each

Background and Goals: Explain why this system is built, what business problems it solves, and what results it will achieve if it succeeds. Try to write the goal in terms of results that can be judged, such as "Change the approval process from offline paper to online submission."
Scope: Make it clear what will be done in this period and what will not be done. The "don't do" part is equally important, as it prevents demand from expanding indefinitely.
User Roles: List the roles that use the system, such as ordinary employees, department heads, and administrators, and describe the main tasks of each role.
Functional requirements: Organized by module or role, each requirement clearly states the trigger conditions, input, processing and output.
Non-functional requirements: including performance, security, usability, compatibility, data retention, etc.
Constraints and Assumptions: Such as existing systems used, time nodes, budget constraints, and unconfirmed premises.
Acceptance Criteria: Indicates under what circumstances it is considered passed, usually corresponding to the functional requirement number.
Change Record: Record the version number, date, modifier and modification content.

How to write requirement items before they can be checked

A good requirement usually contains three parts: number, description and acceptance conditions. For example:

No.: FR-03
Description: The department head can approve or reject the reimbursement form submitted by his subordinates in the to-do list. The reason must be filled in when rejecting.
Acceptance: After logging in, the supervisor can see the department's to-do list; when rejecting the document, it cannot be submitted without filling in the reason; the reason for rejection can be seen on the employee side of the rejected document.

Written this way, development knows what to do, testing knows how to test, and the number can be directly located when requirements change. On the other hand, descriptions such as "the system must be convenient and easy to use" cannot be accepted and should be rewritten into specific and judgeable conditions.

Common misunderstandings

Misunderstanding 1: Requirements analysis equals function list. The function list only answers "what is there" and lacks objects, conditions and results. After reading it, you will still have multiple understandings.
Misunderstanding 2: The thicker the document, the more complete it is. Length does not equal quality. Putting in the color of every button will drown out the really important business rules.
Misunderstanding 3: Requirements analysis should replace design. Requirements describe "what is needed", and design describes "how to achieve it". Writing the database table structure into the requirements will unnecessarily restrict subsequent technology choices.

📊 Core comparison

There are several common ways to write requirement items, applicable to different scenarios:

Writing method	Features	Suitable scene
User story style (as a role, I want to..., so that...)	Easily understand value from the user’s perspective	Agile team, iterate faster products
Numbered entry formula (FR-01, FR-02…)	Fixed structure for easy reference and traceability	Contract projects, systems requiring formal review
Use case format (actors, preconditions, main process, exception process)	Comprehensive coverage of abnormal situations	Business systems with complex processes and many branches
Prototype annotation	Intuitive, suitable for interface-based functions	Products with many front ends and relatively simple business rules

In actual projects, a common practice is to use numbered items as the main body, complex processes with use case descriptions, and interface-related requirements with prototypes or screenshots.

How to use it in practice: Use OmniDoc to draft and modify requirements analysis documents

OmniDoc's UniDoc web editor supports Word-compatible editing, which is suitable for writing the first draft of a requirements analysis document into Word format and continuously revising it. You can follow these steps:

Open app.unidoc.top, create a new document, create first-level and second-level headings according to the above chapter structure, and set up the framework first.
In the "Scope" section, first write two lists of "Included in this issue" and "Not included in this issue" before entering into writing functional requirements to avoid expanding the scope while writing.
Each functional requirement is entered in the format of "Number, Description, Acceptance", and the numbering remains continuous. When deleting a requirement, do not rearrange the numbering directly to avoid invalid references in other documents.
After writing the document, export it to a Word file and send it to the team for review. Existing PDF versions (such as the old requirements document provided by Party A) can be modified in the PDF editor of the desktop client, and then exported to a Word file to continue editing.
Each time a version is revised, add a row of version number, date, modifier and key points of the change to the change record, and then issue a new version.

If the requirements contain flow charts or formulas, be sure to check whether the exported format is correct when editing. Text involving machine translation or OCR recognition needs to be checked paragraph by paragraph before submission for review.

🎯 Which method is suitable for you?

If you are a student or a new analyst, first complete a complete first draft according to the six parts of "background, scope, functional requirements, non-functional requirements, acceptance, and change records", and then add or delete according to the needs of the project.
If you are the project leader, focus on checking whether each requirement has a number and acceptance conditions, and whether the "what not to do" is clearly written.
If you also want to connect with external teams, you can add a glossary and items to be confirmed at the end of the article. Each item to be confirmed is marked with the person in charge and the deadline.

❓ Frequently Asked Questions (FAQ)

1. Are software requirements analysis documents and requirements specifications the same thing?

The two are often used interchangeably in actual work, and their contents are highly overlapping. Requirements analysis focuses on the process of analysis and sorting, while requirements specification focuses on the final formal document. Just use a unified name within the team. The key is the quality of chapters and entries.

2. Where can I find a sample doc for software requirements analysis document?

The quality of online examples varies, and some are written for specific industries. Direct application makes it easy to copy irrelevant content. A safer approach is to only learn from the chapter framework and then fill in the content according to the business rules of your own project.

3. How detailed should the requirements analysis document be?

The standard is that "development and testing can independently understand and accept each other". Places involving business rules, exception handling and permissions must be written clearly, and the details of pure interface styles can be left to the design draft.

4. Requirements change frequently, is it still necessary to write documents?

It is necessary. The change itself is not terrible, the terrible thing is that the change is not recorded. By numbering each requirement and keeping a record of changes, you can make it clear which version is based on when a dispute arises.

5. What is easily missed in software project requirements analysis?

Common omissions include non-functional requirements (such as data backup, concurrency levels, permission details), abnormal situations (such as data processing after network interruption), and interface agreements with other systems. After you’ve written your first draft, you can go through each of these three categories.

📝 Summary

The value of a software requirements analysis document is to provide the team with a consistent understanding of "what is to be done." Organize the content according to the structure of background, scope, functional requirements, non-functional requirements, acceptance and change records. Each requirement is written as an item that can be checked, and the document can truly guide development and testing. When drafting and revising, you can use Word-compatible editing tools to keep your document clear through multiple rounds of reviews.

Open OmniDoc, edit and export documents online