扫描二维码，关注希赛网站
专注在线职业教育23年
下载APP
小程序
>>>>>>>>>>点击进入2016年系统分析师考试网络课堂
>>>>>>>>>>点击进入2016年系统分析师考试大纲和教程
表需求表单
需求管理一直是用户和开发人员争论的焦点，从CMM的角度来说，用户的需求中既有技术层面的，也有非技术层面的，即便是技术层面的需求，也并非面面俱到都要开发。例如，一些技术上不可行或资源要求不能满足的需求就必须剔除，只有适合软件开发的需求才会被最终制作成规格说明，但是这些就一定要和用户之间做好沟通，让他们理解为什么行与不行。
在通常的维护过程中，有一系列的变更请求或问题报告要求需要满足，这些变更请求和问题报告既有可能单个提出的，也有可能是为了分析实现之便综合成相互联系的一组提出的。对于各种不同情况，我们都按CMM的要求，把它们规范化、文档化，控制好过程中的每个环节，保证它们被所有的受影响组通过，保证软件维护计划和活动与它们一致，并且对它们来说这个过程是可追踪的。为了满足达到预期的效果，在执行中，我综合了CMM需求管理的要求制定了如下步骤（具体的项目操作应根据实际项目的需要进行）:
1.需求分析。首先，确认此需求适用的范围，达到的目标;其次，明确申请方参与需求调研活动的职责（如有无决策权、所需配合的活动、所需提供的资源等）;第三，分辨技术与非技术需求;第四，收集相关技术需求;第五，分析申请方业务工作流程;第六，制作需求说明文档，在每个模块分析时均注上标号，便于其后需求变更的跟踪及修改;第七，对本次需求活动拟一个时间进度表。
2.需求评审。根据需求单上所涉及的部门，确定需求评审小组成员要求，明确评审方式，确定评审内容。如对于给定的需求文档记录是否完整及有无遗漏项，文字说明是否前后一致、清晰适当，变更依据是否充分，是否有正常的记录，以及功能的可测试性等。
3.交付验收。在交付给申请人验收时，需附上:功能分析文档、需求规格说明书、需求验收文档。申请人对确定的需求无疑义，在验收文档上签字，若申请人提出相应的变更，则为变更做好记录，修改后的变更依然应通过评审才能交付，申请方所签收的需求作为系统的需求基线确立下来。
4.需求调研。严格依照拟定的需求管理计划进行项目的实际需求调研活动，在活动中记录与各部门进行交流的内容，记录各阶段产生的变更项、变更原因，按预先规定的书面策略进行双方活动的制约。
整体活动图如图所示。
图需求管理的整体过程
在需求的实施方面，我们也加强了过程的跟踪和监控。在CMM实行初期，由于工作流程的改变，在每次项目启动的初期，开发人员要花很大的一部分时间写文档资料，工作压力比以前大了很多，导致一段时间内效率降低，当大家逐渐习惯后，感觉文档是开发人员劳动成果最好的记录，工作比以前清晰，规范的文档减少了对个人的依赖，使软件开发过程的上下环节紧密衔接。而且我们还能根据所有文档内容对每个过程进行检查，不仅提高了工作效率，也规范了管理。
在进度控制方面，我们首先制定了全面的开发计划和进度计划，要求开发人员填写详细的工作计划和实际工作量周报，并根据此绘制项目进度图，随时了解项目进展，并根据项目的进展情况适当调配人手，整个项目比计划略早完成，具体实施的详细步骤要视实际中项目大小而定。
在质量保证方面，我们组织几个骨干人员成立了专门的SQA小组，根据CMM管理规范来检查软件开发过程标准，规程的合理性，文档的电子化，对项目的监督“对事不对人”并定期公布监督结果。
在版本控制方面，通过项目数据库，要求开发人员在每次开发所修改的最终版本上备注版本号和存放路径，以便下一个变更的时候能够拿到最新的一个版本的修改。由于引进了CMM，加强软件维护过程管理，直接解决了原来开发团队所遇到的一些难以处理的问题。项目数据库的建立使维护人员只需要读懂设计文档，和读懂程序比起来，既节约了大量的时间，也要容易得多。在这样的基础上做出修改后出现的问题也越来越少，使软件更加可靠，且能完全满足软件开发人员的需求。
相关链接：
