软件需求分析说明书审查规范.doc

软件需求分析说明书审查规范

软件需求分析说明书审查规范

文件编号

受控编号

版本
1.0
编制日期

生效日期

密级

编制

审核

批准

文件修改控制
修改记录编号
修改
状态
修改位置及内容
修改人
审核人
批准人
修改日期
1.

2.

3.

4.

5.

6.

7.

8.

目录

软件需求分析说明书审查规范 1
目录 3
1. 引言 3
1.1. 目的 3
1.2. 适用范围 3
1.3. 使用说明 4
2. 参考资料 4
3. 术语定义 4
4. 质量要求 6
4.1. 完整性 6
4.1.1. 整体内容完整性 6
4.1.2. 需求项信息完整性 8
4.2. 正确性 9
4.3. 一致性 10
4.4. 可验证性 10
4.5. 划分优先级 10
4.6. 可用性 11
5. 附件 11
5.1. 一些编写建议 11
5.2. 部分参考实例 12
5.2.1. 需求项表格 12
5.2.2. 表格需求项实例 13
5.2.3. 优先级划分方法实例 14
5.2.4. 软件需求分析说明书模板 15
1. 引言
1.1. 目的
软件需求分析说明书在软件开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。为了保证软件说明书对质量，本文档具体描述了《软件需求分析说明书》所要包含的内容及其编制所要达到的质量要求。
1.2. 适用范围
作为《软件需求分析说明书》是否能够进入正式评审的审查标准，符合该规范的能够提交正式需求评审；
作为测试人员编制《软件需求分析说明书审查列表》的依据；
作为开发人员编制《软件需求分析说明书》的指导原则；
1.3. 使用说明
本文重点对需求分析说明书的内容进行要求，对表示方式、方法未明确提出要求对视为不作要求；
本文中的“应”、“必须”含义等同；
本文中的“现有的技术水平”指与该需求相关的行业中，可获得的、已知的、可实际运用于生产的、可信的、经过验证的所有技术；
本文中的需求可行性以经过审核发布的《项目可行性研究报告》为依据；
2. 参考资料
GB 8566 计算机软件开发规范 受控编号？
GB 8567 计算机软件产品开发文件编制指南 受控编号？
GB/T 11457 软件工程术语 受控编号？
Systematic Software Testing Rick D.Craig, Stefan P.Jaskiel　Artech House Publishers -05-1
统一软件开发过程RUP 手册 IBM公司

3. 术语定义
GB/T 11457所列术语和下列定义适用于本文

需求
系统必须符合的条件或具备的功能

软件需求分析
软件需求分析的基本任务是准确地定义未来系统的目标，确定为了满足用户的需求，系统必须做什么。需求分析包括需求获取和需求规约：需求获取是系统分析员经过学习以及同用户的交往，熟悉用户领域的知识，并获得对未来系统的需求；需求规约是系统分析员在获得了用户的初步需求后，必须进行一致性分析和检查，经过和用户协商解决其中存在的二义性和不一致性，并以一种规范的形式准确地表示用户的需求，形成软件需求分析说明书。

软件需求分析说明书（Software Requirements Specifications，简称SRS）：
软件需求分析说明书（也称软件需求规格说明书、软件需求分析报告）是软件需求分析阶段得到的最终文档，它以形式化的术语和表示对软件的功能和性能进行详细而具体的描述。它是用户和开发者之间的技术合同，是软件设计、编码阶段的基础,也是软件测试和验收的依据。
IEEE软件工程标准词汇表(1997年)中定义为：
(1) 用户解决问题或达到目标所需的条件或权能(Capability)。
(2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3) 一种反映上面(1)或(2)所描述的条件或权能的文档说明。

软件质量
IEEE 610.12-1990中定义：
一个系统、组件或过程满足客户或用户的需求的程度，或满足期望值的程度。（“The degree to which a system, component, or process meets customer or user needs or expectations.”
ISO/IEC9126中定义：
与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体。（The totality of features and characteristics of a software product that bear on its ability to satisfy stated or implied needs.）

软件质量保证
软件质量保证，是为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。软件质量保证是面向消费者的活动，是为了使产品实现用户要求的功能，站在用户立场上来掌握产品质量的。软件的质量保证就是向用户及社会提供满意的高质量的软件产品。

可跟踪性
指如果每一个需求的来源、变更历史是清晰的，在进一步产生和改变文件编制时，能够方便地引证每一个需求，则该软件需求分析说明书就是可追踪的。

