《需求分析教学》PPT课件.ppt

《《需求分析教学》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《需求分析教学》PPT课件.ppt（32页珍藏版）》请在三一办公上搜索。

1、需求分析,教学内容1.需求分析的任务与步骤 需求分析的任务、需求分析的步骤、需求分析的原则。2.需求分析方法l 面向数据流的分析方法基本符号、基于数据流的分析方法、数据字典。l 面向数据结构的分析方法 Jackson系统开发方法、Warnier-Orr方法。3.需求规格说明与评审教学要求 掌握：需求分析的方法 理解：需求分析的任务和原则,3.1需求分析的任务与步骤3.1.1需求分析的任务 1.确定对系统的综合需求2.分析系统的数据需求3.导出系统的逻辑模型4.修正系统开发计划5.开发原型系统,3.1.2需求分析的步骤1.调查研究2.分析与综合3.书写文档4.需求分析评审3.1.3需求分析的原则

2、1.必须能够表达合理解决问题的数据域和功能域2.自顶向下、逐层分解问题3.要给出系统的逻辑视图和物理视图,3.2需求分析方案1.支持数据域分析的机制2.功能表示的方法3.接口的定义4.问题分解的机制以及对抽象的支持5.逻辑视图和物理视图6.系统抽象模型,3.2.1面向数据流的需求分析方法3.2.2数据流图1.数据流图的含义2.数据流图的特性3.数据流图基本符号4.数据流图的用途5.数据流图的优缺点6.数据流图画法7.数据流图与其他流程图的差别8.实例,3.2.2数据字典1.数据字典的定义2.数据字典的内容 数据流数据项数据结构数据存储处理逻辑外部实体,3.定义数据的方法4.数据字典的用途 5.

3、数据字典的实现,3.3图形工具3.3.1层次方框图Warnier图IPO图,3.4需求规格说明与评审3.4.1需求规格说明的主要内容1.引言2.任务概述3.数据描述4.功能要求5.性能需求6.运行需求7.其他要求8.附录,3.4.2需求分析的评审3.4.3需求分析评审的方法1.验证需求的一致性2.验证需求的现实性3.验证需求的完整性和有效性,作业 教材第57页 2 4 6 8,对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开

4、发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。,经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”经理觉得奇怪：“我不是刚告诉你我的需求了吗？”分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与

5、实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”,经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”经理坚持道：“行了，行了，我们没有那么多的时间。让我来

6、告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”,风险躲在需求的迷雾之后 以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见需求分析奠定了软件工程和项目管理的基础,拨开需求分析的迷雾 像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲

7、，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：业务需求反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。用户需求描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。功能需求定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。需求分析报告报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管

8、理以及相关项目功能中起着重要作用。,客户的需求观 客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。1、分析人员要使用符合客户语言习惯的表达 需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。2、分析人员要了解客户的业务及目标 只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优

9、秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。,3、分析人员必须编写软件需求报告 分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正

10、需要的产品。4、要求得到需求工作结果的解释说明 分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等,5、开发人员要尊重客户的意见 如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一

11、共同目标所做出的努力表示尊重。,6、开发人员要对需求及产品实施提出建议和解决方案 通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。,7、描述产品使用特性 客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开

12、发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。8、允许重用已有的软件组件 需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。,9、要求

13、对变更的代价提供真实可靠的评估 有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。10、获得满足客户功能和质量要求的系统 每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。11、给分析人员讲解您的业务 分析人员要依靠客户

14、讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。,12、抽出时间清楚地说明并完善需求 客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。13、准确而详细地说明需求 编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时

15、，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义,14、及时作出决定 分析人员会要求客户作出一些选择和决定，这些决定

16、包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。15、尊重开发人员的需求可行性及成本评估 所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。16、划分需求的优先级 绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需

17、求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。,17、评审需求文档和原型 客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。18、需求变更要立即联系 不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是

18、不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。,19、遵照开发小组处理需求变更的过程 为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。20、尊重开发人员采用的需求分析过程 软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利,