传统IT行业里面，会有一个需求分析师的角色。做的工作就是：
1.对甲乙双方的需求访谈；
2.制定《需求规格说明书》；
3.开需求评审会最终需求确认；
4.追着甲乙双方业务部门和技术部门签字；
5.系统开发、测试以及上线后监督功能点是否满足。
自此，一个良好的需求分析师对于上述流程执行到位，他/她的职责就完美了。
如何做到1/2/3/4/5点不在今天的讨论范围之内。
我们今天讨论的是，如何在需求分析工作中，精细的收集功能点，然后针对功能点评估实现所需工作量。收集功能点需要对目标业务的理解程度超越了解的程度，一般是按照经验以及对开发商的细致需求访谈中，确认实体维护、实体交互、流程编排等单元。这是一个业务和技术知识结合考虑的一个场景，过多强调了知识的积累。那么有没有一个捷径，能够在需求分析的工作基础上，不需要过硬的业务知识，就可以向软件度量托怀送抱呢？
我们存量大约有X00个系统，每年的新增系统仅仅是个位数；然而每年的大大小小的软件需求却有Y千个，分散在几十个甲乙类系统中。而大量的需求都是新增和修改，所以参考系统的架构基线就可以比对软件需求的估算度量。因为大多数情况下，涉及到需求的变化都可以定义为“内部逻辑”、“外部接口”、“外部输入”、“外部输出”、“外部查询”（例如IFPUG法）上述实体的变更，结合整个需求的其他一些外部因素作为权重因子，按照计算公式得出工作量评估。
如果将管理需求的系统及管理基线的系统结合软件度量有机的对接，就能展示在需求实施过程中，具体需求分解程度以及需求完成程度，最后可以量化整个需求实施的人工和效率。如果结合扫描代码规范和代码质量的落地程度，还可以挂接实施人员的绩效评估。
然而收集软件基线是一个很苦痛的事情，大量的开发周期管理在没有精细化的情况下，软件功能点仅仅记录在代码中，或者在不立即更新的文档里。我们对于需求功能条目化的渴求是比较明显的。所以不论采取什么措施，将非文档化的需求功能点，按照业务功能菜单：“系统/模块/功能/操作”维护进入软件基线，并对基线的变更有常态化管理，就能迎接软件度量的新时代。
PMP有个术语叫组织过程资产，是把无形资产转为有形资产。看来管理这门课，都是软哒哒流来流去一通百通放之四海皆准怎么说都能说对的事情。
网友评论