开发人员如何理解需求分析.pdfVIP

开发人员如何理解需求分析 首先，最重要的一个问题就是，为什么要做需求分析，或者说需求分析的意义是什么 ?每个人对这 个问题可能都会有不同的体会。我的看法是，需求分析的意义在于准确无歧义地表达项目需要交付 的产品，并且获得需求方的认可，从而为整个项目建立一个基准。指望需求不变化是几乎不可能的 ，不管是开发者还是需求方都有可能随着项目的进展提出变更的需求，所以需求分析 (及变更管理 ) 的目标不是定义一个不会再改变的需求，而是从开发开始到项目结束，双方对于需求 (包括变更 后的 ) 的认知都是一致的。 这样说可能有点抽象，我们可以来拿一个例子进行说明。 比如项目初期形成的需求分析中有这样一段描述： 应用系统能够根据预先定义的个性化模板，定期“ 自动对每条用户的数据生成对应的 pdf 报告文件，并发送到在用户信息中预先设定好的电子邮箱中。 ” 针对这条需求，开发人员找到了一个自动生成 pdf 文件的插件，这个插件会读取一个 xml模板，然后 根据传入的数据生成 pdf 文件。一段时间后，功能做好了，用户的项目经理看了生成的 pdf 觉得不错 ，项目进展顺利。 可是，到了阶段验收的时候，用户组织了一段时间的试用，对这个功能大家都觉得不满意，因为普 通用户根本不会编辑 xml 模板，觉得很麻烦，而且容易出现格式错误。这时，用户提出应该提供一个 通用户根本不会编辑 xml 模板，觉得很麻烦，而且容易出现格式错误。这时，用户提出应该提供一个 编辑界面，让用户以所见即所得的方式来编辑模板，这也是很自然的。 问题就来了：开发人员认为这是对需求的变更，需求里没有提到要做这么个界面嘛 !这样会导致项目 的进度、预算都需要调整，也许有人还会要求用户增加开发费用。而用户会认为这是开发的工作没 做好，怎么能做个功能出来让用户自己编辑 xml 呢? 一百个用户里也难找出一个用户知道 xml 是啥东西 ，更别说编辑它了。所以双方就会在这个问题上纠缠不清。而这只是整个项目中很小的一块需求， 一叶而知秋，其他部分的问题也肯定少不了。 这里面到底是用户不讲理，还是开发人员偷懒 ?其实都不是，我觉得问题出在需求定义得不严谨。 如果开发人员在需求分析过程中和用户交流过模板的格式问题，用户会在第一时间明确模板编辑的 需求，这样写出来的需求可能会是这样的： 应用系统能够提供“ pdf 模板编辑功能，让用户以所见即 所得的方式自行定义个性化模板，根据该模板定期自动对每条用户的数据生成对应的 pdf 报告文件， 并发送到在用户信息中预先设定好的电子邮箱中。 ”这样的需求就更严谨，事后出现争议的问题就减 少了。当然，你还可以在里面找出一些不够严谨的地方，比如 定期“ ”是什么概念，固定一周一次还 是一月一次，还是用户可以自定义，或者是提供几个标准选项让用户自选 ?所有这些不明确的定义 ，都是需求分析过程中要重视的。除非你对于它的不确定性及其可能带来的最坏结果有充分的把握 ，否则忽略它就会在未来给项目带来麻烦。 小结一下我的想法：在项目中，用户的字典里是单证、收入、报表、审核等，而开发人员的字典里 则是键值、索引、按钮、事件这些，而需求分析就像是一位翻译，把用户的语言和开发人员的语言 融合到一起，让双方准确理解对方的意思，从而在开始开发工作之前让双方都真正明白对方的思路 。 对于需求分析中关键的因素，我自己的体会主要有如下三点： 一、深刻理解业务 需求分析人员需要对用户的业务有非常深刻的理解。所谓非常深刻的理解，就是说你能和用户的管 理层就他们的业务问题谈笑风生。如果做金融产品不懂风险管控，做论坛不懂 SEO ，做人事系统不 懂组织行为，如何能对业务有深刻的理解呢 ? 有人看到这里要说了，用户给我讲明白需要