概述
1.获取干系人信息
2.调查与记录
3.整理需求信息
4.撰写需求说明书
5.确认需求
需求
设计
编码
单元测试
验收测试
维护
需求的三个层次
1)业务需求
2)用户需求
3)功能需求(软件必须实现的软件功能)和非功能需求(操作界面)
如何开展需求调研?
了解需求调研方法
座谈法:与用户交谈,向用户提出事先准备好的相关问题。
调查表法:将相关问题制成调查表,向用户群体发调查问卷。
观察法:参观用户的工作流程,观察用户的操作。
收集法:收集用户使用的表格,工作责任,工作规范。
收集同类相关产品的资料、技术资料、演示程序或软件程序。
情景分析:利用情景分析(描述当前一项业务怎么做,描述设想的系统中此项业务怎么做。)
可视化:结合情景分析,结合业务流程图、功能结构图、时序图等图形与客户进行讨论。
业务流程是有层次性的,这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。
首先,明确你要梳理的业务流程的范围——用大的粗略的关键节点,讲清楚这个业务流程范围中的故事,就是顶层业务流程 图。你的顶层业务流程图是业务全局故事的简单表达,但是请注意这里的业务全局不见得是公司整体的业务全局,而是你界定好的业务范围。比如,下图是餐厅的日 常运作流程图,若你界定的业务范围是面向顾客的点餐和结帐流程,那么这就是顶层业务流程图。但是若你界定的是整个餐厅的运作业务流程,那这显然还是一个子 集——并没有包含餐厅的采购、供应商管理、一级库存管理等工作。
1. 界定范围内的业务全局故事。2. 包含该范围内的关键节点。并且,当被质疑说某某环节怎么不存在时,自己要清楚它在下一层分解中应该被包含在那个关键节点中。比如,赠送10周年优惠券,应该会在结帐节点分解中出现。而打印分单,会在点菜节点中分解。而准备儿童座椅应该是接待入座环节。3. 顶层流程图分解出来的关键节点未必都会细化分解下去,生成二级以及三级的流程图。这要看该节点涉及到的“活动”以及“角色”是否复杂。
流程图的常用图示
流程图常用结构
金字塔方法
首先搞清楚对象(调研对象)与对象之间的关系,
理清对象的目标及和其它对象发生关系的目标。
其次理清对象内部的活动以及对象与对象之间的活动。
对活动进行整理,确定活动边界。
根据活动进行详细的需求调研。
五种提高
1.了解被调研对象的组织机构,了解每一个子对象中的关键人物,提高自己的观察能力。
2.了解用户的行业,学习用户使用的术语,标准,以便能够准确的理解用户的需求,提高自己的行业知识面。
3.需求调研中,学会尽量不使用IT行业术语,而采用浅显易懂的口头语言来解释IT行业中高深莫测的术语,以便用户能够很好的理解,提高自己的沟通交流能力。
4.提高自己的速记能力,文字表达能力以及归纳,能迅速的记录需求调研核心的问题,总结归纳之。
5.提高自己的总结能力,书写一份完整的、前后一致的、可追踪的需求报告。
步骤
1.倾听客户的心声
找一个安静的地方,以客户为主,面对面的沟通和交流,倾听客户的心声,
记录客户所说的一切,调研完后对所有的记录进行整理,形成文档,在下一次的调研开始对上次的总结进行确认。
2.整理客户的需求
调研主题
调研对象
调研人
调研时间
调研描述
3.引导客户的需求
许多客户有时候并不知道自己想要什么?有时候并不清楚自己缺少什么?所以就需要我们去引导客户的需求。
常用引导方法:
1)向客户讲述基本的计算机操作。
2)提示客户在全局中的地位以及作用。
3)向客户演示将要实施的系统的原型。
4)从软件开发中需求考虑的几个方面入手。
争取能够提出用户的兴奋需求,这样做出的软件才有生命力,
才能真正体现软件的价值。
4.编写用户需求说明书
需求分析员对收集到的所有需求信息进行分类整理,消除错误,归纳与总结共性的用户需求,然后形成文档,编写《用户需求说明书》。
《用户需求说明书》要和客户以及相关的行业专家进行共同评审。以前整理的需求记录可以作为附件整理在《用户需求说明书》之后。
用自然语言来表达用户需求,相对较粗略。
《产品需求说明书》则更多采用计算机语言和图形符号来刻画需求。
用户需求说明书模板
1)产品介绍
2)产品面向的用户群(用户特征,使用的好处)
3)功能需求(功能1,子功能1、2、3)
4)非功能需求(界面要求,软硬件要求,质量要求)
交谈注意事项
1.约好时间,切勿迟到或早退。注意礼节,尽可能获得用户的好感,并为下次打扰他们埋下伏笔。
2.事先了解用户的身份、背景,以便随机应变。
3.先了解宏观问题,再了解细节问题。
4.尽可能避免给用户添麻烦,但也不能怕给用户添麻烦而降低需求调研的力度。
5.尽可能听取多方的综合意见。
调研后整理
角色:部门、岗位或人
活动:做了什么事情
次序:做这些事情的次序如何
规则:什么情况下到什么事情