|
这里分享一下我之前一直使用的SRS的文档模板，根据我的经验，按照这个文档模板来做软件需求分析，可以提高软件需求分析的质量。 模板中有一些要点和例子直接来自网上，时间很久了，来源已不可考。 文档模板中的斜体字为示例。
章节1、概述 概述提出了对软件需求说明的纵览，这有助于读者理解文档如何编写、如何阅读。如： 本章说明XXX产品的软件需求规格书（简称SRS，下同）的编写目的、编写约定、预期读者和参考文献。
章节1.1、编写目的 指出这个软件需求规格书预期的目的。如： 编写本SRS，以期达到下列目的：
章节1.2、文档约定 描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。例如，说明了高层需求的优先级是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自身的优先级。
章节1.2.1、通用规则 1.编号及应用规则
2.在正式开发之前， TBD（to be determined）项均应该消除。 3.需求描述建议：
4.其它约定：
章节1.2.2、编号规则 章节1.2.2.1、ID编号规则 ID =需求类型 + 4位编号 需求类型： 功能需求 SF（Software Function） 性能需求 SP（Software Performance） 非功能需求 NF（None-Function） 外部接口: 用户界面 UI（User Interface） 硬件接口 HI（Hardware Interface） 软件接口 SI（Software Interface） 通信接口 CI（Communication Interface） 质量属性 QA（Quality Attribute） 业务规则 BR（Business Rule） 用户文档要求 UD（User Document） 其它需求 OR（Other Requirement） 4位编号：由四位字符组成，每个字符可以为0~9，A-Z，无次序要求，但上下文是唯一的。 注：如果为大产品，需求项很多，可使用5位编号。
章节1.2.2.2、需求过程描述项编号规则 Number = 描述分类 + 4位编号 描述分类： 前置条件 C 后置条件 R 正常过程 N 异常过程 E 可选过程 A 4位编号：从0XXY开始。XX从01开始，Y从0开始，开始时Y以零编号，修改时，可从中间插入。采用4位数字编号。
章节1.2.2.3、需求过程描述项编号规则 REF =产品（项目）编号 + “.” + 需求规格书类型 + “.” + 最高级ID + “.” + 次级ID + “.” + … + 最低级ID 产品（项目）编号：产品的编号（如只有项目，就用项目编号），如P001等。 需求规格书类型 用户需求 URS 产品需求 PRS 软件需求 SRS 子系统需求 SSRS 模块需求 MRS
如：P001.SRS.SF0001.A0001.B0002.N0010表示P001产品的软件需求规格书的SF0001需求项的A0001子项的B0002子项的N0010项。
章节1.3、预期读者和阅读建议 列举了软件需求规格书所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。如：
预期的读者和阅读建议参见表1.1。 表1.1
章节1.4、术语和定义 术语（Terms）可以理解为数据字典的数据项（词条），将本文引用的部分罗列出来。如：
术语和定义参见表1.2。 表1.2
章节1.5、缩略语 缩略语（Abbreviations）为专业词汇或自定义词汇的缩写（一般是英文缩写）。如：
缩略语参见表1.3。 表1.3
章节1.6、参考文献 列举了编写软件需求规格书时所参考的资料或其它资源。这可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或产品需求规格书。如有可能，给出详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。
章节2、综合描述 这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。
章节2.1、产品背景 描述了软件需求规格书中所定义的产品的背景和起源。说明了该产品是否是产品系列中的下一成员，是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个新型的、自含型产品。如果软件需求规格说明定义了大系统的一个组成部分，那么就要说明这部分软件是怎样与整个系统相关联的，并且要定义出两者之间的接口。
章节2.2、产品的范围 给出系统边界图和描述。
章节2.3、产品总体功能 概述了产品所具有的主要功能。其详细内容将在第3~6章中描述，所以在此只需要概略地总结，例如用列表的方法给出。很好地组织产品的功能，使每个读者都易于理解。用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图，都是有用的。
章节2.4、用户类型和特征 确定你觉得可能使用该产品的不同用户类型并描述它们相关的特征。有一些需求可能只与特定的用户类型相关。将该产品的重要用户类型与那些不太重要的用户类型区分开。
章节2.5、运行环境 描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。
章节2.6、设计和实现上的限制 确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。可能的限制包括如下内容：
章节2.7、假设和依赖 列举出在对软件需求规格书中影响需求陈述的假设因素(与已知因素相对立)。 这可能包括你打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定，但是另一个SRS读者却可能不这样认为。如果这些假设不正确、不一致或被更改，就会使项目受到影响。 此外，确定项目对外部因素存在的依赖。例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其它文档(例如项目计划)中了，那么在此就可以参考其它文档。
章节3、功能需求 详列出与该特性相关的详细功能需求。这些是必须提交给用户的软件功能，使用户可以用所提供的特性执行服务或者使用所指定的“使用实例”（Use Case）执行任务。描述产品如何响应可预知的出错条件、非法输入或动作，你必须唯一地标识每个需求。
章节3.1、SF0100 功能需求1 需求描述： 优先级： 参与者/角色（用户）： 前置条件： 后置条件： 正常过程： 可选过程： 异常过程： 非功能需求： 注：功能需求的描述，使用Use Case方式，后面将给出一个书写示例。
章节3.2、SF0105 功能需求2 需求描述： 优先级： 参与者/角色（用户）： 前置条件： 后置条件： 正常过程： 可选过程： 异常过程： 非功能需求：
章节4、其它非功能需求 这部分列举出了所有非功能需求，外部接口需求和限制不在此处描述。
章节4.1、性能需求 阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。 确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系。 你还可以在这里定义容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。 尽可能详细地确定性能的需求。可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们都集中在一起陈述。
章节4.2、质量属性 下列质量属性中，选择你需要描述的部分，加以说明，或者加上你认为需要的其它质量属性。
章节4.2.1、有效性 有效性指的是在预定的启动时间中，系统真正可用并且完全运行时间所占的百分比。更正式地说，有效性等于系统的平均故障时间(MTTF)除以平均故障时间与故障修复时间之和。有些任务比起其它任务具有更严格的时间要求，此时，当用户要执行一个任务但系统在那一时刻不可用时，用户会感到很沮丧。询问用户需要多高的有效性，并且是否在任何时间，对满足业务或安全目标有效性都是必须的。如： 一个有效性需求可能这样说明：“工作日期间，在当地时间早上6点到午夜，系统的有效性至少达到99.5％，在下午4点到6点，系统的有效性至少可达到99.95％。”
章节4.2.2、效率 效率是用来衡量系统如何优化处理器、磁盘空间或通信带宽。 如果系统用完了所有可用的资源，那么用户遇到的将是性能的下降，这是效率降低的一个表现。拙劣的系统性能可激怒等待数据库查询结果的用户，或者可能对系统安全性造成威胁，就像一个实时处理系统超负荷一样。如： 为了在不可预料的条件下允许安全缓冲，你可以这样定义：“在预计的高峰负载条件下，10％处理器能力和15％系统可用内存必须留出备用。” 在定义性能、能力和效率目标时，考虑硬件的最小配置是很重要的。
章节4.2.3、灵活性 就像我们所知道的可扩充性、增加性、可延伸性和可扩展性一样，灵活性表明了在产品中增加新功能时所需工作量的大小。如果开发者预料到系统的扩展性，那么他们可以选择合适的方法来最大限度地增大系统的灵活性。灵活性对于通过一系列连续的发行版本，并采用渐增型和重复型方式开发的产品是很重要的。 灵活性目标可如下设定：“一个至少具有6个月产品支持经验的软件维护程序员可以在一个小时之内为系统添加一个新的可支持硬拷贝的输出设备。”
章节4.2.4、安全性 安全性(或完整性)主要涉及：防止非法访问系统功能、防止数据丢失、防止病毒入侵并防止私人数据进入系统。 安全性对于通过WWW执行的软件已成为一个重要的议题。电子商务系统的用户关心的是保护信用卡信息，Web的浏览者不愿意那些私人信息或他们所访问过的站点记录被非法使用。安全性的需求不能犯任何错误，即数据和访问必须通过特定的方法完全保护起来。用明确的术语陈述安全性的需求，如身份验证、用户特权级别、访问约束或者需要保护的精确数据。 一个安全性的需求样本可以这样描述：“只有拥有查账员访问特权的用户才可以查看客户交易历史。”
章节4.2.5、互操作性 互操作性表明了产品与其它系统交换数据和服务的难易程度。为了评估互操作性是否达到要求的程度，你必须知道用户使用其它哪一种应用程序与你的产品相连接，还要知道他们要交换什么数据。 “XX系统”的用户习惯于使用Office excel表格工具，所以他们提出如下的互操作性需求：“XX系统应该能够导入和导出excel格式的数据。”
章节4.2.6、可靠性 可靠性是软件无故障执行一段时间的概率，健壮性和有效性有时可看成是可靠性的一部分。 衡量软件可靠性的方法包括正确执行操作所占的比例，在发现新缺陷之前系统运行的时间长度和缺陷出现的密度。根据如果发生故障对系统有多大影响和对于最大的可靠性的费用是否合理，来定量地确定可靠性需求。 如果软件满足了它的可靠性需求，那么即使该软件还存在缺陷，也可认为达到其可靠性目标。要求高可靠性的系统也是为高可测试性系统设计的。 如某些设备全天工作并且使用稀有的、昂贵的化学制品。用户要求真正与实验相关的那部分软件要高可靠性，而其它系统功能，例如周期性地记录温度数据，则对可靠性要求不高。对于该系统的一个可靠性需求说明如下：“由于软件失效引起实验失败的概率应不超过千分之5”。
章节4.2.7、健壮性 健壮性指的是当系统或其组成部分遇到非法输入数据、相关软件或硬件组成部分的缺陷或异常的操作情况时，能继续正确运行功能的程度。健壮的软件可以从发生问题的环境中完好地恢复并且可容忍用户的错误。当从用户那里获取健壮性的目标时，询问系统可能遇到的错误条件并且要了解用户想让系统如何响应。 一个健壮性需求是这样说明的：“所有的规划参数都要指定一个缺省值，当输入数据丢失或无效时，就使用缺省值数据。”
章节4.2.8、易用性 它所描述的是组成“用户友好”的主要因素。易用性衡量准备输入、操作和理解产品输出所花费的努力。 “化学制品跟踪系统”的分析员询问用户这样的问题：“你能快速、简单地请求化学制品并浏览其它信息，这对你有多重要?”和“你请求一种化学制品大概需花多少时间?”对于定义使软件易于使用的许多特性而言，这只是一个简单的起点。对于易用性的讨论可以得出可测量的目标，例如“一个培训过的用户应该可以在平均3分钟或最多5分钟时间以内，完成从供应商目录表中请求一种化学制品的操作。” 同样，调查新系统是否一定要与任何用户界面标准或常规的相符合，或者其用户界面是否一定要与其它常用系统的用户界面相一致。这里有一个易用性需求的例子： “在文件菜单中的所有功能都必须定义快捷键，该快捷键是由Ctrl键和其它键组合实现的。出现在Microsoft Word2000中的菜单命令必须与Word使用相同的快捷键”。 易用性还包括对于新用户或不常使用产品的用户在学习使用产品时的简易程度。易学程度的目标可以经常定量地测量，例如， “一个新用户用不到30分钟时间适应环境后，就应该可以对一个化学制品提出请求”，或者“新的操作员在一天的培训学习之后，就应该可以正确执行他们所要求的任务的95％”。 当你定义易用性或可学性的需求时，应考虑到在判断产品是否达到需求而对产品进行测试的费用。
章节4.2.9、可维护性 可维护性表明了在软件中纠正一个缺陷或做一次更改的简易程度。可维护性取决于理解软件、更改软件和测试软件的简易程度，可维护性与灵活性密切相关。高可维护性对于那些经历周期性更改的产品或快速开发的产品很重要。你可以根据修复(fix)一个问题所花的平均时间和修复正确的百分比来衡量可维护性。 ”在图形引擎工程中，我们知道，我们必须不断更新软件以满足用户日益发展的需要，因此，我们确定了设计标准以增强系统总的可维护性：“函数调用不能超过两层深度”，并且“每一个软件模块中，注释与源代码语句的比例至少为1：20”认真并精确地描述设计目标，以防止开发者做出与预定目标不相符的愚蠢行为。
章节4.2.10、可移植性 可移植性是度量把一个软件从一种运行环境转移到另一种运行环境中所花费的工作量。软件可移植的设计方法与软件可重用的设计方法相似。可移植性对于工程的成功是不重要的，对工程的结果也无关紧要。可以移植的目标必须陈述产品中可以移植到其它环境的那一部分，并确定相应的目标环境。于是，开发者就能选择设计和编码方法以适当提高产品的可移植性。
章节4.2.11、可重用性 从软件开发的长远目标上看，可重用性表明了一个软件组件除了在最初开发的系统中使用之外，还可以在其它应用程序中使用的程度。比起创建一个你打算只在一个应用程序中使用的组件，开发可重用软件的费用会更大些。 可重用软件必须标准化、资料齐全、不依赖于特定的应用程序和运行环境，并具有一般性。确定新系统中哪些元素需要用方便于代码重用的方法设计，或者规定作为项目副产品的可重用性组件库。
章节4.2.12、可测试性 可测试性指的是测试软件组件或集成产品时查找缺陷的简易程度。如果产品中包含复杂的算法和逻辑，或如果具有复杂的功能性的相互关系，那么对于可测试性的设计就很重要。如果经常更改产品，那么可测试性也是很重要的，因为将经常对产品进行回归测试来判断更改是否破坏了现有的功能性。
章节4.3、安全设施需求 详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防潜在危险的动作。明确产品必须遵从的安全标准、策略或规则。 一个安全设施需求的范例如下：“如果并发请求数的超过了规定的最大值的90％，那么必须在1秒钟内进行限流处理”
章节4.4、业务规则 列举出有关产品的所有操作规则，例如什么人在特定环境下可以进行何种操作。这些本身不是功能需求，但它们可以是某些功能需求需考虑的业务规则。 一个业务规则的范例如下：“只有持有管理员密码的用户才能执行$100.00或更大额的退款操作。”
章节4.5、用户文档需求 列举出将与软件一同发行的用户文档，例如，用户手册、在线帮助和教程。明确所有已知的用户文档的交付格式或标准。
章节5、外部接口需求 利用本章来确定可以保证新产品与外部组件正确连接的需求。关联图表示了高层抽象的外部接口。需要把对接口数据和控制组件的详细描述写入数据字典中。如果产品的不同部分有不同的外部接口，那么应把这些外部接口的详细需求并入到这一部分的实例中。
章节5.1、用户界面 陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。 现在有UI&UE设计，故可以直接写： 参见XXX UI&UE交互设计。
章节5.2、硬件接口 描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。
章节5.3、软件接口 描述该产品与其它外部组件(由名字和版本识别)的连接，包括数据库、操作系统、工具、库和集成的商业组件。 明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服务以及内部组件通信的性质。确定将在组件之间共享的数据。如果必须用一种特殊的方法来实现数据共享机制，例如在多任务操作系统中的一个全局数据区，那么就必须把它定义为一种实现上的限制。
章节5.4、通信接口 描述与产品所使用的通信功能相关的需求，包括电子邮件、Web浏览器、网络通信标准或协议及电子表格等等。定义了相关的消息格式。规定通信安全或加密问题、数据传输速率和同步通信机制。
章节6、其它需求
|
|
|
