There was a project team that started development with the original requirements written by the user, and then the situation continued, a crashing development process. Taking the original requirements written by users and writing our own requirements specification, the reason why it is important is that the original requirements written by users are a very ideal business requirement written without technical implementation. There is always a gap between the ideal and the reality. The reason why we write our own requirements specification is to describe the user's business needs in a practical and practical attitude. Those infeasible requirements are discarded or replaced with more feasible solutions. This is where the requirements specification comes in.
In theory, Requirement Specification is divided into user requirement specification and product requirement specification. The user requirement specification is the system business requirement described from the user's point of view, and is used to sign with the user to confirm the business requirement; the product requirement specification is the system business requirement described from the developer's point of view, which guides the developer to complete the design and development. technical documentation. However, in my opinion, the user requirements specification is not very different from the product requirements specification. What Domain-Driven Design advocates is to allow users, requirements analysts, and developers to stand on a platform and use a unified language (a hybrid language) to express concepts that are clearly understood by everyone. From this point of view, the requirements specification should be one, without distinguishing between user requirements specifications and product requirements specifications.
So how to write requirements specification? Different companies, different people, different projects, and especially different methods are used in requirements analysis, and the format of the written requirements specification is different. Here, I will give you a template that uses RUP unified modeling to analyze requirements and write requirements specification for your reference.
1. Introduction
1.1 Purpose of writing
If so, describe your purpose and role in writing this document. But most importantly, detail who can use the document and what to do. What is a requirements specification document used for? Undoubtedly, the first step is for users and development companies to confirm the business requirements and functional scope of software development. Secondly, of course, it is to guide designers and developers to design and develop systems. Of course, it also includes testers designing tests, technicians writing user manuals, and other relevant personnel familiarizing themselves with the system. These are described to help readers determine whether reading this document can be helpful.
1.2 Business Background
The business background is described for readers to understand the people and things related to this document. You can list various events related to the document, and you can also describe the current status of the enterprise related to the project, problem analysis and solution ideas, as well as the general background, policies and regulations that triggered the development of the project, and so on.
1.3 The project goal (or task overview)
is what benefits the project can bring to users, what problems it solves, or what is the success of the project. As mentioned earlier, this part plays a huge role in the success of the project.
1.4 References
The title, author, edition and date of preparation of the referenced material.
1.5 Definition of terms There is
nothing to say, it is the definitions and conventions of various terms or nouns that may be used in the document, and you can delete them as needed.
2. Overall Overview
This part is a general description of the system as a whole.
2.1
The overall action map drawn by the overall process analysis and its description.
2.2 Overall use case analysis
The overall use case diagram drawn, and the use case description for each use case. If the project is relatively large and there are multiple subsystems, the use case diagram can be changed to a component diagram to describe each subsystem and its mutual interface calls in detail.
2.3 Role Analysis
A use case diagram describes all the roles in the system and their interrelationships. In the description that follows, the definition of each role and its role are explained in detail.
这部分还可以根据项目需要编写其它的内容，如部署方案、网络设备、功能结构、软件架构、关键点难点技术方案，等等。
3．功能需求
3.1 功能模块（子系统）
一个一个描述系统中的每个功能模块（或子系统），即整体用例分析中的每个用例。这部分是需求规格说明书最主要的部分。
3.1.1 用例图
绘制该模块的用例图（详见《功能角色分析与用例图》）。
3.1.2 用例说明
对用例图中的每个用例编写用例说明（详见《用例说明》）。
3.1.3 领域模型
为用例绘制领域模型，并编写领域模型说明，对每个实体进行说明。对实体的说明包括对实体的定义、属性说明、行为说明、实体关系说明等等。如果实体间关系复杂，还要使用对象图说明实体关系的所有情况（如《领域驱动设计》中的描述）。
4．非功能需求
这里描述的是软件对非功能需求的一般要求，即整体设计原则。那些与具体功能相关的非功能需求应该放在用例说明的“非功能需求”部分（详见《非功能需求》）。
5．接口需求
如果项目涉及到与外部系统的接口，则编写这部分需求。
5.1 接口方案
详细描述采用什么体系结构与外部系统的接口。
5.2 接口定义
接口的中文名、英文名、功能描述、参数、返回值、使用者、使用频率，等等。
我们应当怎样做需求分析
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨会
我们应当怎样做需求调研：需求研讨
我们应当怎样做需求调研：迭代
我们应当怎样做需求调研：需求捕获（上）
我们应当怎样做需求调研：需求捕获（下）
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：业务流程分析（上）
我们应当怎样做需求分析：业务流程分析（下）
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：查询报表分析
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：行动图和状态图
我们应当怎样做需求分析：业务领域分析
我们应当怎样做需求分析：原文分析法
我们应当怎样做需求分析：领域驱动设计
我们应当怎样做需求分析：非功能需求
我们应当怎样做需求确认：需求列表
我们应当怎样做需求确认：一个需求列表的实例
我们应当怎样做需求确认：快速原型法
我们应当怎样做需求确认：需求规格说明书
我们应当怎样做需求确认：评审与签字确认会
-------------------------------
实例：