《《软件工程》教学课件05软件需求分析.ppt》由会员分享，可在线阅读，更多相关《《软件工程》教学课件05软件需求分析.ppt（82页珍藏版）》请在金锄头文库上搜索。
1、The Definition PhaseSystem EngineeringSoftware project planningSoftware requirements analysisSoftware scopeRefined确定做什么确定做什么?2003.01.10 SOFTWARE ENGINEERING软件需求分析软件需求分析众众所所周周知知，在在解解决决问问题题之之前前必必须须首首先先理理解解所所要要解解决决的的问问题题。对对问问题题理理解解得得越越透透彻彻，就就越越容容易易解解决决它它。当当我我们们完完全全、彻彻底底地地理理解解了了一一个个问问题题的的时时候候，通通常常就就已已经解
2、决了这个问题。经解决了这个问题。2003.01.10 SOFTWARE ENGINEERING软件需求分析软件需求分析为为了了更更好好地地理理解解问问题题，人人们们常常常常采采用用建建立立问问题题模模型型的的方方法法。所所谓谓模模型型，就就是是为为了了理理解解事事物物而而对对事事物物作作出出的的一一种种抽抽象象，是是对对事事物物的的一一种种无无歧歧义义的的书书面面描描述述。通通常常，模模型型由由一一组组图图示示符符号号和和组组织织这这些些符符号号的的规规则则组组成成，利利用用它它们们来来定定义义和和描描述述问问题题域域中中的的术术语语和和概概念念。更更进进一一步步讲讲，模模型型是是一一种种思思
3、考考工工具具，利利用用这这种种工具可以把知识规范地表示出来。工具可以把知识规范地表示出来。2003.01.10 SOFTWARE ENGINEERING软件需求分析软件需求分析模模型型可可以以帮帮助助我我们们思思考考问问题题、定定义义术术语语、在在选选择择术术语语时时作作出出适适当当的的假假设设，并并且且可可以帮助我们保持定义和假设的一致性。以帮助我们保持定义和假设的一致性。在在对对目目标标系系统统进进行行分分析析的的初初始始阶阶段段，面面对对大大量量模模糊糊的的、涉涉及及众众多多专专业业领领域域的的、错错综综复复杂杂的的信信息息，系系统统分分析析员员往往往往感感到到无无从从下下手手。模模型型
4、提提供供了了组组织织大大量量信信息息的的一种有效机制。一种有效机制。2003.01.10 SOFTWARE ENGINEERING软件需求分析软件需求分析为为了了开开发发复复杂杂的的软软件件系系统统，系系统统分分析析员员应应该该从从不不同同角角度度抽抽象象出出目目标标系系统统的的特特性性，使使用用精精确确的的表表示示方方法法构构造造系系统统的的模模型型，验验证证模模型型是是否否满满足足用用户户对对目目标标系系统统的的需需求求，并并在在设设计计过过程程中中逐逐渐渐把把和和实实现现有有关关的的细细节节加加进进模模型型中中，直直至至最最终终用用程程序序实实现模型。现模型。2003.01.10 SOF
5、TWARE ENGINEERING软件需求分析软件需求分析对对于于那那些些因因过过分分复复杂杂而而不不能能直直接接理理解解的的系系统统，特特别别需需要要建建立立模模型型，建建模模的的目目的的主主要要是是为为了了减减少少复复杂杂性性。人人的的头头脑脑每每次次只只能能处处理理一一定定数数量量的的信信息息，模模型型通通过过把把系系统统的的重重要要部部分分分分解解成成人人的的头头脑脑一一次次能能处处理理的的若若干干个个子子部部分分，从从而而减减少少系系统统的的复杂程度。复杂程度。2003.01.10 SOFTWARE ENGINEERING软件需求分析软件需求分析一一旦旦建建立立起起模模型型之之后后，
6、这这个个模模型型就就要要经经受受用用户户和和各各个个领领域域专专家家的的严严格格审审查查。由由于于模模型型的的规规范范化化和和系系统统化化，因因此此比比较较容容易易暴暴露露出出系系统统分分析析员员对对目目标标系系统统认认识识的的片片面面性性和和不不一一致致性性。通通过过审审查查，往往往往会会发发现现许许多多错错误误，发发现现错错误误是是正正常常现现象象，这这些些错错误误可可以以在在成成为为目目标标系系统统中中的的错错误误之前，就被预先清除掉。之前，就被预先清除掉。2003.01.10 SOFTWARE ENGINEERING软件需求分析软件需求分析通通常常，通通过过快快速速建建立立原原型型，让
7、让用用户户和和领领域域专专家家经经过过亲亲身身体体验验，对对系系统统模模型型进进行行更更有有效效的的审审查查。模模型型常常常常会会经经过过多多次次必必要要的的修修改改，通通过过不不断断改改正正错错误误的的或或不不全全面面的的认认识识，最最终终，软软件件开开发发人人员员对对问问题题有有了了透透彻彻的的理理解解，从从而而为为后后续续的的开开发发工工作奠定了坚实基础。作奠定了坚实基础。2003.01.10 SOFTWARE ENGINEERING软件需求分析的任务软件需求分析的任务为为了了开开发发出出真真正正满满足足用用户户需需求求的的软软件件产产品品，首首先先必必须须确确切切地地知知道道用用户户的
8、的需需求求。对对软软件件需需求求的的深深入入理理解解，是是软软件件开开发发工工作作获获得得成成功功的的前前提提和和关关键键，不不论论我我们们把把设设计计和和编编码码工工作作做做得得多多么么出出色色，不不能能真真正正满满足足用用户户需需求求的的软软件件只会给用户带来失望，给开发者带来烦恼。只会给用户带来失望，给开发者带来烦恼。需需求求分分析析是是软软件件定定义义时时期期的的最最后后一一个个阶阶段段，它它的的基基本本任任务务是是准准确确地地回回答答“系系统统必必须须做做什什么么?”?”这个问题。这个问题。2003.01.10 SOFTWARE ENGINEERING软件需求分析的任务软件需求分析的
9、任务需需求求分分析析是是定定义义软软件件的的最最后后一一个个阶阶段段，也也是是最最重重要要的的一一个个阶阶段段，其其基基本本任任务务是是对对目目标标系系统提出完整、准确、清晰、具体的要求。统提出完整、准确、清晰、具体的要求。需求分析的结果是系统开发的基础，关系到工程的需求分析的结果是系统开发的基础，关系到工程的成败和软件产品的质量。因此，必须采取行之有效成败和软件产品的质量。因此，必须采取行之有效的办法对需求分析进行严格的审查和验证。的办法对需求分析进行严格的审查和验证。BoehmBoehm对软件需求的定义：研究一种无二义性的对软件需求的定义：研究一种无二义性的表达工具，它能为用户和软件人员双
10、方都接受表达工具，它能为用户和软件人员双方都接受并能够把并能够把“需求需求”严格地、形式地表达出来。严格地、形式地表达出来。 2003.01.10 SOFTWARE ENGINEERING软件需求分析软件需求分析在在编编程程过过程程中中，事事情情总总是是会会变变得得清清晰晰；只只有有在在检检验验了了软软件件的的早早期期版版本本后后项项目目共共利利益益者者才才能能够够更更好好地地理理解解需需求求；事事情情变变化化太太快快，需需求求工工程程是是浪浪费费时时间间；底底线线是是开开发发一一个个可可运运行行的的程序，其他都是次要的。程序，其他都是次要的。构构成成这这些些论论点点的的原原因因在在于于其其中
11、中也也包包含含了了部部分分的真实情况（尤其是不超过一个月的小项目）。的真实情况（尤其是不超过一个月的小项目）。2003.01.10 SOFTWARE ENGINEERING信息技术项目成功的信息技术项目成功的3要素要素用户参与程度用户参与程度高级管理层的支持高级管理层的支持明确的需求说明明确的需求说明2003.01.10 SOFTWARE ENGINEERING软件需求分析的困难软件需求分析的困难懂懂得得应应用用领领域域专专业业知知识识的的人人很很可可能能不不是是实实际际编编写写软软件件的的人人。这这些些应应用用领领域域的的专专家家因因而而必必须将他们的需求告诉软件开发的技术人员。须将他们的需
12、求告诉软件开发的技术人员。口口头头、书书面面语语言言中中所所固固有有的的模模糊糊性性给给领领域域专专家家与与开开发发软软件件的的技技术术人人员员之之间间的的交交流流增增添添了了一层复杂性。一层复杂性。我我们们都都拥拥有有自自己己不不同同的的背背景景知知识识，它它导导致致基基于以往的经验对相同的现象做出不同的解释。于以往的经验对相同的现象做出不同的解释。 2003.01.10 SOFTWARE ENGINEERING软件需求分析的困难软件需求分析的困难在在系系统统开开发发的的每每个个阶阶段段应应该该让让未未来来用用户户参参与与，不不论论这这些些未未来来用用户户是是否否是是领领域域专专家家。在在软
13、软件件开开发发过过程程中中，软软件件开开发发的的计计划划有有必必要要允允许许最最终用户来评价该系统。终用户来评价该系统。不不幸幸的的是是，许许多多软软件件企企业业的的人人相相信信只只需需要要在在系系统统开开发发早早期期阶阶段段和和开开发发完完成成时时，向向用用户户了了解解专专业业知知识识。这这种种态态度度很很可可能能会会导导致致许许多多软软件开发项目的失败。件开发项目的失败。 2003.01.10 SOFTWARE ENGINEERING软件需求分析的任务软件需求分析的任务1 1、确定系统的综合要求、确定系统的综合要求系统功能要求系统功能要求系统性能要求：如响应时间、存储容量、安全性能等。系统
14、性能要求：如响应时间、存储容量、安全性能等。系系统统运运行行要要求求：主主要要是是对对系系统统运运行行时时的的环环境境要要求求，如系统软件、外存和数据通信接口等。如系统软件、外存和数据通信接口等。 将来可能提出的要求：为扩充及修改作准备。将来可能提出的要求：为扩充及修改作准备。2 2、分析系统的数据要求、分析系统的数据要求3 3、导出系统的逻辑模型、导出系统的逻辑模型: :用用DFDDFD、DDDD等描述等描述4 4、修修正正系系统统的的开开发发计计划划：通通过过需需求求对对系系统统的的成成本本及及进进度有了更精确的估算，可进一步修改开发计划。度有了更精确的估算，可进一步修改开发计划。2003
15、.01.10 SOFTWARE ENGINEERING软件需求分析的任务软件需求分析的任务-分析系统的数据要求分析系统的数据要求任任何何一一个个软软件件系系统统本本质质上上都都是是信信息息处处理理系系统统，系系统统必必须须处处理理的的信信息息和和系系统统应应该该产产生生的的信信息息在在很很大大程程度度上上决决定定了了系系统统的的面面貌貌，对对软软件件设设计计有有深深远远影影响响，因因此此，必必须须分分析析系系统统的的数数据据要要求求，这这是是软软件件需需求求分分析析的的一一个重要任务。个重要任务。2003.01.10 SOFTWARE ENGINEERINGSoftware Requireme
16、nts Analysis软件需求分析软件需求分析有几种原因使需求分析变得困难：有几种原因使需求分析变得困难：（1 1）客户说不清楚需求或无需求，用户意见不统）客户说不清楚需求或无需求，用户意见不统一，错误的需求等；一，错误的需求等；（2 2）需求自身经常变动；）需求自身经常变动；（3 3）分析人员或客户理解有误，缺乏共同语言，）分析人员或客户理解有误，缺乏共同语言，交流障碍。交流障碍。让我们先接受让我们先接受“需求会变动需求会变动”这个事实吧，这个事实吧，免得在需求变动时惊慌失措。错误观点：反免得在需求变动时惊慌失措。错误观点：反正正“需求会变动需求会变动”，软件也很灵活，所以只，软件也很灵活
17、，所以只做简单的需求分析就开始编程更有效。做简单的需求分析就开始编程更有效。2003.01.10 SOFTWARE ENGINEERINGSoftware Requirements Analysis软件需求分析软件需求分析如果客户本身就懂软件开发，能把需求说得清如果客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。清楚楚，这样的需求分析将会非常轻松、愉快。如果客户全不懂软件，但信任软件开发方，这如果客户全不懂软件，但信任软件开发方，这事也好办。分析人员可以引导客户，先阐述常事也好办。分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定规的需求，再由
18、客户否定不需要的，最终确定客户真正的需求。客户真正的需求。最怕的就是最怕的就是“不懂装懂不懂装懂”或者或者“半懂充内行半懂充内行”的客户，他们会提出不切实际的需求。如果这的客户，他们会提出不切实际的需求。如果这些客户甚至觉得自己是上帝的父母，那么沟通些客户甚至觉得自己是上帝的父母，那么沟通和协商都会很困难。和协商都会很困难。 2003.01.10 SOFTWARE ENGINEERINGSoftware Requirements Analysis软件需求分析软件需求分析在进行需求分析时必须注意：在进行需求分析时必须注意： （1 1）尽可能地分析清楚哪些是稳定的）尽可能地分析清楚哪些是稳定的需求
19、，哪些是易变的需求。以便在进行需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定系统设计时，将软件的核心建筑在稳定的需求上。的需求上。（2 2）在合同中一定要说清楚）在合同中一定要说清楚“做什么做什么”和和“不做什么不做什么”。如果合同含含糊糊，。如果合同含含糊糊，日后扯皮的事情就多。日后扯皮的事情就多。2003.01.10 SOFTWARE ENGINEERINGSoftware Requirements Analysis软件需求分析软件需求分析系统分析人员不可能都是全才。客户表达的需求，系统分析人员不可能都是全才。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人
20、员不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活。理解错了，可能会导致开发人员白干活。所以分析人员写好需求说明书后，要请客户方的各所以分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太明白，个代表验证。如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。次论证需求说明书是否正确。 由于客户大多不懂软件，他们可能觉得软件是万能由于客户大多不懂软件，他们可能觉得软件是万能的，会提出一些无法实现的需求。有时客户还会把的，会提出一些无法实现的需求。有
21、时客户还会把软件系统分析人员的建议或答复给想歪了。软件系统分析人员的建议或答复给想歪了。 2003.01.10 SOFTWARE ENGINEERINGSoftware Requirements Analysis软件需求分析软件需求分析应该先了解宏观的问题，再了解细节的问题。应该先了解宏观的问题，再了解细节的问题。了解需求的方式有好几种：了解需求的方式有好几种： （1 1）直接与客户交谈。）直接与客户交谈。（2 2）有些需求客户讲不清楚，分析人员又猜）有些需求客户讲不清楚，分析人员又猜不透，这时就要请教专家。不透，这时就要请教专家。（3 3）有很多需求可能客户与分析人员想都没）有很多需求可能客
22、户与分析人员想都没有想过。要经常分析优秀的和蹩脚的同类软有想过。要经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，看到了缺点就件，看到了优点就尽量吸取，看到了缺点就引以为戒。引以为戒。2003.01.10 SOFTWARE ENGINEERINGAnalysis Concept and PrinciplesA complete understanding of software require-ments is essential to the success of a software development effort.The requirements analysis task
23、is a process of discover,refinement,modeling,and specification.Both the developer and customer take an active role in requirements analysis and specification.Requirements analysis is a software engineering task that bridges the gap between system-level software allocation and software design.2003.01
24、.10 SOFTWARE ENGINEERINGSoftware Requirements AnalysisRequirements analysis enables the system engineer to specify software function and performance,indicate softwares interface with other system elements,and establish constraints that software must meet.Requirements analysis allows the software eng
25、ineer(often called analyst in this role) to refine the software allocation and build models of the data,functional,and behavioral domains that will be treated by software.2003.01.10 SOFTWARE ENGINEERINGSoftware Requirements AnalysisRequirements analysis provides the software designer with models tha
26、t can be translated in to data,architectural, interface,and procedural design.Finally,the requirements specification provides the developer and the customer with the means to access quality once software is build.2003.01.10 SOFTWARE ENGINEERING系统分析员应有的能力系统分析员应有的能力分析、综合、抽象能力；分析、综合、抽象能力；较好的口头和书面表达能力；较
27、好的口头和书面表达能力；很强的专业基础和软件过程经验；很强的专业基础和软件过程经验；所开发的项目的专业背景，等。所开发的项目的专业背景，等。分析员通常负责开发软件需求规格说明书，分析员通常负责开发软件需求规格说明书，并参加所有的复审并参加所有的复审制定软件需求规格说明书，不仅仅是软件开制定软件需求规格说明书，不仅仅是软件开发人员的事，用户也起着至关重要的作用。发人员的事，用户也起着至关重要的作用。2003.01.10 SOFTWARE ENGINEERINGSoftware Requirements AnalysisSoftware requirements analysis may be d
28、ivided into five areas of effort:1)Problem recognition(问题识别问题识别);2)Evaluation(评价评价) and synthesis(综合综合);3)Modeling(建模建模);4)Specification(软件需求规格说明软件需求规格说明);and5)Review(评审或复审评审或复审).2003.01.10 SOFTWARE ENGINEERINGProblem recognitionInitially,the analyst studies the system speci-fication(if one exists)
29、and the software project plan.It is important to understand software in a system context and to review the software scope that was used to generate planning estimates. Next,communication for analysis must be established so that problem recogn-ition is ensured.The goal of analyst is recogn-ition of t
30、he basic problem elements as perceived by the user/customer.2003.01.10 SOFTWARE ENGINEERINGEvaluation and synthesisThroughout evaluation and solution synthesis, the analysts primary focus is on “what,” not “how.”what data does the system produce and consume,what functions must the system perform,wha
31、t interface are defined,and what constraints apply?During evaluation and solution synthesis activity, the analyst creates models of the system in an effort to better understand data and control flow, functional processing and behavioral operation, and information content.2003.01.10 SOFTWARE ENGINEER
32、INGCommunication TechniquesFacilitated Application Specification Techniques (FAST:方便的应用规范技术方便的应用规范技术):This approach encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of the solution,negotiate different approach,and specify
33、 a preliminary set of solution requirements.2003.01.10 SOFTWARE ENGINEERINGCommunication TechniquesQuality Function Deployment(QFD) is quality management technique that translates the needs of the customer into technical require-ments for software.QFD emphasizes understanding of what is valuable to
34、the customer and then deploying these value throughout the engineering process.QFD identifies three types of requirements:1)Normal; 2)Expected; 3)exciting.2003.01.10 SOFTWARE ENGINEERINGAnalysis PrinciplesThe information domain of a problem must be represented and understood.The function must is def
35、ined.The behavior of software must be represented.The models must be partitioned in a manner that uncovers details in a layered fashion.The analysis process should move from essential information toward implementation detail.2003.01.10 SOFTWARE ENGINEERINGEssential and Implementation ViewsAn essenti
36、al view of software requirements presents the functions to be accomplished and information to be process without regard to implementation.The implementation view of software require-ments presents the real world manifestation of processing functions and information structures. In some cases,a physic
37、al representation is developed as the first step in software design.2003.01.10 SOFTWARE ENGINEERINGThe Software Requirements Specification软件计划系统定义需求分析商业需要其他系统元素（硬件等）的功能代价、资源、进度软件功能软件作用范围软件需求规格说明书2003.01.10 SOFTWARE ENGINEERINGThe Software Requirements Specification最好全部由用户最好全部由用户/需求者编写，但实际上都需求者编写，但实际
38、上都由开发者和用户由开发者和用户/需求者共同编写。需求者共同编写。该说明书是分析和综合结果的描述，包括软该说明书是分析和综合结果的描述，包括软件功能、性能、接口、有效性和逻辑模型的件功能、性能、接口、有效性和逻辑模型的描述描述软件需求规格说明书的描述方法：软件需求规格说明书的描述方法：1)自然语言自然语言2)格式化语言格式化语言3)形式化语言形式化语言2003.01.10 SOFTWARE ENGINEERINGThe Software Requirements Specification（SRS outline）1)Introduction2)Information description3
39、)Functional description4)Behavioral description5)Validation criteria6)Bibliography7)Appendix编写初步用户使用手册和确认测试计划编写初步用户使用手册和确认测试计划2003.01.10 SOFTWARE ENGINEERINGThe Software Requirements Specification正确性正确性无二义性无二义性完整性完整性一致性一致性非计算机人员可以理解非计算机人员可以理解可修改性可修改性可跟踪性可跟踪性2003.01.10 SOFTWARE ENGINEERINGSpecificati
40、on Review复审：该阶段完成标志（由用户复审：该阶段完成标志（由用户/需求者，管需求者，管理部门，开发人员共同承担）理部门，开发人员共同承担）Review of a software requirements specifica-tion(and/or prototype) is conducted by both software developer and customer.Because the specification forms the foundation for design and subsequent software engineering activities,e
41、xtreme care should be taken in conducting the review.2003.01.10 SOFTWARE ENGINEERINGSpecification Review采用需求确认检查单进行需求评审采用需求确认检查单进行需求评审正式技术评审正式技术评审2003.01.10 SOFTWARE ENGINEERING验证软件需求的原则验证软件需求的原则作为需求分析阶段工作的复查手段，应该对作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性以及其他需功能的正确性、完整性和清晰性以及其他需求给予评价。求给予评价。一致性：所有的需求是一致的，没有任
42、何矛盾。一致性：所有的需求是一致的，没有任何矛盾。 完整性：需求必须是完整的，没有任何功能和性完整性：需求必须是完整的，没有任何功能和性能的遗漏。能的遗漏。 现实性：完成需求所要求的软件和硬件条件，目现实性：完成需求所要求的软件和硬件条件，目前是可以达到的。前是可以达到的。 有效性：需求是有效的，可以解决用户的问题有效性：需求是有效的，可以解决用户的问题 。2003.01.10 SOFTWARE ENGINEERINGSummaryAnalysis must focus on the information, functional,and behavioral domains of a pro
43、blem.To better understand what is required,models are created, the problem is partitioned,and representations that depict the essence of requirements and later, implementation detail,are developed.2003.01.10 SOFTWARE ENGINEERINGSummaryIn many cases,it is not possible to completely specify a problem
44、at an early stage.Prototyping offers an alternative approach that results in an executable model of software from which requirements can be refined.开开发发原原型型系系统统将将使使系系统统的的需需求求更更完完整整、准准确确、合合理理，对对提提高高开开发发成成功功率率，对对提提高高软软件件质质量量都都有有很很大大好好处处。但是要增加开发的成本。但是要增加开发的成本。对于用户和系统分析员都不熟悉的系统，以及批量对于用户和系统分析员都不熟悉的系统，以及批
45、量生产的软件，应开发原型系统。生产的软件，应开发原型系统。2003.01.10 SOFTWARE ENGINEERINGSummaryA software requirements specification is developed as a consequence of analysis. Review is essential to ensure that developer and customer have the same perception of the system.Unfortunately, even with the best of methods,the proble
46、m is that problem keeps changing.2003.01.10 SOFTWARE ENGINEERING需求分析方法（需求分析方法（1）功能分析方法功能分析方法(Function Decomposition)(Function Decomposition) 以以系系统统需需要要提提供供的的功功能能为为中中心心来来组组织织系系统统。首首先先定定义义各各种种功功能能，然然后后把把功功能能分分解解为为若若干干子子功功能能, ,同同时时定定义义功功能能之之间间的的接接口口。子子功功能能还还可可继继续续分分解解。数数据据结结构构是是根根据据功功能能/ /子子功功能能的的需需要要设
47、设计计的的。易易开开始始，难难深深入入，也也难难于于检检验验分分析析结结果果的的正正确确性性，同同时时对对需需求求变变化化的的适适应应能能力力差差，局局部部错错误误和和局局部部修修改改很很容容易易产产生生全全局性的影响。局性的影响。2003.01.10 SOFTWARE ENGINEERING需求分析方法（需求分析方法（2）结构化分析方法（数据流法）结构化分析方法（数据流法） 其其基基本本策策略略是是跟跟踪踪数数据据流流，从从问问题题空空间间到到某某种种表表示示的的映映射射方方法法，由由数数据据流流图图（DFD图图）表表示示。SASA法法更更加加强强调调问问题题域域的的研研究究，有有严严格格的
48、的原原则则，当当系系统统较较复复杂杂时时，很很难难检检验验分分析析的的正正确确性性，对对需需求求变变化化的的适适应应能能力力较较差差，没没有有一一种种严严格格的的、可可操操作作的的转转换换规规则则，所所以以从从分分析到设计的过渡比较困难。析到设计的过渡比较困难。2003.01.10 SOFTWARE ENGINEERING需求分析方法（需求分析方法（3）信息建模法信息建模法 是是从从数数据据的的角角度度对对现现实实世世界界建建立立模模型型的的, ,基基本工具是本工具是E-RE-R图。图。面向对象的分析方法面向对象的分析方法 面面向向对对象象的的分分析析方方法法（OOA）的的关关键键是是识识别别
49、问问题题域域内内的的对对象象，分分析析它它们们之之间间的的关关系系，并并建建立立起起系系统统模模型型。OOAOOA采采用用封封装装、继继承承、消消息息通通信信等等原原则则，使使问问题题域域的的复复杂杂性性得得到到了了控控制。制。-UML-UML2003.01.10 SOFTWARE ENGINEERINGAnalysis ModelingStructured Analysis(SA):is a classical modeling methodObject-Oriented Analysis(OOA)Other analysis method:Data Structured Systems D
50、evelopment (DSSD);Jackson System Development(JSD);Structured Analysis and Design Technique (SADT)2003.01.10 SOFTWARE ENGINEERINGAnalysis ModelingThe analysis model must achieve three primary objectives:(1)to describe what the customer requires,(2)establish a basis for the creation of a software desi
51、gn,and(3)to define a set of requirements that can be validated once the software is built.2003.01.10 SOFTWARE ENGINEERING结构化分析方法（结构化分析方法（SA）结构化开发方法（结构化开发方法（Structured Develop-ing Method） 是现有的软件开发方法中是现有的软件开发方法中最成熟、应用最广泛的方法，主要特点最成熟、应用最广泛的方法，主要特点是快速、自然和方便。是快速、自然和方便。结构化开发方法由结构化分析方法结构化开发方法由结构化分析方法（SA法）、结
52、构化设计方法（法）、结构化设计方法（SD法）法）及结构化程序设计方法（及结构化程序设计方法（SP法）构成。法）构成。2003.01.10 SOFTWARE ENGINEERING结构化分析方法（结构化分析方法（SA）结构化分析方法是面向数据流的需求分析方结构化分析方法是面向数据流的需求分析方法。法。SA法是一种建模的活动，主要是根据软件内法是一种建模的活动，主要是根据软件内部的数据传递、变换关系，自顶向下逐层分部的数据传递、变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。解，描绘出满足功能要求的软件模型。SA法的描述方法：法的描述方法：1、分层的数据流图；、分层的数据流图；2、数据词
53、典；数据词典；3、描述加工逻辑的结构化语言、描述加工逻辑的结构化语言、判定表及判定树等判定表及判定树等2003.01.10 SOFTWARE ENGINEERINGThe elements of the analysis modelData Flow Diagram(DFD)/ Data Dictionary(DD) /Process SpecificationEntity-Relationship Diagram(ERD)/ Data Object DescriptionState-Transition Diagram(STD)/ Control Specification2003.01.1
54、0 SOFTWARE ENGINEERINGData Flow Diagram(DFD)Information is transformed as it flows through a computer-based system.The system accept input in a variety of forms; applies software, hardware,and human elements to transform input into output;and produces output in a variety of forms.A data flow diagram
55、(DFD) is a graphical technique that depicts information flow and transforms that are applied as data move from input to output.2003.01.10 SOFTWARE ENGINEERING软件模型软件模型计算机系 统变换输入输入输出输出信息系统模型软件模型通常从数据流图的通常从数据流图的输出端着手分析输出端着手分析，这是因，这是因为系统的目标是产生这些输出，输出数据确为系统的目标是产生这些输出，输出数据确定了系统必须具有的最基本的组成元素。定了系统必须具有的最基本的组
56、成元素。2003.01.10 SOFTWARE ENGINEERINGData Flow Diagram(DFD)Data storeData objectprocessExternal entityA data object;the arrowhead indicates the direction of data flowA transformer of information(a function) that resides within the bounds of the system to be modeledA producer or customer of information
57、 that resides outside the bounds of the system to be modeled.A repository of data that is to be stored for use by one or more processes;may be as simple as a buffer or a queue or as sophisticated as a relation database2003.01.10 SOFTWARE ENGINEERINGData Flow Diagram(DFD)The DFD enables the software
58、engineer to develop models of the information domain and function domain at the same time.数据流图数据流图(Data Flow Diagram)(Data Flow Diagram)描绘系统的逻描绘系统的逻辑模型，只描绘数据在系统中的流动和处理辑模型，只描绘数据在系统中的流动和处理情况，可不考虑具体的处理细节。情况，可不考虑具体的处理细节。2003.01.10 SOFTWARE ENGINEERINGDFD：命名命名数据流的命名：名字数据流的命名：名字(name)(name)应代表整个数据流的内应代表整个
59、数据流的内容；不要空洞、泛指，要有具体含义；如果对某个容；不要空洞、泛指，要有具体含义；如果对某个数据流命名有困难时，应重新分解；命名不能有二数据流命名有困难时，应重新分解；命名不能有二义性。义性。 处理的命名：通常应先为数据流命名再为与之相关处理的命名：通常应先为数据流命名再为与之相关的处理命名；名字应反映整个处理的功能而不是一的处理命名；名字应反映整个处理的功能而不是一部分；名字最好由一个具体的及物动词和一个具体部分；名字最好由一个具体的及物动词和一个具体的宾语组成；通常名字中只包括一个动词；如果对的宾语组成；通常名字中只包括一个动词；如果对某个处理命名有困难时，应重新分解某个处理命名有困
60、难时，应重新分解 。2003.01.10 SOFTWARE ENGINEERINGData Flow Diagram(DFD)A level 0 DFD,also called a fundamental system model or a context model,represents the entire software element as a single bubble with input and output data indicated by incoming and outgoing arrows,respectively.It is important to note t
61、hat no explicit indication of the sequence of processing is supplied by diagram.Explicit procedural representation is generally delayed until software design.2003.01.10 SOFTWARE ENGINEERINGDFD RefinementEach of the bubbles may be refined or layer-ed to depict more detail.Note that informa-tion flow
62、continuity must be maintained,that is,input and output to each refinement must remain the same.This concept,sometimes called balancing.A data flow diagram depicts information flow without explicit representation of procedure logic(e.g.,conditions or loops).2003.01.10 SOFTWARE ENGINEERINGDFD的分层细化的分层细
63、化DFD必须逐步分层细化（一般要经过多次反必须逐步分层细化（一般要经过多次反复），以达到可以找出复），以达到可以找出“可实现的软件元素可实现的软件元素”的程度的程度细化准则细化准则1）第）第0层均是基本软件模型层均是基本软件模型2）仔细说明原始的输入）仔细说明原始的输入/输出文件输出文件3）箭头、圆圈应加有意义的名字）箭头、圆圈应加有意义的名字4）每一次只能加工一个圆圈）每一次只能加工一个圆圈5）保持信息的连续性（完全相同或匹配）保持信息的连续性（完全相同或匹配）2003.01.10 SOFTWARE ENGINEERINGDFD的分层细化的分层细化The refinement of DFDs
64、 continues until each bubble performs a simple function, that is, until the process represented by the bubble performs a function that would be easily implemented as a program component.These is a tendency to overcomplicate the DFD.2003.01.10 SOFTWARE ENGINEERINGDFD实例实例验证定单的正确性汇总对各出版社的要求顾客出版社顾客档案图书目
65、录待处理定单定货存根出版社档案顾客信用情况定单图书目录正确定单一批定单出版社信息对出版社的定单定货信息图书预定系统的DFD图2003.01.10 SOFTWARE ENGINEERING旅行社预定机票准备机票记账旅客航班目录记账文件订票单航班费用机票DFD实例实例2003.01.10 SOFTWARE ENGINEERINGThe Data Dictionary数据字典数据字典(DD)是数据的信息的集合，即对数据流图是数据的信息的集合，即对数据流图中包含的所有元素中包含的所有元素(element)的定义的集合。的定义的集合。数据字典最重要的用途是作为分析阶段的工具。在数据字典最重要的用途是作为
66、分析阶段的工具。在数据字典中建立一组严密一致的定义，有助于分析数据字典中建立一组严密一致的定义，有助于分析员与用户通信、交流，消除误解。员与用户通信、交流，消除误解。数据字典（数据字典（DD）包括包括DFD中中1）数据元素（如：电话号码）数据元素（如：电话号码）2）数据结构（如：图书目录）数据结构（如：图书目录）3）数据文件（如：顾客档案）数据文件（如：顾客档案）4）数据流（如：正确定单）的定义）数据流（如：正确定单）的定义2003.01.10 SOFTWARE ENGINEERINGThe Data DictionaryMost contain the following informati
67、on:1)name2)alias3)where-used/how-used4)content description5)supplementary information:data types, preset values,restrictions or limitations,etc.2003.01.10 SOFTWARE ENGINEERINGThe Data Dictionary数据字典的表示：自学数据字典的表示：自学例如，数据项词条描述包括：数据项名，类型：数例如，数据项词条描述包括：数据项名，类型：数字（离散值，连续值）、文字（编码类型），长度，字（离散值，连续值）、文字（编码类型）
68、，长度，取值范围，相关的数据元素及数据结构等取值范围，相关的数据元素及数据结构等数据存储词条描述包括：数据存储名，简述：存放数据存储词条描述包括：数据存储名，简述：存放的是什么数据，输入数据，输出数据，数据文件组的是什么数据，输入数据，输出数据，数据文件组成：数据结构，存储方式：顺序，直接，关键码，成：数据结构，存储方式：顺序，直接，关键码，存取频率等存取频率等一般，先定义数据流和存储文件，再定义分解得到一般，先定义数据流和存储文件，再定义分解得到的相关数据项。处理的定义按照数据流图的层次逐的相关数据项。处理的定义按照数据流图的层次逐层定义。层定义。2003.01.10 SOFTWARE EN
69、GINEERINGThe Data DictionaryFor large computer-based systems,the data dictionary grows rapidly in size and complexity.In fact,it is extremely difficult to maintain a dictionary manually.For this reason,CASE tools should be used.无论如何实现，数据字典都应具有以下特点：无论如何实现，数据字典都应具有以下特点： 通过名字能够方便地查阅数据。通过名字能够方便地查阅数据。 没有
70、冗余。没有冗余。 容易更新和修改。容易更新和修改。 能单独处理描述每个数据项的信息。能单独处理描述每个数据项的信息。 定义的书写方法简单、方便、严密。定义的书写方法简单、方便、严密。2003.01.10 SOFTWARE ENGINEERINGEntity-Relationship DiagramThe ERD enables a software engineer to fully specify the data objects that are input and output from a system,the attributes that define the properties
71、 of these objects,and relationships between objects.Like most elements of the analysis model,the RED is constructed in an iterative manner.2003.01.10 SOFTWARE ENGINEERING实体实体-联系图（联系图（E-R图）图）学号姓名性别学号课程号成绩课程名课程号学分学生课程选课NM2003.01.10 SOFTWARE ENGINEERINGEntity-Relationship DiagramData objectsRelationshi
72、psAttributes详细的介绍参见详细的介绍参见“数据库原理数据库原理”课程课程2003.01.10 SOFTWARE ENGINEERINGUML的应用的应用UML是一种建模语言而不是方法，是一种建模语言而不是方法，这是因为这是因为UML中没有过程的概念，中没有过程的概念，而过程正是方法的一个重要组成部而过程正是方法的一个重要组成部分。分。UML本身独立于过程，这意味本身独立于过程，这意味着用户在使用着用户在使用UML进行建模时，可进行建模时，可以选用任何适合的过程。以选用任何适合的过程。2003.01.10 SOFTWARE ENGINEERINGUML中的图中的图1、用例图（用例图（
73、Use case diagram）2、类类图（图（class diagram）3、对象、对象图（图（class diagram）4、顺序图（顺序图（Sequence diagram）5、协作图（协作图（Collaboration diagram）6、状态图（状态图（Statechart diagram）7、活动图（活动图（Activity diagram）8、构件图（构件图（Compomnent diagram）9、部署图（部署图（Deployment diagram）2003.01.10 SOFTWARE ENGINEERINGProcess SpecificationThe process
74、 specification is used to describe all flow model processes that appear at the final level of refinement.常用的描述方法有：常用的描述方法有：narrative text,and program design language(PDL)2003.01.10 SOFTWARE ENGINEERINGProgram Design Language结构化语言是介于自然语言和形式语言结构化语言是介于自然语言和形式语言之间的一种半形式语言，它是自然语言之间的一种半形式语言，它是自然语言的一个受限制的子
75、集。一般分为两层结的一个受限制的子集。一般分为两层结构：外层语法较具体，为控制结构（顺构：外层语法较具体，为控制结构（顺序、选择、循环）序、选择、循环）,内层较灵活，表达内层较灵活，表达“做什么做什么”。结构化语言特点：简单，易学，少二义结构化语言特点：简单，易学，少二义性。但不好处理组合条件。性。但不好处理组合条件。2003.01.10 SOFTWARE ENGINEERINGProgram Design Language句子联系只能用：句子联系只能用：IF_THEN_ELSE, WHILE_DO,REPEAT_UNTIL每一个句子只能是祈使句并且是简单句每一个句子只能是祈使句并且是简单句名
76、词（数据）应在名词（数据）应在DD中定义过中定义过谓词动词表示的动作应明确、具体谓词动词表示的动作应明确、具体形容词、副词尽量少用形容词、副词尽量少用个体连词应区别个体连词应区别OR/AND的使用的使用比较应区分比较应区分GT、GE、LT、LE的含义的含义2003.01.10 SOFTWARE ENGINEERING系统动态分析系统动态分析一个软件系统在其运行过程中，构成系一个软件系统在其运行过程中，构成系统的各元素（对象）的状态在改变，对统的各元素（对象）的状态在改变，对象之间的联系也随时间在改变。为了直象之间的联系也随时间在改变。为了直观地分析系统的动作，从特定的视点来观地分析系统的动作，
77、从特定的视点来描述系统的动态特性，必须采用动态分描述系统的动态特性，必须采用动态分析的需求分析方法。析的需求分析方法。常用的动态分析方法有状态迁移图、时常用的动态分析方法有状态迁移图、时序图、序图、Petri网等。网等。2003.01.10 SOFTWARE ENGINEERING 执行执行状态状态 阻塞阻塞状态状态就绪就绪状态状态调度调度I/O请求请求进程进程释放释放时间时间片到片到进程的状态迁移State-Transition Diagram状态迁移图状态迁移图2003.01.10 SOFTWARE ENGINEERINGState-Transition DiagramThe state-
78、transition diagram(STD) represents the behavior of a system by depicting its states and the events that cause the system to change state.In addition, the STD indicates what actions (e.g.,process activation) are taken as a consequence of a particular event.详细的介绍参见相关课程详细的介绍参见相关课程2003.01.10 SOFTWARE EN
79、GINEERINGSummaryStructured Analysis(SA).the most widely used of requirements modeling methods, relies on data modeling and flow modeling to create the basis for a comprehensive analysis model.SA is supported by an array of CASE tools that assist in the creation of each element of the model and also
80、help to ensure consistency and correctness.2003.01.10 SOFTWARE ENGINEERING软件需求分析的工作步骤软件需求分析的工作步骤理解：理解系统规格说明书的软件作用范围，用户理解：理解系统规格说明书的软件作用范围，用户环境等内容环境等内容认识：认识软件作用范围中的功能、性能要求、接认识：认识软件作用范围中的功能、性能要求、接口说明是否明确？约束条件是否恰当？可实现性如口说明是否明确？约束条件是否恰当？可实现性如何？何？决策：根据软件项目的规模、特征、性质等因素和决策：根据软件项目的规模、特征、性质等因素和类似软件开发的历史经验，决定
81、采取那种需求分析类似软件开发的历史经验，决定采取那种需求分析方法方法实现：根据选定的需求分析方法进行软件需求分析，实现：根据选定的需求分析方法进行软件需求分析，写出软件需求规格说明书写出软件需求规格说明书复审：这是关键的一步。复审：这是关键的一步。2003.01.10 SOFTWARE ENGINEERING修正系统的开发计划修正系统的开发计划通过需求分析对系统更深入具体的理解，通过需求分析对系统更深入具体的理解，可以比较准确地估计系统的成本和进度，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划修正以前制定的开发计划。2003.01.10 SOFTWARE ENGINEERING用
82、于需求分析的软件和工具用于需求分析的软件和工具PSL/PSAPSL/PSA（问题陈述语言问题陈述语言/ /问题陈述分析问题陈述分析程序）的主要功能：程序）的主要功能：描述任何领域的信息系统；描述任何领域的信息系统； 创建一个数据库保存对该系统的描述符；创建一个数据库保存对该系统的描述符； 对描述符进行增加、删除和更改等操作；对描述符进行增加、删除和更改等操作； 产生格式化的文档和关于规格说明书产生格式化的文档和关于规格说明书的各种分析报告。的各种分析报告。 2003.01.10 SOFTWARE ENGINEERING软件需求分析小结软件需求分析小结软件需求分析的工作，是软件开发人员软件需求分
83、析的工作，是软件开发人员( (系统系统分析员和系统工程师等分析员和系统工程师等) )与用户密切配合，充与用户密切配合，充分交换意见，达到对需求分析一致的意见。分交换意见，达到对需求分析一致的意见。需求分析阶段的最终任务是要完成目标系统需求分析阶段的最终任务是要完成目标系统的需求规格说明，确定系统的功能和性能，的需求规格说明，确定系统的功能和性能，为以后阶段的开发打下基础。为以后阶段的开发打下基础。需求分析的方法和技术因具体的系统而定，需求分析的方法和技术因具体的系统而定，常用的有常用的有SASA法，原型法，法，原型法，OOAOOA法等。法等。2003.01.10 SOFTWARE ENGINEERING本章内容讲授到此结束！本章内容讲授到此结束！福州大学福州大学软件学院软件学院计算机教研室计算机教研室王灿辉王灿辉2003.01.10 SOFTWARE ENGINEERING
