具体业务： 1、选择关联对应的差旅申请单； 2、填写此次出差费用； 3、点击提交单据； 4、打印封面，贴发票，给初审岗扫描；
需求八要素
异常及反向处理： 1、发起报销时，发现选错出差申请单费用类型，且出差申请单已经终 审； 2、没有部门预算； 3、……………………
需求分析
提炼、分析和仔细审查已经获取到的需求，以确保所有的用户都明白其含 义并找出其中的错误、遗漏或不足之处。关键在于对问题的研究和理解。
问卷调查
缺乏灵活性； 不如面对面沟通直接，无法获取更隐性的 需求，用户也没机会立即澄清对问题有含 糊或错误的回答； 不利于对问题进行展开的回答，无法了解 一些细节； 回答者的数量往往比预期的要少； 花费在原型上的时间很多，使需求获取的 速度大大降低；
原型演示
给用户一个直观的演示，所见即所得； 用户体验好，交互性强； 对用户界面提供了早期的评审；
如何做出一个好需求
————需求管理经验分享
李昌明 2ห้องสมุดไป่ตู้15年1月29日
现象1：从前，有一个需求……
用户：我想要一个秋 千！
产品经理：放心，绝 对舒适！
项目经理：我能想象 到你要的是什么！
系统分析师：好了， 我知道怎么设计了！
开发人员：秋千啊？ 很简单，我知道了！
结果，项目的文档
产品安装是这样的
用户为项目开发的投 资
用户访谈
1、准备访谈；2、主持访谈；3、访谈后续工作（吸收，理解，未明确问题跟进，访谈备忘录）
问卷调查
1、确定问题及类型；2、编写问题；3、设计问卷格式；4、收集整理；
场景模拟
1、资料准备；2、制作原型；3、思维引导；
小组会议
1、选择与会人员；2、准备会议主题；3、主持会议；4、专题讨论；
根据情况选择不同的需求收集方式
意外需求
用户要求范围外的功能或性能，但不实现也不影响其使用。如：使用拼音或 输入关键字可以快速带出相应的费用类型，进行选择；
需求工作是讲究方法的
包括创建和维护需求文档所必需的一切工作
需求收集
需求分析
需求文档
需求确认
需求开发
需求基线
需求变更
风险管理
需求跟踪
需求管理
需求收集
是一个确定和理解不同的用户需求的过程。
可追溯性
文档中需求与系统需求的双向可追踪性；
引用文件
1、制度、规范；2、公司发文；3、其他参考文档；
避免长篇大论式的文档描述
文不如字，字不如表，表不如图。
…………
需求确认
对需求文档进行评审和确认的过程。
需求评审
1、分层次评审；2、正式与非正式评审结合；3、事后跟踪工作；
需求测试
1、准备“概念”测试用户；2、基于“概念”测试用例模拟需求测试；
这个故事告诉我们你的付出不是所有人都能接受……
vanK e THANKS
让 建 筑 赞 美 生 命
后期的技术
其实用户真正想要的
现象2：”需求开发”和”技术开发”，谁的时间长？
vs
需求开发 技术开发
什么是需求？
总结为两个必须：1、系统必须完成的事；2、系统必须具备的品质。
功能
行为
系统
性能
规则
从需求范围看它的层次
从目标到具体，从整体到局部，从概念到细节
业务需求
对系统体系化、流程化的需求，如：费用管控、成本控制等；
需求基线
1. 经评审批准，需求文档就定义了开发工作的需求基线。它是用 户和开发人员之间的约定； 2. 开发人员可以通过基线区分“旧需求”和“新需求”；
3. 通过基线，识别需求变更。
需求变更
需求变更是不可避免的，并不是说不应该做避免的工作，恰恰相反，在开 发前尽量减少变更，以将其带来的风险降到最低。
用户需求
功能需求
目的： 确保需求被开发出来，没有漏项；
了解当前计划执行情况；
减少核心人员变动带来的风险； 在增、删、改需求时，可以确保不忽略每个收到影响的因素。
段子：你的付出不是所有人都能接受
沙僧是个细心的人！这天，他整理大师兄的内裤， 发现有个洞，然后就耐心的缝了起来；第二天发现又有 个洞，于是又补了起来；第三天依旧还是有个洞，正当 他拿起针线时，猴哥过来，一脚踹飞了沙僧。 你 TM 把 洞缝上，我尾巴搁哪儿？搁哪儿？搁哪儿？！是不是欠， 是不是欠！
用户需求的不断增加； 模棱两可的需求； 不必要的特性。如：费控系统的填单界面，技术人员开发了限制附件数量只能在99内； 需求说明文档过于简单；
不准确的估算。如：需求交付时间未考虑测试时间就知会用户，其认为是一种承诺；
需求跟踪
始终保持原始需求与实际系统实现相符，避免遗漏和变样。
正向跟踪 反向跟踪
用户需求
具有业务场景的具体需求，如：预算调整、合同变更等；
系统需求
系统的功能性需求，如：可以批量处理、可以关联单据等；
从用户满意度看它的层次
最大限度地提升用户的满意度
常规需求
用户认为系统应该做到的功能或性能。如：预算执行后要进行反写；
期望需求
用户想当然认为系统应该具备的功能或性能，但并不能正确描述自己想要得到 的这些功能或性能需求。如：预算跨年；
优 用户访谈 势 劣 势
用户较忙时，时间难以安排； 面谈时信息量大，记录较为困难； 需要较强的沟通技巧；
具有较好的灵活性，有较广的应用范围； 采用开放式和封闭式问题设计； 面对面沟通，通过用户表情、肢体语言等 动作来获取一些更隐性的信息； 短时间内以较低的代价从大量的回答中收 集数据； 允许匿名，用户可能会提供真实信息； 结果比较好整理和统计；
增加需求
质量
范围
修改需求
减少需求
需求风险管理
希望能够“掌控”风险，一旦发生能够按照预案进行应对。
日常需求开发中存在风险的做法： 需求收集阶段，没有考虑到足够的用户，导致需求是片面和不完整的。如：只考虑到了执行层
面的人员，忽略了管理层的想法；
忽略了用户分类。如：一线用户、共享用户、出纳对于共享任务平台的要求都有各自的特点；
绘制系统与系统外 的界限和接口关系
创建用户界面原型
分析需求的可行性
确定需求的优先级
寻找意外需求
描述字段属性
建立需求模型
需求文档
目的是使用户和开发人员对需求有一个共同的理解，使之成为整个开发工 作的基础，也是需求的基线。
范围
1、文档用户和内容概述；2、需求范围；3、涉及部门及岗位；
需求
1、业务需求；2、功能需求；3、相应规则；
小组会议
收集需求的时间更快； 对于一些有歧义的问题、不清晰的需求， 十分有用；
要考虑多方的时间，会议的组织难度大； 对于会议的主持和把控需要技巧； 气氛很重要，要开放，言之有物；
合理的提问和引导出全面的需求并记录下来
需 求：差旅费报销 价 值：为一线员工提供差旅报销功能，便于………… 触 发：差旅申请单 前 提：有部门预算，审核通过的差旅申请…… 频 率：平均每天100单 关键情况：关联多张差旅申请单报销