2)、系统性能的需求是在网络正常情况下 , 主要页面响应时间不超过 5s, 大批量业务或复杂计算业务响应时间不超过 30S。随着系统业务数据规模的增长, 系统要满足两年内业务量发展的需求，并满足上述性能要求。系统扩展性的需求是采用三层架构，采用 MVC设计模式, 代码规范易读，据库设计在不严重影响性能的基础上符合第三范式，命名规范，并有注释。交付系统的同时交付系统的概要设计文档和详细设计文档 (含数据库设计文档)；
●以上两种形式，显然是第二种方式更容易编写代码。所以我们要以有用的和有效的方式决定和组织一项详细的需求描述。在描述需求过程中，需要涉及一个项目中所有与“用户”相关的各个方面。 此处的 “用户’ 涉及所有与项目有关系的相关人员，包括公司内部和外部的支援，以及最终的用户、可接受测试人员、用户的合同签订者、软件维护工程师、用户管理员、销售人员等；
●需求规格说明书所具有的特征：
★完整性：每项需求都必须描述清楚将要实现的功能 以使开发人员获得设计和实现这些功能所需的全部必要信息；
★正确性：每项需求都必须准确地陈述其要开发的功能。如果软件需求与对应的系统相抵触，那么该项需求是不正确的。只有用户才能圈定用户需求的正确性，这也是一定要用户积极参与的原因，没有用户参与的需求，评审可能是评审者自己的猜测；
★可行性：每项需求都必须是在已知系统和环境的限制范围内能够实施的。为了避免不可的需求，最好在获取需求过程中，始终有一位软件项目组成员与需求分析人
员或销售人一起工作。这名项目组成员负责检查技术的可行性；
★必要性：每项需求都应记录客户真正所需要的和最终系统所需遵从的标准，也可以理解每项需求都是用来授权编写文档的根源。每项需求应该都能回溯到用户的某项输入；
★划分优先级：为每项需求、特性或使用实例分配一个实施优先级，以指明它在特定产品中所占的分量。如果把所有的需求都视为同等重要，那么项目管理者在开发或节省预算或调度中，可能会无法舍去，丧失控制；
★无二义性：所有阅读开发文档的读者对每项需求说明都只能有一个明确统一的解释，由于自然语言容易引起二义性，因此尽是使用简洁明了的语言描述每项需求，避免二义性的效方法包括对需求文档的正规审查、编写测试用例、开发原型. 以及设计特定的方案脚本；
★可验证性：检查每项需求是否能通过设计测试用例获取它的验证方法，如用演示、检测等方法确定产品是否确实是按照需求实现的。如果需求不可验证，则确定这项需求是否正确就会成为主观臆断，而非客观分析. 对于一份前后矛盾、不可行或有二义性的需求也是不可验证的；
●怎样才能编写出一份合格的需求规格说明书呢？以下是编写需求规格说明书的要求，在编写时满足这些要求就会写出合格的需求文档， 同时也会开发出更好的产品；
1、基本要求：在编写需求规格说明书时.对于需求的描述应坚持遵循下面的要求：
1）、详细：足以指导开发。文档的内容要完整、详尽、不得有遺漏；例如，对于 ' 歌曲的字数由系统自动算出’的需求，应明确描述中文、英文的不同实现方法；
2）、明确、无二义性：对所有阅读本文档的读者来说，每个需求说明都只能有一个明确统一解释， 尽量用简洁明了的自然语表达每项需求，避免二义性。
例如，在需求 “歌曲次数可以不由用户输入" 中，因为出现了 “可以" 字样， 可能会使读者产生二义性，所以无判断到底是否需要输入；