需求规格说明书中有关“功能需求”与“用例”的说明

2.0项目组同事：
    你们好！
    昨天和屈胜讨论了需求规格说明书中第2、3、4章节涉及的两个概念“功能需求”和“用例”，确实在编写需求规格说明书中存在一些解释不明的问题，特在这里详细说明这部分内容，以便大家在编写过程中及时处理这些问题。
    在第2.4章节中，提出了系统“功能组成”的概念。这里的功能组成是指应用支撑平台v2.0系统内部所有完成的功能的列表。如何描述一个功能，我们可以参考一个经典的计算机硬件系统的结构来描述：输入设备、输出设备、运算器、控制器、存储器。那么对应一个完整的功能，我们需要指定用户输入、系统输出、处理数据的过程、业务逻辑、数据存储这样五个主要部分。
    在第3.2章节中，提出了“用例详述”的要求，即引入了用例的概念。用例是软件系统最基本的业务逻辑单元，一个用例应当能够完整的描述一个最简单的业务逻辑。而在项目管理角度来讲，用例是派发工作任务的基本单位，软件项目的开发成本=∑（用例n×用例成本n），其中用例成本=∑（资源n×资源n基本成本），资源n基本成本的单位是$/人月（日/年）。因此，划分详细的用例和资源是软件项目成本管理的核心内容。与第2.4章节中的“功能组成”相对比，一项“功能”可以包含1..n个“用例”，用例是能够被复用的，是软件设计/开发层面的内容，而“功能”是业务层面的内容。
    在第4.1章节中提出了“功能需求”的概念。功能需求即针对功能组成的需求描述，我们可能等同的认为“功能组成”和“功能需求”描述的是同一个事务的不同细致程度，功能组成相当于所有功能的标题（名称）列表，而功能需求则是具体详细描述了每项功能的业务需求（即一项完整功能的五个部分）。

    那么，在编排文档的时候，我们也同样遇到了三个编号要求，在第2.4章节中有功能模块编号，这个编号也同样能够作用于4.1章节，即在2.4章节中定义所有的功能模块列表，在4.1章节详细描述这些功能的业务需求。而在3.2章节中提出了用例编号的概念，依照上述对用例和功能的解释，用例需要另行单独编号。在文档中提出了一个基本的用例编号规则，FEG_项目名称缩写_场景名称缩写SAMPLE_序号。但是对于描述用例来讲，我认为这样编号是不妥当的，因此现提出修改意见，请大家在以后的工作中依据此用例编号方式：
    基本编号规则：FEG_项目名称缩写_一级模块名称缩写_二级模块名称缩写_UC_序号
    项目名称缩写和两级模块名称缩写均依照之前的功能模块划分来填写，序号排序顺序也依照先前功能组成编码规则，但要额外添加一些新的模块划分用于满足在非功能性逻辑里实现的用例的划分
    ·一级模块：非功能性需求
      名称缩写：DEFUNC
       ·二级模块：非功能性需求
         名称缩写：DEFUNC
    一些公共基础设施性用例可以归纳到此范围内，如基础异常处理等方面。

    在编写过程中，可以忽略其他同事的文档需要合并时的问题，按照自己的顺序编号在文档中创建内容，最后整合时再做调整。

    也特别说明，在之前收到的一些同事的初稿中，都很认真的编写了所有相关章节的内容，有些章节的内容是大家不必编写的，我会同意处理，以下也列出所有需要大家编写的章节，提高工作效率。
    第一章：全部不需要编写
    第二章：请编写2.4-2.7
    第三章：请编写所有内容
    第四章：请编写4.1、4.2.1、4.3（如果有内容）
    第五章：请尝试编写，但界面设计我随后出详细的设计规则和指南
    第六章：全部不需要编写
    第七章：全部不需要编写
    请参考以上的工作要求，有任何工作上的疑问随时交流。

    ps：随附件发送需求规格说明书最新的版本（内容更新，格式不会发生变化），2.4章节我纠正一些我自己的概念错误，请参考。