软件需求规格说明书怎么写？附标准格式样例

1.文档概述

1.1 编写目的

【根据不同业务背景的读者，应该提醒重点阅读哪些内容。】

示例：

《软件需求规格说明书》主要是为xx系统所撰写的需求规格说明书。

由于软件开发过程中，最终用户无法准确描述需求，无法理解专业术语，同一事物的理解易造成歧义。

为了避免需求频繁变更，便于明确用户的需求，以求在项目组成员与其他相关成员之间达成一致的需求描述，特编写此需求文档。

本说明书的预期读者为A人员、B人员、C人员、开发人员、测试人员、评审人员。

预期读者	阅读建议
A人员	仔细阅读概述、编写目的、文档约定、系统功能需求、非功能需求与功能列表说明
B人员	仔细阅读概述、编写目的、文档约定、系统功能需求、非功能需求与功能列表说明
C人员	仔细阅读概述、编写目的、文档约定、系统功能需求、非功能需求与功能列表说明
开发人员	仔细阅读全部内容
测试人员	仔细阅读全部内容
评审人员	仔细阅读与评审侧重点相关的内容

1.2 背景

示例：

由于xx问题，由xx提出了xx的解决方案。在经过需求的大概调研后，由xxx整理了此软件需求规格说明书。

1.3术语定义

【术语表应该要解释在本文件中多次出现、易于混淆或者重要的术语，应该被wiki单独管理。】

术语	含义
xx	xxxxxx

1.4参考资料

示例：
《2006-2020国家信息化发展战略》

《软件需求最佳实践》

2.任务概述

2.1业务需求

【面对破解混沌不清的项目目标，一是破解混沌不清的项目目标，寻找真正的项目发起人，二是外部溯源，寻找外部因素所激发的项目】
【要么是解决问题的，要么是创造机会的】

例如：
（1）解决预约安排不合理的问题：避免出现体检部门超负荷；
（2）解决物资供应脱节问题：通过安全库存量管理避免物资短缺现象出现。
…

2.2项目相关人员分析

【项目越与高层管理人员沟通，项目越容易成功。】

2.3用户特点分析

【对于用户而言，我们需要收集和分析的信息包括：与主题相关的经验、技术上的经验、智力能力、对工作的态度、对技术的态度、受教育程度、语言技能、年龄、性别等信息。换句话说，是对其能力进行建模。】

2.4相关事实与假定

【相关事实是可能对产品产生影响的外部因素，例如：原有应用程序主要的问题就是查询操作太慢，导致系统无法正常使用。这样开发人员在处理新系统的查询操作时，就会对性能问题予以足够的重视。】
【假定的内容包括需求定义阶段中所做的假设清单，这些假设都是对产品开发有影响的；它和相关事实的区别在于，它不一定是真实的】

3.业务模型分析

3.1 系统概述

【划分主题域】
示例：
本系统是由客服管理子系统、物资管理子系统、体检业务子系统三个主题域构成的，它们之间的关系如下图所示。

划分依据：
（1）主题域应该按照职责划分，而不是系统的模块划分
（2）应该结合目标来考虑这些主题域，对系统既定目标没有直接贡献，应该将它移出我们的视野。

3.2 体检业务子系统 【主题域1】

本主题域的主要用户是物资部门，将对物资申领、计划、采购、库存管理等任务提供支持。其范围如下图所示。

3.2.1 业务事件

3.2.1.1 体检者申请体检

3.2.1.1.1 业务流程分析

【画流程图】
【简单的事件可以只用文本描述；复杂的事件则可以通过多个业务流程图来表示它。】
当体检者到医院进行体检时，首先到服务中心办理开单、收费业务，然后手持纸质的体检单到各体检科室进行体检，当所有体检结果都生成之后，综合科医生将根据体检结果出具体检报告，此时体检人就可以从服务中心领取结果。其流程如图3所示。

3.2.1.1.2 业务实体分析

【类图】
在这个业务流程中，主要涉及的业务实体以及它们之间的关系如图4所示。

3.2.1.1.3 用例分析

【用例图】
在这个业务流程中，有四类直接与系统交互的用户：服务人员、体检医生、收费人员、综合科医生，涉及的业务活动（用例）如图所示。

3.2.1.2 体检者中途改单

3.2.1.3 财务部门提交团队缴费情况

3.2.1.4 客服中心查询体检情况

3.2.1.5 维护人员管理体检项

3.2.1.6 系统通知用户取报告

3.2.2 报表

3.2.2.1 体检业务周期统计报表

（1）概述
部门/职位：分管体检业务的副院长，服务中心、体检科室、综合科主任
目的：
1.了解每个体检项、体检套餐的承接情况；
2.了解每个体检科室的任务量；
3.了解体检业务量的周期性和增长情况。
相关场景与查询频率：
1.频率：每天、每月、每季固定发生一次；平时不定期发生，频率一般为每人每天不超过3次
2.用户数量：4～10人
（2）数据内容
在此类查询中，主要涉及体检科室、体检单、体检项目和体检套餐4个类，其关系如图16所示。

（3）报表项
具体而言，此类报表包括3种，如图所示。

3.2.2.2 当前体检业务情况

3.2.2.3 团队体检过程报表

3.2.2.4 改单业务情况统计

3.2.2.5 报告领取情况查询

3.2.2.6 体检科室超负荷预警

3.2.2.7 体检业务分类统计

3.2.2.8 各体检项统计表

3.2.3 服务接口

3.2.3.1 获取公司客户收费信息

3.2.3.2 查询团队体检完成情况

3.3 物资管理子系统【主题域2】

本主题域的主要用户是客户中心，将对销售、预约安排等任务提供支持。其范围如下图所示：……

