简介
很多时候开发组和过程管理组都存在一个矛盾，就是开发组熟悉业务但不擅长方法，而过程组擅长方法而不熟悉业务。因此常常出现过程组为了自己的问题（估算，度量，绩效管理等）尝试让开发组学会和使用自己的方法工作，而开发组不愿意花自己的时间、用别人的方法解决别人的问题……
这一问题在整个开发过程中都存在，而在需求管理中尤为突出。因为需求管理实际上涉及到市场、销售（或业务部门）、售前、高层、开发、测试、支持……等众多角色，若每一种角色都基于自己的需要提出一种管理方法，那么企业的管理成本会非常之高。
本咨询包旨在介绍一种能贯穿整个研发过程中的需求管理方法，使得各种不同角色的需求能无缝地集成在一起。我们会看到如何在功能点思想的指导下，使需求管理变成开发团队的日常活动，其度量与采集工作也变得不再耗费工作量，摆脱“初期敷衍”“末期造假”的怪圈。
目标
本阶段完成后，需求分析人员只需要按一种规则编写需求文档，就可以从中直接计数功能点。
详情包括：
1. 形成一个一线业务人员很容易编写的需求文档规则，满足此规则的文档可以无形之中直接提取功能点
2. 学习功能点的基本知识，以便固化规则
3. 学习规则中常见的问题，以避免错误
4. 学习如何从满足上述规则的文档中计数功能点
5. 学习需求发生变化时，如何自动同步需求文档和功能点计数
6. 前瞻性了解此文档如何直接指导开发、测试、维护工作，并最终进行度量分析
这一文档重结构不重形式（Word，在线Wiki，管理工具均可），实际上代表了整个研发团队对产品或项目需求结构的统一认识。
分享提纲
| 功能点第一步：用功能树表达需求边界与架构 | 功能树是一种由大及小地勾勒系统功能边界的方法。 在此阶段，会在宏观上，借助子系统和模块的识别来避免大片功能的缺失。 为了便于一线人员理解，此处将暂时不涉及“功能点”的定义、分类等学术问题，而只使用大家熟悉的一线场景和术语。 现场演练1：用WORD列出产品的子系统与模块 现场企业人员会首先使用一张大白纸尝试描述产品需求的大结构，即上述知识点中子系统和模块的级别。 在讨论、分析、问答并达成一致后，形成Word文档结构。 此处将完成功能树前两个级别的表达： l 功能树全貌 功能树第一级：子系统（反应用户关系的场景） 功能树第二级：模块（反应数据关系的场景） 功能树第三极：业务数据（用户可以理解并识别的业务数据，ILF/EIF前身） 功能树第四级：业务操作（用户可以理解并识别的业务操作，EI/EO/EQ前身） |
| 功能点第二步：列出功能点计数项 | 功能点计数项包括文件（ILF，EIF，可理解为业务实体或业务数据），交易（EI，EO，EQ，可理解为用例）两种。 在此阶段，会在微观上，借助精益需求建模方法（一种由UML的ER图和User Case图演进产生的新图形）。功能树是一种由大及小地勾勒系统功能边界的方法，可以有效避免这种情况。 现场演练2：用ER图分析出产品中的实体（ILF和EIF，即业务数据） 现场企业人员会使用ER图列出业务数据，并利用其关系形成精益的（不多不少的）业务数据集合。 注：这些实体（业务数据）未来将演化为功能点中的ILF和EIF，且对应关系为1：1，但现在尚不需要对其进行深入了解。 现场演练：用精益需求建模法发现用例（将演化为EI/EO/EQ，即业务操作） 现场企业人员会使用用例图（扩展四色图+状态图中的某些元素）绘制单个模块内部的用例。 注：这些用例未来将演化为功能点中的EI，EO，EQ，且对应关系为1：1；但现在上不需要对其进行深入了解。 现场演练3：将子系统/模块/实体/用例表达为树状结构 现场企业人员会使用Word的目录，将练习1～3中发现的不同级别的需求要素，表达为一个统一的四级树状结构。 此处重点是功能树三、四两个级别的表达： l 功能树全貌 功能树第一级：子系统（反应用户关系的场景） 功能树第二级：模块（反应数据关系的场景） 功能树第三极：业务数据（用户可以理解并识别的业务数据，ILF/EIF前身） 功能树第四级：业务操作（用户可以理解并识别的业务操作，EI/EO/EQ前身） |
| 功能点第三步：功能点基本定义 | 在功能树中识别并判断功能点的类型。 l 功能点元素 ILF内部逻辑文件 EIF外部接口文件 EI外部输入 EQ外部查询 EO外部输出 现场演练：从功能树中识别功能点（1） 识别基本的ILF，EIF，EI，EO，EQ |
| 功能点第四步：功能点计数常见问题 | 学习并避免功能点计数中常见的多估和漏估情况。 l 容易漏估的功能点 隐含操作 查看所有 查看详情 删除 小练习1：容易漏估的功能点 l 容易多估的功能点 数据字段 编码数据 小练习2：容易多估的功能点 l 功能点快速识别口诀 现场演练：从功能树中识别功能点——检查漏估和多估（2） 识别可能漏估的的ILF，EIF，EI，EO，EQ |
| 功能点第五步：功能点复杂度与复杂度调整因子 | 了解IFPUG对复杂度、调整因子的设计与局限。 l 复杂度（不建议应用的实践） 文件复制度因子：RETs 操作复杂度因子：FTRs, DETs 复杂度对应表 l IFPUG复杂度调整因子（不建议应用的实践） |
| 功能点第六步：应用调整因子 | 了解IFPUG对复杂度、调整因子的设计与局限；了解现在应用最广的韩国政府的调整因子。 l IFPUG的14个应用调整因子（不建议应用的实践） l 韩国政府的调整因子（推荐） 早期/快速功能点：NESMA快速功能点方法 学习以更快速但精度可接受的北欧快速功能点方法。 l “估计的功能点”方法 Estimated Function Point l “指示性的功能点”方法 Indicative Function Point 注：国际标准中的4个功能点体系对第2～5步的定义都是相同或及其接近的，但由于第5～6步占据了80%以上的工作量而效果却不明显，因此NESMA给出了一个跳过5～6步但又保持相当高精度的方法；因此可以认为本培训主要是基于NESMA方法的。 |
| 功能点第七步：从功能点到工作量，工期 | l 工作量估算 “功能点耗时率” 工期估算 COCOMOII模型 现场演练4：估算一个实际的项目的功能点规模，并预测其工作量、工期 注意：视企业在第一阶段后实践的情况，此练习很可能只有部分团队能完成。 本阶段的现场实践活动 除上述已经分阶段描述的“现场演练”外，还包括： 工作文档指导：团队文档点评与指导 讲师会对个别团队以往需求进行点评，并给出未来需要改进和调整的，以便团队在下一阶段咨询到来之前完成文档改造工作。 现场展示：使用火星人自动计数功能点 讲师会讲授如何把项目的Word文档导入火星人，自动计数功能点数量。 |
京ICP备2022035414号-1
