第13章集成化流程之项目研发过程 - 集成化研发管理平台登录页面.doc

第4章 集成化流程之项目研发过程 4.1 项目需求工程 把所有与需求直接相关的活动通称为需求工程。开展需求工程的目的是使开发方和委托方（客户或本公司领导）对项目需求有共同、清晰的理解，并依据双方确认的需求开展后续开发工作（如设计、编程、测试等）。 需求工程中的活动可分为两大类：需求开发和需求管理，细分为6个活动，如图4-1-0所示。项目需求工程的主要工作成果和责任人见表4-1-0。 需求开发的主要活动： 客户需求调研：通过各种途径获取客户（购买者、使用者和影响者）的原始需求。 客户需求分析：对客户原始需求进行分析，消除错误，补充细节。 项目需求定义：在需求调查和需求分析的基础之上，按照指定的格式撰写需求文档，即《需求规格说明书》，项目团队依据《需求规格说明书》开展后续工作（设计、开发、测试等）。 需求管理的主要活动： 项目需求评审：开发方和客户共同评审需求文档，双方达成共识后作出书面承诺。 项目需求跟踪：比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪表”，确保项目依据需求文档进行开发。 需求变更控制：依据变更控制流程（申请－审批—执行）来处理需求的变更，防止需求变更失去控制而导致项目发生混乱。 图Internet上搜查相关资料。 需求分析员在调研过程中随时填写“客户需求信息”，参考格式如表4-1-1所示。 客户/联系人 客户原始需求（标题和内容） 需求分析 表4-1-1 客户需求信息 需求分析员整理所有客户需求信息，归纳与总结共性的需求，为撰写详细的《需求规格说明书》作准备。调研过程中获取的需求信息可以作为《需求规格说明书》的附件。 MainSoft对应功能： （1）功能菜单：MainSoft营销客服系统→客户问题需求管理→我创建的。 （2）拥有写权限的人员均可以填写“客户问题需求”。详见MainSoft“客户问题需求管理”功能。 4.1.2 客户需求分析 很多时候客户说不清楚需求、说错需求或者提出一些无法实现的需求。如果开发方不加思考地完全听从客户，开发过程中将不断发生需求变更，不断地推倒重做，不仅害了本公司，而且耽搁了客户。 需求分析是对各种途径获取的客户需求原始信息进行分析，消除错误，补充细节等。确保最终的需求文档正确地反映客户的真实意图。对客户需求的分析结果直接填写在表4-1-1的客户需求信息中。 常见的需求分析方法有“问答分析法”和“建模分析法”两类。 问答分析最重要的问题是：“是什么”和“为什么”。每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。 对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。软件工程教科书中常见的建模分析方法有“结构化分析法”和“面向对象分析法”。 现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。 世上不存在一个包罗万象的图用以完整地描述需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。 MainSoft对应功能： （1）功能菜单：MainSoft营销客服系统→客户问题需求管理→我受理的。 （2）受理人可以填写“受理分析说明”。详见MainSoft“客户问题需求管理”功能。 4.1.3 项目需求定义 需求分析员根据需求调查和需求分析的结果，进一步定义准确无误的需求，撰写《需求规格说明书》，模板见表4-1-2。 良好的需求文档具备如下特征： 一、正确 需求文档应当正确地反映客户的真实意图，“正确”是需求文档最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和客户自己都不明白究竟“想要什么”和“不要什么”。 为了确保需求是正确的，开发方和客户方应当对需求文档进行评审。 二、清楚 需求表达正确还不够，因为正确的需求不见得容易看得明白。“清楚”是在正确的基础上使文档“易读易懂”。 清楚的相反意思是“难读”、“难理解”。人们可以采用反问的方式来判断需求文档是否清楚： （1）文档的结构、段落是否乱七八糟？上下文是否不连贯？ （2）文档的语句是否含糊其词、啰里啰嗦？ （3）看了半天是否还不明白需求究竟是什么？ 三、无二义性 “无二义性”是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不