4．具体需求

4.1 体检业务子系统

4.1.1用例模型

4.1.1.1 开单（UC_B_TJ_KaiDan）

1、概述

• 用例名称：开单
• 编号：UC_B_TJ_KaiDan
• 参与者：服务人员
• 用例概述：服务人员根据体检者的选择或预约单开具体检单，并打印出来交给体检者。
• 相关Stakholder：
  

2、事件流

• 前置条件：无
• 后置条件：确保没有重复的体检项目
• 基本事件流：
  • 1.参与者输入用户姓名或预约号，系统确认用户已经预约，并从预约单中获取体检套餐与体检项目显出在屏幕上；
  • 2.系统确认用户选择的体检套餐与体检项目符合要求（参见规则UC_KD_01）；
  • 3.系统保存并打印体检单。
• 备选（扩展）事件流：
  • 1a.参与者或系统确认用户没有预约
    • 1a1.参与者输入用户基本信息，并根据用户选择输入体检套餐与体检项目信息。
  • 1b.系统发现有多个可能重名的预约用户
    • 1b1.系统显示出所有可能重名的预约用户，并显示区分身份的主要信息；
    • 1b2.参与者从中选择符合的预约用户，并从相应的预约单中调出数据。
  • 2a.用户选择的体检套餐不符合要求
    • 2a1.系统给出具体的提示信息，并且阻止参与者完成体检单。
• 异常事件流：
  • 3a.系统保存或打印失败
    • 3a1.系统仍然显示信息录入界面，并提示失败原因。
  • 3b.用户发现打印失败
    • 3b1.系统已退出信息录入界面，参与者可切换到历史体检单界面，重新打印已保存的体检单。

3、相关需求

• 用户原始需求：
  – 通过输入预约号或姓名可查询是否预约，如果有重名则应该都显示；
  – 体检者选择的体检项目若属于已选择的体检套餐，则应提示并说明对应套餐；
  – 如果发现打印出来的体检单不清晰，系统能够支持重新打印的功能。
• 相关功能点：
  – 体检单打印时使用Excel作为模板，模板文件可管理。
  – 当体检者选择出多个体检项目时，系统能够自动给出体检套餐建议。

4、用户界面原型

• 窗口概述：
  – 历史体检单页面：显示已生成的历史体检单信息，在开单工作开始之前将在该页面中（该页面同时是“返回报告”用例的基础，选中历史体检单，点击打印报告……）。
  – 预约判断界面：用来输入预约信息，实现预约单的选择与调取。体检单生成界面：用来录入与验证体检单信息。
  – 打印页面：提供打印预览窗口。
  – 失败提示页面：可能包括多个，显示错误信息，帮助用户提供操作。

• 界面流转示意图：
  

• 界面细节：
  
  5、规则与约束
  

4.1.1.2 体检业务周期统计报表（UC_R_TJ_ZCTJ）

• 报表名称：体检业务周期统计报表
• 报表概述：
  – 用户的部门与职位：体检科室主任、分管体检业务的副院长。
  – 用户的业务意图：了解在指定时间周期内，各类体检业务的总量以及分布情况。
  – 相关场景与频率：每天下班、每周末、每月结束都肯定会执行一次，在平时也可能做多次查询。
• 报表内容（What）：

• 输入/输出格式（How）：
  

• 其他：
  – 排序顺序：可按体检项目、申请次数、实际次数升/降序排列。
  – 挑选标准：所有列入统计的都是在指定周期内完成的体检单。
  – 自动运行详细信息：每天晚上19:00、每周六上午8:00、每月末晚上19:00自动生成日报、周报、月报，发送到指定用户邮箱中。
  – 总计级别：按每个类型分类小计，全部再做总计。
  – 换页级别：每页不超过15条，超过部分分页显示。

4.1.1.3 查询团队体检完成情况（UC_I_TJ_QTDTJ）

1、使用者
● 使用者名称：客服管理子系统。
● 业务目的：了解公司客户的所有体检人的体检结果是否已生成，以便及时地取回报告寄给客户；同时当客户了解进度时可以更好地回答。
● 使用时机：公司客户体检完后的1～2天，以及公司客户询问结果是否已出来的时候。
● 使用频率：对于每个公司客户，通常只有1位相关的销售人员会进行查询，次数通常在3～5次左右。

2、内容与格式
● 交互过程：
[插图] 客服管理子系统：通过接口发送“公司客户描述信息”；[插图] 体检业务管理子系统：通过接口应答“该公司客户的体检情况报告”；[插图] 客服管理子系统：通过接口发送 “查询未完成详情指令” --可选；[插图] 体检业务管理子系统：通过接口应答“未完成详情”–可选。
●“公司客户描述信息”：
[插图] 数据格式：<信息标题>+<信息内容>；[插图] 信息标题：用来说明传送的信息是预约单号、公司客户编号还是公司客户名称；[插图] 信息内容：传送具体的值，预约单号（格式参见业务实体“预约单”）或公司客户编号（格式参见业务实体“公司客户”）或公司客户名称（格式参见业务实体“公司客户”）。

3、设计约束
无

4.1.2 领域模型

本子系统所涉及的主要业务实体及它们之间的关系如图19所示。

4.1.2.1 预约单（BO_YYD）

• 类名称：预约单
• 别名：预约信息
• 涉及主题域：[插图] 客服管理子系统：体检者预约事件
• 体检业务管理子系统：体检者申请体检事件
• 数据窗口分析：
  
• 数字组成与格式：
  

4.1.2 .1 体检团队（BO_TJ_TJTD）

4.2 客服管理子系统

4.3 物资管理子系统

5.补充规约