可修改性
指如果一个软件需求分析说明书的结构和风格在需求有必要改变时是易于实现的、且改变后依然完整、一致的，那么这个软件需求分析说明书就是可修改的。

可行性
指在规定的时间限制和开销下、在特定的环境制约下、利用现有的技术、工具、资源和人力下，需求必须是能够实现的。具体包括：
技术可行，现有的技术水平能够实现所有的需求；
财政可行，有足够的资金来实现所有的需求，且实现的成本在可接受的范围内；
时间可行，在指定的时间范围内能够实现所有的需求；
资源可行，有足够的人力、物力来实现所有的需求；

验证标准
用以判断需求被实现后，实现的结果是否正确的依据。如：对于性能需求，其验证标准是具体的性能指标；对于功能需求，其验证标准是详细的功能效果描述。

软件测试
软件测试是为了度量和提高被测软件的质量，对测试件进行工程设计、实施和维护的整个生命周期过程。(《Systematic Software Testing》)

统一建模语言（UML）
UML(Unified Modeling Language)是一种构建软件系统和文档的通用可视化建模语言。UML 能与所有的开发方法一同使用，可用于软件开发的整个生命周期。UML 能表示系统的静态结构和动态信息，并能管理复杂的系统模型，便于软件团队之间的合作开发。UML 不是编程语言，但支持UML 语言的工具能够提供从UML 到各种编程语言的代码生成，也能够提供从现有程序逆向构建UML 模型。

统一软件开发过程（RUP）
RUP 是一个通用软件过程框架，能够应付种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。“统一过程”是基于构件的，这意味着利用它开发的软件系统是由构件构成的，构件之间经过定义良好的接口相互联系。在准备软件系统的所有蓝图的时候，“统一过程”使用的是“统一建模语言（Unified Modeling Language ）”。事实上，UML 是“统一过程”的有机组成部分——它们是被同步开发的。然而，真正使“统一过程”与众不同的方面能够用三个句话来表示：它是用例驱动的、以基本架构为中心的、迭代式和增量性的。

