的错误数目(bugs/function-point): 分类错误或缺陷率一按照小错误、大错误和严重错误来分类。需求中必须对 “严重”错误进行界定，例如：数据完全丢失或完全不能使用系统的某部分 功能。 4.3.3性能 完成功能时展示出来的及时性或者资源消耗程度，它包括： ●对事务的响应时间（平均、最长）： ● 吞吐量，例如每秒处理的事务数； ●容量，例如系统可以容纳的客户或事务数： ● 降级模式（当系统以某种形式降级时可接受的运行模式）： ● 资源利用情况，如内存、磁盘、通信等。 4.3.4可支持性 提高所构建系统的可支持性或可维护性的所有需求，其中包括编码标准、命 名约定、类库、维护访问权和维护实用程序。 4.3.5设计约束 所构建系统的所有设计约束。设计约束代表已经批准并必须遵循的设计决定。 其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购 买的构件、类库等。 4.4软件需求规格说明的编写 1.目前系统 描述了目前的状态。如果目前软件项目是开发一个新的系统替代以前的系统， 那么此章节可以用来描述老系统的功能和存在的问题。如果目前并没有老系统， 那么该章节就描述在实际业务中遇到的一些问题。 2.建议的系统 这一节应包含所有的软件需求，其详细程度应使设计人员能够设计出可以满 足这些需求的系统，并使测试人员能够测试该系统是否满足这些需求。的错误数目 (bugs/function-point)；  分类错误或缺陷率—按照小错误、大错误和严重错误来分类。需求中必须对 “严重”错误进行界定，例如：数据完全丢失或完全不能使用系统的某部分 功能。 4.3.3 性能 完成功能时展示出来的及时性或者资源消耗程度，它包括：  对事务的响应时间（平均、最长）；  吞吐量，例如每秒处理的事务数；  容量，例如系统可以容纳的客户或事务数；  降级模式（当系统以某种形式降级时可接受的运行模式）；  资源利用情况，如内存、磁盘、通信等。 4.3.4 可支持性 提高所构建系统的可支持性或可维护性的所有需求，其中包括编码标准、命 名约定、类库、维护访问权和维护实用程序。 4.3.5 设计约束 所构建系统的所有设计约束。设计约束代表已经批准并必须遵循的设计决定。 其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购 买的构件、类库等。 4.4 软件需求规格说明的编写 1. 目前系统 描述了目前的状态。如果目前软件项目是开发一个新的系统替代以前的系统， 那么此章节可以用来描述老系统的功能和存在的问题。如果目前并没有老系统， 那么该章节就描述在实际业务中遇到的一些问题。 2. 建议的系统 这一节应包含所有的软件需求，其详细程度应使设计人员能够设计出可以满 足这些需求的系统，并使测试人员能够测试该系统是否满足这些需求