本课推荐《管理软件需求文档 带案例》.docx
《本课推荐《管理软件需求文档 带案例》.docx》由会员分享，可在线阅读，更多相关《本课推荐《管理软件需求文档 带案例》.docx（36页珍藏版）》请在冰点文库上搜索。
本课推荐《管理软件需求文档带案例》
公司名称公司名称公司名称
密级：
宝盒快递系统
需求规格说明书
编写人：
编写日期：
审核人：
审核日期：
批准人：
批准日期：
修订记录
日期
版本
说明
作者
1.
引言
提出对软件需求规格说明书的纵览，帮助读者理解文档如何编写并且如何阅读和解释。
1.1编写目的
对产品（也可能是项目，但是我们统称为产品）进行定义，在该文档中详尽说明这个产品的软件需求，包括修正或发行版本号。
如果这个软件需求规格说明书只与整个系统的一部分有关，那么只定义文档中说明的部分或子系统。
1.2文档约定
描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。
例如，说明高层需求的优先级是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有优先级。
1.3预期的读者和阅读建议
列举软件需求规格说明书所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员等。
描述文档中剩余部分的内容及其组织结构。
提出最适合每一类型读者阅读文档的建议。
1.4产品的范围
提供对指定的软件及其目的的简短描述，包括利益和目标。
把软件与企业目标或业务策略相联系。
可以参考项目范围文档，而不是将其内容复制到这里。
1.5参考资料
列举编写软件需求规格说明书时所参考的资料或其它来源。
可能包括用户界面风格指导、合同、标准、系统需求规格说明书、用户需求、相关产品的软件需求规格说明书。
这里应该给出详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。
1.6术语和缩略语
术语、缩略语
解释
SRS
Software/SystemRequirementsSpecification
2.
综合描述
这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。
2.1产品背景
网购时代，收件成为“最后100米难题”。
而其中，安全问题已经凸显。
2.2
产品功能
本节，只概述产品功能、功能分组等，详细内容在第4节描述。
形式，采用功能树、功能列表用例图、上下文图、高层流程图等。
例如，上下文图，即顶层数据流图，如下：
业务流程图，一般采用“跨职能流程图”画。
下图是总体业务流程图：
功能树，如下：
功能树的优点是广为人知。
其实，用例图比功能树能表达更多信息：
2.3用户类和特征
确定可能使用该产品的不同用户类并描述它们相关的特征。
有一些需求可能只与特定的用户类相关。
将该产品的重要用户类与那些不太重要的用户类区分开。
2.4运行环境
描述软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或者与其共存的应用程序。
2.5设计和实现上的限制
确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。
可能的限制包括：
♦必须使用或者避免的特定技术、工具、编程语言、数据库；
♦经费、进度、资源等方面的限制；
♦所要求的开发规范或标准；
♦企业策略、政府法规或工业标准；
♦硬件限制，例如定时需求或存储器限制；
♦数据转换格式标准。
♦其它。
2.6假设和依赖
列举出在对软件需求规格说明书影响需求陈述的假设因素。
可能包括打算要用的商业组件或有关开发或运行环境的问题。
你可能认为产品将符合一个特殊的用户界面设计约定，但是另外一个分析员却不这么认为。
如果这些假设不正确、不一致或者被更改，都会使项目受到影响。
此外，确定项目对外部因素存在的依赖。
例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖哪个项目能否按时提供正确的组件。
如果这些依赖已经记录到其它文档（如项目计划）中了，那么在此就可以参考其它文档。
2.7用户文档需求
列举出将与软件一同发行的用户文档部分，例如，用户手册、在线帮助和教程。
明确所有已知的用户文档的交付格式或标准。
2.8关键点
说明本软件需求规格说明书中的关键点（例如：
关键功能、关键算法和所涉及的关键技术等）。
3.
外部接口需求
3.1用户界面
陈述所需要的用户界面的软件组件。
描述每个用户界面的逻辑特征。
以下是可能要包括的一些特征：
♦将要采用的图形用户界面标准或产品系列的风格；
♦屏幕布局或解决方案的限制；
♦将出现在每个屏幕的标准按钮、功能或导航链接；
♦快捷键；
♦错误信息显示标准。
对于用户界面的细节，例如特定对话框的布局，建议写入一个独立的用户界面规格说明中，不要写入软件需求规格说明书中。
3.1.1界面转换流程
界面转换图（Web系统中叫页面流pageflow），反应了界面之间的流转逻辑。
第一种设计如下，稍显啰嗦：
第二种设计如下，比较紧凑：
本质上，界面转换图，是一种“状态图”。
但一般，界面转换图，强调界面的层次关系，不常标出“转换条件”。
所以，如果需要，还可以给出更专业的“状态图”。
本宝盒快递系统，可以明确“界面需求”如下：
3.1.2
界面设计
界面原型。
广告页：
界面原型。
取件输入界面：
界面原型。
箱位提醒界面：
3.2
硬件接口
描述系统中软件和硬件每个接口的特征。
可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。
多门控制器的硬件信息：
●32位ARM系列为主处理芯片
●内部运行RTOS实时操作系统
●和FAMS2存储管理系统
多门控制器与快递柜的连接：
多门控制器连接扩展板：
3.3
软件接口
描述产品与其它外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具、库和集成的商业组件。
明确并描述在软件组件之间交换数据或信息的目的，描述所需要的服务以及内部组件通信的性质，确定将在组件之间共享的数据。
如果必须用一种特殊的方法来实现数据共享机制，那么就必须把它定义为一种实现上的限制。
3.4通信接口
描述与产品所使用的通信功能相关的需求，包括电子邮件、WEB浏览器、网络通信标准或协议及电子表格等，定义相关的信息格式、规定通信安全或加密问题、数据传输速率和同步通信机制。
4.
功能需求
4.1功能分类
将功能性需求先粗分再细分，可以用功能结构图、功能树等表示：
或者，以下表格方式也很常用。
和上图的功能树是等价的。
功能类别
功能
快件
存取
子系统
快递员操作
登陆
存件
操作历史查询
收件人操作
取件
集中监控子系统
远程查询状态
心跳监控
异常告警
信息管理子系统
账户管理
操作历史查询
账务管理
重置取件密码
注意，用例图不是“功能分解”思维。
如培训中所讲，用例图是“情境构想思维”，所以建议《需求》同时考虑功能树+用例图：
4.2
收件人操作功能
4.2.1说明和优先级
提出对该系统特性的简短说明并指出该特性的优先级是高、中还是低。
4.2.2
功能：
收件人取件
详细列出与该特性相关的功能需求。
这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的用例执行任务。
描述产品如何响应可预知的出错条件或非法输入或动作。
传统的需求分析，也用操作流程图，如下：
相比操作流程图，如培训所讲，“用例规约=系统行为定义+操作流程定义”：
1.用例名称:
收件人取件
2.简要说明:
收件人在宝盒快递系统的自助快件寄存柜完成快递件的收取
3.事件流:
3.1基本事件流
1）收件人点击系统缺省显示的广告页
2）系统进入取件密码输入界面
3）收件人输入完整、正确的取件密码
4）系统打开相应的箱门，并显示箱位提示界面
5）系统修改快递箱使用状态，将相应的快递箱状态置为“未占用”
6）系统将取件密码失效
7）系统记录取件流水，包括时间、快递单号、快递柜号、快递箱号
8）收件人取出快件，并关闭箱门
9）系统返回缺省的广告页
3.2扩展事件流
3a）如果密码输入错误，
系统停留在密码输入界面，
系统清空密码输入框，并提示“密码输入错误，请重新输入”
3b）如果连续20秒无输入动作，
系统自动返回缺省广告页
8-9a）如果收件人没有关闭箱门
系统在20秒后自动返回缺省的广告页
4.非功能需求:
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
5.前置条件
收件人手机收到短信，提示有新包裹。
短信中说明了“快递柜”的具体地点、以及取件密码。
6.后置条件
密码正确：
则取件成功、密码失效。
密码错误：
则取件失败。
7.扩展点
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
8.优先级
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
4.2.3【培训补充一】正反案例：
基本事件流+前置条件
接下来把“用例规约实践”的问题收集、归类。
事件流，是用例规约用来定义“内外行为步骤”的。
归纳用例规约实践中常犯的错误（基本事件流部分和前置条件部分）：
●内容缺失——只有actor行为，缺少system行为呼应
●格式不对——actor行为和system行为，没有分行写
●前置条件——“前置条件”小节不会写
反面案例
推荐改为
1）收件人点击屏幕进入取件操作界面
2）收件人输入取货密码
3）收件人取件
4）收件人关闭箱门
增加system的“行为描述行”……
理由：
只有actor行为，缺少system行为呼应。
3）用户输入密码
4）用户输入密码无误，系统显示厢位提示界面
5）箱门打开，用户取件
3）收件人输入完整、正确的取件密码
4）系统打开相应的箱门，并显示箱位提示界面
理由：
actor行为、和system行为，必须分行写
3）收件人在快递柜键盘中输入收件短信中提供的完整正确的密码
4）快递柜自动开启
3）收件人输入完整、正确的取件密码
4）系统打开相应的箱门，并显示箱位提示界面
理由：
主语必须是actor或system
“箱门”不应是主语，是“系统”打开箱门
1）收件人查询确定收到取件的手机短信
2）收件人通过手机短信提示选择快递柜号
从“事件流”中删除这两行描述
理由：
事件流中只写系统可感知的actor行为
1）收件人手机收到短信，提示有新包裹。
2）收件人在宝盒系统的界面点击广告页，取件屏幕切换到取件输入界面。
1）收件人点击广告页
2）系统切换到取件输入界面
……
前置条件：
收件人手机收到短信，提示有新包裹。
理由：
“事件流”小结只描述行为
“前置条件”小结可描述业务事件
4.2.4
【培训补充二】正反案例：
扩展事件流
表3-4，归纳了用例规约实践中常犯的错误（扩展事件流部分）：
●内容错位——应在扩展事件流中描述的内容，跑到了基本事件流
●格式不对——影响了其他人的理解
●内容过泛——包含了不应包含的内容
其中“内容过泛”是接触用例技术不久的实践者，非常纠结的问题。
这里，“分析的边界”是问题的关键。
像样例中的“如果密码已输入正确，但柜门仍然无法开启，请电话联系快递柜客服”，就超出了“用例分析的边界”，即超出了“为了实现取件目标，用户与系统所进行的交互序列”这一分析目的。
反面案例
推荐改为
基本事件流：
3）收件人输入短信密码；
4）系统判断输入密码，密码无效则提示“取货密码”无效，有效则进入箱位提取界面
3）收件人输入完整、正确的取件密码
4）系统打开相应的箱门，并显示箱位提示界面
扩展事件流
3a）如果密码输入错误，
系统停留在密码输入界面，
系统清空密码输入框，并提示“密码输入错误，请重新输入”
理由：
主事件流只描述Happypath，
意外情况应放在扩展事件流描述
扩展事件流：
5a）系统判断密码错误
5b）系统提示取货密码无效，让用户重新输入
5c）用户重新录入密码
扩展事件流：
5a）如果输入密码错误
系统提示取货密码无效，让用户重新输入
用户重新录入密码
理由：
描述格式要正确
扩展事件流：
1）收件人在进行取件操作前，必须确认收到手机短信；
2）在输入短信密码后，如果柜门没有打开，请确定密码输入正确，如果密码已输入正确，但柜门仍然无法开启，请联系快递柜客服，客服电话：
*******
3）如果短信丢失，收件人可根据订单号点击重置密码按钮重发收货密码的请求。
从扩展事件流中删除这几行描述
理由：
用例规约中只写系统可感知的actor行为
4.2.5
【培训补充三】用例大忌：
遗漏“隐藏在背后的能力点”
有的开发人员，在用例分析时，流于形式，似乎从基本事件流、到扩展事件流，都分析并定义了，但其实依然遗漏了大量“分析点”。
例如，表3-5所列样例，就是这样：
●【大眼一看】用户与系统的交互序列，是完整的。
●【但实际上】程序员依据这样的用例规约开发时，依然对“柜门如何控制”、“记录哪些信息”等需求心存困惑。
●【或许更糟】程序员毫无反应地“照单编程”，那后续必然就是“遗漏需求报Bug需求变更”的节奏了。
表3-5样例点评与改进（系统处理）
反面案例
推荐改为
基本事件流
1）收件人点击系统的广告界面
2）系统进入取件密码输入界面
3）收件人在输入界面输入取件密码点击确认
4）系统显示与取件密码匹配的箱位提示界面
5）收件人取件，并关闭箱门
6）系统返回显示广告页面
在4后增加：
5）系统修改快递箱使用状态，将相应的快递箱状态置为“未占用”
6）系统记录取件流水，包括时间、快递单号、快递柜号、快递箱号
理由：
用例规约中，最容易漏的就是“隐藏在背后的那些系统能力点”，例如信息的保存、状态的变化
所以，不能遗漏“隐藏在背后的那些系统能力点”。
特别是：
●领域相关的关键逻辑需求
——例如，“系统修改快递箱使用状态，将相应的快递箱状态置为‘未占用’态”。
●业务相关的数据记录需求
——例如，“系统记录取件流水，包括时间、快递单号、快递柜号、快递箱号”。
4.2.6
【培训补充四】用例大忌：
缺乏“定量描述”
另一类让程序员无所适从的错误，是缺乏“定量描述”。
这类问题后续的节奏也必然是“需求不明报Bug需求变更”。
例如，表3-6所列样例，就是这样：
●【大眼一看】像“如果收件人输入密码超时”这样的需求定义很多见、很正常嘛。
●【但实际上】程序员无法依据这样的用例规约编程。
超时的程序逻辑怎么写？
●【改过之后】在两方面，约束和指导了编程。
一是监控“连续无输入动作”时间，二是“定量为20秒”。
明确、无歧义。
本例和上例，其实都透漏了一个真相：
我们的很多软件需求变更，其实不是需求“变”了，根本就是“没分析清楚”。
呼呼！
表3-6样例点评与改进（系统处理）
反面案例
推荐改为
扩展事件流：
3b）如果收件人输入密码超时，系统转入广告页面
扩展事件流：
3b）如果连续20秒无输入动作，
系统自动返回缺省广告页
理由：
“超时”模糊、不明确，应“量化”
4.3
快递员操作功能
4.3.1说明和优先级
提出对该系统特性的简短说明并指出该特性的优先级是高、中还是低。
4.3.2功能：
快递员登陆
详细列出与该特性相关的功能需求。
这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的用例执行任务。
描述产品如何响应可预知的出错条件或非法输入或动作。
1.用例名称:
。
。
。
。
。
。
。
。
。
。
。
。
。
2.简要说明:
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
3.事件流:
3.1基本事件流
1）。
。
。
。
。
。
。
。
。
。
。
。
。
2）。
。
。
。
。
。
。
。
。
。
。
。
。
。
3）。
。
。
。
。
。
。
。
。
。
。
。
。
。
3.2扩展事件流
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
4.非功能需求:
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
5.前置条件
。
。
。
。
。
。
。
。
。
。
。
。
。
6.后置条件
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
7.扩展点
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
8.优先级
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
4.3.3功能：
操作历史查询
1.用例名称:
。
。
。
。
。
。
。
。
。
。
。
。
。
2.简要说明:
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
3.事件流:
3.1基本事件流
1）。
。
。
。
。
。
。
。
。
。
。
。
。
2）。
。
。
。
。
。
。
。
。
。
。
。
。
。
3）。
。
。
。
。
。
。
。
。
。
。
。
。
。
3.2扩展事件流
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
4.非功能需求:
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
5.前置条件
。
。
。
。
。
。
。
。
。
。
。
。
。
6.后置条件
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
7.扩展点
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
8.优先级
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
4.3.4功能：
快递员存件
传统的需求分析，也用操作流程图，如下：
相比操作流程图，如培训所讲，“用例规约=系统行为定义+操作流程定义”：
1.用例名称:
。
。
。
。
。
。
。
。
。
。
。
。
。
2.简要说明:
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
3.事件流:
3.1基本事件流
1）。
。
。
。
。
。
。
。
。
。
。
。
。
2）。
。
。
。
。
。
。
。
。
。
。
。
。
。
3）。
。
。
。
。
。
。
。
。
。
。
。
。
。
3.2扩展事件流
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
4.非功能需求:
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
5.前置条件
。
。
。
。
。
。
。
。
。
。
。
。
。
6.后置条件
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
7.扩展点
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
8.优先级
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
4.4
集中监控功能
4.4.1说明和优先级
提出对该系统特性的简短说明并指出该特性的优先级是高、中还是低。
4.4.2功能：
远程状态查询
详细列出与该特性相关的功能需求。
这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的用例执行任务。
描述产品如何响应可预知的出错条件或非法输入或动作。
4.4.3功能：
心跳监控
详细列出与该特性相关的功能需求。
这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的用例执行任务。
描述产品如何响应可预知的出错条件或非法输入或动作。
4.4.4功能：
异常告警
详细列出与该特性相关的功能需求。
这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的用例执行任务。
描述产品如何响应可预知的出错条件或非法输入或动作。
4.5信息管理功能
4.5.1说明和优先级
提出对该系统特性的简短说明并指出该特性的优先级是高、中还是低。
4.5.2功能需求
详细列出与该特性相关的功能需求。
这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的用例执行任务。
描述产品如何响应可预知的出错条件或非法输入或动作。
4.5.2.1功能functionA.1
（1）说明
本功能的简要说明
（2）角色
本功能的执行人员
（3）前置条件
该功能启动的前提条件
（4）输入
描述本功能的输入信息（包括需要访问的存储信息）。
（5）过程
对本功能将做什么进行详细的描述。
（6）输出
描述本功能的输出信息（包括需要访问的存储信息）。
（7）后置条件
该功能结束的退出条件
（8）业务规则
列举出与该功能相关的操作规则。
例如什么人在特定环境下可以进行何种操作。
4.5.2.2functionA.1图书借阅
（1）说明
借阅人通过此功能向系统查询并提交借书请求
（2）角色
借阅人
（3）前置条件
♦借阅人借阅证件在有效期内
♦借阅人没有逾期未归还的图书
（4）输入
借阅证
（5）过程
主过程描述
1用户用借阅证提供的帐号登录系统，系统显示我的图书馆界面
2.用户选择查询图书，系统显示查询界面
3.用户按书名、作者、出版社查询，系统显示查询结果
4.用户可单选或多选书本，并确认借阅。
系统显示确认借阅图书清单。
5.用户选择确认借阅，系统显示借阅定单及费用
6用户选择提交定单，系统显示提交结果和定单号
7.系统执行后置条件
分支过程描述
2.1.1用户选择查看原有定单，系统执行4;
4.1.1用户可单选或多选书本，放入借书篮，系统显示借书篮现有内容
4.1.2.1.1用户选择继续借书，系统执行2；
4.1.2.2.1用户选择提交借书篮，系统执行4
4.2.1用户选择放弃，系统执行2；
6.1.1用户选择保存定单，系统保存并执行1；
6.2.1用户选择放弃，系统执行1；
异常过程描述
1.1.1借阅证已过期，拒绝登录，结束
1.2.1借阅人有逾期未归还书本，启动“归还图书”功能
5.1.1用户余额不足，系统显示余额和所需金额
5.1.2.1.1用户选择续费，启动“交纳借阅费”功能
5.1.2.2.1用户选择放弃，系统执行1
（6）输出
费用记录
借阅定单
（7）后置条件
♦创建借书定单
♦更新借阅人借阅记录
（8）业务规则
每次每人至少选择一本,至多选择三本
5.
非功能需求
5.1性能需求
阐述不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员做出合理的设计选择。
确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系；还要定义容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。
也可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们集中在一起陈述。
例如：
“在运行WINDOWS2000的450MHZPentiumII的计算机上，当系统至少有50%的空闲资源时，95%的目录数据库查询必须在两秒内完成”。
5.2安全性需求
陈述与系统安全性、完整性或私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。
明确产品必须满足的安全性或保密性策略。
一个软件系统的安全需求的范例如下：
“每个用户在第一次登录之后，必须更改他的最初登录密码。
最初的登录密码不能重用。
”
5.3软件质量属性
详尽陈述与客户或开发人员至关重要的质量特性。
这些特性必须是确定、定量的并可验证的。
至少应指明不同属性的相对侧重点，例如易用程度优于易学程度，或者可移植性优于有效性。
5.4其它需求
定义至今未出现的需求。
例如国际化需求、法律上
升级会员 