软件需求分析使用说明审查规范标准
软件需求分析说明书审查规范
文件修改控制
目录
软件需求分析说明书审查规范 (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 2002-05-1
统一软件开发过程RUP2000手册IBM公司2000年
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.需求项表格
5.2.2.表格需求项实例
5.2.3.优先级划分方法实例
进行优先级划分时首先要制定划分标准，下面为优先级划分方法的2个例子：
1.根据需求对产品或项目的重要性进行简单的划分：
高：必须实现的基本功能、性能需求或客户强烈要求实现的需求；
中：辅助需求；
低：特色需求；
2.以通过对每个需求综合评估优先级的多个影响因素及每个因素的权重，再计算出
优先权值，最后再根据优先权值划分优先级，或者直接使用优先权值表示优先级；
如：
确定优先权值与优先级的对应关系：
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.RUP2002 模板
包括软件需求规约模板与软件需求补充规约模板，两者构成相对完整的需求分析，适用于采用RUP过程的需求分析。
需求说明书(软件项目管理系统)
需求说明书（软件项目管理系统） §1、前言 1.1概述 1.1.1 项目名称：软件项目管理系统 项目代码：ProjectManager 1.1.2 开发目的：本系统应能 a．管理软件项目和项目组； b．管理与项目相关的数据项和数据结构； c．管理与项目相关的系统功能描述和分组； d．管理与项目相关的项目任务和项目任务进度； e．管理与项目相关的问题，并且能进行问题跟踪； f．管理与项目相关的文档。 1.1.3 相关读者：部门经理，项目经理，测试人员，设计人员，编程人员。 1.1.4 本项目与其它产品（软件）关系。 1.2术语 本分析书所使用的专门术语定义： 部门经理——能建立项目和项目组的系统使用者； 项目经理——能进行§1.1.2.b - §1.1.2.f管理的系统使用者； 设计人员——能进行§1.1.2.b - §1.1.2.f管理的系统使用者； 编程人员——能进行§1.1.2.d - §1.1.2.f管理的系统使用者； 数据项——目标系统中的最小信息单位； 数据结构——数据项的有意义集合； 系统功能——通过目标系统能完成的有效活动； 项目任务——开发项目中要求完成的有效活动； 1.3参考资料 列举编写本分析书时所参考资料的详细信息、标题、作者、版本号、发表日期和来源等。 1.4运行环境 操作系统：Windows 2000 Professional； 数据库：MS SQL 2000 或Oracle。 1.5条件和限制 开发环境：Microsoft Visual Studio .NET 2003； 使用工具：C# §2、系统需求 1.1 功能说明 根据用户编码和用户密码校核该用户是否合法； 在校验用户密码后，可修改用户自己的密码；
软件需求设计评审注意事项总结
软件需求设计评审注意事项总结.txt22真诚是美酒，年份越久越醇香浓型；真诚是焰火，在高处绽放才愈是美丽；真诚是鲜花，送之于人手有余香。一颗孤独的心需要爱的滋润；一颗冰冷的心需要友谊的温暖；一颗绝望的心需要力量的托慰；一颗苍白的心需要真诚的帮助；一颗充满戒备关闭的门是多么需要真诚这一把钥匙打开呀！1931年，中共中央代表欧阳钦在向党中央报告说明中央苏区情况时，具体地说明了红一方面军的“三大纪律八项注意”, 此后三大纪律八项正式成为了全军和地方武装的纪律。本文所讨论的“八项注意”是对于软件需求设计评审工作的一些情况的说明。 现在让我们把目光聚焦到软件需求设计评审上来, 我们已经知道如何去获取需求,也知道了撰写需求规格说明书。现在的问题是,我们所撰写的需求规格说明书是否能让用户接受呢? 而用户又如何对需求说明书作出理性和客观的评审和确认呢? 事实上，当我们撰写需求规格说明书的时候不妨站在用户的角度去评写，唯其如此方能事先避免一些问题。本文探讨用户应该如何去“评审”软件需求说明书，并因此提出了需求评审的”八项注意”，以飨同仁。 需求确认是需求开发过程的第四个阶段,前三个阶段按顺序分别为需求获取、需求分析、编写需求规格说明。需求确认活动要力图确保如下几点: 1 需求规格说明正确描述了预期的、满足各方涉众需求的系统能力和特征。 2 所述之软件需求是由系统需求、业务规格和其他来源中正确推导而来的。 3 需求是完整和高质量的。 4 需求的表示在所有地方都是一致的。 5 需求为产品设计和构造提供了基础。 需求确认活动可以确保需求符合优秀需求陈述的特征，包括完整、正确、可行、必要、具有优先级、无二义性和可验证, 同时亦符合好的需求规格说明的特征，即完整性、一致性、易修改和可跟踪性。 一般而言，我们通过需求评审活动去实现需求确认的目标, 参与评审者应包括各级客户、开发人员和测试人员, 在整个审查过程中，我们会有诸多“注意”。事实上,在实践活动中,每个企业会根据自身的情况存在更多的检查事项, 在此列出的八项亦属于最基本的要素。 一、注意对需求规格说明的正确性进行评审 需求规格说明的正确性通常可以从如下方面得以体现： 1 是否有需求与其他需求相互冲突或者重复？ 通常一份长达几百页的需求规格说明书都不会是一蹴而就的，它可能是系统分析师几个夜晚的心血之作。正是因为撰写过程的连续性，可能导致同一份文档中前后名词定义不一致，前后观点上有重叠或差异的情况出现，这需要我们在撰写报告前首先要在思想上形成统一概念,
软件需求规格说明书案例
软件开发方向 “成绩管理系统”软件需求规约 安博教育集团 二零零八年十月
修订历史记录
目录 1 引言 (5) 1.1 目的 (5) 1.2 文档格式 (5) 1.3 预期的读者和阅读建议 (5) 1.4 范围 (6) 1.5 术语 (6) 1.6 参考文献 (6) 2 系统概述 (6) 2.1 概述 (6) 2.2 功能 (6) 2.3 运行环境 (7) 2.4 假设与依赖 (7) 3 系统特性 (8) 3.1 系统角色 (8) 3.2 学生管理 (8) 3.2.1 增加学生信息 (8) 3.2.2 修改学生信息 (9) 3.2.3 删除学生信息 (9) 3.2.4 导入学生信息 (9) 3.3 教师管理 (9) 3.3.1 增加教师信息 (9) 3.3.2 修改教师信息 (9) 3.3.3 删除教师信息 (9)
3.3.4 导入教师信息 (9) 3.4 课程管理 (10) 3.4.1 增加课程基本信息 (10) 3.4.2 修改课程基本信息 (10) 3.4.3 删除课程基本信息 (10) 3.4.4 维护课程学生信息 (10) 3.5 成绩查询 (11) 3.5.1 学生查询成绩 (11) 3.5.2 教师查询成绩 (11) 3.6 成绩分析与统计 (11) 3.6.1 考试成绩表 (11) 3.6.2 班级各科平均成绩表 (11) 3.6.3 年级成绩排名表 (11) 3.7 系统维护 (12) 3.7.1 数据字典维护 (12) 4 非功能性需求 (12) 4.1 性能需求 (12) 4.2 安全性需求 (12) 4.3 可用性需求 (13) 4.4 用户文档 (13) 4.5 其它需求 (13) 5 外部接口需求 (14) 5.1 用户接口 (14) 5.2 硬件接口 (14)
管理系统软件需求说明书
厦漳大桥养护管理系统 V1.0 软件需求说明书 二〇一七年七月 2017.07
修改记录
目录
第一章引言 1.1编写目的 本文档作为甲乙双方就厦漳大桥养护管理系统需求理解达成一致共识的基础文件，作为双方界定项目范围、签定合同的主要基础，也作为本项目验收的主要依据。同时，本文档也作为后继工作开展的基础，供双方项目主管负责人、项目经理、技术开发人员、测试人员等理解需求之用。 1.2适用范围 本文档适用于所有与本项目有关的软件开发阶段及其相关人员，其中：项目负责人、公司方项目经理、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。 1.3文档概述 本文档主要描述了厦漳大桥养护管理系统的软件需求。 本文档首先从业务背景、系统功能、运行环境等方面概要描述系统，其次从软件接口等方面描述系统的外部接口需求，然后进一步详细描述功能性需求和非功能性需求以及待确定的问题。 1.4参考资料 甲方提供的原型图、需求资料、项目背景资料等。 1.5业务背景 厦漳跨海大桥2013年5月28日正式投入运营，工程起点在主线K1+065处与厦门至成都国家高速公路海沧枢纽立交相接，途经青礁村、海门岛，止于漳州龙海市沙坛村后宅处，终点里程桩号K10+400.390，与招银疏港高速公路相连。路线长度为9335.390m，其中桥梁长度为8669.9m。大桥工程主要包括北汊桥、海门岛立交及收费服务区、南汊桥、海平互通立交等几个部分，双向6车道，设计时速100km/h。 全桥共打下桩基1441根、墩身322座、主塔4座，共296根斜拉索，用材11.5万吨钢筋、 68.7万立方米混凝土。能抗14级台风和7度地震。北汊主桥为连续半漂浮体系双塔双索面斜拉桥，主跨780m，可满足3万吨级船舶安全通航，在同类型桥梁中居全国第六、世界第
需求分析及评审模板
需求分析 沈阳网络通信股份有限公司（版权所有，翻版必究）
文件修改控制
目录1. 目的 2. 适用范围 3. 职责 3.1 开发部门 3.2 开发体系决策层SMG 4. 术语和缩略语 5. 工作程序 5.1《需求分析报告》的编制 5.2《需求分析报告》的评审 5.3《需求分析报告》的更改 6.引用文件 6.1 NP601100《配置管理》 6.2 NW503101《需求分析报告编写规范》 7.质量记录 7.1 NR503100A“需求分析报告评审记录”
1.目的 保证本公司开发的软件产品和软件项目的需求分析活动在受控状态下进行。在进行软件开发前，明确其应达到的目标，对系统目标做出完整、准确、清晰、具体的要求。 2.适用范围 适用于所有软件项目和/或软件产品。 3.职责 3.1 软件研发部门：负责编制《需求分析报告》，并参加评审。 3.2开发体系决策层SMG：负责参加评审重大项目的《需求分析报告》，并批准相应 的评审结果。 4.术语和缩略语 SMG（Senior Manager Group）：开发体系决策层 软件项目：指根据合同需求开发的软件。也可以称为合同软件。 软件产品：公司根据市场的调研、预测等结果而自行开发的软件。 PM（Project Manager）：项目经理。 5.工作程序 5.1 《需求分析报告》的编制 5.1.1 需求分析文档可由开发人员编制。软件项目经理SPM或其指定人员根据调研结 果，编制该项目的需求分析文档即《需求分析报告》和/或《软件功能规格说明书》， 必要时可邀请客户派人员参加编制工作。 5.1.2 《需求分析报告》的内容以满足客户要求或系统所要实现的功能和性能要求为 准，同时还要满足本公司NW503101《需求分析报告编写规范》或《开发计划》 中明确的标准与规程的要求，如有明确的法律、法规、行业标准等规定时，《需 求分析报告》必须遵守相应规定。 5.1.3 若客户已提供《需求分析报告》或具有同等作用的文档，则本公司无须进行《需 求分析报告》的编制。但在使用前必须进行评审，以确保准确理解客户的需求， 并取得客户的确认。 5.2 《需求分析报告》的评审
需求规格说明书范例-《网上招聘系统》需求规格说明书.docx
公司 LOGO 项目编号XXXXXXXXX 文档编号１０ 密级内部 软件需求规格说明书 版本： XXXXX软件公司 评审日期：XXXX年XX月XX日
公司 LOGO 修改记录 版本号修改日期修改描述修改人
目录 1导言 ......................................................错误 ! 未定义书签。 目的 . .............................................错误 ! 未定义书签。 范围 . .............................................错误 ! 未定义书签。 缩写说明 . .........................................错误 ! 未定义书签。 术语定义 . .........................................错误 ! 未定义书签。 引用标准 . .........................................错误 ! 未定义书签。 参考资料 . .........................................错误 ! 未定义书签。 版本更新信息 . .....................................错误 ! 未定义书签。2系统定义 . .................................................错误 ! 未定义书签。 项目来源及背景 . ...................................错误 ! 未定义书签。 项目要达到的目标 . .................................错误 ! 未定义书签。 系统整体结构 . .....................................错误 ! 未定义书签。3应用环境 . .................................................错误 ! 未定义书签。 系统运行网络环境 . .................................错误 ! 未定义书签。 系统运行硬件环境 . .................................错误 ! 未定义书签。 系统运行软件环境 . .................................错误 ! 未定义书签。4功能规格 . .................................................错误 ! 未定义书签。 角色（ Actor ）定义 . ................................错误 ! 未定义书签。 应聘者 . .......................................错误 ! 未定义书签。 管理用户 . .....................................错误 ! 未定义书签。 数据库 . .......................................错误 ! 未定义书签。系统主 Use Case图 . .................................错误 ! 未定义书签。 客户端子系统 . .....................................错误 ! 未定义书签。 职位选择 . .................................错误 ! 未定义书签。 简历输入 . .....................................错误 ! 未定义书签。 问卷回答 . .....................................错误 ! 未定义书签。 管理端子系统 . .....................................错误 ! 未定义书签。 登录管理 . .....................................错误 ! 未定义书签。 题库管理 . .....................................错误 ! 未定义书签。 试卷管理 . .....................................错误 ! 未定义书签。 职位发布 . .....................................错误 ! 未定义书签。 简历管理功能 . .................................错误 ! 未定义书签。 面试管理 . .....................................错误 ! 未定义书签。 用户管理 . .....................................错误 ! 未定义书签。5性能需求 . .................................................错误 ! 未定义书签。 界面需求 . .........................................错误 ! 未定义书签。 响应时间需求 . .....................................错误 ! 未定义书签。 可靠性需求 . .......................................错误 ! 未定义书签。 开放性需求 . .......................................错误 ! 未定义书签。 可扩展性需求 . .....................................错误 ! 未定义书签。 系统安全性需求 . ...................................错误 ! 未定义书签。6产品提交 . .................................................错误 ! 未定义书签。
软件需求分析规格说明书格式
软件需求分析规格说明书格式 2008年03月28日11:08:00 chenguang79阅读数：1993 1.引言 1.1编写的目的 /*说明编写本说明书的目的 1.2背景说明 /*给出待开发系统的全名及项目提出者，开发者，及用户。同时说明该软件系统将做什么和不做什么。 1.3术语定义 1.4参考资料 /*列出本文档所引用的全部资料以及资料的来源。 2. 任务概述 2.1功能概述 /*简要叙述本系统预计实现的主要功能及功能之间的相互关系，最好用图表明。 2.2约束条件 /* 简要说明对系统设计产生影响的限制备件，如管理模式，硬件限制，技术或工具的制约等。 3. 数据流图与数据字典 3.1 数据流图 3.1.1 数据流图图形 /*将需求分析构造的数据流图按层次逐层画出。 3.1.2加工说明 /*对数据流图中的每一个加工，按编号，加工名，输入流，输出流及加工过程逐一说明。 3.2 数据字典 /*本节对数据流图中使用的数据项，数据结构，文件的内容及组织结构逐项说明. 3.2.1 数据项说明 3.2.2数据结构说明 3.2.3文件说明 4 系统接口 4.1 用户接口 /*说明人机交互界面的用户需求，如屏幕格式，报表，菜单的格式与内容及功能键定义。 4.2 硬件接口 /* 说明本软件系统与硬件设备的接口信息的内容，格式以及运行软件的硬件设
备特征。 4.3 软件接口 /*说明本软件系统与其它支持软件之间的接口规格，支持软件应明确其版本号。 5. 性能需求 5.1 精度要求 /* 说明输入/输出数据以及传输数据的精度要求。 5.2时间特征 /* 定量说明系统应达到的响应时间，更新处理时间，数据传输转换时间，计算时间的特征值 5.3灵活性 /* 说明本软件在需求发生变化时(操作方式，精度要求，时间特征等)的适应能力。 6 软件属性 6.1 可使用性 /* 规定系统的某些特殊需求，如检查点设置，恢复方法和重启动方法，以确保软件可使用。 6.2 系统安全性 /* 规定系统为保证运行安全，信息安全面而采用的技术措施，如密码，防病毒，防黑客等。 6.3 可维护性 /* 规定系统为提高系统的可维护性将采取的措施。 6.4 可移植性 /* 规定程序以及挡方面军的兼容性，扩充性的约束。 7 其它需求 7.1 数据库需求 /*对数据库的静态结构，动态组织，访问信息的方式，使用频率以及数据的存储等方面提出需求。 7.2 系统操作要求 /*列出系统所要求的正确或特殊的操作方式，如用户的操作方式和系统的后援和恢复操作。 7.3 故障及其处理 /* 尽量烈列出能够预测的系统故障(包括软硬件及其它系统)，并指出故障可能造成的影响及故障排除的方法。 8 附录
软件系统需求说明书
专 组号：小组成员： 完成时间：
目录 1.系统概述 (3) 1.1. 系统功能简介 (3) 1.2 系统用户角色 (3) 2.理由 (3) 3.项目范围 (3) 4.系统假设 (3) 5.系统定义 (4) 6.用户场景 (5) 7.用户用例 (5) 7.1 用户用例步骤 (5) 7.2系统需求 (9) 7.2.1 功能需求 (9) 7.2.2 非功能需求 (12) 8.文档历史 (14)
1.系统概述 1.1. 系统功能简介 教务处工作人员根据设置的用户名和密码，登录到学生信息管理系统，并对学生提交的信息修改进行审核,,系统优先级高; 档案管理员添加、查看、删除、修改学生的基本信息, 系统优先级高; 老师查看自己所管班级的学生的信息, 系统优先级高; 学生修改、查看自己的某些信息, 系统优先级高; 1.2 系统用户角色 2.理由 由于现在的学校规模在逐渐的扩大，设置的专业类别、分支机构及老师、学生人数越来越多，对于过去的学生信息管理系统，不能满足当前学生信息管理的服务性能要求。本报告对于开发新的<<学生信息管理系统>>面临的问题及解决方案进行初步的设计与合理的安排，对用户需求进行了全面细致的分析，更清晰的理解学生信息管理系统业务需求，深入描述软件的功能和性能与界面，确定该软件设计的限制和定义软件的其他有效性需求，对开发计划进行了总体的规划确定开发的需求与面临困难的可行性分析。 3.项目范围 学生信息管理系统是典型的信息管理系统，其开发主要包括后台数据库的建立、维护以及前端应用程序的开发两个方面。对于前者要求建立起数据一致性和完整性强、数据安全性好的数据库。而对于后者则要求应用程序具有功能完备，易使用等特点。学生信息管理系统对全校学生实行统一的管理，可以方便的进行增添、查询、修改、删除学生信息的工作。为了使本系统成功达到用户的要求，需要在2012.12.28之前完成本系统的开发测试，并写提交相关的技术文档。通过与用户的沟通，及时获得用户的最新需求以便于本系统的完善。 4.系统假设 本项目的开发时间为2012.9.9—2012.12.28 开发人员人数：3人 技术文档写作人员人数3人
软件需求规格说明书(案例)
“成绩管理系统”软件需求规约 安博教育集团 二零零八年十月
修订历史记录
目录 1 引言 (5) 目的 (5) 文档格式 (5) 预期的读者和阅读建议 (5) 范围 (6) 术语 (6) 参考文献 (6) 2 系统概述 (6) 概述 (6) 功能 (7) 运行环境 (8) 假设与依赖 (8) 3 系统特性 (9) 系统角色 (9) 学生管理 (9) 增加学生信息 (9) 修改学生信息 (9) 删除学生信息 (9) 导入学生信息 (9) 教师管理 (10) 增加教师信息 (10) 修改教师信息 (10) 删除教师信息 (10) 导入教师信息 (10) 课程管理 (11) 增加课程基本信息 (11) 修改课程基本信息 (11) 删除课程基本信息 (11) 维护课程学生信息 (11) 成绩查询 (12) 学生查询成绩 (12) 教师查询成绩 (12) 成绩分析与统计 (12) 考试成绩表 (12) 班级各科平均成绩表 (12) 年级成绩排名表 (13) 系统维护 (13) 数据字典维护 (13) 4 非功能性需求 (13) 性能需求 (13) 安全性需求 (13) 可用性需求 (14) 用户文档 (14) 其它需求 (15)
5 外部接口需求 (15) 用户接口 (15) 硬件接口 (15) 软件接口 (15) 通信接口 (15) 1 引言 目的 该文档首先给出了整个系统的整体网络结构和功能结构的概貌，试图从总体架构上给出整个系统的轮廓，然后又对功能需求、性能需求和其它非功能性需求进行了详细的描述。其中对功能需求的描述采用了UML的用例模型方式，主要描述了每一用例的基本事件流，若有备选事件流则描述，否则则省略。而且还给出了非常直观的用例图。这些文字和图形都为了本文档能详细准确地描述用户的需求，同时也为用户更容易地理解这些需求的描述创造了条件。 该文档详尽说明了这一软件产品的需求和规格，这些规格说明是进行设计的基础，也是编写测试用例和进行系统测试的主要依据。同时，该文档也是用户确定软件功能需求的主要依据。 文档格式 本文档按以下要求和约定进行书写： （1）页面的左边距为2.5cm，右边距为2.0cm，装订线靠左，行距为最小值20磅。 （2）标题最多分三级，分别为黑体小三、黑体四号、黑体小四，标题均加粗。 （3）正文字体为宋体小四号，无特殊情况下，字体颜色均采用黑色。 （4）出现序号的段落不采用自动编号功能而采用人工编号，各级别的序号依次为（1）、1）、a)等，特殊情况另作规定。 预期的读者和阅读建议 本文档的主要内容共分4部分：综合描述、系统特性、和非功能性需求和外部接口描述。综合描述部分主要对系统的整体结构进行了大致的介绍；系统特性部分对系统的功能需求进行了详细描述，是本文的主要部分；非功能性需求部分对非功能需求进行了详细的描述；外部接口需求部分对用户界面、软件接口、硬件接口和通讯接口等进行了描述。 本文档面向多种读者对象： （1）项目经理：项目经理可以根据该文档了解预期产品的功能，并据此进行系统设计、项目管理。
软件需求分析说明书模板
保密级别：S 资料编号：SRS-[产品代号] -[序列号] 版本：V[*].[*] [产品型号名称（二号字体）] [部件型号名称（可选、小二号字体）] 软件需求分析说明书 共11页 编制： 审核： 审定： 会签： 批准： XXXXXXXXXX公司 [****]年[**]月[**]日
文档修改记录
目录 1引言 (2) 1.1编写目的 (2) 1.2范围 (2) 1.3定义、首字母缩写词和缩略语 (2) 1.4参考资料 (2) 2项目概述 (3) 2.1产品描述 (3) 2.2产品需求 (3) 2.2.1功能需求 (3) 2.2.2性能需求 (4) 2.2.3可服务性需求 (4) 2.3用户及用户特点 (4) 2.4一般约束 (5) 2.5假设和依据 (5) 3用例描述 (5) 3.1用例1 (5) 3.2用例2 (6) 3.3用例n (6) 4外部接口需求 (7) 4.1用户接口 (7) 4.2硬件接口 (7) 4.3软件接口 (7) 4.4通信接口 (8) 5设计约束 (8) 5.1其他标准的约束 (8) 5.2硬件的限制 (8) 6属性 (8) 6.1可用性 (8) 6.2安全性 (9) 6.3可维护性 (9) 6.4可转移＼转换性 (9) 6.5警告 (9) 7其他需求 (9) 7.1数据库 (9) 7.2操作 (10) 7.3场合适应性需求 (10) 8附录 (10)
[说明：本模板中的蓝色字体与橙色字体为说明性文字，在最终提交的文档中请删除这些说明性的文字。] 1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者范围。 1.2 范围 说明： a．待开发的软件系统的名称； b．说明软件将干什么，如果需要的话，还要说明软件产品不干什么； c．描述所说明的软件的应用。应当： 1）尽可能精确地描述所有相关的利益、目的、以及最终目标。 2）如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。 1.3 定义、首字母缩写词和缩略语 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
软件需求规格说明书
图书管理系统软件需求规格说明书 编著郑帅王超朱丙虎魏建德李璋 1 引言 本需求规格说明书是为了方便管理图书管理系统而编写，主要面向图书管理员、学生，老师, 和其他借阅图书的人员。本文档是整个软件开发的依据，它对以后阶段的工作起指导作用。本文也是项目完成后系统验收的依据。同时本说明书还是《用户手册》和《测试计划》的编写依据 1.1 编写目的 本文主要研究图书管理系统的主要功能，将用户对该系统的需求进行准确、具体的描述。 本文的预期读者是开发团队，指导老师，用户。 1.2 背景及范围 本项目的名称：图书管理系统开发软件。 本项目的任务提出者及开发者是图书管理系统软件开发小组,用户是图书管理员以普通及学生用户。本产品能具体化、合理化的管理图书馆的所存图书。 1.3 定义缩写词略语 C#语言：C#是微软为.NET Framework量身订做的程序语言，C#拥有 C/C++的强大功能以及Visual Basic简易使用的特性，是第一个组件导向的程序语言，和C++与Java一样亦为对象导向程序语言。 图书管理系统：图书管理是帮助图书管理员对图书进行有效管理的软件。使用C#语言，独立完成其功能。 1.4 参考资料 2 项目概述 2.1 目标 a. 为了图书管理系统更完善； b. 为了图书管理员对图书的管理更方便； c. 为了使学生更加快捷地查询图书信息。 2.2用户特点 本软件的使用对象是图书管理员及普通借书同学。懂计算机的基本操作就可以利用该软件进行所需操作。 2.3假定与约束 2.3.1 假设和依据 假设开发经费不到位，管理不完善，设计时没能用全得到考虑，本项目的开发都将受到很大的影响。 2.3.2一般约束
软件需求分析使用说明审查规范标准
软件需求分析说明书审查规范
文件修改控制
目录 软件需求分析说明书审查规范 (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 2002-05-1 统一软件开发过程RUP2000手册IBM公司2000年 3.术语定义 GB/T 11457所列术语和下列定义适用于本文 需求 系统必须符合的条件或具备的功能 软件需求分析 软件需求分析的基本任务是准确地定义未来系统的目标，确定为了满足用户的需求，系统必须做什么。需求分析包括需求获取和需求规约：需求获取是系统分析员通过学习以及同用户的交往，熟悉用户领域的知识，并获得对未来系统的需求；需求规约是系统分析员在获得了用户的初步需求后，必须进行一致性分析和检查，通过和用户协商解决其中存在的二义性和不一致性，并以一种规范的形式准确地表达用户的需求，形成软件需求分析说明书。 软件需求分析说明书（Software Requirements Specifications，简称SRS）：软件需求分析说明书（也称软件需求规格说明书、软件需求分析报告）是软件需求分析阶段得到的最终文档，它以形式化的术语和表示对软件的功能和性能进行详细而具体的描述。它是用户和开发者之间的技术合同，是软件设计、编码阶段的基础,也是软件测试和验收的依据。
软件需求规格说明书(案例)
软件开发方向“成绩管理系统”软件需求规约 二零零八年十月
修订历史记录
目录 1 引言 (5) 1.1 目的 (5) 1.2 文档格式 (5) 1.3 预期的读者和阅读建议 (5) 1.4 范围 (6) 1.5 术语 (6) 1.6 参考文献 (6) 2 系统概述 (6) 2.1 概述 (6) 2.2 功能 (7) 2.3 运行环境 (8) 2.4 假设与依赖 (8) 3 系统特性 (9) 3.1 系统角色 (9) 3.2 学生管理 (10) 3.2.1 增加学生信息 (10) 3.2.2 修改学生信息 (10) 3.2.3 删除学生信息 (10) 3.2.4 导入学生信息 (10) 3.3 教师管理 (11) 3.3.1 增加教师信息 (11) 3.3.2 修改教师信息 (11) 3.3.3 删除教师信息 (11) 3.3.4 导入教师信息 (11) 3.4 课程管理 (12) 3.4.1 增加课程基本信息 (12) 3.4.2 修改课程基本信息 (12) 3.4.3 删除课程基本信息 (12) 3.4.4 维护课程学生信息 (12) 3.5 成绩查询 (13) 3.5.1 学生查询成绩 (13) 3.5.2 教师查询成绩 (13) 3.6 成绩分析与统计 (13) 3.6.1 考试成绩表 (13) 3.6.2 班级各科平均成绩表 (13) 3.6.3 年级成绩排名表 (14) 3.7 系统维护 (14) 3.7.1 数据字典维护 (14) 4 非功能性需求 (14) 4.1 性能需求 (14) 4.2 安全性需求 (14) 4.3 可用性需求 (15)
[软件需求]销售系统软件需求说明书
[软件需求]销售系统软件需求说明书
＜网络营销系统＞ 软件需求说明书 作者：杨晶 完成日期：2010年7月6日 签收人： 签收日期： 修改情况记录：
目录 1 引言 (1) 1.1 编写目的 (1) 1.2 范围 (1) 1.3 定义 (2) 1.4 参考资料 (3) 2 项目概述 (4) 2.1 产品描述 (4) 2.2 产品功能 (4) 2.3 用户特点 (5) 2.4 一般约束 (5) 2.5 假设和依据 (5) 3 具体需求 (6) 3.1 功能需求 (6) 3.1.1 功能需求1 (6) 3.1.2 功能需求2 (7) 3.1.n 功能需求n (7) 3.2 外部接口需求 (8) 3.2.1 用户接口 (8) 3.2.2 硬件接口 (8) 3.2.3 软件接口 (8) 3.2.4 通信接口 (9) 3.3 性能需求 (9) 3.4 设计约束 (9) 3.4.1 其他标准的约束 (10) 3.4.2 硬件的限制 (10) 3.5 属性 (10) 3.5.1 可用性 (10) 3.5.2 安全性 (11) 3.5.3 可维护性 (11) 3.5.4 可转移＼转换性 (11) 3.5.5 警告 (12) 3.6 其他需求 (12) 3.6.1 数据库 (12) 3.6.2 操作 (12) 3.6.3 场合适应性需求 (13) 4 附录 (13)
1 引言 1.1 编写目的 近年来，互联网技术的迅猛发展使电子商务在世界范围内蓬勃兴起。基于Internet的电子商务冲击着传统企业的经营模式、管理模式和经济活动的运作手段，它为中小企业提供了大量市场机会，也缩小了大型企业和中小企业之间的市场地位的差距，为中小企业提供了竞争的机会。 1.2 范围 说明： a．该系统名为网络销售系统 b．该系统更大的方便了群众，减少了用户外出或者购买的不便。 c．该系统的应用： 1）该系统的开发，为更多的经销商提供了 更好的发展平台，扩大了业务，更好的适 应了当今社会的发展需求，同时为广大的 用户提供了方便。
软件需求分析说明书
软件需求分析说明书集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
学生信息管理系统 需求分析说明书 1.引言 编写目的 确定学生信息管理系统功能的有效性需求；以供本系统的开发人员参考。 项目背景 开发软件名称：学生信息管理系统。 用户：教学办公室 项目和其他软件：系统的关系。 本项目采用客户机/服务器原理，客户端程序是建立在window NT系统上以 Java为开发软件的应用程序，服务器端采用Linux为操作系统的工作站，是采用Oracle 的为开发软件的数据库服务程序。 定义 学号：学校给学生的编号，用来区分各个学生的信息的中介。 课程名：学校开设课程的名字 Java+SQL：编写该系统的面向对象的开发语言和数据库语言。
参考资料 ⑴《Oracle从入门到精通》 ⑵《JAVA程序设计项目教程》 ⑶《数据库原理及应用》 ⑷《软件工程案例教程》 2．任务概述 目标 ⑴开发意图：由于学校的不断招生，现有的系统空间小，运行速度缓慢，操作过于复 杂，有的操作还不能执行，所以要开发本系统。 ⑵应用目标：学生信息管理系统将解决现有系统的空间不足，运行缓慢，操作复杂，操 作无效等问题。 运行环境 本系统采用C/S体系结构 操作系统：Microsoft Windows xp 支持环境：IIS 数据库：Oracle 软件设备：eclipse 内存：512 M以上 硬盘空间：40G以上 CPU: 233MHZ以上
内存：256M以上 硬盘空间：以上 假定与约束 使用本系统的用户群集中在 22-35 岁的年轻人，用来做学生信息的存储，对计算机的操作一般比较熟练。根据他们对本程序的认可、方便操作的程度，结合他们日常工作的频繁程度，系统每天操作完成一个功能点应该在 2- 10 次之间。用户对界面的友好性，有非常高的要求。本系统的规模比较小，并且将提供操作手册进行操作项的详细说明 （1）、Client/Server结构总体设计方案对它的约束：本系统做为Client/Server 结构的一个应用系统，不可避免的要受到Client/Server结构的约束。在其实施的各个阶段都要服从它的一些规划，包括功能设计、系统配置和计划。同时，由于信息的共享，机票预订系统还受到其它系统的信息约束。 （2）、人力、时间的约束：本系统开发过程中也要考虑到人力、资金和时间的约束。 （3）、技术发展规律的约束：计算机技术和产品的发展日新月异，将会给信息处理带来更多的手段，同时也会带来更加丰富的信息表达形式。例如图象和语音技术的进步，多媒体技术的发展，这些都要求系统在设计时考虑技术变化的可能性，为可能的变化预留一定的系统处理能力。 3．需求规定 对功能的规定 系统流程图：系统流程图是用户操作此系统的流程和各个用户能够操作的功能，如A-1就是一个系统流程图；用户有系统管理员，教师和学生，每个用户要进入此系统都要登录。每个用户有不同的功能，系统管理员有查询，增加，修改，删除，修改密码，设置权限等功能；教师有查询，修改密码和输入学生成绩的功能；学生只有查询和修改密码的功能。 A-1系统流程图 用例图：用例图是用来表示用户能使用的功能和权限。如图A-2表示系统管理员可以运用的功能，像修改密码，管理学生信息、成绩信息、课程信息、班级信息并且设置权
ERP软件系统需求说明书
《择易企业管理系统商务版V3。0》 软件需求说明书 软件开发有限公司
《择易企业管理系统商务版V3。0》软件需求说明书 目录 1.编写目的 (8) 2.背景 (8) 2.1.定义 (8) 2.2.参考资料 (8) 2.3.目标 (8) 2.4.用户的特点 (8) 2.5.假定和约束 (8) 3.需求规定 (8) 3.1.采购管理 (8) 3.1.1采购订单APOrder (9) 3.1.2采购收货APRecieve (11) 3.1.3采购退货APRetturn (12) 3.1.4采购发票APInvoice(扩展) (14) 3.1.5采购付款 (15) 3.1.6显示凭证（不产生凭证，只是显示凭证的内容） (16) 3.1.7采购数据查询 (16) 3.1.8采购统计报表 (16) 3.1.9采购决策分析图 (16) 3.1.10采购历史数据维护 (16) 3.2.销售管理 (17)
3.2.1销售订单AROrder (18) 3.2.2销售发货APROredr (19) 3.2.3销售退货ARReturn (20) 3.2.4销售发票ARInvoice (22) 3.2.5销售收款 (23) 3.2.6显示凭证（不生成凭证，仅提供显示凭证的内容） (24) 3.2.7门市零售 (24) 3.2.8库存盘点（见库存管理） (24) 3.2.9货品调拨（见库存管理） (24) 3.2.10货品维修服务 (24) 3.2.11销售数据查询 (25) 3.2.12销售统计报表 (25) 3.2.13销售决策分析图 (26) 3.2.14销售历史数据维护 (26) 3.3.库存管理（Inventory Control） (26) 3.3.1货品入库（入库单）ICReceiveOrder (27) 3.3.2货品出库（出库单） (29) 3.3.3货品调拨 (30) 3.3.4货品盘点 (31) 3.3.5组合货品定义 (32) 3.3.6货品组装 (33) 3.3.7货品拆分 (33)
软件需求规格说明书实用模板(超详细)
XXXXXX 单位
XXXXXXX 项目
软件需求规格说明书
龙子湖网络科技
项目 文档 文档 ID 说明 作者 最后更新时间
项目名称 软件需求规格说明书
V1.2 *** 2011-10-20
版本更新概要 版本号 V1.0
V1.1
V1.2
时间 2011-10-02
2011-10-20
2011-11-08
更新人
更新摘要 移动 OA、车辆管理模块
需求容 移动政务资源管理系统
平台需求容 根据业务需求，电子公
文在线预览
项目负责人审核与确认 供应商：
职位
审核时间
审核意见(签字)
客户方：
目录
第一章 引言 ................................................................... 5
1 编写目的 .................................................................. 5 2 软件需求分析理论........................................................... 5 3 软件需求分析目标........................................................... 5 4 参考文献 .................................................................. 6
第二章 需求概述................................................................ 7
1. 项目背景 .................................................................. 7 2. 需求概述 .................................................................. 7 3. 条件与限制(可选)........................................................... 8 4. 移动办公系统结构........................................................... 8 5. 移动办公网络拓扑图......................................................... 9
第三章 系统功能需求........................................................... 10
1. 移动办公系统升级改造需求.................................................. 10 界面显示要求 ........................................................... 11 待办公文列表 ........................................................... 11 待办公文列表排序 ....................................................... 12 公文详细信息界面元素.................................................... 12 信息审批 ............................................................... 12 会议申请 ............................................................... 12 意见录入 ............................................................... 12 移动 ................................................................... 13 会议管理 ............................................................... 13 通知通告 ............................................................... 14 通讯录管理 ............................................................. 14
2. 车辆管理模块升级改造需求.................................................. 14 系统功能架构 ........................................................... 14 网络拓扑结构 ........................................................... 16