4. 质量要求
合格的软件需求分析说明书要满足如下质量要求：
1. 完整性
2. 正确性
3. 一致性
4. 可验证性
5. 划分优先级
6. 可用性
下面我们分别对每个质量要求进行说明，同时给出如何满足各质量要求的指导原则。
4.1. 完整性
完整性是指软件需求分析说明书包含了所有应该具备的内容，由于不同的产品、项目对软件需求分析说明书所应该具备的内容的不完全相同，因此为了便于指导和规范文档的实际编制本规范将完整性划分为整体内容完整性、需求项信息完整性，并针对不同的内容提出不同的要求，包括：必须和可选，具体如下：
4.1.1. 整体内容完整性
整体内容完整性用以确定整个软件需求分析说明书中具体应该包含的内容和不应该包含的内容，具体如下：
一. 需求没有遗漏：确定在需求分析说明书编制的过程中，没有遗漏需求获取阶段所确定的需求。其依据为包括但不但限于经过正式审核的下列文档：
1. 市场调研报告；
2. 用户需求调查报告；
3. 需求分析讨论会议记录；
二. 需求没有冗余：即同一需求不能在软件需求分析说明书中出现多次；
三. 不存在超出产品/项目范围的需求；
四. 除设计上的特殊限制之外，软件需求分析说明书中不描述任何设计、验证或项目管理细节的内容；
五. 软件需求分析说明书必须包含下列信息：
1. 目的：说明编写这份软件需求说明书的目的，指出预期的读者
2. 概述：说明产品或项目的背景、总体描述、功能、用户特点、一般的设计约束。只描述影响产品及其需求的一般因素，不说明具体的需求，概述的目的仅近使需求更易于理解
3. 参考资料：列出软件需求分析说明书中所有用得到的所有参考资料，详细说明参考资料的来源。
内容包括但不但限于：
1) 本产品或项目的经过核准的计划任务书或合同、上级机关的批文；
2) 本项目的其它已经过审核的正式文档；
3) 企业内部制定发布的正式管理文件；
4) 各处引用的资料，如出版物、网络资讯；
5) 所要用到的软件开发标准。
且每条参考资料记录中包含的内容及格式应满足下列要求（按类型划分）：
1) 专著出版物：主要作者，其它作者，书名，版本，出版地：出版者，出版年；
2) 连续期刊出版物：文献作者，文献其它作者，题名，刊物名，版本：在原文献中的位置；
3) 标准：标准编，号标准名，公司受控编号；
4) 文件：文件编号，文件名，文件版本
5) 网络资讯：作者，题名，发布网址，发布时间
4. 术语定义：提供软件需求分析说明书中用到的专门术语、缩写词、缩略语的定义，这部分信息能够在软件需求分析说明书中用一个单独章节提供或者在附录中提供，也能够参考其它的文件；
5. 具体需求：指产品或项目必须符合的条件或具备的功能，它包括软件开发者在建立设计时需要的全部细节。由于不同的产品项目其需求都不同，同样的需求能够使用不同的分类方法进行划分，因此这里只列举一种比较常见的划分方式，并分别加以说明：
1) 功能需求：规定了在不考虑物理约束的情况下必须能够执行的动作，也就是一般所说的系统能够做什么；
2) 性能需求：是指软件功能在执行过程中需要满足的强加条件，如速度、效率、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率、资源用途等等
3) 属性需求：可扩展性、可移植性、稳定性、可靠性、可维护性、 兼容性、 安全性、可配置性、 可服务性、 可安装性，可国际化性、可用性、易用性等方面的考虑因素；
4) 外部接口：用户、硬件、其它软件和其它硬件的相互关系，如用户接口、软件接口、硬件接口、通信接口等；
5) 强加的设计限制或实现约束：说明必须遵守的技术标准和软硬件限制等设计约束，如对硬件配置的要求，对软件开发环境限制、运行环境限制和对软件设计、实现方式的限制；
六. 包含第五条中未列出但应该在需求分析说明书中说明的其它信息；
七. 对第五条第5项具体需求所列出的几类需求的要求：除功能需求总是必须的，其它需求根据产品/项目的实际情况进行增删裁减。
4.1.2. 需求项信息完整性
需求项信息完整性指每个具体需求的需求项需包含足够的信息，来详细明确定义需求要实现的目标。
一. 针对每个需求项，必须包含下列信息：
1. 唯一标识：跟踪需求的标签，唯一且不变，建议采用“项目编号+内部编号”方式，使需求编号在整个公司的范围内都是唯一点；
2. 简要描述：简单描述该需求要实现的目标；
3. 类型：需求的类型，依所采用的需求分类方法而定；
4. 目的：简要描述提出该需求的目的，若很明显则写“略”；
5. 来源：谁提出该需求，具体能够是人(客户、用户、员工)、公司、市场等；
6. 详细描述：对该需求的详细说明；由于不同类型的需求其详细描述需要包含的内容不同，下面分类列出具体应该包含的详细内容：
A. 功能性需求：
应包括但不但限于下列内容：
1) 环境要求：完成该功能应该满足的具体条件，如什么状态、情况、什么样的软硬件环境下能够进行该功能；
2) 触发者：使该功能的执行的人或事，能够是用户或是其它系统、定时事件等；
3) 输入：描述该功能执行前及在执行过程中所有输入的详细定义。例如：
数据类型输入的数据类型、数量、度量单位、源、时间关系、要求（如精度）；
功能执行过程中的用户操作控制信息；
事件类型输入的事件时间设定；
所引用的用以统一定义输入的有关接口说明或接口控制文件。
4) 处理：该功能所完成的任务，即从输入到输出的变换操作过程。具体应包括但不但限于下列内容：
对所有输入的有效性检查；
对所有输入的处理顺序、流程或方法，即系统如何把输入变换成相应输出，能够使用自然语言、方程式、数学算法、逻辑操作、图、表、状态机等不同表示方式进行描述；
对所有输出有效性的检查；
对所有异常情况的处理及响应，例如，溢出、通信故障、要所有非合法输入的响应、错误处理等；
5) 输出：描述该功能所有最终预期结果的详细定义。如：
数据类型输出的数据类型、数量、目的地、度量单位、时间关系、要求（如精度）；
所引用的用以统一定义输出的有关接口说明或接口控制文件。

B. 非功能性需求：
性能需求：
达到该性能需求必须具备的条件或限制；
该性能需求所要达到的具体性能指标
属性需求：
可移植性：具体列出要求能够移植的平台；
可维护性：具体列出保证可维护性的具体的方法；
安全性：具体列出要达到的安全级别或安全程度；
兼容性：具体列出所要兼容的平台或软硬件环境；
可测试性：具体列出保证该特性的具体功能和方法；
可靠性：具体列出可靠性的要求，如无故障运行时间；
设计限制：
列出所有的限制因素，如：
需遵守的技术标准: 列出所有必须遵守的技术标准、规范（包含标准名、标准编号、版本号（或发布日期）、公司受控编号信息）
硬件限制：列出所有影响或约束产品/项目的硬件成分，如运行环境最低配置；
软件限制：列出所有影响或约束产品/项目的软件成分，如软件开发环境限制、软件运行环境限制和软件的设计限制；

