需求分析的20条法则
对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。
经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”
分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”
经理觉得奇怪：“我不是刚告诉你我的需求了吗？”
分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”
经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”
分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们
并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”
经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”
风险躲在需求的迷雾之后
以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。
拨开需求分析的迷雾
像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：
·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。
下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。
经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。
在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。
优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。
由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。
客户的需求观
客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1、分析人员要使用符合客户语言习惯的表达
需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标
只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s
3、分析人员必须编写软件需求报告
分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4、要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5、开发人员要尊重客户的意见
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6、开发人员要对需求及产品实施提出建议和解决方案
通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无
效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7、描述产品使用特性
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
8、允许重用已有的软件组件
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9、要求对变更的代价提供真实可靠的评估
有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
10、获得满足客户功能和质量要求的系统
每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
11、给分析人员讲解您的业务
分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
12、抽出时间清楚地说明并完善需求
客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
13、准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题做出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
14、及时做出决定
分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
15、尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16、划分需求的优先级
绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
17、评审需求文档和原型
客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。
更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
18、需求变更要立即联系
不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
19、遵照开发小组处理需求变更的过程
为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
20、尊重开发人员采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
“需求确认”意味着什么
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”
这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。
需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。
需求分析方法论 原则上，需求分析阶段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中心分析人员或用户理解有误 系统分析人员不可能都是全才，更不可能是行业方面的专家。用户表达的需求，不同的分析人员可能
案例one：教学管理系统（用例驱动的交互式需求获取） 以一个教学管理系统JXGL的分析与设计作为示例，说明用例驱动技术在软件项目开发中的应用。 高等学校的教学管理内容十分丰富，工作繁多。作为一个示例，规定开发教学管理系统JxGL只处理每学期的课程选修注册和学生的成绩管理。教学管理系统JXGL的用户是学校的学生、教师和教学管理员。学生使用JXG系统查询新学期将开设的课程和授课教师的情况，选择自己要学习的课程，并进行登记注册。学生还可以使用JXGL系统查询自己的课程成绩。教师使用JXGL系统查询新学期将开设的课程、参加听课的学生情况，以及学生的考试成绩。教学管理员使用JXGL系统进行教学管理，包括新学期的课程选课注册管理和学生成绩管理。 1.需求描述: 对教学管理系统JXGL要求提供两个方面的服务: (1)选课管理，负责新学期的课程选课注册工作; (2)成绩管理，负责学生成绩管理。 在选课管理方面应填写的用户需求描述如下。 (1)录入与生成新学期课程表 教学管理员在新学期开始前录入新学期课程，打印将开设的课程目录表，供师生参 考选择。若某课程的实际选课学生少于10人，则停开该课程，把该课程从课程目 录表中删除;若某课程的选课学生多于30人，则停止选课。 (2)学生选课注册 新学期开始前一周为选课注册时间，在此期间学生可以选课注册，并且允许改变或 取消注册申请。 每个学生选课不超过4门课程。每门课程最多允许30名学生选课注册。 学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。在 选课注册结束后，教学管理员打印学生选课注册名单和开课通知书，送交有关部门 和授课教师。 (3)查询 可以查询课程信息、学生选课信息和学生、教师信息。 学生、教师、教学管理员可以查询课程表，获得课程信息。查询的关键词以是:课 程名，授课教师名，学分。 教师、教学管理员可以查询学生选课情况。查询的关键词可以是:学生名、程名， 授课教师名，学分。学生只允许查询自己的选课信息，不允许查询别人选课信息。 学生、教师、教学管理员可以查询学生或教师的信息。查询的关键词可以是学生名、 教师名，性别、班级、职称。 (4)选课注册信息的统计与报表生成。 教学管理员对学生的选课注册信息进行统计(按课程，按学生，按班级)，印汇总统 计报表。 在成绩管理方面应填写的用户需求描述如下: (1)成绩录入:
物流需求预测 (河北工程大学管理科学与工程阮俊虎） 物流需求是指一定时期内社会经济活动对生产、流通、消费领域的原材料、半成品和 成品、商品以及废旧物品、废旧材料等的配置作用而产生的对物在空间、时间和费用方面 的要求，涉及运输、库存、包装、装卸搬运、流通加工以及与之相关的信息需求等物流活 动的诸方面[1]。物流需求的度量可以采用价值量和实物量两种度量体系。实物量意义上 的物流需求主要表现为不同环节和功能的具体作业量，如货运量、库存量、加工量、配送 量等；价值量意义上的物流需求是所有物流环节全部服务价值构成的综合反映，如物流成本、物流收入、供应链增值等 [2]。 物流需求预测是根据物流市场过去和现在的需求状况，以及影响物流市场需求变化的 因素之间的关系，利用一定的判断、技术方法和模型，对物流需求的变化及发展趋势进行 预测。国内外许多专家和学者都对物流需求的预测进行了研究，提出不同的预测方法和手段。物流预测方法可以分为定性预测方法（如德尔菲法和业务人员评估法等）和定量预测 方法，但多数是定量预测方法，因此，本文主要是对国内物流需求定量预测方法进行综述，归为时间序列预测方法、因果关系预测方法、组合预测方法等三类。 1．时间序列预测方法综述 时间序列预测方法是依据从历史数据组成的时间序列中找出预测对象的发展变化规律，以此作为预测依据。常用的时间序列预测模型有增长率法、移动平均法、指数平滑法、随 机时间序列模型、灰色模型、以及在经济领域已经被广泛应用的混沌与分形等。 增长率法指根据预测对象在过去的统计期内的平均增长率，类推未来某期预测值的一 种简便算法。该预测方法一般用于增长率变化不大，或预计过去的增长 [3]趋势在预测期内仍将继续的场合。刘劲等（2002）在利用增长率系数法对百色 地区港口货运量进行了逐一分析。 移动平均法是用一组最近的实际数据值来预测未来一期或几期内产品的需求量的一种 常用方法。当产品需求既不快速增长也不快速下降，且不存在季节性因素时，移动平均法 能有效地消除预测中的随机波动。根据预测时使用的各元素的权重不同，移动平均法可以 分为：简单移动平均和加权移动平均。杨荣英等[4]（2001）在讨论移动平均值的基础上，提出了移动平均线方法，并介绍了运用移动平均线进行物流预测的方法。李海建等[5]（2019）利用二次移动平均线模型对芜湖市物流业发展的规模进行了预测。 指数平滑法是在移动平均法基础上发展起来的一种时间序列分析预测法，它是通过计 算指数平滑值，配合一定的时间序列预测模型对现象的未来进行预测。其原理是任一期的
【系列原创】需求分析的六个原则（四）客户和用户要区别对待 Posted by 不再沉默 on 2008-10-30 10:39:19View 2981Comments17客户和用户根据产品的定位有时候是一致的，有时候则是分离的，这个大家都很清楚，通常来说，做企业级消费产品的客户和用户通常是分离的，做大众级消费产品的客户和用户通常是一致的，但也不是绝对，例如公务用轿车，应该是大众消费类产品，但是它多所面对的客户和用户通常是分离的，客户是各类政府公务部门，用户则是具体的操作者，也就是这些单位的工作人员。 具体什么是客户，什么是用户，我就不花很大的篇幅来介绍了，我想大家肯定都非常熟悉他们之间的区别的，其实简单一句话就可以概括：客户一定是掏钱的，用户不一定是掏钱的。 作为产品经理，其实在规划一个产品的时候，需要重点考虑的就是基于产品而要面对的这两类人群（其实还有一类，叫buyer，可以翻译成购买者，看了一些这方面的资料，感觉国内是把客户和购买者合为一体了，这样做其实也有好处，就是可以把抽象的客户概念在营销过程中具体成一个实际的人）。 04年的时候，我在一家为企业提供信息化服务的公司，负责企业信息化产品的管理，一次，我们的一个销售谈了一家半官方性质的公益组织，他们找到我们想用我们的产品搭建一套企业信息系统，包含内部信息管理和外部信息发布，但是那个销售人员只会拉单，对于具体的产品则不是很熟悉，因此，在确定了基本意向和他们的大致需求后，我就陪同这个销售人员一起去见这个准客户。 和政府客户谈单与企业谈单就是不一样，企业客户会直入主题，深入了解你产品的方方面面，但是政府客户就不一样了，本来想着花半天时间和客户沟通一下就可以了，结果一上午过去了，都没谈到实质的内容，客户倒是挺热情，中午的时又是他买单（呵呵，其实都是公家的钱）请客吃饭，搞的我们都觉得要是这单子不给对方优惠，我们都对不住人家。 下午继续聊呗，下午的时候他才找了一个他们单位里负责硬件维护的人和我们谈，离开的时候，热情的拉着我的手，对我们说“你们谈吧，具体的我就不管了，XX（维护硬件的那个人），你好好和小X（我的姓）他们了解一下，以后这个系统就是你的工作了”，说完，端着茶杯就到自己的屋子里醒酒去了。 具体和接下来这个哥们怎么谈的就不说了，但是因为这也是我第一次和政府类客户打交道，还真感觉有些不适应，但是通过这次谈单也给了我一些新的启发。 1、客户是客户，用户是用户，他们的关注点是完全不一样的。 就拿这个客户来说，之所以要上信息系统，目的就是为了响应国家政府机关上网的号召，说的直白一些，基本属于完成上级任务，做好政绩工程的动机，至于系统上去以后怎么用，怎么才能用好就不是他们要考虑的，而用户（也就是具体和我们谈的人）对于领导为什么要上这个系统就不会关注太多了，反正我就是一个一般工作人员，领导安排什么就做什么就行了，因此，在那天接下来的交流中，这个人就非常仔细地了解我们的产品到底是什么情况，都有那些功能，甚至都可以了解应该如何具体使用了，因为对于他来说，最关键的怎么能够用好这个产品，不要出意外而引起领导的不满。
培训需求分析的方法和工具 培训需求分析是企业培训的出发点，也是最重要的一步工作。如果需求分析不准确，就会让接下来的培训偏离轨道，做无用功，浪费企业的人力、物力和财力，却收不到应有的效果。企业要进行有效的需求分析，就必须采取合适方法和工具，本文全面介绍了通常情况下培训需求分析使用的方法以及对应的工具。 一、需求分析的方法和工具 1.1 调研问卷法 调研问卷法是最普遍也最有效的收集资料和数据的方法之一。一般由培训部门设计一系列培训需求相关问题，以书面问卷的形式发放给培训对象，待培训对象填写之后再收回进行分析，获取培训需求的信息和数据。 调研问卷法进行培训需求分析，可以遵循以下五个步骤，见表1： 在设计调研问卷的问题时，应该注意下几个问题： 1、问题尽量简短，并注意使用简单的、固定用法的术语，避免使用读者不了解或者容易引起歧义的名词； 2、一个问题只涉及一件事，避免“结构复杂”的问句； 3、题目设计要简单，不要使作答者作计算或逻辑推理； 4、避免出现诱导答案的问题，保证作答者完全陈述自己观点。
备注：填表时在对应的内容下面用“√”标明。 1.2 访谈法 访谈法也是数据收集的一种重要方法。它是指为了得到培训需求的数据和信息，与访谈对象进行面对面交流的活动过程。这个过程不只是收集硬性数据，比如事实、数据等，包括印象、观点、判断等信息。 访谈法可以遵循以下几个步骤进行，见表3：
1.3现场取样法 现场取样法一般较多使用于服务性行业的培训需求调查（如饭店、卖场等），是通过选取培训对象现场实际工作的部分片段进行分析，以确定培训需求的一种分析方法。现场取样法主要包括两种形式：拍摄和取样。 拍摄是指在培训对象的工作环境中安装监控录影机、摄像机等拍摄设备，对培训对象的现场工作过程进行实际拍摄，事后通过录影带进行观察分析，得出培训需求结论。表5为拍摄样板的示例。
需求预测方法 常用的物资需求预测方法主要包括基于时间序列模型的移动平均预测法、指数平滑预测法、趋势外推预测法等;基于因果分析模型的回归分析预测法，基于统计学习理论以及结构风险最小原理的支持向量机预测方法，基于人工智能技术的人工神经网络算法。归纳如图1： 图1：物资需求预测方法 一、 时间序列法 1.定义：将预测对象按照时间顺序排列起来，构成一个所谓的时间序列，从所构成的这一组时间序列过去的变化规律，推断今后变化的可能性及变化趋势、变化规律，就是时间序列预测法。 2.概况： 时间序列法主要考虑以下变动因素：①趋势变动，②季节变动，③循环变动，④不规则变动。 若以S t ，T t ，C t ，I t 表示时间序列的季节因素S t ，长期趋势波动、季节性变动、不规则变动．则实际观测值与它们之间的关系常用模型有 加法模型： 乘法模型： 混合模型： 时间序列预测一般反映三种实际变化规律：趋势变化、周期性变化、随机性变化。 t t t t I S T x ++=t t t t I S T x ??=)() )t t t t t t t t I T S x b I T S x a +?=+?=
3.时间序列常用分析方法：移动平均法、指数平滑法、季节变动法等 （1）移动平均法 ①简单移动平均法：将一个时间段的数据取平均值作为最新时间的预测值。该时间段根据要求取最近的。例如：5个月的需求量分别是10，12，32，12，38。预测第6个月的需求量。 =27。 可以选择使用3个月的数据作为依据。那么第6个月的预测量Q=32+12+38 3 ②加权移动平均法：将每个时段里的每组数根据时间远近赋上权重。例如：上个例子，3个月的数据，可以按照远近分别赋权重0.2，0.3，0.5。那么第6个月的预测量Q=0.2×32+0.3×12+0.5×38=29（只是在简单移动平均的基础上考虑了不同时段影响的权重不同，简单移动平均默认权重=1.） （2）指数平滑法 基本思想：预测值是以前观测值的加权和，且对不同的数据给予不同的权数，新数据给予较大的权数，旧数据给予较小的权数。 指数平滑法的通用算法： 指数平滑法的基本公式：St=aYt+(1-a)St-1 式中， St--时间t的平滑值； Yt--时间t的实际值； St-1--时间t-1的平滑值； a--平滑常数，其取值范围为[0,1] 具体方法：一次指数平滑、二次指数平滑、三次指数平滑。 方法的选取：指数平滑方法的选用，一般可根据原数列散点图呈现的趋势来确定。当时间数列无明显的趋势变化，可用一次指数平滑预测。如呈现直线趋势，选用二次指数平滑法；若实际数据序列呈非线性递增趋势，采用三次指数平滑预测方法。如呈现抛物线趋势，选用三次指数平滑法。或者，当时间序列的数据经二次指数平滑处理后，仍有曲率时，应用三次指数平滑法。 （3）季节变动法 根据季节变动特征分为：水平型季节变动和长期趋势季节变动 ①水平型季节变动: 是指时间序列中各项数值的变化是围绕某一个水平值上下周期性的波动。若时间序列呈水平型季节变动，则意味着时间序列中不存在明显的长期趋势变动而仅有季节变动和不规则变动。
3、原则第二点：第三方可能会遗漏或补充一些额外的需求。 每个人都期望产品能做好，这种强烈的成功心理容易让人们产生日晕心理，从而影响我们对需求的筛选。 4、原则第三点：对第三方的自由发挥不应抱怨和生气，而是将其视为客户。 客户是第一位的，而他们又是我们的客户，因此，我们应该心平气和的对待他们的想法，无论这些想法是出于公还是出于私的。 需求分析的六个原则（四）客户和用户要区别对待 1、需求分析第四个原则：客户和用户要区别对待。 客户是客户，用户是用户，有时候一致，有时候分离，这是我们首先要搞清楚的。 2、原则第一点：产品为最终用户设计，需求的功能转换为最终用户的使用要求而确定。 用户决定产品，我们需求工作基于用户，始于用户，归于用户。 3、原则第二点：为客户寻找价值上的需求。 客户是多样的，价值导向也是多样的，我们的产品能否承载多样化的客户价值决定了产品能否实现最终的交换。 4、原则第三点：用户的利益高于一切。 产品的最终价值是通过用户来体现的，脱离了用户的产品，就是“皮之不存，毛将焉附”。 需求分析的六个原则（五）用最简单的文字工具记录需求 1、需求分析第五个原则：用最简单的文字工具记录需求。 客户并不麻烦，需求也不复杂，麻烦的是我们把一切做的太复杂了。 2、原则第一点：所有人都能懂的东西，最不容易出错。 没有人喜欢复杂的东西，需求也不例外。 3、原则第二点：不需要再学习的东西，最不容易出错。 产品是需求的表现，没有人喜欢复杂的产品，要做到这一点，就从需求开始吧。 4、原则第三点：不要希望客户能花更多的时间来了解需求转换后的原型。 我费些事，客户就可以省些事，客户省事了，我们最终也就省事了。
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.在程序的描述与分析中，用以指明数据来源.数据流向和数据处理的辅助图形是( )
需求分析的六个原则（六）天下没有免费的午餐 在前面的文章中，已经说到了这个问题，客户向我们提出的需求都是他内心最期望我们能够满足的，我看到一个朋友的留言，我觉的非常好，他是这么说的： “客户不是我们的竞争对手，他没有理由来欺骗我们，因为欺骗我们的最终结果就是使我们做出不符合他们需求的产品”，“如果说我们的产品有问题，那么首先应该从我们身上找问题，而不是客户”。 我非常赞同这位朋友的观点，这个观点其实也表明了需求分析原则六所强调的第一点：客户从来没有不合理的需求。 理解这点其实很简单。 客户购买我们的产品，是由各种各样的因素决定的，有价格的因素，有服务的因素，但从根本来看，还是因为我们的产品能够比其他的同类产品更好地解决客户的问题（当然，最终的购买还是多个因素综合作用的结果，也就是所谓的“性价比”），客户在使用我们产品的过程中，一方面自身会有新的需求产生，另一方面则发现我们目前的产品无法满足或者有效的满足这些需求，因此，他就会把这些新的需求反馈给我们，并期望我们能够在接下来的产品中能有所改进。 这是一个再正常不过的逻辑，我想没有一个客户会向我们提出不合理甚至是虚假的需求，因为这样做的结果最终只能是两败俱伤，只有我们的竞争对手会这样做。 有朋友会说了，嗯，你说的这点没有问题，但是，我却感觉客户提出的好多需求虽然真实，合理，但是却是不现实的，这又该如何解决呢？ 果然如此吗？ 要回答这个问题，得从两个方面来考虑。 1、客户提出的需求有不现实的吗？ 何为现实呢？客观存在的就是现实的，也就是说，只要客户提出了一个需求，那么就说明客户肯定是有这样的需求的。 之所以我们认为某个需求不现实，根本在于我们没有搞清楚这个客观是基于哪一方的。这里强调一点，这种客观是基于客户一方的，而非我们一方的。 也就是说，有时候我们认为这个需求不现实，仅仅是从我们自己的角度来看待的，我们不是客户，不应该替客户判断某个需求的现实性。 还有一种情况是什么呢？
需求分析方法 一需求分析概括 需求分析应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S＝｛D1，D2，D，…Dn｝ 问题域Di由若干问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di＝｛P1，P2，P3，…Pn｝ 问题Pi有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj＝｛F1，F2，F3，…Fk｝ 需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时，应该注意两个问题： 1.最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质，以便选用最合适 的技术来实现此需求 2.需求说明不能有”二义性”，更不能前后矛盾。如果有二义性或前后矛盾，即要重新分 析此需求。 二需求分析方法论 第一阶段：“访谈式”
第一阶段是和具体用户方的领导层、业务层人员的访谈沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。 建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。 实现手段：访谈、调查表格 输出成果：调查报告、业务流程报告 第二阶段：“诱导式” 结合第一阶段的基本信息，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式，启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、习惯性。用户可以操作简单演示的DEMO，感受整个业务流程的设计合理性、准确性等等问题，以及提出改进意见和方法。 实现手段：诱导（拜访）、原型演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：“确认式” 此阶段在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段。这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。通过审查，提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归到需求分析报告中）
1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面，需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。 在性能方面，需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面，需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面，需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求，识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。开发人员通过调查研究，要理解当前系统的工作模型和用户对新系统的设想与要求。 此外，在需求的获取时，还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如，多长时间需要对系统做一次备份，系统对运行的操作系统平台有何要求，发生错误后重启系统允许的最长时间是多少等。
遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求，开发人员应该采取科学的需求获取方法。在实践中，获取需求的方法有很多种，比如，问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析，开发人员便可以得到一些有用的信息。采用这种方法时，调查问卷的设计很重要。一般在设计调查问卷时，要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制，自由灵活，能够激发用户的思维，使他们能尽可能地阐述自己的真实想法。但是，对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的，用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理，但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈，进而了解到用户的意见，是最直接的需求获取方法。为了使访谈有效，在进行访谈之前，开发人员要首先确定访谈的目的，进而准备一个问题列表，预先准备好希望通过访谈解决的问题。在访谈的过程中，开发人员要注意态度诚恳，并保持虚心求教的姿态，同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样，开发人员要根据用户的身份特点，进行提问，给予启发。当然，进行详细的记录也是访谈过程中必不可少的工作。访谈完成后，开发人员要对访谈的收获进行总结，澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。
第11章、需求管理与预测心得报告 第三组 王仕奇、吴芝颖、何纯绵 吴嘉诚、陈怡君、黄君婷11.1需求管理&11.3需求的组成 在此篇需求管理与预测，理解到预测是企业长期规划的基础，对公司与其重大的管理决策都相当重要。规划者，应探索未来。在规划过程中，欲达成预定目标，须因应环境变化，方能做出最佳的判断。而且，预测系用以评估未来环境中，影响组织运作之事件的评估工具。故预测可谓评估事件于未来可能发生的状况，此为作业规划最常见的技术，以提供管理者作为拟订计划的假设或前提。在实务上，预测往往无法达到百分之百的准确度，主要是因为企业环境中有太多因素无法确定，所以相对于要追求百分之百的预测准确度，企业须持续地监控预测数据并学习如何顺应不正确的预测，反而更为重要。而于章节中有提到需求的组成，可让我知道预测有哪些因子，利用这些因素来判断并达成预测的精准度。常见的趋势型态亦然。 11.2预测的类型&11.4时间序列分析 1.时间序列分析 企业对于预测资金投入是否正确是相当重要，尤其身处于变动的环境中，例如在竞争相当激烈，企业每一个动作都是决胜的关键，所以在本章中可以得到某几种预测模式如（质化，时间序列分析，因果关系，模拟四种），当中时间序列分析较为重要，这都可以利用历史的数据来预估你未来几季的销售量，这代表可以控制投放多少成本在生产产品，以免浪费。以企业应可依据预测的时间范围，需求的准确度，是否有适合的人员等因素来选择预测模式。选择预测模式时，如企业的弹性是需要快速响应的时候，预测需求的准确性相对也会较低，然而，当
预测的结果需作为一项大型资本投资决策时，同样亦需要较精确的预测值。 2.时间序列的分解 时间序列介绍了一个预测的方式，包含着各种因子。我觉得该分析方式不仅可应用在生产管理，还能够分析于其他地方，例如，我报告当中的＂艳遇个数＂也能够做为一个分析的对象。该分析模式能够在数据之中找到不少信息，例如，艳遇的状况是有增长的趋势，还是有下跌的趋势？艳遇的次数会因为季节而产生变化吗，是否在夏季有较好的表现，而冬季则反之？ 而这些分析模型也因此更能够应用在生活状况，我们能够从收集数据中判读出我们想要的资料。例如，前八个月总共艳遇次数48次，那是否意味着接下来第九个月，将会出现6次的艳遇？然而或许该权重分配不均，前四个月整天宅在家只有4次记录，后四个月每天开开心心的出门于是有44次的纪录，那么，在第九个月的状况，假若也是开开心心的出门，就能够将分配给前四个月的纪录权重下降，后四个月的纪录权重上升，预估出第九个月能碰到11次的艳遇。或是，我完全不考虑前七个月总共28次的艳遇，只在乎第八个月20次的艳遇：这样第八个月权重设为1，得到第九个月将可能遇到20次艳遇的解。 我想，学以致用就能从这些步骤中看出。我们从各式各样的管道中学到了一些知识，这些知识本来是用在该领域的，但我们能够融会贯通，应用于生活，得到更多样性的变化。比方说，总共48次的艳遇次数，在每个月的数据分别是：0,1,1,2,5,7,12,20，从数据数据中显示艳遇次数有一个上升的趋势，而且呈现惊人的上涨。 那第九个月还等什么？冲出去街道掳人回家了啦！ 3.指数平滑 指数平滑法是生产预测中常用的一种方法。也用于中短期经济发展趋势预测，所有预测方法中，指数平滑是用得最多的一种。简单的全期平均法是对时间
需求分析与测试的重要性 读《软件工程案例教程》有感 对于学习软件工程这门课程，我认为有许多东西要学习。其实在我看来学习这门课程的精髓是学习一种方法。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。读完软件工程案例教程这本书，我觉得自己受益匪浅。 整本书的内容逻辑很清晰明了，由浅入深循序渐进，首先我就大概描述下我们所学的内容，第一章是从整体分析软件工程这门学科的发展和所处的社会环境，接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模和测试等。对于这本书我主要对需求分析和测试比较感兴趣，在这我要着重的谈一些自己的心得体会以及自己的看法。 一．需求分析 1.1需求分析的重要性 一款成功的软件是建立在成功的需求分析之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。由此我们可以看出需求分析的重要性。 需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。 其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是"很明显"的信息。最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织的执行需求的获取活动。 1.2需求分析的原则 （1）需求分析必须能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构，而功能域反映上述3方面的控制信息。 （2）需求分析要把一个复杂问题按功能进行分解并逐层细化。通常，软件系统要处理的问题如果太大、太复杂就很难理解，若划分成几部分，并确定各部分间的接口，就可完成整体的功能。在需求分析过程中，软件系统的用户需求中的数据、功能和行为都应细化。 （3）需求建模。模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为，这些模型是软件工程中下一阶段进行系统设计的基础。 1.3需求分析的注意事项
浅析卷烟需求预测的基本方法当前，卷烟市场呈现“工、商、零”三维一体的新型格局，市场的卷烟货源投放来自于卷烟需求预测，卷烟需求预测工作的虚实影响到卷烟市场的货源满足率。作为最贴近市场、最了解市场、最熟悉客户的客户经理，我们无疑在卷烟市场需求预测方面占有举足轻重的地位，其预测准确率的高低直接关系到“按客户订单组织货源”的可行性及“卷烟市场营销上水平”的进程。 卷烟需求预测就是在卷烟市场调研和对卷烟销售历史数据分析的基础上，运用科学分析方法，对市场需求及未来变化趋势进行分析研究，从而预测未来市场需求和变化趋势的过程。卷烟需求预测一般分为定性预测法和定量预测法。定性预测法是利用对业务知识熟悉、具有丰富经验和较强的综合分析能力的业务人员或专家学者，根据卷烟销售历史资料和相关资料，对卷烟未来销售趋势做出性质上的判断和预测。 定量预测法则是利用销售历史资料，运用一定的数学分析方法和数学模型，找到数据或影响变量之间的规律性联系，以此对卷烟需求或销售的变化趋势做出定量的分析和预测。 卷烟是一种特殊消费商品，其销量以时间为序列，呈现一定的销售规律，但由于消费者的不确定因素，单靠定性或定量预测方法是不能准确预测其销量的。在实际工作中，往往是定性和定量分析和预测方法结合使用。以定性分析确定卷烟市场需求发展趋势，然后以定量预测方法确定数学模型，从而对卷烟市场需求和销售变化
情况做出准确和精确的判断和预测。下面，我将结合“镇巴辖区卷烟销售情况”，对现用的卷烟需求预测方法之“移动平均法”做以实例说明。一、现有方法介绍： <一）、方法说明： 移动平均预测法是一种重要的时间预测方法，它能反映数据的变化趋势，具有较好的修匀历史数据、消除随机波动影响的作用。对具有长期趋势变动和季节性变动的时间序列数据，经过移动平均调整后，可以消除不规律的变动，从而较好地揭示经济现象的长期发展趋势。<二）、计算公式： n y y y M n t t t t ---+++= K 211 注： 1 t M 为第t 期的移动平均值， t y 代表第t 期的实际销量，n 代表平均预测法的跨 度周期<通常取n=3、n=5） <三）、方法步骤： 见下表，以镇巴2018年5月份需求预测为例： 镇巴2018年5月份需求预测(移动平均法>
公司法经典案例分析全面深入的 我们都会接触到，公司法中的经典案例分析有什么呢？看完 ___的公司法经典案例的分析后你就会明白了！ 一道司法考试中公司法关于诉讼制度经典案例，问题如下： 第二十二条公司股东会或者股东大会、董事会的内容违反、规的无效。股东会或者股东大会、董事会的会议召集程序、表决方式违反法律、行政法规或者公司章程，或者决议内容违反公司章程的，股东可以自决议作出之日起六十日内，请求人院撤销。 第三十四条股东可以要求查阅公司账簿。股东要求查阅公司会计账簿的，应当向公司提出书面请求，说明目的。公司有合理根据认为股东查阅会计账簿有不正当目的，可能损害公司合法利益的，可以拒绝提供查阅，并应当自股东提出书面请求之日起十五日内书面答复股东并说明理由。公司拒绝提供查阅的，股东可以请求 ___要求公司提供查阅。第七十五条自股东会会议决议通过之日起六十日内，股东与公司不能达成股权收购协议的，股东可以自股东会会议决议通过之日起九十日内向 ___提起诉讼。 第一百五十二条董事、高级管理人员有本法第一百五十条规定的情形的，有限责任公司的股东、股份有限公司连续一百八十日以上
单独或者合计持有公司百分之一以上股份的股东，可以书面请求监事会或者不设监事会的有限责任公司的监事向 ___提起诉讼;监事有本法第一百五十条规定的情形的，前述股东可以书面请求董事会或者不设董事会的有限责任公司的执行董事向 ___提起诉讼。 监事会、不设监事会的有限责任公司的监事，或者董事会、执行董事收到前款规定的股东书面请求后拒绝提起诉讼，或者自收到请求之日起三十日内未提起诉讼，或者情况紧急、不立即提起诉讼将会使公司利益受到难以弥补的损害的，前款规定的股东有权为了公司的利益以自己的名义直接向 ___提起诉讼。 他人侵犯公司合法权益，给公司造成损失的，本条第一款规定的股东可以依照前两款的规定向 ___提起诉讼。 第一百八十三条公司经营管理发生严重困难，继续存续会使股东利益受到重大损失，通过其他途径不能解决的，持有公司全部股东表决权百分之十以上的股东，可以请求 ___解散公司。 对于以上诉讼制度怎样列原告、被告? 【解答】《公司法》司法解释(二)第四条股东提起解散公司诉讼应当以公司为被告。原告以其他股东为被告一并提起诉讼的， ___
结构化分析（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 图描述出来。这样的表达与当前系统完全对应，因此用户容易理解。 ⑵抽象出当前系统的逻辑模型;
欢迎阅读 软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整?性，促 使用户在软件设计启动之前周密地、全面地思考软件需求； 2）了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准；
3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依据； 需求分析的具体内容可以归纳为六个方面：软件的功能需求，软件与硬件或其他外部系统接口，软件的非功能性需求，软件的反向需求，软件设计和实现上的限制，阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内容应正确、完整、一致和可验证。此外，为保证软件设计质量，便于软件功能的休整和验证，软件需求表达无岔意性，具有可追踪性和可修改性。2.1、????? 软件功能需求 1 不 （5）??? 尽可能不使用“待定”这样的词。所有含有待定内容的需求都不是完整的文件，如果出现待定的部分，必须进行待定部分内容说明，落实负责人员、落实实施日期。 2）功能描述的无岔意性和可追踪性 需求功能描述的无岔意性、可追踪性和规范化： （1）??? 功能描述必须清晰地描述出怎样输入到怎样输出，并且输入、输出描述应对应有数据流描述、控制流描述图，这些描述必须与其它地方描述一致；
（2）??? 可以用语言、方程式、决策表、矩阵或图等对功能的描述。如果选用语言描述必须使用结构化的语言，描述前必须说明该步骤（或子功能）的执行是顺序，选择， 重复，还是并发，然后说明步骤逻辑。整个描述必须单入单出。 （3）??? 描述时，每一个功能名称和参照编号必须唯一，且不要将多个功能混在一起进行描述，这样便于功能的追踪和修改。 （4）??? 功能描述应注意需求说明和程序设计的区别。需求设计仅仅是软件的功能设计，它给出软件运行的的外部功能描述，以及为了实现这一外部功能必须做哪些事情（采 2.2、 2.3、 （2）??? 处理容限、精度、采样参数的分辨率，误差处理等； （3）??? 可靠性的MTBF要求，可维护性、安全性要求等。（对可能的不正常的输入给以正常响应是可靠性的重要内容，这属于功能性需求。） 2.4、????? 软件反向需求 软件的反向需求描述软件在那些情况下不能做什么。这一条是随软件实际要求而定。有两类情形需要采用反向需求的形式。第一种情况：某些用户需求适宜采用反向形式说明，如数据安全性要求属于这类形式。第二种情况：对一些可靠性和安全性要求较高的软件，有些必须描述软件不能做些什么。如控制点火时序，我们必须交代清楚在那些情况下不能点火，否则会造成故障。