<项目名称> Version: <1.0> 软件需求规约 Date:<dd/mmm/yy> <document identifier> 3.2功能需求 [此节为以自然语言风格表达的需求说明为此设计的系统功能性需求。对于许多应用程序，此节会 成为SS包的主体部分，所以应仔细考虑此节的组织方式。此节通常按特性来组织，但也可能会 有其他适用的组织方式，例如按用户或子系统组织的方式。功能性需求可能包括特性集、性能和 安全性。 当利用应用程序开发工具（如需求工具、建模工具等）来获取功能性时，此节文档将引用获取相 应数据的方法，并指出用来获取数据的工具的位置和名称。】 3.2.1<功能性需求一> [需求说明。1 3.3非功能需求 3.3.1可用性 [此节应包括所有影响可用性的需求。例如， 指出普通用户和高级用户要高效地执行特定操作所需的培训时间 指出典型任务的可评测任务次数或根据用户己知或喜欢的其他系统确定新系统的可用性需 求 指出在符合公认的可用性标准（如IBM的CUA标准和Microsoft的GUUⅡ标准）方面的需求] 3.3.1.1<可用性需求一> 「在此给出需求说明。] 3.3.2可靠性 「对系统可靠性的需求应在此处说明。以下是一些建议： 可用性一指出可用时间百分比(XxXx%)、使用小时数、维护访问权、降级模式操作等。 平均故障间隔时间MTBF)-通常表示为小时数，但也可表示为天数、月数或年数。 平均修复时间MTTR)一系统在发生故障后可以暂停运行的时间。 精确度一指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。 最高错误或缺陷率一通常表示为每千行代码的错误数目bugs/KLOC)或每个功能点的错误 数目bugs/function--poim0。 错误或缺陷率一按照小错误、大错误和严重错误来分类。需求中必须对“严重”错误进行 界定，例如：数据完全丢失或完全不能使用系统的某部分功能。】 3.3.2.1<可靠性需求一> [需求说明。] Confidential ©<公司名称>，2000 Page 5<项目名称> Version: <1.0> 软件需求规约 Date: <dd/mmm/yy> <document identifier> Confidential <公司名称>, 2000 Page 5 3.2 功能需求 [此节为以自然语言风格表达的需求说明为此设计的系统功能性需求。对于许多应用程序，此节会 成为 SRS 包的主体部分，所以应仔细考虑此节的组织方式。此节通常按特性来组织，但也可能会 有其他适用的组织方式，例如按用户或子系统组织的方式。功能性需求可能包括特性集、性能和 安全性。 当利用应用程序开发工具（如需求工具、建模工具等）来获取功能性时，此节文档将引用获取相 应数据的方法，并指出用来获取数据的工具的位置和名称。] 3.2.1 <功能性需求一> [需求说明。] 3.3 非功能需求 3.3.1 可用性 [此节应包括所有影响可用性的需求。例如， • 指出普通用户和高级用户要高效地执行特定操作所需的培训时间 • 指出典型任务的可评测任务次数或根据用户已知或喜欢的其他系统确定新系统的可用性需 求 • 指出在符合公认的可用性标准（如 IBM 的 CUA 标准和 Microsoft 的 GUI 标准）方面的需求] 3.3.1.1 <可用性需求一> [在此给出需求说明。] 3.3.2 可靠性 [对系统可靠性的需求应在此处说明。以下是一些建议： • 可用性—指出可用时间百分比 ( xx.xx%)、使用小时数、维护访问权、降级模式操作等。 • 平均故障间隔时间 (MTBF) – 通常表示为小时数，但也可表示为天数、月数或年数。 • 平均修复时间 (MTTR) — 系统在发生故障后可以暂停运行的时间。 • 精确度 — 指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。 • 最高错误或缺陷率—通常表示为每千行代码的错误数目 (bugs/KLOC) 或每个功能点的错误 数目 (bugs/function-point)。 • 错误或缺陷率—按照小错误、大错误和严重错误来分类。需求中必须对“严重”错误进行 界定，例如：数据完全丢失或完全不能使用系统的某部分功能。] 3.3.2.1 <可靠性需求一> [需求说明。]