OmniDocHow to write software testing requirements analysis: steps and examples
Explain how to write a software testing requirements analysis document: organize the items from the requirements list, split them into traceable test points, mark the priority and judgment basis, and submit it for review in Word format. At the same time, distinguish its division of labor from test plans and test reports.
Key points of this article
- Requirements analysis documents are located upstream and answer "what to test", which is different from the division of labor of test plans and test reports.
- First number each requirement, and then split it into numbered test points to facilitate traceability and change impact analysis.
- Each test point must state the input conditions, expected results and judgment basis to avoid vague descriptions such as "fast" and "reasonable"
- Check coverage, traceability relationships and terminology consistency item by item before delivery, and return missing items to the original requirements to supplement
After many testers get the project, they often write use cases first. As a result, the use cases repeat each other, but the boundary conditions in the requirements are missed. The problem often lies in the lack of a requirements analysis in the middle: split the requirements list into verifiable test points, and then derive use cases, test plans and test reports from the test points.
This article is written for test engineers and test leaders who need to independently produce test requirements analysis documents, as well as developers who have just taken over such tasks. After reading, you should be able to start from a list of requirements, sort out the requirements items, test points, priorities and traceability relationships, and deliver them for review in Word format.
The requirements analysis document is not a test plan or a test report. It is located upstream and answers "what to measure"; planning answers "how to measure, when to measure, and who will measure"; and reporting answers "how does it measure". The division of labor among the three is clear so that subsequent documents will not duplicate each other.
How to write software testing requirements analysis? One sentence conclusion
First number each requirement, then split each requirement into a number of verifiable test points, and finally mark the priority and source. In this way, any test point can be traced back to the original requirement, and when requirements change, the affected scope can be quickly identified.
| your situation | Recommended practices | reason |
|---|---|---|
| The requirements list is relatively complete and the function points are clear | Break down test points one by one and record them in tables | One-to-one correspondence saves trouble in traceability |
| The requirements are described in one sentence, but details are missing. | First confirm the input, output and abnormal scenarios with the product before splitting | It is easy to miss branches when there is insufficient basis |
| Requirements change frequently | Each requirement retains a version number, and test points reference the requirement number. | The impact of changes can be quickly identified |
| Involving multi-terminal or third-party interfaces | Group by end or interface, separate columns for dependencies and constraints | Avoid mixing test points at different ends |
| Team review required | Output Word version with revision history | Easy to comment and save |
Before you start: Confirm these points first
- Whether the requirements have been finalized: Confirm that you have received the version that has passed the review. The items on the draft will be changed repeatedly in the future, and the test points based on the draft will soon become invalid.
- Are the business terms consistent: The same concept may be written as "user", "member" and "account" in the requirements. Establish a glossary first to avoid inconsistent calibers between test points.
- Are non-functional requirements complete: Performance, security, compatibility, and usability are often scattered in appendices or notes. Miss them, and the test plan lacks corresponding verification direction.
- Judgment basis for each test point: The test point must be able to clearly explain "what is the passing standard". If the judgment can only be based on feeling, you should go back to the product or design documents to supplement it.
- Document ownership and version: Indicate the corresponding requirement version, writer and reviewer. This information may seem trivial, but it is the basis for subsequent planning and reporting.
Steps to write test requirements analysis document in Word format in UniDoc web editor
- Open the UniDoc web editor (app.unidoc.top) and create a new document.
- Write basic information at the beginning of the document: project name, requirement version number, author, reviewer and date.
- Set up a structure according to chapters: scope and terminology, list of requirements items, decomposition of test points, priorities and basis, and items to be confirmed.
- Organize the requirements list into a table, with one requirement per line, listing the requirement number, requirement description and source chapter.
- In the "Test point decomposition" section, list the test point number (such as TP-requirement number-serial number), test content, input conditions and expected results for each requirement.
- Mark the priority and type (function, exception, boundary, performance, security, etc.) for each test point, and write down the basis for judgment in the remarks.
- After completion, export it in Word format, send it to the reviewers for comments, and then update the revision record and version number based on the comments.
If the original requirements are in PDF, you can first export them to Word using the PDF editor of the desktop client (download.omnidoc.top), and then copy the requirement items into the analysis document. The original PDF remains intact, making it easier to check the source later.
Check each item after completion
| Check items | How to see | What to do if there is a problem |
|---|---|---|
| Demand coverage | Each requirement has a corresponding test point, and each item is screened according to the requirement number | If it's missing, return to the original requirement text for supplementary explanation |
| Tracing relationships | Each test point can point back to the requirement number, randomly selecting a few to look up the reverse lookup | Refers to the source that cannot be restored, or deleted |
| The expected outcome can be determined | Without asking the person, readers can directly judge whether they succeed or fail | Changing vague descriptions to observable results |
| Anomalies and boundaries | Whether scenarios such as null values, extremely long inputs, concurrency, and permissions have been considered | Supplement it under the corresponding requirements |
| The terminology is consistent | Compare item by item with the glossary | Rewrite it uniformly, keeping one explanation |
| Review comments are synchronized | Whether the revision record clearly states this change | Version numbers increase in number, indicating the changes to be made |
📊 Core Comparison: Requirements Analysis Documents, Test Plans, and Test Reports
| Documentation | Answer the question | Typical content |
|---|---|---|
| Test requirements analysis | Which points need to be measured, and what is the basis for determining each point? | Requirement items, test points, priorities, and traceability relationships |
| Test the plan | How to measure it, when to do it, who to measure it, and how to allocate resources | Scope, strategy, environment, personnel, schedule, risk |
| Test report | What are the results after testing, and what defects remain unclosed? | Implementation status, defect statistics, legacy issues, conclusions |
The sequence of these three is: requirements analysis comes first, plans are formulated based on it, and reports are written based on the execution results of the test points. Including test point content in the plan or writing execution results into requirements analysis can cause the document to lose boundaries.
❓ Frequently Asked Questions (FAQ)
1. What is the difference between test requirements analysis and test cases?
Requirements analysis answers "which points need to be tested," while use cases answer "how exactly to operate, what input, what results are expected." Use cases should be derived from test points, not directly disassembled from the original requirements.
2. The requirements document is a PDF. Can I write analyses directly within it?
It is not recommended to directly alter the original file. You can export to Word using a PDF editor, copy the required entries into a new analysis document, and keep the originals intact, making it easier to trace the source.
3. How detailed should the test point be disassembled?
A movement that can independently determine whether it passes or fails is the standard. A single requirement breaks down several test points, depending on the rules and the number of branches; the key is not to miss any branches.
4. Can test points be generated using machine translation or AI?
It can be used as a draft, but the business rules in the requirements must be checked individually. The generated content may not match the original requirements; important entries must be confirmed in the original text.
📝 Summary
The core of software testing requirements analysis is to first number it, then break down the points, and then verify: each test point must be traceable to the requirements and clearly state the basis for determination. Separate it from the test plan and test report, and the division of labor between documents becomes clear. Organizing and submitting it for review in Word format makes subsequent use case design and change management much smoother.
