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