7. 验证标准：用于该需求被实现后，检查实现结果是否符合需求，给测试或用户提供明确的验证依据。如：对于性能需求，列出具体的性能指标；对于功能需求，给出详细的实现效果；若验证标准已包含在详细描述中，则指明位置即可；
8. 优先级：用以表明该需求在产品/项目中的重要程度及被实现代优先顺序，应定义优先级的划分方式，不同的产品/项目能够采用不同的划分方式；
9. 依赖性：对其它需求的存在、变化的依赖，如列出本需求所引用的需求，若无任何依赖，则写“无”；
二. 包含第一条中未列出但应该在需求项中说明的其它信息；
4.2. 正确性
正确性指对需求的定义必须是正确，它涵盖了软件需求分析说明书中所定义的需求与用户的实际需求是一致的、对需求内容的描述是明确、准确、精确和无歧义的。具体应满足但不但限于下列要求：
1. 每个需求与用户的实际需求是一致，即正确表示了用户的真正需求，能够使用让用户确认的方式来保证；
2. 内容的表示没有错误，应满足包括但不但限于下列要求：
1) 使用正确的语法，拼写，标点；
2) 无错字和别字；
3) 用词贴确；
3. 内容的表示无歧义，如同一读者对同一表示经过不同的断句方式得出多种正确的理解；
4. 无不一致的内容，详见质量要求的“一致性”部分；
5. 没有因使用不明确的表述而存在可随意发挥的内容，如：描述中出现了对于软件需求分析说明书作者自己很清楚但读者并不清楚的主观性词语（除了已经对这些词语进行了明确的定义或引用说明），具体如：“待定”、“可能”、“即将”、“考虑”、“最好”、“最差”、“一般情况”、“特殊情况”、“能够”、“用户友好性”，“容易”，“简单”，“快速”，“有效”，“几个”，“艺术级”，“改进的”，“最大”，“最小”、“较好”、“较差”、“等等”、“一期实现”、“根据需要”、“如果可能”、“高级”。
4.3. 一致性
一致性指不存在内容相互矛盾的地方。具体应满足但不但限于下列要求：
1. 同一内容在整个软件需求分析说明书中其内涵和外延都是一致的；
2. 不存在一个需求与软件的其它需求或高级别的系统需求发生冲突的现象；
3. 术语的定义与标准、规范、行业用户的定义一致；
4. 需求被引用时的含义与定义时的含义保持一致；
5. 术语被引用时的含义与定义时的含义保持一致，若某一术语在某一特殊的行文中使用时具有多种歧义，那么对该术语的每种含义作出解释并指出其适用场合；
4.4. 可验证性
可验证性指针对每项需求能够找到某种方法，经过这种方法能够验证该需求被实现后其实现的结果是否正确。具体应满足但不但限于下列要求：
1. 每个需求必须是可行的，只有可行的才是可验证的；
2. 每个需求项必须有明确的验证标准，且验证标准在现有的技术水平下是可测量的（能够找到某种测试方法，经过这种方法能够明确判断出是否已经达到预期指定的要求），如对于该性能需求，必须给出已经量化的所要达到的具体性能指标，且这些指标都能用某种方法或工具进行测量；
3. 需求必须一致的，详见质量要求的“一致性”部分；
4. 需求必须是明确的，详见质量要求的“正确性”部分的第5条；如任何需求如果说“产品/项目将要支持什么”是不可验证的，必须具体说明何时支持，如何支持。
4.5. 划分优先级
划分优先级指为每个需求指定实施的优先级，以表明它在产品/项目中的重要程度及被实现代优先顺序。具体应满足下列要求：
为整个软件需求分析说明书制定统一的优先级划分标准；
为每个需求指定一个定义好的优先级；
4.6. 可用性
可用性指需求分析说明书易于阅读、理解、修改、跟踪、维护、管理。具体应满足但不但限于下列要求：
1. 每项需求都有唯一标识，便于需求的引用、跟踪、管理；
2. 明确指出需求间的相互关联，便于在需求变更时确定变更所涉及和影响的范围；
3. 明确说明每项需求的来源和目的，便于需求的跟踪、维护；
4. 维护记录需求的修改历史，便于需求的跟踪、管理；
5. 对需求进行良好的组织，如：对需求进行类型划分后将相关的需求分组，对需求进行层次划分使需求的结构层次清晰，为需求建立目录表、索引等。便于需求的阅读、管理。
6. 编写、排版风格保持统一，便于阅读、理解，如对于同一类的内容，使用相同的表示方式和方法；
7. 最终产品的每一个特性用某一术语描述，便于修改、维护；
8. 部分编写格式符合一定的标准，如参考文档记录的格式；
9. 需求的粗细粒度要保持一致；如软件需求分析说明书中同时存在下列的需求描述，其粒度是不一致的：“用户信息对于红色合法的颜色代码应是R”、“对于绿色合法的颜色代码应是G”、“产品应能对来自语音编辑指示做出反应”，最后一个需求应作为一个子系统而不应作为单个的功能性需求。
10. 对多处出现的同一内容进行统一的定义再分别引用，便于修改、维护和保证一致性；
11. 避免将多个需求合成单个需求
12. 若选择使用某软件需求分析说明书的模板，应：
1) 如果模板中的个别章节或部分内容不适用，则在软件需求分析说明书中要保留章节号并写明不适用，不应删除；
2) 若模板中未列出，但需求中应该包含的信息，应在文档中适当的位置添加；
5. 附件
此章节内容只作为开发人员编写软件需求分析说明书时的一个参考，不作为审查的内容。
5.1. 一些编写建议
列出软件需求分析说明书编写过程中的一些建议，这些建议的描述相对比较定性、笼统。
1. 使用书面语，不用口语；
2. 使用短句和短的段落；
3. 采用主动语气；
4. 语句表示方式的风格要保持一致；
5. 编写时尽量使用定量、客户的词汇，少用定性、主观的词汇；
6. 编写时以开发人员的角度来审视是否需要软件需求分析说明书作者的额外解释和帮助开发人员才能理解需求，才能进行设计和实现？若是，则需进一步细化需求；
7. 避免一个段落中包含了多个的需求；
8. 对软件需求说明书进行持续的改进，软件产品的开发过程中，在项目的开始阶段可能无法详细说明某些细节，在开发过程中可能发现缺陷、缺点和错误，一旦发现需立即按需求管理的流程改进；
9. 不要在一个需求中使用“和”/“或”，以避免将多个需求合成一个需求；
10. 使用需求编制、管理工具，以便需求的变更并保证变更后需求仍是一致的、保证编写和排版风格的统一；
11. 尽量使用形式化的语言，少用自然语言，如使用UML、图、表格、规范化模型等方式。因为尽管自然语言是丰富多彩的，但不易精确表述；
12. 编写时重点在其表示的内容，不要拘泥于表示的形式，形式能够多种多样，合适易用的即可；
13. 建议选择使用适用的需求分析说明书模板；
5.2. 部分参考实例
列出软件需求分析说明书中部分重要内容的常见表示方式的例子。
5.2.1. 需求项表格
使用表格的方式来组织需求项的内容。
唯一标识
【必须】(跟踪需求的标签，唯一且不变，建议采用(项目编号+文档的内部编号)方式，使需求编号在整个公司的范围内都是唯一点)
简要描述
【必须】(简单描述该需求要实现的目标)
类型
【必须】(需求的类型，依需求的分类方法而定)
目的
【可选】(简要描述提出该需求的目的，若很明显则写“略”)
来源
【必须】(指谁提出该需求，具体能够是人(客户、用户、员工)、公司、市场等)
详细描述
【必须】对该需求的详细说明；由于不同类型的需求其详细描述需要包含的内容不同，下面分类列出具体应该包含的详细内容：
A. 功能性需求：
应包括但不但限于下列内容：
1. 环境要求：完成该功能应该满足的具体条件，如什么状态、情况、什么样的软硬件环境下能够进行该功能；
2. 触发者：使该功能的执行的人或事，能够是用户或是其它系统、定时事件等；
3. 输入：描述该功能执行前及在执行过程中所有输入的详细定义。例如：
数据类型输入的数据类型、数量、度量单位、源、时间关系、要求（如精度）；
功能执行过程中的用户操作控制信息；
事件类型输入的事件时间设定；
所引用的用以统一定义输入的有关接口说明或接口控制文件。
4. 处理：该功能所完成的任务，即从输入到输出的变换操作过程。具体应包括但不但限于下列内容：
对所有输入的有效性检查；
对所有输入的处理顺序、流程或方法，即系统如何把输入变换成相应输出，能够使用自然语言、方程式、数学算法、逻辑操作、图、表、状态机等不同表示方式进行描述；
对所有输出有效性的检查；
对所有异常情况的处理及响应，例如，溢出、通信故障、要所有非合法输入的响应、错误处理等；
5. 输出：描述该功能所有最终预期结果的详细定义。如：
数据类型输出的数据类型、数量、目的地、度量单位、时间关系、要求（如精度）；
所引用的用以统一定义输出的有关接口说明或接口控制文件。

