如何做好需求.pptVIP

精品课件资料分享 SL出品 如何做好软件需求捕获? 一、 会面前做充分的准备 二、让客户打开话匣子 三、千万不要浪费客户的时间 四、搞清能正确回答问题的人 五、发挥原型的效力 六、充分利用需求确认会议 二、让客户打开话匣子 有一些人通常会问这样的问题：“你们的工作流程是什么样的？”，这种问题是非常经典的无效问题。 当你向客户提出问题的时候，你可以先进行换位思考，如果有人问你这个问题你该怎么回答呢？是不是很好回答呢？如果连你也觉得这个问题并不好回答时，就需要考虑换个问法了。 某些功能的猜想和假设，也一定要问客户，是不是根本就不需要 . 勇于否定自己，这样会减少不必要的开发工作，也会给客户留下你很尊重事实的良好印象。 四、搞清能正确回答问题的人 不同的问题需要问不同的人，需求中有很多是细小的操作级别的问题，也有很多是关乎全局的问题，这就要求一定要搞清楚什么问题去问什么人。 五、发挥原型的效力 原型对于提高客户对软件的认知程度有很好的效果，他能使客户对软件有一个直观的认识，面对原型，他们可以更好地提出他们的想法和意见，尤其对那些对软件缺乏认识的客户。 对原型的修改，再确认，最后得到稳定的原型，这些工作会让需求更稳定，减少很多实施工作中的反复修改工作或者返工。 需求确认会议通常由全体涉众（利益相关人）参加，这可是个确认需求的难得的机会，大家能聚在一起，这样的机会其实很难得，所以一定要珍惜。 六、充分利用需求确认会议 一定要先针对全局性的问题（与大家都相关的问题）进行交流，千万不要针对部分人感兴趣的问题讨论个没完没了，那样的话，不感兴趣的人会走开的，那样你再想征求与他们相关问题的意见时就找不到人了。 明确需求层次 重要，且与合同的制定，报价模式的制定密切相关 整体方案 情况1： 客户只是有个目标，希望通过供应商提供一套软件系统可以解决问题。 客户需要的是对于实现目标的解决方案，是个包括业务模型以及相应软件系统的整体方案。 需求包含两个部分的内容: 其一：业务建模； 其二：软件需求； 在这种情况下，同用户达成一致的首先是用户的业务模型。 其后，编写实现业务模型中软件任务的软件需求。 在没有完成业务模型的确认前，无法了解软件的规模，无法完成报价。 合同可以签署为两阶段合同. 阶段一：业务建模，采用时间－原料法进行报价； 阶段二：软件开发，采用固定价格法。 情况2：客户有目标，同时也有了业务领域的解决方案。 需要软件供应商提供的是一个可以完成业务模型中任务的软件。在这种情况下，客户明确了解要些什么功能，输入、输出、处理。 在需求的确认上会力求细致准确。在项目完成的验收时，验证软件是否完成了软件需求。 中间工作成果 业务领域的当前工作说明； 业务领域的当前问题； 目标、关键问题； 未来系统的构想； 后果和风险； 相关人员认可； 相关人员冲突协议； 需求优先级； 最终需求； 需求是否完备和必要； 工作方式 访谈： 用于高层了解目标、未来构想； 任务示范：了解业务领域的当前工作说明；业务领域的当前问题； 专题讨论会：相关人员冲突协议；需求优先级；关键问题；后果和风险；BPR的决定；最终需求；需求是否完备和必要； 问卷调查： 分析人员无法到场情况下可采用，了解初步需求。 需求编写 数据需求 数据需求： 描述进出系统的数据。 E/R 图： 优点：直接转化成数据库设计； 缺点：太专业，用户无法确认 数据字典： 优点：客户捕获大量细节，用户易理解； 缺点：编写工作量大； 虚拟界面： 优点：可直接从手工表单获得，用户易理解，完成部分界面的设计和确认； 缺点：容易过于的细化为界面设计。 功能需求 功能需求：记录用户如何进入系统对功能模块进行操作，输入、处理、输出。 总的用例图： 说明系统的范围，外部的接口，相关人员 用例的事件说明： 说明具体功能模块的人、机职责划分。 说明： 由于用例的事件流的说明中已经包含了设计层的需求， 故作为验证是否实现了业务领域的任务是很好的，同时也可以作为后期操作手册和测试用例的基础资料使用 但是过于的细化，不宜作为产品的介绍、给予客户验收的需求规格使用。 给予客户的需求规格可以使用细化些的总用例图（用例包＋功能列表） 功能细节：复杂功能的描述； 有特别算法；出错纠正；业务规则；报表； 特性需求 特性需求：客户业务处理中非常规的情况。 以及处理方式。 是集成测试和验收测试的一个重点。 同时，特性需求容易在一开始的需求导出时遗漏。 特性需求往往会产生一个新功能分支或特别的设计。故越早发现越好。 需求的变更管理 由于承办方（发现某个具体需求无