需求
起初神创造天地。地是空虚混沌,渊面黑暗;神的灵运行在水面上。神说:“要有光”,就有了光。神看光是好的,就把光暗分开了。神称光为昼,称暗为夜。有晚上,有早晨,这是头一日。
————《圣经》
需求≠需要
² 形成需求有三个要素:对物品的偏好,物品的价格和手中的收入。
² 需要只相当于对物品的偏好,并没有考虑支付能力等因素。一个没有支付能力的购买意愿并不构成需求。
² 需求比需要的层次更高,涉及的因素不仅仅是内在的。
需求分析师的技能要求
² 具备三大技巧:听、问和反馈
² 熟练掌握基本的工具
² 掌握项目所需的行业知识
具备三大技巧:听、问和反馈
² 听,应微笑并用眼睛看着听。对对方所说的话给予恰当及时的回应,即点头或微笑,必要时还要对客户提到的问题做记录。
² 问,应善长运用提问技巧,准确地提出问题,迅速发现客户的需求。
² 反馈:通过手绘的草图与被调研对象确认需求是否正确。
熟练掌握基本的工具
² Office办公软件:word、excel、ppt
² 画面原型工具: AxureRP 、 Authorware 、PhotoShop
² 简单的绘图工具:Visio、画图板
掌握项目所需的行业知识
² 如果做的项目是你所不了解的一个行业(专业)同组有要最好要有专家。最终用户做为这个专家是最好的,但是你最少要了解一定的专业知识(最少专用词汇你要知道),不然您甚至不知道去问什么问题或者如何去问他们,甚至于人家在说什么你也不知道。
² 相应的专业资料是必须的,最少要有专业入门书籍和对应的资料,也需要求更深入的一些资料。当然有专家的参入就另当别论。
² 如果行业的难度不是很大,可以通入分析人员的自我学习在短时间内了解行业,也许可以不用专家,否则专家是必须的。
需求调研的目的
² 问题:存在的问题是驱动项目产生的关键
² 背景:(业务场景、业务数据、业务环境)
² 解决方案:提出一个满足业主需求的解决方案;
² 共识: 双方对未来产生结果的认同,达成共识的基础是双方对结果均有理解,而不能一味期望客户提供他们的要求。
分析客户类型
² 的确很专业。能提供基本可用的文档,能给出要求规范,能向你提出有价值疑问和担心。能快速回答你的问题。
² 以为自己很专业。 给的文档基本没法用。没法提供规范和标准,喜欢指指点点和挑毛病。只会向你提傻逼问题。基本回答不了你的问题。
² 啥都不懂。 不给文档。能给你几个参考范例(打开数个网站,告诉你我要做成和它们一样的。)只能等着你来问100个问题。
把握客户心理
² 客户想要什么?
² 客户要这干什么用?
² 客户为什么这么想?
² 客户会不会有别的想法?
客户想要什么?
² 认真倾听客户说话,因为客户在说的时候,他多半同时在想自己要什么东西。他说完了,轮到咱了,首先复述客户需求,在复述的同时我们就可以发表建议了。此时态度要把握好,要把客户的需求合理化、简单化。说白了就是程序别太复杂,风险能排全排除掉,别搞个逻辑又复杂又不实用的东西出来。
客户要这干什么用?
² 听完所有的需求,提炼出客户所要东西的重点,围绕重点开始研究,复述客户的需求。作事千万别说:“我以为”。别怕麻烦,现在多说几遍大家都还是客气,比以后大家对需求有争执强。
客户为什么这么想?
² 客户大多不是IT专家,大多是行业专家,对自己所作的行业至少对本公司的行业流程比较清楚,所有我们就需要搞清楚他们的行业流程或说业务逻辑,看看他们到底想让我们用程序为他们实现什么功能,他们要干什么?
另外,不少关键问题通过了解其具体想要干什么就很容易的化解掉了。
客户会不会有别的想法?
² 通过以上四步我们的目标是: 搞清客户的要求,找出要求的逻辑,客户想要的结果,同时排除开发的风险,挖掘与控制潜在的要求。
需求分析的难点
² 用户需求描述不清
² 需求变更频繁
² 对需求理解有偏差
项目背景分析
² 谁提出了项目(高层)
² 对项目的关键预期
² 当前遗留系统(后续针对成本可指定利旧规则)
² 业务假设(如业务量)
² 技术假设(是否有技术选型要求)
目标分析
² 访谈项目干系人
² 组织相关人员进行研讨(可采用头脑风暴)
² 描述问题(针对研讨结果)
² 分析问题(针对研讨结果)
项目约束分析
² 进度约束(如领导视察)
² 预算约束(可以直接问,也可以通过其经营规模、客户数量、历史同行投入推导)
² 其他约束(法律法规、技术标准、社会文化等)
² 资源支持(如场地等)
明确范围
² 子系统划分:通过构件、接口、服务(虚线)、使用(实现)
² 子系统之间的业务流程
³ 业务流程要注重事件驱动,事件可以使外部、也可以是内部;
³ 要关注异常流程和辅助流程;
³ 要确定业务需求的优先级;
撰写详细的需求文档
² 《框架图》可视化表现产品的框架、布局、细节、部分交互。
² 《流程图》理出产品的逻辑关系。
² 《功能需求文档》罗列功能、应用、交互上细节,分离基础件,作为开发分工和系统及数据构造的 基础文档。
需求分析、概要设计、详细设计的区别
² 软件功能规格说明书,需要确定用户对软件的需求,要作到明确、无歧义。不涉及具体实现方法。用户能看得明白,开发人员也可据此进行概要设计。
² 软件概要设计说明书,说明系统模块划分、选择的技术路线等,整体说明软件的实现思路。并且需要指出关键技术难点等。
² 软件详细设计说明书,对概要设计的进一步细化,一般由各部分的担当人员依据概要设计分别完成,然后在集成,是具体的实现细节。理论上要求可以照此编码。
项目工作量、工期预算
² 项目经理组织所有团队成员坐下来讨论,先划分功能模块,然后讨论每个功能模块的可行性、难度、花费时间、bug发生率、测试耗时。再讨论一头一尾 系统搭建和系统整合的所需时间。
² 项目经理对工程耗时和可行性完全心里有数后,画出工程的时间轴。包括并行状况,里程碑节点、测试期、缓冲期等。时间轴要实事求是,并且预留好充分的缓冲期。
仿真实验需求分析
² 需求分析
与客户沟通,了解客户需要,分析客户提供的资料。熟悉实验原理、实验目的、实验仪器,理解实验的基本原理,并推导实验相关公式;确定实验仪器类型、仪器个数,清楚仪器的工作原理,掌握实际仪器的使用方法。
² 分析实验内容
理解实验考察内容,不同实验内容之间的关系。将实验内容进行细化,分解为各个考察点:实验步骤、仪器调节、记录数据、物理量计算、实验误差、注意事项等。
搜集实验资料
² 整理并阅读手头已有的实验资料;
² 从网络上搜集该实验相关的文档、论文、图片、实验数据结果,论坛上的实验疑问解答等;
² 访问国内知名高校的实验室网站,获取实验资料和实验室情况。
剖析实验教案
² 以实验教案为纲领,对搜集得来的资料进行分析归纳。在此过程中,既熟悉了实验,也了解到客户提供的资料是否全面;
² 确定当前实验的内容范围,根据内容推导出可能缺少的仪器和原理性材料;
熟悉实验内容与步骤
² 根据教案或者客户的描述,明确实验的操作流程,绘制操作流程简图,对关键性步骤进行标记。
² 分析每一步操作对实验产生的影响,和该步骤所要求达到的目的。
² 记录实验操作步骤对应的实验现象,以及该步骤需要记录的数据,明确所需数据的读数方法等。
明确实验重点、难点
² 仿真实验是实验教学的工具,目的在于辅助实验教学;
² 实验中的重难点是教学中要求学生掌握且难以掌握的部分,也恰恰是仿真实验应该发挥作用的部分;
² 根据实验中需要学生掌握的知识点,对实验步骤进行分解提炼,把握实验的关键点和重要步骤。
确认仿真内容
² 仪器的结构
(1)仪器真实结构
(2)原理图
² 仪器的操作
(1)如何通过软件模拟该操作?
(2)仿真结果是否能够体现实验要求?
(3)该操作是否便于开发实现?
(4)客户能否满意?真实感、易用性、条理性
² 实验现象
(1)哪些实验现象需要仿真?
(2)需要哪些模拟特效?
² 仪器的测量结果
(1)该结果是否需要复杂的公式进行模拟?
(2)模拟该结果是否存在我们不熟悉的算法和技术?
制作需求文档
² 根据与客户沟通的结果,对结果进行整理。列出要开发的实验内容、实验仪器、场景样式,包括仪器需求设计和内容需求设计。
² 仪器需求设计:列出各个仪器的功能说明,仪器的各个按钮、旋钮等仪器结构部件的功能说明、操作方式和实现方法;仪器调节窗体设计,窗体的大小、角度、可操作部件等;仪器操作各个部件时对应的现象,现象实现效果以及描述说明。
² 内容需求设计:完成内容的标准操作步骤,各个步骤中需要记录的实验数据,需要求解的物理量以及求解公式。