下载文档原格式
一、二填空及推断1.软件系统通过影响问题域，能够帮助人们解决问题称为解系统2.需求分析的分类（功能需求、性能需求、质量属性、对外接口、约束）3. 对于找寻涉众的必要性通过分析不同困难度的信息系统的涉众特点将信息系统分为（小型统统、组织及系统、战略信息系统、组之间系统）4.获得信息的方法（传统方法、集体获得方法、原型、模型驱动方法、认知方法、基于上下文方法）5.常见的涉众类别有（用户、客户、开发者、管理者、领域专家、政府力气、市场力气）6.需求获得方法利用面谈可获得的信息内容包括（事实和问题、被会见者的观点、被会见者的感受、组织和个人目标）7.原型的分类（①依据运用方式分类：演示、严格意义上的、试验、引示系统②依据媒介载体分类：样板、纸上向导③依据开发方式：演化式、抛弃式④依据构建技术：水平、垂直。
原型）8.需求开发的一些特性确定了需求开发过程只能是一个迭代式的增量过程，而且还不是一个简洁的线性增量过程，它的各个活动之间存在这困难的组织关系。
9.头脑风暴是一种特别的群风光谈方式10.面谈就是在需求获得活动中发生在需求工程师和用户之间的面对面的会见，它是一种运用问答格式，具有特定目的的干脆会话，也是事务中最为广泛的需求获得方法之一。
11.需求验证最主要的方法是需求评审。
（判）需求是用户对问题域中的实体状态或事务的期望描述（判）为了满足用户的业务需求，需求工程师须要描述系统高层次的解决方案，定义系统应当具备的特性。
（判）全部对软件的开发和应具有发言权和确定权的人统称为涉众。
（判）软件系统的涉众群体不是固定不变的（判）模型驱动方法是一类以定义明确的模型为理论基础，依据模型指导和组织活动开展的需求工程方法。
（判）一对一的面谈是时间成本比较高的需求获得方法，尤其是在获得一个或多个涉众方相关的主题时，需反复和多个涉众方支配逐步深化的面谈解决问题。
（判）原型系统通常被构造为不完整的系统，以在将来进行改进、补充或代替。
需求分析名词解释需求分析是指对需求进行理论分析、实际调查和实地勘察的过程，目的是明确用户的需求，为产品或服务的设计、开发和运营提供指导和依据。
在需求分析中，有一些重要的名词需要解释，如下所示：1. 需求：指用户对产品或服务的实际需求或期望。
需求可以分为功能需求和非功能需求两类。
功能需求是指产品或服务必须具备的具体功能或特性；非功能需求是指产品或服务在使用过程中必须满足的性能、安全性、可用性、可维护性等方面的要求。
2. 需求分析：是指对需求进行详细、全面、准确地分析和描述的过程。
需求分析的目标是明确产品或服务的需求，包括功能需求和非功能需求。
需求分析主要包括需求收集、需求整理、需求确认等步骤。
3. 需求收集：是指通过各种方式收集用户的需求信息。
需求收集可以使用多种技术和方法，如面谈、问卷调查、观察、文档分析等。
需求收集的目标是获取用户对产品或服务的需求和期望。
4. 需求整理：是指对收集到的需求进行分类、归纳、整理和优化的过程。
需求整理可以将大量的需求信息进行分类和组织，以便进一步分析和处理。
5. 需求确认：是指与用户或相关利益相关方共同确认需求的准确性和完整性的过程。
需求确认可以通过演示、原型、评审等方式进行。
确认需求是为了保证产品或服务的开发和设计过程能够按照用户的真实需求进行。
6. 需求文档：是对需求进行详细描述的文档。
需求文档包括需求说明书、用例文档、需求规格说明书等。
需求文档是需求分析的重要成果，用于指导软件开发和测试。
7. 需求管理：是指对需求进行有效的管理和控制的过程。
需求管理包括需求变更管理、需求追踪管理、需求确认管理等。
通过需求管理，可以确保产品或服务的需求在整个开发和运营过程中得到有效控制和管理。
8. 用户故事：是一种对需求进行简洁、可理解的描述方式。
用户故事通常由三个部分组成：角色、目标和理由。
用户故事是敏捷开发方法中常用的需求描述技术。
以上是需求分析中常用的一些名词的解释。
在需求分析过程中，了解和掌握这些名词的含义和用法，对于进行准确、全面的需求分析非常重要。
一、引言【1】每个需求分析的开始（引言之前）都应该有“变更历史”和“审核历史”两个表。
原因：因为用户的要求不可能一次满足。
每次变更之后做好记录以便后期查询。
【2】引言部分：引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。
【3】编写目的：开发这个软件产品意义、作用、以及最终要达到的意图。
通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格。
在编写目的中指出预期的读者和者使用者！【4】项目背景：了解时下环境更能表明当前软件的重要性和必要性！更能突出对使用本软件的用户带来更大的利益！对开发人员来说背景了解的越清楚，编程序的准确度就会越高！【5】术语定义：列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
方便用户或后来编程人员的阅读，提高工作效率【6】项目风险：具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险。
【7】文档约定：描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。
形成统一规范，方便阅读【8】预期读者和阅读建议：列举需求分析所针对的各种不同的预期读者【9】产品范围：说明该软件产品及其开发目的的简短描述，包括利益和目标。
把软件产品开发与企业目标，或者业务策略相联系。
就是对软件进行成功的定位，找不到妥帖沟通方式的定位等于没有定位。
技术定位，深度定位，横向定位。
【10】参考文档：列举编写软件产品需求分析报告时所用到的参考文献和资料。
包括使用的各类技术性的参考资料、客户之间的合同、可行性分析等。
二、任务概述【11】目标：叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景材料。
解释被开发系统与其他有关系统之间的关系。
目标可分为开发目标和应用目标。
【12】用户特点：列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，专业水平的高低，不同教育背景以及国内外用户的区别联系等。
需求函数涉及数学知识点一、知识概述《需求函数中的数学知识点》①基本定义：需求函数简单来说呢，就是描述一种商品的需求量和影响需求量的因素之间关系的数学式子。
就好比我们去超市买饼干，哪些东西会影响我们买多少饼干呢？像饼干的价格啊，我们自己的收入呀，还有其他零食的价格等等，把这些关系用数学式子写出来就是需求函数啦。
②重要程度：在经济学里是超级重要的。
它就像搭房子的大梁，可以帮助经济学家预测消费者的行为，企业也能根据这个来决定生产多少东西，定什么价格才有赚头。
③前置知识：得先知道一些基本的函数知识，像什么是变量，什么是常量，还有函数的图像怎么画和基本的代数运算。
比如说知道y = 2x + 1这种简单的函数式子是怎么回事。
④应用价值：比如说超市想知道某种商品降价或者促销时能多卖出多少，就可以用需求函数来分析。
或者企业推出新产品，也得考虑价格、竞争对手产品价格等因素对销量的影响，这时候需求函数就派上大用场啦。
二、知识体系①知识图谱：在经济学这个学科里，需求函数和供给函数啊、均衡价格这些知识点都紧密相连。
它就处于描述市场供求关系这个大知识板块的重要位置，是构建经济学模型的基础部分。
②关联知识：和线性函数、斜率这些数学知识关系很大。
因为很多时候需求函数是线性的，斜率能够表示价格变化对需求量变化的影响程度等。
再就是和统计知识有关，因为要确定需求函数的参数往往需要统计数据。
③重难点分析：掌握难度嘛，主要难在确定函数的形式以及函数中的那些参数。
关键点就是要理解每个变量是怎么影响需求量的。
就好像我一开始学习的时候，搞不清收入对商品需求到底咋影响，是递增还是递减关系，就晕乎了很久。
④考点分析：在经济学的考试里那可是必考的啊。
考查方式很灵活，可以出选择题，让你判断不同变量对需求函数的影响方向；也可以出大题，让你根据给定的一些数据构建需求函数，或者利用需求函数计算什么均衡点之类的。
三、详细讲解【理论概念类】①概念辨析：需求函数里最核心的就是需求量是因变量，那些影响它的因素像价格、收入、相关商品价格等都是自变量。
总需求与总供给分析例题和知识点总结一、总需求与总供给的基本概念总需求（Aggregate Demand，AD）是指在一定时期内，一个经济社会中所有家庭、企业、政府和外国部门对产品和服务的需求总量。
总需求由消费（C）、投资（I）、政府购买（G）和净出口（NX）构成，用公式表示为：AD ＝ C ＋ I ＋ G ＋ NX 。
总供给（Aggregate Supply，AS）是指在一定时期内，一个经济社会中所有企业愿意并且能够提供的产品和服务的总量。
总供给取决于生产要素的数量、质量和技术水平等因素。
二、总需求曲线总需求曲线表示在其他条件不变的情况下，物价水平与总需求之间的关系。
总需求曲线向右下方倾斜，这意味着物价水平下降会导致总需求增加，物价水平上升会导致总需求减少。
原因主要有以下几点：1、财富效应：当物价水平下降时，货币的实际价值增加，消费者感到更富有，从而增加消费支出，导致总需求增加。
2、利率效应：物价水平下降会导致实际货币供给增加，利率下降，投资和消费增加，总需求增加。
3、汇率效应：物价水平下降会使本国利率下降，汇率贬值，出口增加，进口减少，净出口增加，总需求增加。
三、总供给曲线总供给曲线表示在其他条件不变的情况下，物价水平与总供给之间的关系。
总供给曲线可以分为短期总供给曲线和长期总供给曲线。
短期总供给曲线向右上方倾斜，原因在于粘性工资、粘性价格和错觉。
在短期内，工人的工资和企业的产品价格不能迅速调整，当物价水平上升时，企业的利润增加，会增加产出，导致总供给增加。
长期总供给曲线是垂直的，表示在长期中，经济的潜在产出水平是固定的，不受物价水平的影响。
长期总供给取决于劳动、资本、技术和自然资源等生产要素的数量和质量。
四、总需求与总供给的均衡总需求与总供给的均衡是指总需求曲线和总供给曲线相交的点，此时的物价水平和产出水平称为均衡物价水平和均衡产出水平。
当总需求增加时，总需求曲线向右移动，会导致物价水平上升和产出增加；当总需求减少时，总需求曲线向左移动，会导致物价水平下降和产出减少。
需求分析需求分析是软件开发过程中非常重要的一个环节，它是指对用户需求进行全面、准确地分析和收集，以便于确定所需软件系统的功能、性能、安全性等具体要求。
在实际软件开发项目中，如何正确地进行需求分析是影响软件开发成败的重要因素之一，以下将从基本概念、过程方法和常见问题三个方面详细阐述需求分析。
一、基本概念1.需求定义：需求是指客户或用户对某个系统或产品的具体要求。
需求大多来源于用户需求、行业标准、法律法规、技术能力等。
例如，企业需要一个销售管理系统来提升营销效率、一家医院需要一个信息系统来管理患者信息和医疗资源、某个电商平台需要一个订单管理系统来提供更好的服务等。
2.需求分类：根据不同的角度，需求可分为：（1）功能需求：即系统应该完成的操作、处理数据的需求，包括输入、输出、计算、验证等。
（2）非功能需求：系统除了功能外的理性质量要求，如性能、安全、可靠性等。
（3）业务需求：与所属行业或用户业务相关的需求，如支付功能可能需要适配多种支付方式。
（4）可追溯性需求：能够量化为测试用例的需求，例如：给定某些输入值，预期输出结果应该是什么。
二、过程方法需求分析过程是一个涉及用户、业务、行业和技术层面的复杂过程。
正确地执行需求分析将确保开发团队在满足客户期望的同时，合理规划开发周期和成本。
一般情况下，正确执行需求分析需要考虑以下几个方面：1.与客户谈判首先设计人员应该与客户进行会面，了解客户需要的功能、业务以及用户需求。
他们应该了解客户的文化，内部运作方式和工作流程，了解项目的背景和动因，并针对质量标准进行讨论，以促进有效沟通。
2.收集规则与目标在确定用户需求后，设计人员需要开始收集相关信息，包括技术和非技术的要求。
这通常会涉及到信息的收集、盘点和分类整理，记录所有内容并确保每个要素都能明确认识和定义。
3.确定优先级别下一步是通过与客户的交互，确定每个需求的优先级次序。
设计人员需要与客户讨论整个系统的运作方式，并确定优先级次序，以确保项目能够在范围内、时间和成本内完成。
需求管理需求获取困难需求不明确、表达不清晰、可行性低、需求冲突问题、步骤收集资料、了解概括、确认初步系统目标及范围识别需求方1、确认目标用户2、先外部用户再内部用户3、先痛点问题再功能方案需求方：最终用户、运维、数据需求方(人力、财务、领导)、运行影响WHO、运营、测试、生产方、购买方输出调研大纲、调研计划现有系统运作方式现存系统问题需要解决痛点最终用户背景速度、可靠性、安全性需求、运行环境业务流程启动、终止、正常、异常条件，输入数据、处理规则、输出数据数据来源、名称、计算方法、单位、精度、取值范围、去向、生成时间、产生频度、高频度、存储方式、保密需求确认最重要的3项需求思考将来可变需求需求调研会议纪要：指出和记录未回答条目和未解决问题总结归纳、迭代调研大纲需求调研五步法内容方法个别用户交流客户、销售反馈统计数据分析需求专题讨论会文档查阅问卷调查现场客户访谈业务流程分析竞品分析新产品找答案，成熟产品找不同现有系统推导观察用户对原有系统使用用户画像标签化、具体化、分析行为特征关联性根据新产品研发、历史产品升级、定制化项目选择不同方法原则条理化WHY-WHO-HOW-WHAT业务流程主线按不同角色分场景，梳理业务流转情况实例化：输入（GIVEN）、处理(WHEN)、输出(THEN)分不同层面：系统、业务单位、个人可视化原型法（100-1000功能点间）影响地图（思维导图WHY 、who、how、what）用户故事地图（业务流程框架图，与功能架构图区分开）产品定义骨干故事拆分故事沟通确认1、构建用户画像2、寻找目标场景3、梳理业务流程4、调研痛点5、思考解决方案6、识别外部依赖与风险全面化：全生命周期需求、各类干系人使用、安装、培训、维护、报废需求分析目的需求澄清需求过滤：冲突、重叠、不一致、不实际需求细化划分优先级目标思维方式穷举：确保无遗漏分类：去除冗余需求功能需求非功能需求界面需求性能需求：容量、速度、精度、吞吐性、可靠性、可用性易用性需求可维护性、可移植性：组织、环境、业务规则操作环境需求安全型需求：保密性、可存取性文化、政策需求法律需求分层：结构化表达目标需求业务需求操作需求抽象：识别稳定与变化的需求方法结构化方法面向对象的方法需求验证与确认方式需求评审需求交底需求反讲每日需求沟通（敏捷开发）界面原型图表化展示沟通编写需求验收准则功能点度量需求规模评审原则分层次正式/非正式结合分阶段对评审员培训需求评审检查单定义评审结束条件做好评审后跟踪工作建立标准评审流程需求描述内容用户角色业务流程功能界面原型数据处理规则其他约束格式流程图用例图（表格）用例编号角色描述前置条件基本流程备选流程异常流程后置条件备注系统数据视图：ER图（实体联系图）矩形框：实体菱形框：联系椭圆形框：属性连线（用1或n表示联系数量，多对多用n,m表示）BRD（基于商业）价值产品成本风险PRD（产品需求）面向开发、测试、项目经理特征记录需求来源记录需求筛选理由技巧产品需求四段论用例界面原型非功能需求优先级用户需求四段论角色功能目的验收准则内容完备角色业务流程功能界面原型数据处理逻辑非功能性需求优先级清晰易读多用图表短段落，短句子定量描述定义验收标准多用术语。
第二章 需求、供给和均衡价格 知识点总结第一节 需求分析一、需求概述1、需求的含义：指消费者在一定时期内在各种可能的价格水平下愿意而且能够购买的该商品的数量。
2、影响需求的因素：1）商品自身的价格；2）消费者的收入水平；3）相关商品的价格；4）消费者的偏好；5）消费者对商品价格的预期。
二、需求函数1、含义：Q d =f(P)表示一种商品的需求量和该商品的价格之间存在着一一对应的关系。
2、公式：Q d =α-β·P3、图形：需求曲线向右下方倾斜；斜率为负；Q 与P 成反方向变动。
4、需求定理：其他条件不变的情况下，商品的价格和需求量成反方向变动。
三、需求变动1）需求量的变动：商品自身的价格引起的。
表现为：商品的价格—需求数量组合点沿着既定的需求曲线运动。
2）需求的变动：商品自身价格以外的因素引起的。
表现为：需求曲线的位置发生移动。
四、需求弹性1、弹性的一般含义1）公式：弹性=当自变量变化1%时，因变量变化？%。
自变量的变动比例因变量的变动比例2）弧弹性：e=YX X Y ∙∆∆3）点弹性：e=YX dX dY ∙2、需求的价格弹性1）含义：在一定时期内一种商品的需求量变动对于该商品的价格变动的反应程度。
或者，在一定时期内当一种商品的价格变化百分之一时所引起的该商品的需求量变化的百分比。
需求的价格弹性= —价格的变动比例需求量的变动比例2）计算：A 弧弹性：e d = — 表示需求曲线上两点之间的弹性。
Q P P Q ∙∆∆如要计算需求曲线某两点之间的弹性一般用需求价格弹性的中点公式来求得：e d = — 。
222121Q Q P P P Q ++∙∆∆B 点弹性：e d = — 表示需求曲线上某点的弹性。
Q P dP dQ ∙另外，点弹性也可以用几何方法求得：线性需求曲线上的任何一点的弹性，都可以通过由该点出发向价格轴或数量轴引垂线的方法来求得。
3）弹性的五种类型：e d ＞1；e d ＜1；e d ＝1；e d =0；e d =∞。
《需求分析师常见知识合集》一、工具类软件项目需求与设计案例——计时工具系统对于类似word之类的工具类软件，应该如何获取它的需求呢？五维三级需求法应该如何应用呢？该案例以一步一动的方式详细剖析了需求的过程......(一)计时工具系统案例与需求方法简介1)计时工具系统案例与需求方法简介某软件公司的开发项目进度计划总是那么不准确，延期经常出现，更可恨的是项目团队甚至无法给出一个相对比较明确的延迟时间，这给市场的推广会带来很大的影响。
以下是公司领导之间的对话：市场部经理：研发部承诺本月实现的产品功能又没按期交付，这已经是第三回了。
这导致产品上市时间总是不确定，给我们市场和营销人员带来很大的麻烦，你们知道吗？研发部经理：针对这个问题我们花了很多时间来解决，但一直收效不好。
我也在积极想办法，我用过FP模型、WBS方法等....总经理：（打断研发经理的话）这问题靠我们自己闭门造车是不行了，看看能不能借助外脑？我看这样吧，由你（研发经理）负责，请一个这方面的顾问，如果有必要还可以采用信息化手段，采购或研发个工具软件，帮助我们更好地解决该问题....这就产生了一个项目机会，那么对于这类件项目，又该如何抓需求呢？2)五维三级需求法“五维三级需求法”即从广度（五维：因、人、事、物、规）和深度（三级：业务和用户需求、产品需求、功能需求）两个视角分解复杂问题，展开需求分析，获取高质量的需求结果。
1．分析软件的“因”。
任何信息系统项目建设的出发点一定是要解决业务中存在的问题，以期达到某种建设目标，所以应将“因”维（分析业务问题，确定项目目标）作为软件需求分析的起点。
2．分析软件的“人、事、物、规”。
围绕达成“因（项目目标）”的几个关键业务场景，通过“人”维了解组织结构、清晰岗位职责，通过“事”维区分业务场景、梳理业务流程，通过“物”维收集单证报表、获取数据求，通过“规”维分析软件相关系统、明确时间节点等限制条件。
3．形成软件的“业务和用户需求”。
在“因、人、事、物”分析的基础上，分别描述核心业务流程和收集用户需求。
（1）对于存在业务变革的项目，讨论重点在核心业务流程，主要关注业务现在具有怎样的组织、执行怎样的流程、传输怎样的单证，并探讨未来会怎么办。
为了保证需求效果，讨论可一次围绕一个特定业务场景展开，事先草拟好业务流程图当“靶子”，并尽量邀请高层参加。
对于如体制调整等一些短期内无法决策的问题，也应标识出几种可能的变化情况，为后续的系统架构设计指明应考虑适应的变化点。
（2）对于不存在业务变革的项目（如工具软件、局部技术改造类项目），重点在于收集用户提出的各类意见（常以解决方案的形式出现），并挖掘意见背后的真正问题，结合行业最佳实践协商解决方案，形成用户期待软件具有的特性列表。
4．形成软件的“产品（软件）需求”。
任何软件或产品都必须在“时间、成本”等约束下，对“质量和功能”进行折衷，业务和用户需求中的很多事并不一定都要纳入系统中去实现。
因此，在产品（软件）需求阶段重点是在“规”的约束下，协商确定现阶段产品的项目范围和开发任务，如现阶段“到底有哪些岗位使用该系统，用户能够使用系统完成哪些工作，系统怎样帮助用户完成这些工作（自动化程度有多高）？”等等。
本阶段形成的文档名为《用户需求分析说明》，主要采用用例模型来描述。
5．形成软件的“功能需求（需求规格说明）”。
这阶段主要是对产品需求中的每个用例（即用户使用系统完成的一项工作），由系统开发者和具体用户协商，按用例优先级逐个确定其操作界面、操作步骤等，这层次的工作将为具体的物流信息系统开发提供完备的需求规格说明。
本阶段形成的文档名为《用户需求规格说明》，一般采用用例细化描述文档和补充规约（非功能性需求等）来表示。
注：业务、用户、产品等需求的概念和区别参考推荐阅读16. 需要特别说明两点：一是为了化解需求复杂度，“五维三级需求法”可逐个业务场景的迭代应用。
比如，在应用时可针对一个业务场景，完成一次需求分析过程。
待完成该业务场景下的业务需求、产品需求和功能需求后，再着手另一个业务场景下的需求分析过程；二是五维度中的核心是“因”。
只有准确把握好“因”，才能把握住“人、事、物、规”的变化趋势。
由于“因”常常由上一层次目标所决定，所以软件建设，需将建设目标纳入企业信息化顶层设计的背景中通盘考虑，才能准确到位。
(二)从“因”维确定用户痛点和协商解决方案1)获取甲方用户需求时，首先应访谈谁？怎么约？怎么谈？●首先约谁谈？抓需求，第一个要约见的是甲方的项目负责人。
因为他负责这个项目，有责任和义务去和乙方交流，选择乙方。
至于甲方的其他人员，应该通过甲方项目负责人去协调约见，如果擅自约见，可能会遭到拒绝，并引起甲方的反感。
●约谈对方方式主要有电话、邮件、面谈三种建议先提前一周发邮件约见，再提前半天打电话确认提醒，最后面谈。
一般应在邮件里包含：公司优势和访谈提纲。
公司优势包括以往成功案例、对项目的初步认识等，有利于体现乙方的专业能力和认真态度，加深甲方的认识；访谈提纲可以让甲方有更好地准备，比如在提纲中提到甲方业务规章制度，甲方访谈时就可以事先带一份过来，从而提高访谈的效率。
●访谈地点的选择约甲方普通人员访谈，一般在其办公室即可。
但是约见甲方项目负责人，由于他往往工作很忙，在其办公室一般干扰会很多，如一会儿有人敲门开汇报事情，一会儿有电话打入，导致需求访谈效果不佳。
因此，和甲方项目负责人的访谈地点一般建议选择方便、而且干扰少的地点，如其楼下的咖啡厅或者公司的会议室。
可以开玩笑地和他说：“领导办公室干扰太多了，领导能不能将约好的1小时时间完全给我，我们在楼下的咖啡厅坐坐？”●谈什么？和甲方的项目负责人交谈，是一次体现乙方专业能力，树立甲方信心的极好机会，应该事先做好充足准备。
交流时应注意从甲方的业务视角出发，聚焦甲方业务问题和解决问题的业务模式，避免过于技术视角。
由于甲方项目负责人不可能了解所有业务细节，所以一般访谈时还会和甲方项目负责人协商确定再召开一次业务需求研讨会（多人同时参加的用户代表访谈），会上将各类用户代表召集在一起，讨论业务细节，明确项目范围。
所以，还需协商制定会议计划，明确会议的时间、地点和人员，并通过甲方项目负责人通知相关人员，做好会前准备工作。
2)计时工具系统的“因”维度需求分析一、基本工作步骤“因”维度需求分析一般分为三步骤：1、通过同类方案（竞品）研究法成为领域专家；2、约谈甲方的项目负责人，找到核心痛点，介绍行业内各类解决方案，并与之协商适合甲方的解决方案；3、通过甲方的项目负责人，筹备多用户代表参加的集中访谈，确定会议时间、地点和参与人员。
二、以计时工具系统为例，详解“因”维度需求分析过程（案例背景详见推荐阅读1）1、通过同类方案（竞品）研究法成为领域专家通过前面案例介绍我们知道，负责该项目的需求师必须是工作量预计领域的专家。
如果对于该领域不熟悉，一般采用同类方案（竞品）研究法（详见推荐阅读2）尽快了解业务、掌握行业术语，并对市场上已有解决方案（竞品）的各自特点和利弊展开分析。
2、约谈甲方的项目负责人在该案例中，主要是约谈研发部门经理（为什么先约谈他？详见推荐阅读3），开展用户代表访谈。
访谈目标主要是：明确用户核心痛点，向他介绍行业各类解决方案，并协商该公司适合的解决方案。
以下是访谈的内容实录：（以下对话目标：明确用户核心痛点）需求师：能否介绍一下贵部门当前在工期预计中遇到的问题？研发部经理：我部门各个项目团队给出的项目进度计划总是不太准确，经常出现延期，更可恨的是项目团队甚至无法给出一个相对比较明确的延迟时间，这给市场的推广会带来很大的影响。
有什么好办法吗？（以下对话目标：围绕核心痛点，向用户介绍行业内常见解决方案）需求师：根据我们的研究，对于这类问题，目前业内做法主要是：根据用例包、用例的方式来组织需求，然后将某个用例或子用例作为工作任务分配给开发人员，但在开发时间估计上主要有三种解决方案：一是使用FP、COCOMO模型来估计工作量。
但是要想计算准确，需要很多历史经验值，并且要求前期需求做得非常精细，难度极大；二是自上而下的估计法。
主要由领导或专家指定相应的完成时间。
但由于开发人员未参与时间预计，所以如果到了时间开发人员完成不了，他容易反过来抱怨是领导时间安排不合理；三是自底向上的估计方法。
任务明确后让开发人员反馈工作量及所需的工作天数。
但开发人员容易将时间估计的偏长，而且还是有一些工作任务，由于开发人员经验不足，他反馈的工作量无法按期完成，甚至无法明确要延迟多少天。
（以下对话目标：与用户协商该公司适合的解决方案）研发部经理：三种方法我部门好像都采用过，确实存在你说的问题。
我感觉估算的基础是经验数据，对于不同的开发人员而言其产能是不一致的，甚至对于相同的开发人员而言，不同的任务所需的时间也是不同的，因此关键在于缺乏这种经验数据。
需求师：正是这样，所以我想向你推荐了PSP（个人软件开发过程）的方法来积累经验数据。
举个例子，我在编写技术书籍时，就采用这种思路，对所有的工作过程进行了时间的记录，在半年之后，就积累了许多相关的产能数据，现在给编辑的时间承诺总是能够比较的准确。
研发部经理：哦，难怪你做的承诺都一般很少延误，这种经验能否适用于软件开发的管理呢？需求师：呵呵，这是当然。
PSP是个人软件开发过程，它本来就是为软件开发设计。
它是CMM的创始人提出的，PSP、TSP和CMM分别针对软件开发员、软件开发小组和软件开发组织。
通过PSP的贯彻，就一定能够提高软件开发人员的时间安排、时间估算的能力。
由于统计个人开发时间是件比较繁琐的事，所以需要开发个工具配合它。
研发部经理：好！那我们就开发这么一个工具！3、通过甲方的项目负责人，筹备用户代表集中访谈会（以下对话目标：通过甲方项目负责人，筹备有更多其他用户代表参加的集中访谈会）需求师：太好了，这正是我要建议的！但是由于这款软件涉及到的人员较多，有很多细节需要确认，我们能否在下周召开一次用户代表集中访谈会？请您帮助召集更多的相关人员参加。
研发部经理：当然可以！那我们再商量下会议的时间、地点、主题和需要参加的人员......这样，这次计时工具系统的“因”维度需求分析就大致完成了，回来后需求师还应该整理访谈记录，形成文档（文档模板参见附件1）！(三)采用业务流程模型和特性列表描述业务需求和用户需求1)一图说清业务需求、用户需求、产品（软件）需求和需求规格的关系一、四者的关系如上图所示1、业务需求和用户需求是软件项目需求的起点。
业务需求侧重于和高层探讨业务流程（特别是需要优化的流程，详见推荐阅读1），一般产出物是业务流程图；用户需求侧重于和各类用户代表开展面对面的访谈，一般产出物是汇总访谈结果的需求特性列表；2、这时不论是业务需求、还是用户需求都比较粗糙，需要经过分析处理后，形成软件（产品）需求，才能交付给开发团队使用。