非功能性需求：
性能需求：
达到该性能需求必须具备的条件或限制；
该性能需求所要达到的具体性能指标
属性需求：
可移植性：具体列出要求能够移植的平台；
可维护性：具体列出保证可维护性的具体的方法；
安全性：具体列出要达到的安全级别或安全程度；
兼容性：具体列出所要兼容的平台或软硬件环境；
可测试性：具体列出保证该特性的具体功能和方法；
设计限制：
列出具体的限制因素；
验证标准
【必须】（用于后期检查实现结果是否符合需求，给测试或用户提供明确的验证依据。如：对于性能需求，列出具体的性能指标；对于功能需求，给出详细的实现效果；若验证标准已包含在详细描述中，则指明位置即可。）
优先级
【必须】(用以表明该需求在产品/项目中的重要程度及被实现代优先顺序，应定义优先级的划分方式，不同的产品/项目能够采用不同的划分方式)
依赖性
【必须】(对其它需求的存在、变化的依赖，如列出本需求所引用的需求，若无任何依赖，则写“无”。)

5.2.2. 表格需求项实例
使用表格方式组织需求项内容的一个简单实例。
唯一标识
XX_SDK_1.1.1
简要描述
视频预览
类型
功能
目的
满足用户对视频进行实时预览的要求
提出人
XX
详细描述
该功能的环境要求：
1． 装有板卡及相应的驱动；
2． 安装了显卡及相应的驱动；
该功能的触发者：
用户
该功能的输入：
视频通道，显示位置
该功能的处理：
能控制通道对应的视频源数据经过显卡在屏幕上实时显示出来。能
对以下异常情况反馈用户通知：
1) 无视频信号；
2) 显卡未准备好；
该功能的输出：
显示在屏幕上的视频预览图像；
该功能涉及的关键术语的索引或解释：
无
验证标准
1． 能正常预览视频图像；
2． 预览图像实时（实时标准：24fps）；
3． 对异常情况下的处理参照详细描述中内容；
优先级
高
依赖性
XX_SDK_：显卡管理

