下载文档原格式
2.2需求分析需求分析是通过开发人员的分析概括，抽象为完整的需求定义，再形成一系列文档的过程。
2.2.1需求分析的目的与意义需求分析是一个非常重要的过程，它完成的好坏直接影响后续软件开发的质量。
有效的需求分析通常都具有一定的难度。
需求分析不仅仅是属于软件开发生命周期早期的一项工作，而且还应该贯穿于整个生命周期中，它应该随着项目的深入而不断地变化。
此外，为了方便后续的评审和测试等工作，需求的描述应该尽量做到：具体、详细、可以测量和可以实现，并且基于时间。
2.2.2需求分析的步骤遵循科学的需求分析步骤可以使需求分析工作更高效。
需求分析的一般步骤如图2-3所示。
需求涉及的方面：在功能方面，需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。
在性能方面，需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。
在运行环境方面，需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。
在界面方面，需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。
1. 获取需求，识别问题开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。
开发人员通过调查研究，要理解当前系统的工作模型和用户对新系统的设想与要求。
遗漏需求是最难修订的需求错误。
获取需求是需求分析的基础。
为了能有效地获取需求，开发人员应该采取科学的需求获取方法。
在实践中，获取需求的方法有很多种，比如，问卷调查、访谈、实地操作、建立原型和研究资料等。
问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。
通过对用户填写的调查问卷进行汇总、统计和分析，开发人员便可以得到一些有用的信息。
采用这种方法时，调查问卷的设计很重要。
一般在设计调查问卷时，要合理地控制开放式问题和封闭式问题的比例。
需求调研方法论需求调研方法论我曾参加___的审计信息化创新项目需求调研工作，这是一个很好的研究和实践需求调研的机会。
在完整、系统地参加了项目的需求调研过程后，我研究研究了他人的需求调研理论，并总结了我在需求调研过程中的一些想法，形成了本文。
本文的编写过程中，由于时间关系，未能一次性完成整个文档结构。
经过数次结构的调整后，才形成现在的样子。
其中可能还存在不完善、不严谨之处，欢迎各位指正和探讨。
目录：1.需求概述1.1 软件需求1.1.1 需求定义1.1.2 需求层次在需求概述中，我们将介绍软件需求的定义和层次。
在软件需求的定义中，我们将详细说明什么是软件需求，并解释软件需求的重要性。
在需求层次中，我们将介绍软件需求的分类和层次结构。
此处删除明显有问题的段落）在本文中，我们将介绍一些常用的需求调研方法，包括文献调研、问卷调查、访谈调研、焦点小组讨论等。
我们将详细介绍每种方法的优缺点和适用场景，并提供一些实用的技巧和注意事项。
最后，我们将总结本文的主要内容，并提出一些对需求调研工作有帮助的建议和思考。
我们希望本文能够为需求调研工作者提供一些实用的指导和启示，帮助他们更好地完成需求调研工作。
须遵守的规定。
这些规定可能会对软件产品的开发和使用产生影响，因此也可以作为软件需求的来源之一。
需求是用户对于改善现状、解决问题或达成目标的期望。
软件产品的功能实现过程就是通过满足用户需求，使得用户能够达成目标。
软件需求可以分为四个层次：业务需求、用户需求、功能需求和非功能性需求。
软件需求的来源有多种，可以通过访谈、调查用户或潜在用户、研究竞争对手同类产品、需求分析人员的经验、市场支持活动以及政策制度和法律法规等方式获取。
不同的用户在不同的环境和思想下，对同一领域的需求存在差异。
软件产品的研发是在有限的资源、时间和技术条件下进行的，不可能满足所有潜在用户的需求。
因此，软件产品需要明确目标用户，关注目标用户的需求，以获取目标用户的认同和满意度，从而实现销售的成功。
试析凯恩斯的有效需求理论及其方法论凯恩斯的有效需求理论是现代宏观经济学的基石之一，它提出了一种解释经济波动和失业的理论，并针对这些问题提出了应对措施。
凯恩斯的有效需求理论认为，经济波动和失业是由于有效需求不足造成的。
有效需求是指总支出，包括消费、投资和政府支出。
凯恩斯认为，当总支出不足以刺激生产时，经济就会陷入不景气，出现失业问题。
他认为，解决失业问题的关键在于增加有效需求。
为了解决有效需求不足的问题，凯恩斯提出了一系列政策建议和方法论。
首先，凯恩斯主张通过增加政府支出来刺激有效需求。
他认为，政府可以通过提高公共投资和开展基础设施建设等方式来增加有效需求，从而刺激经济增长和就业。
其次，凯恩斯强调通过调整货币政策来增加有效需求。
他认为，当经济处于萧条时，央行可以通过降低利率、扩大货币供应等方式来刺激消费和投资，从而提高总支出。
此外，凯恩斯还提出了通过调整财政政策来增加有效需求的方法。
他认为，政府可以通过减税、增加社会福利等方式来提高家庭可支配收入，促进消费，从而增加总支出。
凯恩斯的有效需求理论不仅提出了解决经济波动和失业问题的具体方法，还具有以下几个重要的方法论。
首先，凯恩斯主张应当关注总支出而非利润。
在他看来，传统的经济学将利润看作经济增长的主要动力，但凯恩斯认为，当总支出不足时，就算企业利润再高也无法持续发展。
他强调，应当通过增加总支出来刺激经济增长。
其次，凯恩斯提出了管理经济的概念，即通过调整有效需求来实现经济稳定。
他认为，传统的自由市场机制无法有效解决经济波动和失业问题，需要政府和央行采取积极的干预措施来管理经济。
最后，凯恩斯的有效需求理论提出了对经济问题进行统计研究的要求。
他强调应该收集和分析大量的统计数据，以便更好地了解和应对经济波动和失业问题。
总之，凯恩斯的有效需求理论提供了一种解释经济波动和失业问题的视角，并提出了刺激有效需求的方法。
他的方法论中强调关注总支出、管理经济和统计研究的重要性。
学习业务建模和需求分析（⼀）：⽅法论做IT的，不管是做项⽬、架构、开发、设计等等，我们最惧怕的⼀句话，恐怕就是：需求⼜变了。
需求变了，经常让我们措⼿不及，经常让我们愤恨不已，甚⾄让我们感到恐惧。
但我们知道，这个世界上没有⽆缘⽆故的爱和恨，⾃然也不会有⽆缘⽆故的变化。
缺乏的是深⼊的分析和探讨，抓住其本质。
当我们接触到⼀个需求时，我们多么渴望有⼀个⾮常懂得⾏业知识、公司业务操作⽅式、哪⾥有问题、该怎么弄⼀个系统来处理问题、界⾯该如何设计、业务逻辑应该怎样等等的全能型甲⽅啊；然⽽，现实是残酷的，上述的每⼀⽅⾯，我们似乎都难以搞定，总是在反反复复中不停的变来变去，这就产⽣了我们看到的：需求⼜变了。
---------------------------------分割线---------------------------------很多时候，我们怎么做需求呢？我想我们通常是这样的。
某⼀天，你被⽼板召唤过去，可能亲切的（当然也可能霸道的）告诉你，你将负责***项⽬，即⽇开始去甲⽅那⾥开始需求调研；然后，你就开始⼀头雾⽔的去到甲⽅那⾥，当然，估计甲⽅也不会有什么完整的准确的⽂档等着你。
接下来怎么办呢，那就开会吧，名⽈需求分析会议。
不过⼤部分的时候，都是甲⽅说说说，⼄⽅记记记，来来回回搞出⼀份需求⽂档出来。
然后就开⼯⼲活。
这份需求⽂档全不全、内容准不准，没有⼈知道。
有多少未知的变更风险，只有天知道。
---------------------------------分割线---------------------------------这样的需求调研⽅法，可以直接说，就是没有⽅法。
那需求调研有没有好的⽅法呢？那我们倒过来分析⼀下：1、甲⽅为什么肯花钱做⼀个项⽬，肯定是哪⾥不顺了？2、为什么不顺呢？肯定是现有的东东不满⾜了3、所以我们必须先搞清楚“现有的东东”4、但是甲⽅现有的东东太多了，我们⼀定要准确的划出要搞清楚的范围---------------------------------分割线---------------------------------转换为专业术语：1、圈定出需求调研范围2、列出现有的业务流程建议采⽤6W1H⽅法，明确出谁（Who）在什么时间（When）什么地点（Where）为谁（Whom）做什么（What），并找到为什么要这么做（Why），详细的做法（How）。
《软件需求分析》教学大纲目录一、内容概要 (2)1.1 课程介绍 (3)1.2 教学目标 (4)1.3 教学内容概述 (5)二、软件需求分析基础 (6)2.1 软件需求分析的重要性 (7)2.2 软件需求分析的基本概念 (8)2.3 需求分析的基本原理 (9)2.4 需求分析的方法论 (11)三、需求获取与整理 (11)3.1 需求获取的策略 (13)3.2 需求整理的技巧 (15)3.3 需求规格说明书的编写 (16)四、需求分析方法 (17)4.1 结构化分析方法 (19)4.2 面向对象的分析方法 (20)4.3 数据流分析方法 (21)4.4 其他需求分析方法简介 (22)五、需求验证与确认 (24)5.1 需求验证的目的和方法 (25)5.2 需求确认的流程和标准 (26)5.3 案例分析 (27)六、需求管理 (29)6.1 需求管理的概念和重要性 (30)6.2 需求变更的管理 (31)6.3 需求跟踪与监控 (33)6.4 需求文档的管理 (34)七、需求分析与设计的关系 (36)7.1 需求分析与设计的相互作用 (37)7.2 需求驱动的设计方法 (38)7.3 案例分析 (39)八、课程总结与展望 (41)8.1 课程总结 (42)8.2 学生学习成果评估 (43)8.3 对未来软件需求分析发展的展望 (45)一、内容概要本课程旨在培养学生掌握软件需求分析的基本理念、方法和技能，使学生具备从事软件项目需求分析工作的能力。
课程内容包括软件需求分析的基本概念、原理、过程和方法，以及相关工具的使用。
熟悉软件需求分析的过程和方法，包括需求获取、需求分析、需求定义和需求验证等阶段。
能够参与软件项目的需求分析工作，与项目团队成员有效沟通，确保需求的准确性和完整性。
软件需求分析基础：介绍软件需求分析的基本概念、原理、目标和任务，以及需求分析在软件开发生命周期中的地位和作用。
需求获取：讲解需求获取的方法和技巧，包括与客户沟通、现场调研、问卷调查等。
做需求分析时常用的方法论一、PEST分析法PEST分析法用于对宏观环境的分析。
宏观环境又称一般环境，是指影响一切行业和企业的各种宏观力量。
主要包括：政治环境、经济环境、社会环境、技术环境1、政治环境：政治环境包括一个国家的社会制度执政党的性质，政府的方针、政策、法令等。
不同的国家有不同的社会性质，不同的社会制度对组织活动有不同的限制和要求。
构成政治环境的关键指标有：政治体制、经济体制、财政政策、税收政策、产业政策、投资政策、国防开支水平、政府补贴水平、民众对政治的参与度等。
2、经济环境：经济环境主要包括宏观和微观两个方面，宏观经济环境主要指一个国家的国民收入、国民生产总值及其变化情况，以及通过这些指标反映的国民经济发展水平和发展速度。
微观经济环境主要指企业所在地区或所服务地区的消费者收入水平、消费偏好、储蓄情况、就业程度等因素，这些因素直接决定着企业目前以及未来的市场大小。
关键指标：GDP及增长率、进出口总额及增长率、利率、汇率、通货膨胀率、消费价格指数、居民可支配收入、失业率、劳动生产率等。
3、社会环境：社会环境包括一个国家或地区的居民受教育程度和文化水平、宗教信仰、风俗习惯、审美观点、价值观等。
文化水平会影响居民的需求层次；宗教信仰和风俗习惯会禁止或抵制某些活动的进行；价值观会影响居民对组织目标、组织活动以及组织存在本身的认可；审美观点则会影响人们对组织活动内容、活动方式以及活动成果的态度。
构成社会文化环境的主要指标有：人口规模、性别比例、年龄结构、出生率、死亡率、种族结构、生活方式、购买习惯、教育状况、城市特点、宗教信仰状况等因素。
4、技术环境：技术环境除了要考察与企业所处领域直接相关的技术手段和发展变化外，还应及时了解：*国家对科技开发的投资和支持重点*该领域技术发展动态和研究开发费用总额*技术转移和技术商品化速度*专利及其保护情况等构成技术环境的关键指标有：新技术的发明和进展、折旧和报废速度、技术更新速度、技术传播速度、技术商品化速度、国家重点支持项目、国家投入的研发费用、专利个数、专利保护情况等。
高二幼师创业计划书一、创业概述幼儿教育是非常重要的一环，在孩子成长过程中扮演着重要的角色。
随着社会的发展和人们对教育的重视，幼儿园行业也变得越来越受到关注。
我是一名高二学生，对幼儿教育有着浓厚的兴趣，并且希望在未来能够创立自己的幼儿园，为孩子们提供更好的教育环境和服务。
本计划书将详细阐述我创业的理念、目标、方案以及实施的具体步骤。
二、创业理念1.教育理念：幼儿期是孩子成长的关键阶段，他们的思维、语言、行为等能力都在这个阶段得到形成和发展。
我的教育理念是以尊重、关爱、启发为基础，通过寓教于乐的方式培养孩子们的兴趣和能力，引导他们主动学习、积极探索，培养他们的创造力和自信心。
2.教育目标：我希望通过我的幼儿园，为孩子们打造一个温馨、快乐、有爱的学习环境，让他们在这里快乐成长、健康发展。
同时，我也希望能够与家长建立良好的合作关系，共同关注孩子的成长和发展，为他们提供更优质的教育资源和服务。
三、市场分析1.市场需求：随着人口结构的变化和家庭生育观念的转变，越来越多的年轻家庭开始重视孩子的早期教育，他们希望能够为孩子选择一所优质的幼儿园，帮助他们建立良好的学习基础和人格素养。
因此，幼儿园行业的市场需求日益增长。
2.竞争情况：虽然幼儿园行业的市场需求持续增长，但市场竞争也越来越激烈。
目前，市场上已经涌现出许多幼儿园，其中一些大型连锁幼儿园拥有较强的品牌影响力和资源优势，给中小型幼儿园带来一定的竞争压力。
四、创业方案1.目标市场：我打算在城市中选择一个人口较为集中、社会环境较为优越的地区开设幼儿园。
这样既能满足家庭对幼儿园的需求，也能为孩子们提供更好的学习和成长环境。
2.服务内容：我的幼儿园将提供全方位的幼儿教育服务，包括早教、启蒙、玩乐、美育等多个方面。
除了常规的学习课程外，还将开设一些特色课程，如音乐、舞蹈、绘画等，帮助孩子们全面发展。
3.教育团队：我计划招聘一支专业的教育团队，他们将负责孩子们的教育教学工作，并且具有丰富的教育经验和爱心，能够为孩子们提供专业、有爱的教育服务。
需求分析的3个层次马斯洛需求层级理论也好，Y方法论、Z方法也好，归根到底都是一些思考框架和方法，如何把握需求、提炼需求，还是需要我们在真实的环境中多聊、多看、多做。
无论是市场营销还是产品设计，“需求”这个词，是最频繁被提及的词汇。
在市场营销领域，无论是新的产品的研发设计，还是制定推广活动方案，我们需要做的是“消费者洞察”。
所以市面上有大量的调查公司，帮助品牌通过问卷、焦点小组访谈等方式，收集用户反馈，以求获得insight。
近些年，随着互联网行业兴起和产品经理岗位的火热，“需求”一词有反复被提及，需求分析成为产品经济的必备技能之一；在“人人都是产品经理”上搜索8,226条结果。
马斯洛需求层级理论也好，Y方法论、Z方法也好，归根到底都是一些思考框架和方法，如何把握需求、提炼需求，还是需要我们在真实的环境中多聊、多看、多做。
需求的第一个层次：需求的忠实记录者腾讯推崇产品文化，其有一个著名的「10/100/1000法则」：即每位产品经理每个月必须做 10 个用户调查，关注 100 个用户博客，收集反馈 1000 个用户体验。
于是，很多产品经理，特别是刚刚进入产品领域的新手，每天将“用户需求”、“使用场景”这些词挂在嘴边，并践行腾讯的「10/100/1000法则」，每天都在记录用户的反馈和槽点。
能坚持倾听用户反馈并记录用户需求，固然不错，然而这还不够。
举一个小例子。
早些年，针对B端广告主制作视频素材的需求，做了一个小工具，小白用户选定模板之后按规定上传图片或者视频，就可以渲染出一支质量还凑合的视频，并且可以直接推送到投放后台。
然而，很多广告主在后台留言，希望能开放下载功能。
这个时候，我们就面临着一个选择：是否需要开放下载？需求的第二个层次：需求的挖掘机多问一句Why，发掘需求背后的动因。
通常情况下，用户通过语言或者文字表达出来的，只是最直接的功能指向。
每一个功能指向背后，都暗藏着一个刺激因素，这个刺激因素才是用户真正希望解决的问题。
终于有时间可以总结了，二十年的代码经验，总是想有些可以写的，没多少写作经验，借此向朋友们多学习吧。
一、从故事谈起
（这个故事记不得出处了，多年来在给项目经理们讲课时，经常用到。
）话说在上世纪50年代的一个人民公社的领导，找到我们软件公司的项目经理，说我们有一个项目由你来做吧。
项目经理：“yes sire,你的需求是什么？”
公社领导：我对公社养牛的家伙很不满意，他养的牛满足不了我们放卫星的要求，我想要一头吃的草比现在的牛少一半，干的活比现在的牛多一倍的新牛（像不像你们的BOSS）；我的需求很明确吧？
项目经理：是的是的；我现在可以写出需求规格说明书了，然后你鉴上字，确定下来，我们就可以开工了。
公社领导：好，就这样定了。
在需求分析与评审会上，我听到了这个项目的初始需求，项目经理带回来的是让项目组开发出一头新牛的生物工程项目。
如果按项目经理理解的需求，我们需求玩把DNA技术了，呵呵，反正软件公司是万能的嘛。
可事情真的是这样？
其实真的不是这样的，在项目经理与用户的交流过程中用户已经把实际需求显性的说了出来，其实就是想如何利用第三方产品或工具提高生产效率。
如果项目经理能在需求分析过程中把握好用户的产业特点，并能理解用户的需求，那么提出的解决方案就能真正解决用户所存在的问题。
所以这个解决方案很简单，卖给他们几台拖拉机！
故事讲起来很轻松，可我发现在实际工作中我们的项目经理们经常在做生物工程。
如何在工作中正确的识别用户的需求是项目成功的基础，这一点没有人会反对，可做起来非常不容易。
多年来我所接触的项目大多是政府电子政务方面的，所以在这里所有的项目背景也将结合此类项目与大家进行探讨。
首先遇到的问题，可能是最令我们头疼的，就是用户没有完整的时间来说明他们的需求，可能用户都说不明白一头牛！
用户在通常情况下有两部份人与软件公司的开发人员接触，这时其实项目需求的风险有时会更大；因为业务的决策者通常会将重要的沟通任务交给了用户单位的信息管理人员，而这些岗位上的人员由于种种原因有一种职业优势，更容易出现生物工程的需求。
先举一例（首先说明，在这里的例子虽然是从实际工程中提练出来的，由于可以理解的原因，需求是被修订了的），我们的用户需要上OA系统，而我们正好有OA 产品；但由于用户需求的差异，每个用户的OA都是需要进行一些小的修正以适应用户在习惯上的差别。
当客户单位的信息中心技术人员向我们的项目经理描述需求时，他头脑中有完整的OA产品功能与性能，因为在这之前他已经了解了许多OA产品，于是他就找了一家他认可的公司产品做为需求向我们提了出来。
当我们的产品经过两周的调整后，布置到了用户的系统中，这时客户信息中心的技术人员很认可系统的功能，我们的项目经理也很轻松，可当领导来认真的考察一番后，对产品非常失望，因为重要功能与他们的要求相差很远。
为什么会出现这类问题？其实到现在我还没有说出这是什么客户，我想有经验的项目经理早就在心里问了吧，对了这与用户的业务有着很重要的关系，
这是人大办公厅，在通常的政府办公厅（室），公文流转是OA中的核心内容，可在人大办公系统，领导最关心的不是公文流转，而是会议系统，并且是相对比较复杂的会议管理，其实这与人大的核心业务有着很大的关系，不论是提案还是协调，都是在不同的会议中进行处理，而且每年都有重要的会议需要管理。
我们的项目经理在并没有认真分析客户业务的情况下，轻信了所谓需求与方案，做了个小小的“生物工程”。
当然要避免这类问题并不难，难的是能有一些方法及时发现这类，能在不同的项目中识别用户真正的需求，确实需要一些技巧。
继续就这个案例来讨论一下，对我们来说，首先应有的是风险意识，在这个过程中，项目经理在风险管理上并没有完成任务，在第一个里程碑评审过程中，对客户业务的理解产生了偏差，而项目组并没有在这方面进行深入的研究，过分的相信了与用户沟通及以往的经验，在项目早期，项目经理也曾多次与客户主管领导进行沟通，也进行了相当规模的集中访谈；在这个过程中，用户针对OA 中会议系统的不足，提出了他们的想法与要求，但当时领导并没能及时区分通常的OA与他们所需要的重要区别在哪？也没能全面的说明会议系统对人大办公厅核心业务的作用。
其实在这个阶段，很少能有用户准确的说明他们希望的是什么，但他们能说明的是根据他们的知识以及理解而产生的需求，也就是一头生物牛，对项目团队来说，这已经能说明问题了，关键是项目团队如何能将这头生物牛理解成客户的真正需求：拖拉机。
在项目管理过程中，能不能避免这类事情的发生？坦率的说，完全避免，至少我现在还没有什么特别有效的办法，但在实践中，我们总结了一些办法，希望能有效的在早期风险评估过程中能发现此类风险并采取一些规避措施。
二、如何开始需求分析？
我自己的习惯，总是先从理解客户开始。
理解客户什么？其实就是理解客户到底在说什么？先从一个极端的例子开始吧，市场部在9月底非常顺利的签订了一份OA合同，在项目任务书中明确要求11月底以前上线运行，当项目经理到客户处进行了初步的接触后，向我汇报说客户要求的与我们的差别虽然不是很大，但要在11月底上线，只有九周的时间，这其中还有一个长假，所以延期布置的风险很大；对此我带着项目经理与客户的主管领导进行了一次交流，这才理解，客户在12月初要进行单位信息化建设的检查与评比，而客户在年初计划中已经将这个项目列了进去，由于种种原因，一直没能实施，只是到第四季度了，整个行业要进行评比与检查，而信息化建设又是重要内容，所以才有这样的时间要求。
由此，整个项目的策略就完全不一样了，功能需求的等级就让位于及时布置与培训了。
我们反而提前完成了领导的预期目标，至于检查以后，这个单位并没有在OA上继续提出需求变更的要求，原因也是极端的，领导换了，新的领导关注的是业务系统的信息化建设，对OA他认为可以放一放，所以他们根本就没有使用(^-^)。
还是回到一个常规项目上的需求分析吧，我们以一个全新的项目来进行一次需求分析之旅。
我们还是来做一个某政府办公系统的OA吧。
当然有许多公司有很成功的产品，这里只是想与大家讨论需求分析中的一些方法论上的问题，与产品无关啦。
回头再来交待一下项目团队的组成，我还是借用曾经完成过西天取经这样大型复杂项目的四位高人吧，项目经理当然是师傅了，项目中的主力是高手候哥，当然还有魅力之星戒子，以及老实能干的老沙了。
师傅召开了第一次项目组成例会，并就此开始了历经千折百转的开发之旅。
<没有一场战役是在没有计划的情况下打赢的，可也没有一场战役是完全按照计划打赢的>
这是二战时期同盟国元帅告诫后世的，我是很认同的，需求管理并不只在需求分析阶段，如果你喜欢按传统严格分成阶段的话。
师傅以这样的开场白开始了项目经理的工作。
需求分析要完成什么任务？如何制定计划？各村有各村的高招，我认为微软Microsoft Solution Framework(简称MSF)中的定义会更好的帮助项目经理进入状态，在MSF中它将其定义为“远景/范围”阶段。
从里程碑的意义上讲，都是关键基线（baseline）的建立，但从远景／范围上理解在操作上要比需求分析更能与用户达成共识，远景与范围，其实更难让用户认可的是范围，需求的不稳定一部份是对需求的理解与进化带来的，另一部份就是范围的扩大带来的，使用远景／范围文档并与用户一起进行评审，以建立基线，比需求基线的建立更容易让用户理解，变更控制管理以及风险管理也会更有效。
这就是需求管理计划制定的必要性，项目经理人们对计划的管理普遍感到力不从心，其实计划的目的就是让项目团队与客户一起明确我们的项目远景与范围，并了解我们的项目团队是如何对项目远景与范围的进展变更，以及风险进行管理与控制的。
的内容有什么那？一般我会将其分成两类，一类是项目团队自已要做的功课，这部份在许多情况下是不会与客户沟通的，我称其为补课阶段，这也是一个全新领域项目开始的第一课。
第二类是必须与客户共同完成的，这其中起关键作用的是项目最终使用者以及项目的决策者。
这也是项目计划前的计划，孙子兵法有云“知已知彼，百战不殆”，这开始的第一课就是了解我们的客户与任务。
“好了，师傅，我们先要做什么？”;候哥还是第一个耐不住性子的。
我们第一个要确定的就是切入点，其实就是项目着手的方向；
首先要了解我们的客户是谁？他们是服务于单位领导以及各业务处室，公文处理当然是这个系统的主要任务了。
“我们已经知道这些就可以了呀，师傅”，戒子想还用师傅说呀，这些我们都知道。
公文还是要分成外来文与内部文，这个单位的业务会有大量的数据报表，这些数据报表是各处室之间处理业务经常用到的形式，需要审批的内容肯定是从下属单位到办公室到各业务处理之间运行的，我们不是去过联合办公大厅嘛。
好了，看来需要处理异地公文流转了，同时肯定有许多业务报表。
还有一点，戒子不是网上明星嘛，上网查查，与我们这个客户相近的行业OA软件，了解一下其中的特点。
[不论项目内容是该单位的核心业务还是像OA这样的辅助性系统，一定要了解客户的核心业务内容及流程，有许多项目团队只对项目本身所涉及的业务比较重视，其实这有许多潜在的风险]
[切入点要做的几件事：
了解客户
了解业务
了解行业
了解同行产品
计划的制定就可以从这些角度开始吧。
[这些事在与客户正式开始沟通之前就应尽量了解，这样在与客户交流时会有效的减少在业务上的陌生感，会尽快使客户对项目团队产生必要的信任。
]。
