
上图表示在沟通过程中的信息误解
很多时候都是这样,用户原始需求和实际交付不是一回事儿,钱也花了,时间也到了, 质量上勉强修修补补, 附带一些说明书来各种限制来勉强交付。很少一部分客户,对结果非常满意
需求分析的困难性
- 有几种原因使需求分析变得困难
- 客户说不清楚需求;
- 需求自身经常变动;
- 分析人员或客户理解有误。
- “据历史记载,没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。”
需求捕获
捕获是需求分析的基础,巧妇难为无米之炊
Plans are nothing; planning is everything. — Dwight D.Eisenhower
- 开发是把人们的期望转化成一种能够满足其期望的产品的过程。强调过程的重要性
- 产品什么都不是,而开发的过程就是一切。
- 发现什么都不是,而发现过程(探索过程)就是一切。
那么需求捕获到底是什么?
- 一个过程
- 一个发现的过程
- 一个试图发现的过程
- 一个试图发现期望的过程
- 一个试图发现对新产品的期望的过程
- 一个试图发现客户对新产品的期望的过程
需求捕获方法
- 用户主诉
- 问卷调查
- 头脑风暴会议
- 超越用户
- 用户的反复无常
脑图工具协助捕获
需求分析前的工作
-
1)确定涉众和用户类型(命名、简要描述、特征、能力);
- 比如一卡通的上线与售票员的失业问题,是否可以转岗或其他应对措施
- 如果项目上线,他们一定会阻挠或者消极应对
- 一定要处理好相关利益相关者的问题
-
2)确定涉众代表(命名、简要描述、责任、参与);
-
3)项目中加入涉众代表(访谈、问卷、评审、角色扮演);
-
4)创建共同的构想(问题定义、系统范围、用户目标、非功能 需求前景文档);
-
5)采用传统的需求捕获技术对需求进行捕获;
-
6)组建需求分析队伍(少量、有问题域知识)
需求分析时
- 在合同中一定要说清楚“做什么”和“不做什么”
- 尽可能地分析清楚哪些是稳定的需求,哪些是易变的需求。以便在进行系统设计时,将软件的核心建筑在稳定的需求上,否则将会吃尽苦头
- 必须满足和协调涉众的利益
有效的需求分析员
- 大多数需求分析人员都是从开发人员成长起来的
- 从数字世界到现实世界
- 教育不同,训练不同
- 一个有效的需求分析员需要在需求分析过程中和用户建立真正的伙伴关系
- 能够在错综复杂的现象中发现问题背后的问题(从表象到本质)
- 在陌生的领域内能学得更快(比如之前是汽车, 后来到医疗)
- 有效的需求分析员必须用自己的智慧、行动和真诚去发现需求、挖掘需求
- 要用共同的语言和用户进行交流
- 好的方法和习惯能够让需求分析更加有效
建立真正的伙伴关系
- 技术视为市场服务的
- 转变态度,具有服务意识知道用户的业务目标是什么吗? 知道用户三年甚至更久的发展方针是什么吗? 知道我们的软件能够给用户带来哪些利益吗? 用户把我们当作朋友吗?
- 培养人际关系真诚的面对客户,用真心换取真心,尽力和用户成为朋友
- 展开商业想象大胆寻求满足用户需求的更佳 途径。象用户一样看待事物远远不够,要争取看得更清晰,即“超越用户”
发现问题背后的问题
- 如果需求分析只是停留在表面的问题,而不能够发现用户真正关心的问题,很难相信开发出来的软件能够让用户发自内心的满意
- 用户的要求往往是开发完成某个功能(如人事管理,财务等)的软件,用来解决目前存在的问题。但是软件真正能够给用户创造的价值是什么,这是每一个需求分析员必需思考的问题
- 饭店顾客的需求,客户真的是来吃饭的,还是来找人聊天陪伴的
用共同的语言进行交流
- 应该努力的去熟悉用户的行业,学习用户使用的术语,标准,以便能够准确的理解用户
- 应该尽量不使用IT行业的术语,而采用浅显易懂的口头语言来解释IT行业中高深莫测的术语,以便用户能够很好的理解
用例设计
- 用例反映需求
- 用例联结上下游
- 粒度过大:对设计者无用,不能提供足够的信息
- 粒度过小:客户无法理解专业术语,无法通过良好的迭代过程获取稳 定和完整的需求
- 用例采用半形式化描述以满足双方的要求
- 用例开发团队
用例分析误区
- 用例分析技术包括了整个需求过程
- 只是一个需求分析技术,是在传统的需求捕获技术的基础上使用的,并无法替代这些技术;
- 用例分析技术是分解技术
- 其实用例分析技术是一种合成技术,将在需求捕获中收集而来的零散的特性合成为用例
适合做需求分析的人
- 乐于学习的人
- 善于学习的人
- 具有快速学习能力的人
- 能站在用户立场上思考的人
- 不以自我为中心的人
- 性格不同的人组成的小而平衡的团队
需求工程
把所有与需求直接相关的活动通称为需求工程