序言

人生 = [思维方式(-100-100)] 乘以 [热情(0-100)] 乘以 [能力(0-100)]
深刻思考直至清晰看见！—>>思维的沙盘推演
如何掌控：凡事预则立，不预则废！
正确思维方式：主动良性的沟通，认真充分的需求分析，遵照项目过程规范，团队士气氛围
重视：项目的沟通，需求分析
用别人玩乐的时间学一点：文史哲，生活做到事事洞达
需求分析是行动的指导思想和革命纲领。
两点之间最快的往往不是走直线。
文学能力强和需求分析相辅相成。
平庸的企业和平常的人才不需要哲学。
有人的地方就有损益，做任何事情都有人顶你，有人损你。
如果忽略人的因素，只顾埋头做事，十有八九是做不成的。
处理四类人：
1.针对关键玩家：业绩体现，地位稳固提升 切忌让对方责任上升，全力变小，业绩下降

第一章

需求分析技能：
掌握理论知识：软件工程&需求工程
使用一套方法(四部曲)：获取，分析，表述，确认
注意两个关键词：用户导向，情境思维

软件工程过程：
1.需求开发和管理
2设计和开发
3.集成
4.测试
5.评审
6.项目决策
7.交付验收

第二章

需求工程主要分两大块：
需求的开发(包括：需求采集，需求分析，需求表述，需求确认)：初始阶段做的事情
需求的管理(包括：需求的跟踪，需求变更的控制)：贯穿项目全过程

需求分析大逻辑：
1.思想上高度重死
2.观察人缘关系，找出关键玩家
3.重点迎合关键玩家的预期，兼顾普通玩家
4.影响并带动关键玩家一起深入思考，清晰“看见”系统实现后场景

第三章

需求采集阶段：

1.己方的热身和准备：
因为需求来自客户的，所以必须保证客户参与需求分析的过程中，即使系统已经很成熟了。
准备：认真阅读招标书，投标书，合同（了解背景，方便和客户方展开话题）

假设公司有类似软件或项目，我们可以熟悉一下，提取出来需求要点
获取客户和客户所需系统的使用背景资料(该系统是给客户那个部门使用，该系统和其他现有系统或者其他供应商系统有没有什么关系)
此外准备好客户可能的提问的问题清单
制定准备访谈计划
多渠道掌握客户方干系人情况(通过客户经理，售前支持，直属领导，前任项目经理等)

需求访谈小逻辑：
1.现状：目前是怎样的做法？
2.问题：目前的做法存在哪些问题，可能会暴露哪些问题？
3.问题的业务背景：
.外因（市场环境，竞争态势，客户需求变化等）
.内因（职能改变，效率提升，管理要求等）

4.解决方案：针对问题，是否已经确定了初步的解决方案？如果是，可进一步探讨方案的可行性(问题解决+代价合理)；如不是，先探讨总体方案

2.与客户方的互动
确定客户方需求总代表(联络人，协调客户内部，平衡需求，代表客户确认需求等，可以由客户方项目经理兼任，但一定要是前一章所说的“关键玩家”)-—知道谁说了算，有签字拍板的权利
与客户方需求总代表(可以由项目经理兼任)初步一对一交流，沟通情况，建立信任。
认可访谈计划（访谈时间，访谈内容，参加人员）
准备访谈环境设别（会议室，投影仪，白板等）
按计划推荐访谈进程
如果导致对方不信任，不信任都是由细节导致的，最后需求验收可能就麻烦了

总结：
直接采集到的需求往往是比较粗线条的，零散的，可能还是自相矛盾的，还不足以依照构建系统
需求分析才是将采集到的需求整理，细化，规范到可以系统性实现的关键过程
需求分析与需求采集并不是完全割裂的过程，在需求分析中遇到问题时，仍需要折回需求采集过程

需求本身是以用户为导向的：识别用户，识别系统边界开始
怎么做？
先把整个系统看作一个“黑盒”，识别出哪些外部系统，用户需要和本系统交互，用“角色”概念将用户氛围几个大类

从用户的角度列出场景清单即功能清单（基于事件流的方式去编写，采用扩展循环工作流去应对特殊突发事件）
1.通过流程图和文字对场景进行描述。系统或者子系统子模块以“黑盒思维”处理流程图上的每一个节点
2.边界之外需交互的其他系统、人也看作一个黑盒节点
3.将最理想的情境作为主事件流首先描述
4.性能，界面流畅度实用度，数据一致性，前置条件，后置条件，优先级(非常重要：因为做项目资源受限)

业务视角，平铺直叙
描述人机交互 而非人机界面
描述用户意图 而非用户操作
是结构陈述 而非程序设计

完成了用例(功能)描述需求之后，几乎已经完成了大部分需求分析任务，但还有以下地方可以改进优化：接口需求(用户接口和技术接口)、质量需求、管理需求、设计和实现约束需求。

3.用户接口分析：
移动端体验重要，所以用户接口重要
考虑以下：对UI的展示信息，人机交互过程，界面快照，界面展示关键数据，界面能做什么

4.技术接口：
接口 = 技术 + 格式 + 交互机制
步骤一：交互机制设计（时机:联机接口或批处理接口；发起:谁发起、是否需要回调、何时发起、发起频度如何；返回：同步还是异步；错误应对：重试、对账、反交易）
步骤二：接口技术选择（技术：报文或者Remoting or Json等；报文：二进制 or 文本 or xml；有无约束条件：性能要求，技术限制）
步骤三：接口格式定义（编程语言，通信协议）

5.质量需求分析
我们通过场景分析，识别关键质量需求，描述关键质量需求

质量需求具体步骤：

识别关键威胁(使用频率、密集程度等场景，说明响应时间、速度等要求)，
分析它的影响，
分析它出现的概率，
确保关键质量需求

具体来说：
5.1传输安全性
银行web端通过采用SSL密码管道保证信息传输安全
5.2操作用户安全控制
对用户进行权限控制，登陆密码验证
密码设计具有复杂度，8位以上(数字+字母+特殊字符组合)，密码每三个月强制修改，新密码不能与最近5次一样
用户登录配合验证码
初始密码设置存活时间，首次登陆强制修改密码
对用户的每一个操作都有日志记录，操作用时记录
5.3系统处理容量
业务处理能力：当天业务量>=5000笔／天
峰值业务处理能力：>=2000笔／小时
存储容量约16G
5.4系统回应时间要求
报文进入系统平均处理时间5秒
金管局用户登录平均时间小于10秒，参与行用户登录时间小于30秒
日终处理时间：小于20分钟

6.需求确认：
6.1.内部确认
关键开发成员完全理解
6.2.客户方确认
客户方干系人对需求充分理解(需求写的过程，对方完全参与进来)，无异议

一旦确认了，后期改的话就比较慎重了

补充：需求分析不是一个简单的工作环节，而是一种思维方式。将梦想变成理想，讲理想变成现实的切实指导纲领，所以需求分析很重要。

样板

需求分析书模版示例图：
1.前言／背景
a>目的
b>范围
c>术语定义、缩写词、略词
d>参考资料

2.需求概述
a>用例模型（参与者和功能清单）
b>限制和假设

3.详细需求
a>用例描述（功能）
可参照前面的模版
b>外部接口描述
1.用户界面
11.硬件接口
111.软件接口
1111.通讯接口
c>质量需求
1.性能
2.易用性
3.安全性
4.高可用性
….
d>管理需求
1.权限控制
2.运行时许
3.业务控制
4.管理报表
….
e>维护需求
1.运行监控
2.数据迁移
3.日志
4.备份
….