1、需求定律：对于正常商品而言，需求量随价格上升而减少，随价格
下降而增加，二者成反比。
2、预算线：在消费者收入与商品价格既定的条件下，消费者花掉其全
部货币收入后能够买到的商品组合。
3、边际效用：每增加一单位某种商品的消费所引起的总效用的增加。
4、边际替代率：消费者用一种商品代替另一种商品的意愿程度。
5、边际产量：某种生产要素每增加一单位劳动所引起的总产量的增加。
6、边际技术替代率：增加每单位劳动所能够替代的资本数量。
7、边际收益：每增加一单位产品的销售所引起的总收益的增加值。
8、边际成本：增加最后一单位产量所引起的总成本增加。
9、边际效用递减规律：随着消费者对某种商品的消费量的增加，它从
该商品连续增加的消费单位中所得到的的边际效用是递减的。
10、边际生产率递减规律：在技术给定和其他投入要素不变情况下，
当把一种可变生产要素投入到一种或几种不变生产要素中时，最初这种生产要素增加会使产量增加，但当它的增加超过一定限度时，增加的产量会递减，最后会使产量绝对减少。
11、等成本线?预算线：在生产者成本和生产要素价格既定条件下，
生产者所能购买的两种要素最大组合线。
12、无差异曲线：能给消费者带来同等程度满足的两种商品的不同数
量组合的点的轨迹。
13、等产量曲线：两种生产要素的不同数量组合可以带来相同产量的
曲线。
14、消费者剩余：消费者愿意支付的价格与实际支付的价格之间的差
额。
15、生产者剩余：厂商在提高一定数量的某种产品时实际接受的总价
格和愿意接受的最小总价格之间的差额。
16、机会成本：厂商利用同样生产要素所能生产的其他产品最大的价
值。
17、显性成本：厂商购买投入要素的实际支出。
18、隐性成本：厂商自己拥有并被使用于生产活动的成本。
19、派生需求：由于消费者对产品的需求导致厂商对生产要素的需求。
20、边际收益产品：厂商增加一单位生产要素的使用所引起的总收益
的增量。21、边际要素成本：由于厂商增加一单位生产要素所引起的总成本增
加量。
22、价格歧视：在完全垄断和寡头垄断市场上，垄断厂商以不同的价
格出售同一种产品给不同购买者的行为。
23、一级价格歧视：垄断产商格局消费者支付意愿对他销售的每单位
生产要素的最高的可能的价格。
24、二级价格歧视：厂商按照消费者购商品不同数量而确定不同价格。
25、三级价格歧视：厂商把市场划分为两个或多个子市场，并将同种
商品在不同市场按照不同价格销售的行为。
26、边际成本定价：政府要求垄断厂商将产品最高价格定在边际成本
与市场需求曲线交点处。
27、平均成本定价：政府要求垄断厂商将产品最高价格定在平均成本
与市场需求曲线交点处。
28、斯威齐模型/折断的需求曲线：美国经济学家斯威齐为了解释寡
占市场价格刚性问题提出一种假说，认为寡占市场价格之所以是刚性价格，在某一水平固定下来不轻易变动，是因为这种市场的需求曲线不是一条顺滑线而是在某一价格水平出现拐折点然后折转向下倾斜。
29、价格领导：在一个寡头垄断行业内，由一家厂商确定价格作为行
业的价格领导者，其他厂商以领导者价格为准制定自己的价格决策。
完全竞争市场
特征：①价格既定②产品同质③资源自由流动④信息充分
价格需求曲线：
P：价格Q：数量D：需求S：供给E：均衡（或期望）e：弹性ed：需求的价格弹性es：供给的价格弹性exy:需求的交叉价格弹性U：效用TU：总效用MU：边际效用CS:消费者剩余MRS：商品的边际替代率L：劳动力K：资本TP:总产量AP：平均产量MP:边际产量MRTS:边际技术替代率C：成本STC：短期总成本TFC：总不变成本TVC：总可变成本TC：总成本AFC：平均不变成本AVC：平均可变成本AC：平均总成本MC：边际成本LTC：长期总成本LAC：长期平均成本SAC：短期平均成本LMC：长期边际成本SMC：短期边际成本TR：总收益AR：平均收益MR：边际收益PS：生产者剩余MP：边际产品VMP：边际产品价值W：劳动价格MRP：边际收益产品MFC：边际要素成本r：利率PEP：价格扩展线
微观所有的公式只有两个，那就是效用论的d（U）/d（X）=0
和生产论的dπ/dl=0(求k的时候就是dk），所有一切的共识全都是从这两个式子加上不同的条件推导出
案例one：教学管理系统（用例驱动的交互式需求获取） 以一个教学管理系统JXGL的分析与设计作为示例，说明用例驱动技术在软件项目开发中的应用。 高等学校的教学管理内容十分丰富，工作繁多。作为一个示例，规定开发教学管理系统JxGL只处理每学期的课程选修注册和学生的成绩管理。教学管理系统JXGL的用户是学校的学生、教师和教学管理员。学生使用JXG系统查询新学期将开设的课程和授课教师的情况，选择自己要学习的课程，并进行登记注册。学生还可以使用JXGL系统查询自己的课程成绩。教师使用JXGL系统查询新学期将开设的课程、参加听课的学生情况，以及学生的考试成绩。教学管理员使用JXGL系统进行教学管理，包括新学期的课程选课注册管理和学生成绩管理。 1.需求描述: 对教学管理系统JXGL要求提供两个方面的服务: (1)选课管理，负责新学期的课程选课注册工作; (2)成绩管理，负责学生成绩管理。 在选课管理方面应填写的用户需求描述如下。 (1)录入与生成新学期课程表 教学管理员在新学期开始前录入新学期课程，打印将开设的课程目录表，供师生参 考选择。若某课程的实际选课学生少于10人，则停开该课程，把该课程从课程目 录表中删除;若某课程的选课学生多于30人，则停止选课。 (2)学生选课注册 新学期开始前一周为选课注册时间，在此期间学生可以选课注册，并且允许改变或 取消注册申请。 每个学生选课不超过4门课程。每门课程最多允许30名学生选课注册。 学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。在 选课注册结束后，教学管理员打印学生选课注册名单和开课通知书，送交有关部门 和授课教师。 (3)查询 可以查询课程信息、学生选课信息和学生、教师信息。 学生、教师、教学管理员可以查询课程表，获得课程信息。查询的关键词以是:课 程名，授课教师名，学分。 教师、教学管理员可以查询学生选课情况。查询的关键词可以是:学生名、程名， 授课教师名，学分。学生只允许查询自己的选课信息，不允许查询别人选课信息。 学生、教师、教学管理员可以查询学生或教师的信息。查询的关键词可以是学生名、 教师名，性别、班级、职称。 (4)选课注册信息的统计与报表生成。 教学管理员对学生的选课注册信息进行统计(按课程，按学生，按班级)，印汇总统 计报表。 在成绩管理方面应填写的用户需求描述如下: (1)成绩录入:
【系列原创】需求分析的六个原则（四）客户和用户要区别对待 Posted by 不再沉默 on 2008-10-30 10:39:19View 2981Comments17客户和用户根据产品的定位有时候是一致的，有时候则是分离的，这个大家都很清楚，通常来说，做企业级消费产品的客户和用户通常是分离的，做大众级消费产品的客户和用户通常是一致的，但也不是绝对，例如公务用轿车，应该是大众消费类产品，但是它多所面对的客户和用户通常是分离的，客户是各类政府公务部门，用户则是具体的操作者，也就是这些单位的工作人员。 具体什么是客户，什么是用户，我就不花很大的篇幅来介绍了，我想大家肯定都非常熟悉他们之间的区别的，其实简单一句话就可以概括：客户一定是掏钱的，用户不一定是掏钱的。 作为产品经理，其实在规划一个产品的时候，需要重点考虑的就是基于产品而要面对的这两类人群（其实还有一类，叫buyer，可以翻译成购买者，看了一些这方面的资料，感觉国内是把客户和购买者合为一体了，这样做其实也有好处，就是可以把抽象的客户概念在营销过程中具体成一个实际的人）。 04年的时候，我在一家为企业提供信息化服务的公司，负责企业信息化产品的管理，一次，我们的一个销售谈了一家半官方性质的公益组织，他们找到我们想用我们的产品搭建一套企业信息系统，包含内部信息管理和外部信息发布，但是那个销售人员只会拉单，对于具体的产品则不是很熟悉，因此，在确定了基本意向和他们的大致需求后，我就陪同这个销售人员一起去见这个准客户。 和政府客户谈单与企业谈单就是不一样，企业客户会直入主题，深入了解你产品的方方面面，但是政府客户就不一样了，本来想着花半天时间和客户沟通一下就可以了，结果一上午过去了，都没谈到实质的内容，客户倒是挺热情，中午的时又是他买单（呵呵，其实都是公家的钱）请客吃饭，搞的我们都觉得要是这单子不给对方优惠，我们都对不住人家。 下午继续聊呗，下午的时候他才找了一个他们单位里负责硬件维护的人和我们谈，离开的时候，热情的拉着我的手，对我们说“你们谈吧，具体的我就不管了，XX（维护硬件的那个人），你好好和小X（我的姓）他们了解一下，以后这个系统就是你的工作了”，说完，端着茶杯就到自己的屋子里醒酒去了。 具体和接下来这个哥们怎么谈的就不说了，但是因为这也是我第一次和政府类客户打交道，还真感觉有些不适应，但是通过这次谈单也给了我一些新的启发。 1、客户是客户，用户是用户，他们的关注点是完全不一样的。 就拿这个客户来说，之所以要上信息系统，目的就是为了响应国家政府机关上网的号召，说的直白一些，基本属于完成上级任务，做好政绩工程的动机，至于系统上去以后怎么用，怎么才能用好就不是他们要考虑的，而用户（也就是具体和我们谈的人）对于领导为什么要上这个系统就不会关注太多了，反正我就是一个一般工作人员，领导安排什么就做什么就行了，因此，在那天接下来的交流中，这个人就非常仔细地了解我们的产品到底是什么情况，都有那些功能，甚至都可以了解应该如何具体使用了，因为对于他来说，最关键的怎么能够用好这个产品，不要出意外而引起领导的不满。
3、原则第二点：第三方可能会遗漏或补充一些额外的需求。 每个人都期望产品能做好，这种强烈的成功心理容易让人们产生日晕心理，从而影响我们对需求的筛选。 4、原则第三点：对第三方的自由发挥不应抱怨和生气，而是将其视为客户。 客户是第一位的，而他们又是我们的客户，因此，我们应该心平气和的对待他们的想法，无论这些想法是出于公还是出于私的。 需求分析的六个原则（四）客户和用户要区别对待 1、需求分析第四个原则：客户和用户要区别对待。 客户是客户，用户是用户，有时候一致，有时候分离，这是我们首先要搞清楚的。 2、原则第一点：产品为最终用户设计，需求的功能转换为最终用户的使用要求而确定。 用户决定产品，我们需求工作基于用户，始于用户，归于用户。 3、原则第二点：为客户寻找价值上的需求。 客户是多样的，价值导向也是多样的，我们的产品能否承载多样化的客户价值决定了产品能否实现最终的交换。 4、原则第三点：用户的利益高于一切。 产品的最终价值是通过用户来体现的，脱离了用户的产品，就是“皮之不存，毛将焉附”。 需求分析的六个原则（五）用最简单的文字工具记录需求 1、需求分析第五个原则：用最简单的文字工具记录需求。 客户并不麻烦，需求也不复杂，麻烦的是我们把一切做的太复杂了。 2、原则第一点：所有人都能懂的东西，最不容易出错。 没有人喜欢复杂的东西，需求也不例外。 3、原则第二点：不需要再学习的东西，最不容易出错。 产品是需求的表现，没有人喜欢复杂的产品，要做到这一点，就从需求开始吧。 4、原则第三点：不要希望客户能花更多的时间来了解需求转换后的原型。 我费些事，客户就可以省些事，客户省事了，我们最终也就省事了。
前言 (3) 第一章课程设计要求 (4) 1.1、设计题目 (4) 1.2、课程设计的目的意义 (4) 1.3、设计的时间及分组 (4) 1.4、课程设计内容 (4) 1.4.1掌握交通规划四阶段交通需求预测的原理方法 (4) 1.4.2学习交通规划软件TransCAD的操作方法 (5) 1.4.3对研究区域提出交通改善策略 (5) 第二章小组成员及任务分配 (6) 第三章四阶段中各阶段做法及成果展示 (6) 3.1 相关资料收集 (6) 3.2 交通发生和吸引预测及平衡 (6) 3.2.1交通区划分原则及划分结果 (6) 3.2.2交通生成预测 (7) 3.2.3 预测结果 (8) 3.3 交通分布预测 (8) 3.4 交通方式划分 (10) 3.5 交通分配预测 (11) 3.6 交通分配评价 (13) 3.7 对我校道路网分析及建议 (14) 3.7.1道路网规划 (14) 3.7.2慢行交通系统设计 (14) 3.7.3道路横断面设计 (15) 3.7.4总结 (15) 第四章 transcad中交通规划四阶段法具体操作 (15) 4.1生成初始路网图 (15) 4.1.1 生成路网前准备 (15) 4.1.2 新建路网层（线层） (16)
4.2 生成小区图 (17) 4.3 在路网与交通区层填入数据并进行人口预测 (18) 4.4 生成小区质心 (19) 4.5 创建网络 (21) 4.6 生成阻抗矩阵 (22) 4.7 对未来年限小区发生与吸引量进行平衡 (23) 4.8 用重力模型进行交通分布预测 (24) 4.9 进行交通分配并查看结果 (25) 4.10 绘制小区质心间的期望线 (27) 4.11 交通方式划分 (27) 第五章总结 (28)
需求分析方法论 原则上，需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力；在具体的任务开展上，以不干扰需求方的自主权为主，除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功，IT中心必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。 其中，需求分析是一个项目的开端，也是项目建设的基石。在以往的信息化建设失败的案例中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用应用管理软件。作为IT中心，必须提醒需求方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时IT 中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、实施上有发言权。 一、如何进行需求分析 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术人员都合适。在写需求说明书时应该注意两个问题： 1、最好为每个需求注释“为什么”，这样可让双方（IT中心、需求方）了解需求的本质，以便选用最合适的技术来实现此需求。 2、需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 二、重点监控需求分析 由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 1、用户说不清楚需求 有些用户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进行应用系统以及网络建设时，需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时，用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。 2、需求自身经常变动 根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 3、IT中心分析人员或用户理解有误 系统分析人员不可能都是全才，更不可能是行业方面的专家。用户表达的需求，不同的分析人员可能
需求分析的六个原则（六）天下没有免费的午餐 在前面的文章中，已经说到了这个问题，客户向我们提出的需求都是他内心最期望我们能够满足的，我看到一个朋友的留言，我觉的非常好，他是这么说的： “客户不是我们的竞争对手，他没有理由来欺骗我们，因为欺骗我们的最终结果就是使我们做出不符合他们需求的产品”，“如果说我们的产品有问题，那么首先应该从我们身上找问题，而不是客户”。 我非常赞同这位朋友的观点，这个观点其实也表明了需求分析原则六所强调的第一点：客户从来没有不合理的需求。 理解这点其实很简单。 客户购买我们的产品，是由各种各样的因素决定的，有价格的因素，有服务的因素，但从根本来看，还是因为我们的产品能够比其他的同类产品更好地解决客户的问题（当然，最终的购买还是多个因素综合作用的结果，也就是所谓的“性价比”），客户在使用我们产品的过程中，一方面自身会有新的需求产生，另一方面则发现我们目前的产品无法满足或者有效的满足这些需求，因此，他就会把这些新的需求反馈给我们，并期望我们能够在接下来的产品中能有所改进。 这是一个再正常不过的逻辑，我想没有一个客户会向我们提出不合理甚至是虚假的需求，因为这样做的结果最终只能是两败俱伤，只有我们的竞争对手会这样做。 有朋友会说了，嗯，你说的这点没有问题，但是，我却感觉客户提出的好多需求虽然真实，合理，但是却是不现实的，这又该如何解决呢？ 果然如此吗？ 要回答这个问题，得从两个方面来考虑。 1、客户提出的需求有不现实的吗？ 何为现实呢？客观存在的就是现实的，也就是说，只要客户提出了一个需求，那么就说明客户肯定是有这样的需求的。 之所以我们认为某个需求不现实，根本在于我们没有搞清楚这个客观是基于哪一方的。这里强调一点，这种客观是基于客户一方的，而非我们一方的。 也就是说，有时候我们认为这个需求不现实，仅仅是从我们自己的角度来看待的，我们不是客户，不应该替客户判断某个需求的现实性。 还有一种情况是什么呢？
1.在软件需求规范中，下述哪些要求可以归类为过程要求( ) A. 执行要求 B. 效率要求 C. 可靠性要求 D. 可移植性要求 2.在软件需求分析和设计过程中，其分析与设计对象可归结成两个主要的对象，即数据和程序，按一般实施的原则，对二者的处理应该( ) A. 先数据后程序 B. 与顺序无关 C. 先程序后数据 D. 可同时进行 3.在下面的叙述中哪一个不是软件需求分析的任务( ) A. 问题分解 B. 可靠性与性要求 C. 结构化程序设计 D. 确定逻辑模型 4.进行需求分析可使用多种工具，但( )是不适用的。 A. 数据流图(DFD) B. 判定表 C. PAD图 D. 数据字典 5.在软件的需求分析中，开发人员要从用户那里解决的最重要的问题是( )
A. 要让软件做什么 B. 要给该软件提供哪些信息 C. 要求软件工作效率怎样 D. 要让软件具有何种结构 6.软件需求分析阶段的工作，可以分为四个方面：对问题的识别.分析与综合.编写需求分析文档以及( ) A. 软件的总结 B. 需求分析评审 C. 阶段性报告 D. 以上答案都不正确 7.各种需求分析方法都有它们共同适用的( ) A. 说明方法 B. 描述方式 C. 准则 D. 基本原则 8.数据流图是常用的进行软件需求分析的图形工具，其基本图形符号是( ) A. 输入.输出.外部实体和加工 B. 变换.加工.数据流和 C. 加工.数据流.数据存储和外部实体 D. 变换.数据存储.加工和数据流
9.判定表和判定树是数据流图中用以描述加工的工具，它常描述的对象是( ) A. 逻辑判断 B. 层次分解 C. 操作条目 D. 组合条件 10.试判断下列叙述中，哪个（些）是正确的( ) a.软件系统中所有的信息流都可以认为是事务流 b.软件系统中所有的信息流都可以认为是变换流 c.事务分析和变换分析的设计步骤是基本相似的 A. a B. b C. c D. b和c 11.决定大型程序模块组织的基本原则的两种交替设计策略为( ) A. 面向用户的原型化和面向的原型化 B. 物理模型与逻辑模型 C. 数据字典和数据流 D. 数据分解和算法分解 12.在程序的描述与分析中，用以指明数据来源.数据流向和数据处理的辅助图形是( )
需求分析的重要性以及如何做好需求分析[转] 收藏 文章出处：https://www.doczj.com/doc/749082986.html,/shinepolo/archive/2008/04/08/1139700.html 为什么以这个为主题写.是因为最近在做一个购物网,需求没有做好,导致做前台的时候商品与图片是1对1的关系,后台添加的时候有很大的弊端.和漏洞不好弥补.不是不好弥补.是牵扯的逻辑太多.如果说改了这个网站可以重做了.所以说很失败. 如果因为一个地方的失误.很可能导致整个项目的失败.那么你最近的所有努力将灰飞烟灭... 那么,如果在项目开始前做好充分的需求.而且需求要做的到位,需求的思维严禁程度至关重要.. (下面为转载) 一、为什么要需求分析 需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死. (这个问题是最典型也是最常见的,现在这个问题一般很好避免,都知道项目的一些敏感性的东西,例如想会有哪些地方设计的不好可能导致以后的使用出现BUG.) 二、需求分析的任务 简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求. 三、需求分析的过程 需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审. 问题识别 就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.
计算题： 一、某公司新设一条生产线，包括A、B、C、D、E五类工作，根据现有资料得知这四类工作所需的标准任务时间为0.4，2.2，1.8，2.0，1.5（小时/件），在估计未来两年每一类工作所需工作量的基础上，见下表： 假设每人每年工作小时数为1200小时，预测未来操作所需的最低人力数。 二、假设有一家企业的人力资源需求与销售额紧密联系，且其劳动生产率每年以5%的比率增加，根据下表的历史数据预测未来三年的实际员工需求： 三、已知某企业当年的营业额是80 000 000元，预计四年后营业额将增长为107 200 000元，生产效率每年提高1%。根据以往市场数据和工作设计推算，每50人能完成50 000 000元的销售额，依次推算四年后企业用人需求。
小组案例讨论：你会计算离职率吗？ 人事部李经理走进总经理办公室，她想总经理可能要和她讨论月度人事报告的事宜，不过她充满信心，因为报告内容详尽，数据分析有条有理，并对下一阶段公司人力资源管理提出了自己的看法，报告应该是完美的。 “你的报告我看过了，总的来说是一份很不错的报告。但我很奇怪，你在计算各部门的人员离职率时，为什么会出现离职率大于100%的情况呢？你能解释一下它代表什么意义呢？”总经理指着她的报告问道。 李经理看着报告，发现后勤部门原来有17人，后来由于后勤部门的保安工作外包给保安公司，清洁工作也外包给清洁公司，后勤部门的人员降到只有5人。按通常离职率计算方法，离职率=离职人数/[(期初在职人数+期末在职人数)/2]*100%，得出的结果是109%。这代表什么意思呢？当初李经理也有疑问，但没有深究下去。现在面对总经理的提问，李经理低下了头：“很抱歉，我确实不知如何解释，可能是计算方式不对，我会尽快找出解决办法。” 李经理很困惑：翻过很多人力资源管理方面的书籍，离职率的计算公式都是按自己所采用的公式，难道这个公式错了吗？否则为什么会出现离职率超过100%的现象呢？如果错了，那离职率到底应该怎样计算呢？ 离职率是企业用以衡量企业内部人力资源流动状况的一个重要指标，通过对离职率的考察，可以了解企业对员工的吸引和员工的满意情况。离职率过高，一般表明企业的员工情绪较为波动、劳动关系存在较严重的矛盾，企业的凝聚力下降，它可导致人力资源成本增加（含直接成本和间接成本）、组织的效率下降。但并不是说员工的离职率越低越好，在市场竞争中，保持一定的员工流动，可以使企业利用优胜劣汰的人才竞争制度，保持企业的活力和创新意识。 按字面理解，离职率应指员工离职的数量占“员工”的比率，也可以理解为每100个员工中有多少个员工离职，因此离职率应不超过100%。在众多的资料中，离职率通常是以某一单位时间的离职人数与正式职工平均人数之比表示，正式职工平均人数又为单位时间期初人数与期末人数的平均值。但按这样的计算方法，就有可能出现上面的情况，即离职率超过100%，难道员工全部离职了吗？如果不考虑其他因素，员工真的全部离职，则按这种方法计算出来的离职率为200%，这与人们通常情况下理解的离职率是矛盾的。离职率怎样计算才合理呢？ 现假设某公司一年的前六个月中每个月的期初人数、期末人数、录用人数、离职人数如下表所示： 该公司在一月份时跳槽员工较多，故二、三月份开始大量招聘新员工，四、五、六月份员工的变动则较为平稳。请讨论用不同的计算方法来求离职率，并给李经理提出合理的计算方法建议。
1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面，需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。 在性能方面，需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面，需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面，需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求，识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。开发人员通过调查研究，要理解当前系统的工作模型和用户对新系统的设想与要求。 此外，在需求的获取时，还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如，多长时间需要对系统做一次备份，系统对运行的操作系统平台有何要求，发生错误后重启系统允许的最长时间是多少等。
遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求，开发人员应该采取科学的需求获取方法。在实践中，获取需求的方法有很多种，比如，问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析，开发人员便可以得到一些有用的信息。采用这种方法时，调查问卷的设计很重要。一般在设计调查问卷时，要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制，自由灵活，能够激发用户的思维，使他们能尽可能地阐述自己的真实想法。但是，对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的，用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理，但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈，进而了解到用户的意见，是最直接的需求获取方法。为了使访谈有效，在进行访谈之前，开发人员要首先确定访谈的目的，进而准备一个问题列表，预先准备好希望通过访谈解决的问题。在访谈的过程中，开发人员要注意态度诚恳，并保持虚心求教的姿态，同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样，开发人员要根据用户的身份特点，进行提问，给予启发。当然，进行详细的记录也是访谈过程中必不可少的工作。访谈完成后，开发人员要对访谈的收获进行总结，澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。
需求分析与测试的重要性 读《软件工程案例教程》有感 对于学习软件工程这门课程，我认为有许多东西要学习。其实在我看来学习这门课程的精髓是学习一种方法。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。读完软件工程案例教程这本书，我觉得自己受益匪浅。 整本书的内容逻辑很清晰明了，由浅入深循序渐进，首先我就大概描述下我们所学的内容，第一章是从整体分析软件工程这门学科的发展和所处的社会环境，接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模和测试等。对于这本书我主要对需求分析和测试比较感兴趣，在这我要着重的谈一些自己的心得体会以及自己的看法。 一．需求分析 1.1需求分析的重要性 一款成功的软件是建立在成功的需求分析之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。由此我们可以看出需求分析的重要性。 需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。 其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是"很明显"的信息。最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织的执行需求的获取活动。 1.2需求分析的原则 （1）需求分析必须能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构，而功能域反映上述3方面的控制信息。 （2）需求分析要把一个复杂问题按功能进行分解并逐层细化。通常，软件系统要处理的问题如果太大、太复杂就很难理解，若划分成几部分，并确定各部分间的接口，就可完成整体的功能。在需求分析过程中，软件系统的用户需求中的数据、功能和行为都应细化。 （3）需求建模。模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为，这些模型是软件工程中下一阶段进行系统设计的基础。 1.3需求分析的注意事项
需求分析的20条法则 对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。 经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。” 分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。” 经理觉得奇怪：“我不是刚告诉你我的需求了吗？” 分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。” 经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？” 分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们
并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。” 经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。” 风险躲在需求的迷雾之后 以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。 拨开需求分析的迷雾 像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容： ·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。 ·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
结构化分析（SA）方法 结构化开发方法(Structured Developing Method)是现有的软件开发方法中最成熟，应用最广泛的方法，主要特点是快速、自然和方便。结构化开发方法由结构化分析方法(SA法)、结构化设计方法(SD 法)及结构化程序设计方法(SP 法)构成的。 结构化分析(Structured Analysis，简称SA 法)方法是面向数据流的需求分析方法，是70 年代末由Yourdon,Constaintine 及DeMarco 等人提出和发展，并得到广泛的应用。它适合于分析大型的数据处理系统，特别是企事业管理系统。 SA 法也是一种建模的活动，主要是根据软件内部的数据传递、变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。 1 SA 法概述 1.SA 法的基本思想 结构化分析(Structured Analysis，简称SA 法)是面向数据流的需求分析方法，是70年代由Yourdon,Constaintine 及DeMarco 等人提出和发展，并得到广泛的应用。 结构化分析方法的基本思想是“分解”和“抽象”。
分解：是指对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决。 图4 是自顶向下逐层分解的示意图。顶层抽象地描述了整个系统，底层具体地画出了系统的每一个细节，而中间层是从抽象到具体的逐层过渡。 抽象：分解可以分层进行，即先考虑问题最本质的属性，暂把细节略去，以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的属性表示一个自系统的方法就是“抽象”。 2.SA 法的步骤 ⑴建立当前系统的“具体模型”; 系统的“具体模型”就是现实环境的忠实写照，即将当前系统用DFD 图描述出来。这样的表达与当前系统完全对应，因此用户容易理解。 ⑵抽象出当前系统的逻辑模型;
需求分析的六个原则（五）用最简单的文字工具记录需求 需求是信息的具体表现，我们知道，一个信息进行一次传递，需要具备以下5个条件： 1、信息本身 2、信息发出者 3、信息承载介质 4、信息接收者 5、信息所处的环境 这5个条件的综合作用决定了这个信息最终的质量。 具体到需求这种和产品经理每日息息相关的信息上，我们都必须面对一个非常现实的问题，就是：如何来保证我们获得的信息的衰减性是最小，并且我们又如何能把这种信息尽量少衰减的传递给下一个接收者。 既然本章的标题是“用最简单的文字工具记录需求”，并且在本系列的第三章中，我提供了一个自己整理的《需求反馈文档》模板，属于记录市场需求的第一个工具，因此，在本
章里，就以这个模板工具为例，详细来说明一下如何把需求记录 好。 第一部分： 这个部分比较简单，主要是说明原始需求提出者的信息，具体包括三项： 1、需求来源：我这里是以我所在公司的情况写的，大家可以根据自己情况来定，其实这部分就是说明需求的市场细分，这个需求是个人终端客户提出的，还是企业级客户提出的。 2、来源方名称：说明需求提出者的名称，如果是个人，就是姓名，如果是企业，就是企业名称。 3、来源时间：说明需求提出者的反馈时间。 这项比较关键，因为咱们通常会发现，客户向公司的是市场人员反馈了一个需求后，市场人员往往不能及时反馈给我们，要么是想起来的时候才说，要么就是等着开会的时候才说，要么就是右耳朵进，左耳朵出，根本没放在心上。
因此，我在公司里一直强调有需求一定要及时通过这个文档反馈给产品部，当然，要让相关部门的每个人都真正重视起来，一是需要时间，二是需要规范。 第二部分： 这个部分就是针对内部第三方的了，主要是说明需求获取方的信息，在前面的文章说过了，许多行业的产品经理很少有直接面对客户的机会，因此，我们往往还是通过第三方来得到市场需求，具体包括5项： 1、需求提交人：这里用需求提交人，而不是需求来源，就是为了区别客户和第三方。 2、提交时间：说明这个需求是第三方什么时候加入到需求池中的。 3、所在部门：说明第三方所在的部门。 4、工作职位：说明第三方在该部门内的工作岗位。 5、PST位置：PST是什么呢？就是产品战略表（Product Strategy Table），关于PST 的解释这里不多说，对于第三方来说，只要说明这个需求是针对那个产品线或者产品的即可。 第三部分： 这个部分就是针对需求本身的了，大家可以看出来，一共就三部分，非常简单，为什么呢？就是因为大家要知道，对于客户来说，他们在提出需求的时候，根本不可能按照我们期望的那样分门别类的告诉你。 有一次，我们的一个产品经理和一个客户进行需求沟通，他首先问客户“你对我们产品的功能有什么想法呢？” 对于客户来说，产品功能还是比较熟悉的，也多少说了一些，但是接下来问题就出现了，他又问客户“你对产品的UI有什么想法呢？”。 客户一下子就糊涂了，想了半天，问他“UI是什么？”，他可能也意识到这个词太专业了，于是又给客户解释说“UI就是界面，也就是产品的外观”，客户这次似乎是多少明白了一些，但是明显感觉在说的时候有些不够放开了，为什么呢？大家可以分析一下，你把UI就解释为界面或者产品外观，实际上在限制客户的思维，客户在每说一个需求的时候，就会想“我说的这个是和界面或者外观有关系的吗？”。 这或许还好一些，UI还比较容易解释，如果是UE呢，谁敢说能让客户很清楚的知道UE 是什么意思呢？用户体验？估计用户会更没体验了，呵呵！
欢迎阅读 软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整?性，促 使用户在软件设计启动之前周密地、全面地思考软件需求； 2）了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准；
3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依据； 需求分析的具体内容可以归纳为六个方面：软件的功能需求，软件与硬件或其他外部系统接口，软件的非功能性需求，软件的反向需求，软件设计和实现上的限制，阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内容应正确、完整、一致和可验证。此外，为保证软件设计质量，便于软件功能的休整和验证，软件需求表达无岔意性，具有可追踪性和可修改性。2.1、????? 软件功能需求 1 不 （5）??? 尽可能不使用“待定”这样的词。所有含有待定内容的需求都不是完整的文件，如果出现待定的部分，必须进行待定部分内容说明，落实负责人员、落实实施日期。 2）功能描述的无岔意性和可追踪性 需求功能描述的无岔意性、可追踪性和规范化： （1）??? 功能描述必须清晰地描述出怎样输入到怎样输出，并且输入、输出描述应对应有数据流描述、控制流描述图，这些描述必须与其它地方描述一致；
（2）??? 可以用语言、方程式、决策表、矩阵或图等对功能的描述。如果选用语言描述必须使用结构化的语言，描述前必须说明该步骤（或子功能）的执行是顺序，选择， 重复，还是并发，然后说明步骤逻辑。整个描述必须单入单出。 （3）??? 描述时，每一个功能名称和参照编号必须唯一，且不要将多个功能混在一起进行描述，这样便于功能的追踪和修改。 （4）??? 功能描述应注意需求说明和程序设计的区别。需求设计仅仅是软件的功能设计，它给出软件运行的的外部功能描述，以及为了实现这一外部功能必须做哪些事情（采 2.2、 2.3、 （2）??? 处理容限、精度、采样参数的分辨率，误差处理等； （3）??? 可靠性的MTBF要求，可维护性、安全性要求等。（对可能的不正常的输入给以正常响应是可靠性的重要内容，这属于功能性需求。） 2.4、????? 软件反向需求 软件的反向需求描述软件在那些情况下不能做什么。这一条是随软件实际要求而定。有两类情形需要采用反向需求的形式。第一种情况：某些用户需求适宜采用反向形式说明，如数据安全性要求属于这类形式。第二种情况：对一些可靠性和安全性要求较高的软件，有些必须描述软件不能做些什么。如控制点火时序，我们必须交代清楚在那些情况下不能点火，否则会造成故障。
软件项目需求分析的20条法则 以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。 拨开需求分析的迷雾 像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那幺，我们就拨开雾影，分析一下需求的具体内容： ·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。 ·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。 ·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。 ·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。 ·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。 前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其它任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。 下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什幺任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。 经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。 在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希
河南城建学院 《城市交通规划》课程设计说明书 课程名称： _____________ 城市交通规划___________________ 题目：城市交通规划四阶段法课程设计_________ 专业： _____________ 交通工程____________________ 学生姓名: _______________________________________________ 学号： _________ 0______________________________ 指导教师: ______________ 李爱增、吴冰花、张蕾 ____________ 设计教室: ____________ 10#B504、505 _____________________ 开始时间:2016 年06月3日 完成时间:2016年06月3日 课程设计成绩:
指导教师签名: 年—月—日1.交通生成预测 (1) 1.1交通生成总量的预测 (1) 1.1.1理论知识 (1) 1.1.2分部计算过程 (1) 1.2发生与吸引预测 (6) 1.2.1理论知识 (6) 1.2.2分部计算过程 (6) 2.................................................................................................................................................. 交通分布预测 (9) 2.1理论知识 (9) 2.2计算过程 (10) 3.交通方式划分 (14) 3.1换算基础资料 (14) 3.2分部计算过程 (17) 4.交通分配 (17) 4.1理论知识 (17) 4.2分布计算过程 (18) 4.3预测结果 (19) 5.设计小结 (20) 5.1设计过程中遇到的问题及解决办法 (20) 5.2对城市交通规划及交通需求预测的认识及看法 (20) 5.3设计收获及感想体会 (21)