软件需求分析使用说明审查规范标准
软件研发不同阶段需要遵循的标准
软件研发是一个具有复杂性和多样性的过程，需要在不同的阶段遵循不同的标准来保证软件质量和研发效率。
以下是软件研发不同阶段需要遵循的标准：一、需求分析阶段在软件研发的最初阶段，需求分析是非常关键的一环。
在这个阶段，需要遵循一些标准来确保对需求的准确理解和明确定义：1.1 确定需求的来源和优先级在需求分析阶段，首先需要确定需求的来源，包括客户、用户、管理层等，还需要对这些需求进行优先级的确定，以确定哪些是最为重要的需求。
1.2 明确定义需求在需求分析阶段，需要对需求进行明确定义，包括功能性需求、非功能性需求、性能需求等，以便在后续的研发中可以清晰地进行实现和验证。
1.3 编写需求规格说明书在需求分析阶段，需要编写需求规格说明书，对所有的需求进行详细描述和规范，以便开发团队和测试团队能够清楚地了解需求。
二、设计阶段设计阶段是软件研发的核心阶段之一，良好的设计是保证软件质量和研发效率的关键。
在设计阶段，需要遵循一些标准来进行设计的规范和评审：2.1 遵循设计原则在设计阶段，需要遵循一些设计原则，如高内聚低耦合、模块化、重用性等，以确保设计的合理性和可维护性。
2.2 编写设计文档在设计阶段，需要编写设计文档来对软件架构、模块设计、接口设计等进行详细描述和规范，以便团队成员共同理解设计方案。
2.3 设计评审在设计阶段，需要进行设计评审，对设计文档进行仔细的审查和评定，以保证设计的合理性和符合需求。
三、编码阶段编码是软件研发的具体实施阶段，也是最为直接的阶段之一。
在编码阶段，需要遵循以下标准：3.1 遵循编码规范在编码阶段，需要遵循一定的编码规范，如命名规范、格式规范、注释规范等，以保证编码的规范性和可读性。
3.2 代码复审在编码阶段，需要进行代码复审，对编写的代码进行严格的复审，发现并纠正潜在的问题和错误。
3.3 编写单元测试在编码阶段，需要编写单元测试来对编写的代码进行测试，以发现和解决潜在的问题和错误。
四、测试阶段在软件研发的最后阶段，测试是非常重要的一环。
软件需求分析
软件需求分析基本概念 需求分析也称为软件需求分析、系统需求分析或需求分析⼯程等，是开发⼈员经过深⼊细致的调研和分析，准确理解⽤户和项⽬的功能、性能、可靠性等具体要求，将⽤户⾮形式的需求表述转化为完整的需求定义，从⽽确定系统必须做什么的过程。
⽬标需求分析是软件计划阶段的重要活动，也是软件⽣存周期中的⼀个重要环节，该阶段是分析系统在功能上需要“实现什么”，⽽不是考虑如何去“实现”。
需求分析的⽬标是把⽤户对待开发软件提出的“要求”或“需要”进⾏分析与整理，确认后形成描述完整、清晰与规范的⽂档，确定软件需要实现哪些功能，完成哪些⼯作。
此外，软件的⼀些(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运⾏时与其他软件的关系等也是软件需求分析的⽬标。
原则为了促进软件研发⼯作的规范化、科学化，软件领域提出了许多软件开发与说明的⽅法，如结构化⽅法、原型化法、等。
这些⽅法有的很相似。
在实际需求分析⼯作中．每⼀种需求分析⽅法都有独特的思路和表⽰法，基本都适⽤下⾯的需求分析的基本原则。
(1)侧重表达理解问题的数据域和功能域。
对新系统程序处理的数据，其数据域包括数据流、数据内容和数据结构。
⽽功能域则反映它们关系的控制处理信息。
(2)需求问题应分解细化，建⽴问题层次结构。
可将复杂问题按具体功能、性能等分解并逐层细化、逐⼀分析。
(3)建⽴分析模型。
模型包括各种图表，是对研究对象特征的⼀种重要表达形式。
通过逻辑视图可给出⽬标功能和信息处理间关系，⽽⾮实现细节。
由系统运⾏及处理环境确定物理视图，通过它确定处理功能和数据结构的实际表现形式。
内容需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。
具体分为功能性需求、与设计约束三个⽅⾯。
1．功能性需求功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其⽤户提供有⽤的功能所需执⾏的动作。
功能性需求是软件需求的主体。
开发⼈员需要亲⾃与⽤户进⾏交流，核实⽤户需求，从软件帮助⽤户完成事务的⾓度上充分描述外部⾏为，形成软件需求规格说明书。
系统软件需求和需求分析说明书模板(用例图+界面+文档)
1系统需求和需求分析说明书模板Mohit系统需求和需求分析说明书模板第一部分概述1．项目名称及背景➢项目名称➢开发背景2．文档说明第二部分任务说明1．功能概述2．用户环境浏览器(如IE 6以上版本)+网络开发(生产)环境:第三部分需求分析1．实现功能➢系统用例图用户业务逻辑如下图所示：95➢管理员功能清单功能编号功能名称文中标题编号备注101 人事管理101001 机构管理101002 部门管理101003 员工管理➢普通用户功能清单2．用例说明➢ [用例1] ●用例图●描述●参与者➢[用例2] ●用例图●描述●参与者➢[用例3] ●用例图●描述●参与者➢[用例4] ●用例图●描述●参与者➢[用例5] ●用例图●描述●参与者➢[用例6 ●用例图●描述●参与者➢[用例7] ●用例图●描述●参与者➢ [用例8]●用例图●描述●参与者➢ [用例9]●描述文件搜索功能：可以按条件查询需要的文件。
●参与者//*参与者，参与用例的对象*// ➢[用例10]●用例图发送消息消息管理管理消息●描述消息管理主要包括：创建消息、修改消息、删除消息、发布消息。
●参与者//*参与者，参与用例的对象*// ➢[用例11]●用例图●描述●参与者➢[用例12] ●用例图●描述●参与者➢[用例13] ●用例图●描述●参与者➢[用例14]●用例图●描述●参与者3．用例关系附1.2 系统设计说明书模板系统设计说明书版本历史第一部分概述1．文档说明2．系统需求概述第二部分系统总体结构第三部分系统设计类图//*系统中主要的、关键实体类图，参考图如下*//➢[用例1]实现●时序图//用例1的时序图，参考图如下*//●描述界面设计1．公共模块界面设计说明：页面设计要求尽量使用div布局完成。
所有的GridView要求实现分页功能。
图1.1用户登陆首页用户登陆首页要求：只有当用户名、密码都正确时才能通过验证。
107图1.2 管理员登录后看到的主界面管理员登录后的主页面要求：显示个人便签信息，左侧显示系统菜单和个人基本信息，上标栏有“主页”、“重新登录”、“修改密码”、显示当前时间功能。
软件开发技术规范
软件开发技术规范在当今信息技术高速发展的时代，软件开发已经成为各行各业中不可或缺的一部分。
为了确保软件开发的质量和效率，制定一套规范的技术标准是非常必要的。
本文将介绍软件开发技术规范的内容和要求，以及其对软件开发过程的重要性。
一、引言随着软件开发行业的蓬勃发展，软件项目的规模和复杂性也日益增加。
为了确保软件开发过程的顺利进行和最终交付的质量，制定一套统一的技术规范是必不可少的。
软件开发技术规范旨在规范软件开发过程中的各个环节，包括需求分析、设计、编码、测试和发布等，以提高软件开发的效率和质量。
二、技术规范的内容1. 需求分析规范需求分析是软件开发的第一步，也是最为关键的一步。
在需求分析阶段，开发团队应该与客户充分沟通，明确客户的需求和期望。
需求分析规范应包括以下内容：- 确定需求的方法和工具，如面谈、问卷调查等；- 编写需求文档的格式和要求，包括功能需求、非功能需求等；- 确定需求评审的标准和流程，以确保需求的准确性和完整性。
2. 设计规范设计是软件开发的核心环节，良好的设计能够提高软件的可维护性和扩展性。
设计规范应包括以下内容：- 确定设计文档的格式和要求，包括结构设计、数据设计等；- 确定设计评审的标准和流程，以确保设计的合理性和可行性；- 确定设计模式和规范，以提高代码的复用性和可读性。
3. 编码规范编码是将设计转化为实际代码的过程，编码规范的制定可以提高代码的质量和可维护性。
编码规范应包括以下内容：- 确定编码风格和命名规范，以提高代码的可读性；- 确定代码注释的要求和规范，以提高代码的可理解性；- 确定代码版本管理的规范和流程，以确保代码的可追溯性和可控性。
4. 测试规范测试是确保软件质量的重要手段，测试规范的制定可以提高测试的效率和准确性。
测试规范应包括以下内容：- 确定测试计划和测试用例的编写规范，以确保测试的全面性和覆盖率；- 确定测试环境的配置和管理规范，以提高测试的稳定性和可重复性；- 确定缺陷管理和修复的规范和流程，以确保缺陷的及时发现和解决。
软件需求规格说明(规范)
GC508.04 密级：（软件项目名称）软件需求规格说明标识：版本：页数：拟制：SQA审核：审核：批准：拟制部门：年月日修改文档历史记录：日期版本说明修改人目录1 范围 (1)1.1 标识 (1)1.2 系统概述 (1)1.3 文档概述 (1)2 引用文档 (1)3 需求 (1)3.1 要求的状态和方式 (1)3.2 CSCI能力需求 (2)3.2.X（CSCI能力） (2)3.3 CSCI外部接口需求 (2)3.3.1 接口标识和接口图 (2)3.3.X（接口的项目唯一的标识符） (2)3.4 CSCI内部接口需求 (3)3.5 CSCI内部数据需求 (3)3.6 适应性需求 (3)3.7 安全性需求 (3)3.8 保密性需求 (3)3.9 CSCI环境需求 (4)3.10 计算机资源需求 (4)3.10.1 计算机硬件需求 (4)3.10.2 计算机硬件资源使用需求 (4)3.10.3 计算机软件需求 (4)3.11 软件质量因素 (4)3.12 设计和实现约束 (4)3.13 人员需求 (4)3.14 培训需求 (4)3.15 后勤保障需求 (4)3.16 其它需求 (4)3.17 验收、交付和包装需求（修改有关内容） (4)3.18 需求的优先顺序和关键程度 (5)4 合格性规定 (5)5 需求可追踪性 (5)6 注释 (5)1 范围1.1 标识【本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号及发布号。
】1.2 系统概述【本条应概述本文档所适用的系统和软件的用途。
它还应描述系统与软件的一般特性；概述系统开发、运行和维护的历史；标识项目的需方、用户、开发方和保障机构；标识当前和计划的运行现场；列出其它有关文档。
】1.3 文档概述【本条应概述文档的用途和内容，并描述与它的使用有关的保密性方面的要求。
】2 引用文档【本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识所有不能通过正常采购活动得到的文档的来源。
软件需求分析与规格说明书撰写技巧
软件需求分析与规格说明书撰写技巧在软件开发过程中，准确的需求分析和规格说明书是成功实现客户需求的关键。
这些文档起到指导整个开发过程的作用，所以撰写时需要注意细节和准确性。
本文将介绍一些软件需求分析与规格说明书的撰写技巧，帮助开发团队更好地完成这一任务。
1. 理解需求分析的重要性需求分析是整个软件开发过程的基础。
只有深入理解用户需求，才能准确地确定开发目标和功能。
团队成员应该花时间与用户交流，理解他们的期望、需求和挑战。
这将帮助团队更好地把握软件的核心功能和用户价值。
2. 定义范围和目标在规格说明书中，团队需要明确定义软件的范围和目标。
范围包括软件的功能、特性和限制。
目标是开发团队要达到的结果。
这些定义应该尽可能明确、具体，并通过各种图标和表格进行可视化呈现。
3. 使用简单明了的语言规格说明书应该使用简洁、明了的语言。
避免使用过多的技术术语和行业术语，确保用户能够轻松理解文档内容。
语言应该清晰而又不失严谨。
4. 分解需求将整个软件功能分解成更小的、可管理的部分是一种有效的分析技巧。
这样做可以更好地理解系统需求，并能够更好地定义每个模块的功能和交互方式。
5. 使用图表和表格图表和表格是规格说明书中不可或缺的元素。
使用流程图和状态转换图来描述系统的工作流程和状态转换。
使用表格来清晰地列出不同模块的功能和交互要求。
这些视觉化的工具可以帮助团队更好地理解软件需求，并减少沟通和理解上的误差。
6. 引入示例和场景规格说明书中引入示例和场景是一种有效的沟通方式。
通过真实场景的描述，用户能更好地理解软件的功能和使用方式。
示例可以具体到用户操作的每个步骤，让用户对软件的使用过程有更清晰的认识。
7. 注意详细性和准确性规格说明书需要尽可能详细和准确。
团队需要注意细节，确保每个功能和要求都能得到充分的描述。
不要有模棱两可的语言，避免给开发过程中留下歧义或疑惑。
8. 与用户和开发团队保持沟通在撰写规格说明书的过程中，与用户和开发团队保持密切的沟通是至关重要的。
软件工程实践中的软件需求与规格说明
隐性需求
未明确表达但潜在 存在的需求。
非功能性需求
描述系统的性能、 可靠性、安全性等
要求。
显性需求
用户清晰明确的需 求。
第二章 软件需求获取与分析
● 02
需求发掘
需求发掘是软件工程中非常重要的一环，主 要方法包括用户访谈、原型设计和场景分析。 通过这些方法，可以更好地了解用户需要和 产品功能，在软件需求获取阶段起到关键作 用。
需求确认的意义
确保需求准确性 增强项目可行性议确认 书面确认文件 需求跟踪矩阵
需求确认的结果
明确需求范围 达成需求一致 开始软件设计阶段
需求变更控制
软件项目中，需求变更是常见现象，变更控制的重 要性在于确保变更的合理性和影响的可控性。通过 制定严格的变更控制流程和挑战，可以最大程度减 少变更带来的风险。
需求分析
需求分析的目的
明确软件系统的功 能和性能需求
需求分析的技术
数据流分析、面向 对象分析
需求分析的过程
包括需求获取、需 求定义、需求规格
需求分析的工具
用例建模工具、需 求跟踪工具
需求建模
数据流图
描述数据在系统内 部流动和处理的过
程
状态图
描述系统各个对象 的状态转换
数据字典
定义系统中使用的 所有数据项
需求文档审查
审查的目的
确定需求文档质量 和准确性
审查的标准
依据需求文档质量 标准进行评审
审查的过程
审查人员分工，审 查会议召开等
总结
软件需求验证与确认是软件工程实践中至关 重要的部分，通过有效的方法和流程，可以 确保项目顺利进行并最终交付高质量的软件 产品。
第6章 软件需求与规格说明总结
软件需求规格说明书
软件需求规格说明书（SRS，Software Requirement Specification）
定义：用来描述待开发系统的功能性目标和非功能性目标的文档
来源：需求来源于客户对系统的预期
作者：SRS由需求分析人员（BA）负责编写
对象：架构师，开发，测试
作用：整个研发过程的依据，为开发、测试人员提供设计的基本思路，明确开发、测试方向
SRS描述规范举例：
1.功能需求
按模块为单位描述功能需求，重复以下几点描述每一模块的功能需求。
1.1 模块1
第一个模块。
每个模块用一个用例图表示，在写SRS时，名字使用能够表达模块功能的短语表示，而不用模块1表示。
1.1.1 业务用例图
描述此模块的用例图。
一个用例图中有若干个Actor、用例及其关系，描述包括涉及到的所有Actor、用例及其关系。
其中，Actor是参与者；一个用例描述的是一个功能需求；关系是用例和用例之间的关系。
用例的名字使用能够表达用例目标的动词短语。
1.1.2 业务流程图
用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。
一个业务流程图是用来描述1.1.1用例图中的一个用例事件的业务流程操作。
1.1.3 用例描述
下面是对业务流程图对应的这个用例的描述说明：
用例举例。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件需求分析说明书审查规范文件修改控制目录软件需求分析说明书审查规范 (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项具体需求所列出的几类需求的要求：除功能需求总是必须的，其他需求根据产品/项目的实际情况进行增删裁减。