《软件工程第三章.ppt》由会员分享，可在线阅读，更多相关《软件工程第三章.ppt（36页珍藏版）》请在三一办公上搜索。
1、 软件工程 讲稿,第二部分 课程内容,第三章软件需求工程,学习目标:了解软件需求分析的任务与重要性，理解其中的重要概念，如SRS，里程碑，可提交物等；掌握软件需求分析的步骤、方法；了解软件需求分析内容与后续工作的关系；理解软件需求工程知识；掌握软件需求分析文档的撰写；需求分析阶段存在的常见问题。,3.1 概述,所谓“需求分析”，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。软件开发项目过程可以用图3.1开发过程模型来说明。,图3.1 开发过程模型,3.1 概述,图中几个概念的含义。当前系统：将用户正在使用的系统。目标系统：在应用计算机
2、后要实现的系统。当前系统的物理模型：用一个具体化的模型模拟、了解当前系统的组织机构、资源利用情况和日常数据处理过程。当前系统的逻辑模型：在理解当前系统的具体运行过程后，从个体的细节抽象出本质的过程模型。,3.1 概述,目标系统的逻辑模型：分析当前系统与目标系统逻辑上的差别，明确目标系统要“做什么”的实质工作，从当前系统的逻辑模型导出目标系统的逻辑模型。目标系统的物理模型：确定待开发系统的系统元素，将功能和数据结构分配到系统元素中。它的具体物理模型则是由它的逻辑模型经实例化后，具体到某个业务领域得到的。,3.2 需求分析任务,软件需求分析阶段研究的对象是软件项目的用户要求，如何准确表达用户的要求
3、，怎样与用户共同明确将要开发的是一个什么样的系统，是需求分析要解决的主要问题。下面简要叙述需求分析阶段的具体任务。一、确定对系统的综合要求。对系统的综合要求有下述四个方面：1系统功能要求2系统性能要求3运行要求4将来可能提出的要求,3.2 需求分析任务,二、分析系统的数据要求分析系统的数据要求通常采用建立概念模型的方法。三、导出系统的逻辑模型综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、数据字典和主要的处理算法描述这个逻辑模型。四、修正系统开发计划根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。五、开发原型系统
4、,3.2 需求分析任务,对于软件系统的开发，使用“样机”(原型系统)的主要目的是，使用户通过实践获得关于未来的系统将怎样为他们工作的更直接更具体的概念，从而可以更准确地提出和确定他们的要求。,3.3 软件需求分析类型,3.3.1功能需求与非功能需求 软件系统需求通常分为三类:功能需求,非功能需求,领域需求。1.功能需求功能需求描述系统所预期提供的功能或服务。2.非功能需求 非功能需求，是指那些不直接与系统具体功能相关的一类需求。它们与系统的总体特性相关，如可靠性、反应时间和储存空间等。,3.3 软件需求分析类型,图3.3 非功能需求的类型,3.3 软件需求分析类型,3.领域需求 领域需求起源于
5、系统的应用领域而不是系统的用户需要。它们可能是一个新的特有的功能需求、对已存在的功能需求的约束或者是需要实现的一个特别计算。3.3.2用户需求 用户需求是从用户角度来描述系统功能和非功能需求，以便让不具备专业技术方面知识的用户能看懂。这样的需求描述只描述系统的外部行为，要尽量避免对系统设计特性的描述。,3.3 软件需求分析类型,3.3.3系统需求 系统需求是比用户需求更详细的需求描述，是系统实现的基本依据，因此，是一个完全的和一致的系统描述，是软件工程人员系统设计的起点。自然语言时常被用来书写系统需求描述，但被用来做更详细的描述时，深层次的问题就暴露出来，主要有：自然语言的二义性会造成语义理解
6、的偏差。自然语言书写的需求描述随意性大。没有一个简单的方法使自然语言书写的需求模块化。替代的描述方式如表3.2所示:,3.3 软件需求分析类型,表3.2：可以替换自然语言的方法,3.4 软件需求分析原则,进行用户需求是需求分析的第一步，用户需求通常可以分为功能需求和性能需求两类。功能需求定义了系统应该做什么，系统要求输入什么信息，输出什么信息，以及如何将输入变换为输出。性能需求则定义了软件运行的状态特征，如系统运行效率，可靠性，安全性，可维护性等等。,3.5 需求分析方法,在软件工程学的需求分析中常用的方法通常采用结构化分析技术、面向对象分析技术，以及原型开发技术等。3.5.1结构化分析方法结
7、构化分析技术是一种面向数据流的分析方法。结构化分析就是使用数据流图、数据词典、结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档。建立功能模型数据流程图，又称数据流图，它是以图形的方式来表达数据处理系统中信息的变换和传递过程。数据流程图有三个重要属性：,3.5 需求分析方法,数据流程图有三个重要属性：1）可以表示任何一个系统(人工的、自动的或混合的)中的信息流程。2）每个圆圈可能需要进一步分解以求得对问题的全面理解。3）着重强调的是数据流程而不是控制流程。数据流程图中的基本符号有：1、数据流数据流是有名字有流向的数据，在数据流程图中，数据流用标有名字的箭头来表示。,3
8、.5 需求分析方法,2、加工加工又称处理逻辑，表示数据所进行的加工或变换，以标有名字的圆圈代表加工。指向加工的数据流是该加工的输入数据，离开加工的数据流是该加工的输出数据。3、文件文件是数据暂存的处所，可对文件进行必要的存取，在图中以标有名字的双直线段表示。4、数据源及数据终点表明数据处理过程的数据来源或数据去向的标志称为数据源及数据终点，在数据流程图中均以命名的方框来表示。,3.5 需求分析方法,2.建立数据模型软件系统本质上是信息处理系统，因此，在软件系统的整个开发过程中都必须考虑两方面的问题“数据”及对数据的“处理”。在需求分析阶段则既要分析用户的数据要求，又要分析用户的处理要求。为了把
9、用户的数据要求清晰明确地表达出来，系统分析员通常建立一个概念性的数据模型(也称为信息模型)。概念性数据模型是一种面向问题的数据模型，是按照用户的观点来对数据和信息建模。最常用的表示概念性数据模型的方法，是实体一联系方法，用这种方法表示的概念性数据模型又称为ER模型。,3.5 需求分析方法,ER模型中包含“实体”、“联系”和“属性”等三个基本成分：1实体 实体是客观世界中存在的且可相互区分的事物，实体可以是人也可以是物；可以是具体事物也可以是抽象概念。在ER图中用矩形框代表实体。2联系客观世界中的事物彼此间往往是有联系的，联系可分为三类：(1)一对一联系(11)(2)一对多联系(1N)(3)多对
10、多联系(MN),3.5 需求分析方法,在ER图中，用连接相关实体的菱形框表示联系。3属性属性是实体或联系所具有的性质。通常一个实体由若干个属性来刻画。在ER图中用椭圆形或圆角矩形表示实体(或联系)的属性，并用无向边把实体(或联系)与其属性连接起来。4范式通常用“范式(Normal Forms)”定义消除数据冗余的程度。第一范式(1 NF)数据冗余程度最大，第五范式(5 NF)数据冗余程度最小。但是，范式级别越高，存储同样数据就需要分解成更多张表，因此，“存储自身”的过程也就越复杂。,3.5 需求分析方法,从实用角度看来，在大多数场合选用第三范式都比较恰当。1第一范式每个属性值都必须是原子值，即
11、仅仅是一个简单值而不含内部结构。2第二范式满足第一范式条件，而且每个非主属性完全依赖于某个候选键(而不是部分依赖于某个候选键)3第三范式符合第二范式的条件，所有非主属性即不部分依赖于某个候选键，也不传递依赖于某个候选键。,3.5 需求分析方法,3.建立行为模型分析建模是实现真实世界模型向计算机模型转换的核心环节，也是一种处理软件复杂性的有效手段。在需求开发阶段，分析建模的关键是针对用户需求建立抽象的分析模型，从而有助于开发人员理解用户需求，同时增强自然语言的需求规格说明。分析模型往往采用一些图形化的表示方式，从数据、功能和行为等不同角度表达用户需求。,3.5 需求分析方法,4.数据词典数据字典
12、是结构化分析方法的一个有力工具，它对数据流程图中出现的所有数据元素给出逻辑定义。有了数据字典，使数据流程图上的数据流、加工和文件能得到确切的解释。数据字典的条目可以分成四大类，即：数据流条目。数据流条目主要说明数据流条目是由哪些数据项组成的，以及数据在单位时间内的流量，它的来源、去向等。条目格式如下：数据流名：组成：流量：,3.5 需求分析方法,来源：去向：文件条目。文件条目主要说明文件由哪些数据项组成，存储方式和存取频率等。条目格式如下：文件名：组成：存储方式：存储频率：,3.5 需求分析方法,数据项条目。数据项名：类型：长度：取值范围：加工条目。加工条目主要说明加工的输入数据、输出数据及其
13、加工逻辑等。条目格式如下：加工名：输入数据：输出数据：加工逻辑：,3.5 需求分析方法,3.5.2面向对象分析方法面向对象方法是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，简称OO方法，它是建立在对象概念(对象、类和继承)基础上的方法。1.面向对象方法符合人们对客观世界的认识规律。2.面向对象方法开发的软件系统由对象类组成，对象的封装性很好地体现了抽象和信息隐蔽的特征。对象以属性及操作作为接口(界面)，使用者只可通过接口访问对象(请求其服务)，对象的具体实现细节对外是不可见的。这些特征使得软件系统的体系结构是模块化的，易于理解、扩充和修改。,3.5 需求分析方法,3面向对
14、象方法中的继承机制有力支持软件的复用在同一应用领域的不同应用系统中。3.5.3结构化语言描述结构化自然语言是书写系统需求时对自然语言所做的严格的格式。这个方法的好处是：保持了自然语言中绝大部分好的性质，包括表现能力和易懂性，同时又在不同程度上对描述做了一致性的约束。需求描述的结构化是围绕三个主要内容进行的，一是系统操作对象，二是系统运行的功能，三是系统处理的事件。,3.6 软件需求工程管理,软件需求管理指的是一个为系统的需求进行启发、组织、建档的系统方法，一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。需求模型是指将软件需求的捕获与开发、管理作为一个工程，以软件需求的捕获
15、与开发、管理为研究对象，抽象化的工程参考模型，用以指导软件需求的各项实践活动。软件需求管理过程主要分为以下几个阶段的工作：定义需求当完成用户需求调查后，首先对用户需求说明书进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。,3.6 软件需求工程管理,当完成需求的定义及分析后，需要将此过程书面化，要遵循既定的规范将需求形成书面的文档，我们通常称之为需求分析说明书。邀请同行专家和用户（包括客户和最终用户）一起评审需求规格说明书，尽最大努力使需求规格说明书能够正确无误地反映用户的真实意愿。需求确认求确认是需求管理过程中的一种常用手段，也是需求控制的五一节之一；确认有两个层
16、面的意思，第一是进行系统需求调查与分析的人员与客户间的一种沟通，通过沟通从而对需求不一致的进行剔除；另外一个层面的意思是指，对于双方达成共同理解或获得用户认可的部分，双方需要进行承诺。,3.6 软件需求工程管理,建立需求状态状态也就是一种事物或实体在某一个时刻或点所处的情况，此处要讲的需求状态是指用户需求的一种状态变换过程。为什么要建立需求状态？在整个生命周期中，存在著有几种不同的情况，在需求调查人员或系统分析人员进行需求调查时，客户存在的需求可能有多种，一类是客户可以明确且清楚的提出的需求；一类是客户知道需要做些什么，但又不能确定的需求；另一类是客户本身可以得出这类需求，但需求的业务不明确，
17、还需要等待外部信息。还有是客户本身也说不清楚的。,3.6 软件需求工程管理,需求评审对工作产品的评审有两类方式，一类是正式技术评审，也称同行评审，另一类是非正式技术评审。需求评审的规程与其它重要工作产品，主要区别在于评审人员的组成不同。前者由开发方和客户方的代表共同组成，而后者通常来源于开发方内部。需求评审究竟评审什么？要细到什么程度？怎么样进行？严格地讲，应当检查需求文档中的每一个需求，每一行文字，每一张图表。评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。如果有可能，最好可以制定评审的检查表。,3.6 软件需求工程管理,需求变更控制需
18、求发生变更的起因主要有：原先的提出的需求可能存在著一定的缺陷，因此要变更需求。市场业务需求发生了变化，原先的需求可能跟不上当前的市场业务发展。在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来。需求变更控制的动机是：如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。如果需求变更带来的坏处大于好处，那么拒绝变更。,3.7 软件需求文档,软件需求说明（SRS,又称软件规格说明书）是系统分析员在需求分析阶段需要完成的文档，是软件需求分析的最终结果。它的作用主要是：作为软件人员与用户之间事实上的技术合同书 作
19、为软件人员下一步进行设计和编码的基础作为测试和验收的依据 软件需求说明必须用统一格式的文档进行描述，主要包括引言、任务概述、需求规定、运行环境规定和附录等内容。SRS围绕以下四个方面组织：,3.7 软件需求文档,(1)系统规格说明：目标系统的总体概貌；系统功能、性能要求；系统运行要求；将来可能的修改扩充要求。如果采用SA方法进行需求分析，则数据流图是描述系统逻辑模型主要工具。(2)数据要求：建立数据词典描绘系统数据要求，给出系统逻辑模型的准确、完整定义。(3)用户描述：从用户使用角度对系统的描述，相当于初始的用户手册。内容包括系统功能、性能概述，预期的系统使用步骤与方法，用户运行维护要求等。(
20、4)修正的开发计划：经过需求分析，对系统开发的成本估计，资源使用要求，项目进度计划的可能修改。,3.7 软件需求文档,一份好的软件需求规格说明应该具有唯一性、完整性、可验证性、一致性、可跟踪性、可修改性等特征。1唯一性用户的每一个要求系统功能仅有一种解释。2完整性需求分析的完整性包括：系统包含全部重要的用户需求(功能、性能、设计约束、外部接口)；规定每种输入数据的软件响应(正确输入的响应和不正确输入的响应)；全部术语、图表完整，符合需求规范标准。,3.7 软件需求文档,3可验证性SRS中每个功能、性能需求是可以验证的。一个需求是可验证的，是指存在一个有限的人工或者机器执行的过程，以确认该需求是否符合用户要求。4一致性SRS陈述的各项功能、性能要求是相容的，没有互相发生矛盾或者冲突。5可修改性SRS的组织结构使得当需求发生必须的变化时，对SRS的修改能够保证完整、一致、容易地完成。6可跟踪性对于软件开发中的每个需求在SRS中可以追溯出其来源。,