5.2.3. 优先级划分方法实例
进行优先级划分时首先要制定划分标准，下面为优先级划分方法的2个例子：
1. 根据需求对产品或项目的重要性进行简单的划分：
高：必须实现的基本功能、性能需求或客户强烈要求实现的需求；
中：辅助需求；
低：特色需求；

2. 以经过对每个需求综合评估优先级的多个影响因素及每个因素的权重，再计算出优先权值，最后再根据优先权值划分优先级，或者直接使用优先权值表示优先级；如：
确定优先权值与优先级的对应关系：
综合优先权值
优先级
70～100
高
40～69
中
1～39
低
确定优先级的考虑因素、权重分配及综合优先权值算法：
因素(Fn，列出所有考虑因素)
因素的优先权值（Pn：1～100）
权重(Wn：0~1，所有因素的权重和为1)
对客户的重要程度
最重要的取100，最不重要的取1
0.8
预估的实现成本
成本最低的取100，成本最高的取1
0.15
……
……
0.05
综合优先权值
∑(Pn*Wn)
优先级

一个需求的优先级评定：
因素(Fn，列出所有考虑因素)
因素的优先权值（Pn：1～100）
权重(Wn：0~1，所有因素的权重和为1)
对客户的重要程度
90
0.8
预估的实现成本
60
0.15
……
40
0.05
综合优先权值
∑(Pn*Wn)＝90×0.8＋60×0.15＋40×0.05＝83
优先级
高

5.2.4. 软件需求分析说明书模板
列出实际工作中可能比较常见的软件需求分析说明书模板。

1. 计算机软件产品开发文件编制指南（GB 8567-88）之软件需求说明书模板
国标GB 8567-88计算机软件产品开发文件编制指南中的软件需求说明书模板。

2. RUP 模板
包括软件需求规约模板与软件需求补充规约模板，两者构成相对完整的需求分析，适用于采用RUP过程的需求分析。