《第3章需求分析课件.ppt》由会员分享，可在线阅读，更多相关《第3章需求分析课件.ppt（70页珍藏版）》请在三一办公上搜索。
1、2023/3/28,1,第3章 需求分析,3.1 需求分析的任务3.2 与用户沟通获取需求的方法3.3 分析建模与规格说明3.4 实体-联系图3.5 数据规范化3.6 状态转换图3.7 其他图形工具3.8 验证软件需求,2,2023/3/28,开发一个软件系统前，必须了解用户的期望和要求,重要性：,软件开发的基础和前提,最终目标软件系统验收的标准,避免或者尽早剔除早期的错误,可行性分析阶段已经粗略了解了用户的需求，但许多细节被忽略。在系统开发前，还需要进一步确定、分析这些细节。-需求分析过程,3,2023/3/28,困难：,片面性,不完全,模糊性,不准确,不一致性,歧义等等,因此必须使用系统的
2、方法、借助于一系列行之 有效的技术和工具进行需求分析。,应用系统复杂，庞大,4,2023/3/28,调查发现软件项目失败的原因：,13.1%不完整的产品要求；12.4%缺乏用户的参与；10.6%缺少资源（人力、财力）；9.9%不现实的期望；9.3%高层领导支持不足；8.7%产品要求与指标的改变；8.1%没有订计划；7.5%不再需耍该开发中的系统。其中，与产品需求有关的（1,2,4,和6项）占了44.1%。这些数据突出地显示了软件产品需求在软件开发中的重要性。,5,2023/3/28,软件需求,需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。,
3、6,2023/3/28,软件需求的层次,7,2023/3/28,软件需求管理的过程,需求分析,编写需求规格,需求验证,需求获取,需求变更,需求确认,需求变更,8,2023/3/28,需求工程基本任务,需求工程,需求管理,需求开发,需求获取,需求分析,需求规格说明,需求验证,变更管理,9,2023/3/28,需求分析定义,需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。,10,2023/3/28,软件开发是要实现目标系统的物理模型。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题。,需求分析模型,表达需求,11,2023/3/2
4、8,1 需求分析的任务,需求分析的基本任务：准确的回答“系统必须做什么？”（注意：细致、精确地回答“What”（合同的拟定），而不是“How”）,1、确定系统的综合性要求(1)功能要求(2)性能要求(3)可靠性和可用性需求(4)出错处理需求(5)接口需求(6)约束(7)逆向需求(8)将来可能提出的要求,2023/3/28,12,2、分析系统的数据要求,系统处理的信息和系统应该产生的信息在很大程度上决定系统的概貌。,分析系统数据要求，通常使用概念模型的方法。数据信息在数据字典中，为了直观地描绘数据结构，可采用层次方框图和Warnier图等辅助工具。采用规范化理论来规范化数据结构。,2023/3/
5、28,13,3、导出新系统的逻辑模型,4、修正系统的开发计划,成本和进度的更准确估计。,14,2023/3/28,需求分析是一项软件工程活动，它包括：需求获取刻划出软件的功能和性能；指明软件与其他系统元素的接口；建立软件必须满足的约束。需求建模需求分析建立起来的模型为日后软件设计人员提供了可被翻译成数据、体系结构、接口和处理过程设计的模型。,小结：需求分析的任务,15,2023/3/28,需求规格说明需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。需求评审需求分析研究的对象是用户的要求。必须全面理解用户的各项要求，准确表达被接受的用户要求。只有经过确切描述的软件需求才能成为软件设
6、计的基础。,16,2023/3/28,需求获取,需求获取是在问题及其最终解决方案之间架设桥梁的第一步。需求获取的目的是清楚地理解所要解决的问题，完整地获得用户的需求。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。,17,2023/3/28,软件需求的层次,业务需求 反映了组织或客户对系统、产品高层次的目标要求，它们一般在项目视图和范围文档中给予说明。用户需求 描述用户使用软件需要完成哪些任务，它们可通过使用实例图或脚本说明加以阐明。功能非功能需求 定义了开发者必须实现的软件功能，而非功能需求如表所示:,
7、18,2023/3/28,19,2023/3/28,需求获取过程,需求获取包括以下活动：发现和分析问题 发现问题症结，并分析问题的原因/结果关系。获取需求 根据对问题的理解定义需求。使用调查研究方法收集信息；遵循需求获取框架，按照三个成分观察：即数据、过程和接口。需求归档 以草稿形式归档调查结果。形式有用例、决策表、需求表等。,20,2023/3/28,需求获取的步骤,软件开发项目和组织文化的不同，对于需求开发没有一个简单的、公式化的途径。下面9个步骤，针对信息系统的需求获取。定义项目的视图和范围 包括组织结构图、各部门的岗位/角色列表。确定用户类 包括人员/责任矩阵。确定目标系统的业务工作流
8、 包括物流、资金流、信息流，建立业务工作流模型。,21,2023/3/28,运用需求获取技术开发反映主要业务规则的用例（或数据流图）并设置优先级。收集来自用户的质量特性信息和其他非功能需求 将性能、安全性、可靠性等需求和其他设计约束结合业务规则，形成功能需求。分类在用例（或数据流图）中涉及的数据 包括数据的组成和数据之间的关系。详细拟订用例（或数据流图）的规格说明，建立功能模型，并进行审查，用以澄清需求获取的参与者对需求的理解。,22,2023/3/28,开发并评估界面原型 设想输入设备、输出设备、显示风格、显示方式、输出格式等，建立接口规范和信息流传输规则。从功能描述中开发概念测试用例 用测
9、试用例来验证用例（或数据流图）、功能需求和原型。,23,2023/3/28,需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。表现在：需求的不稳定性：在整个软件生存周期内软件需求会随着时间的推移发生变化；需求的不准确性：用户和开发人员的认识会随着使用系统实现业务流程的实践逐步提高，一开始不可能设想得面面俱到。需求获取只有通过有效的客户/开发者的合作才能成功。,24,2023/3/28,需求整理与表达的方法,采用穷举方法可以避免遗漏。采用归纳方法，通过对各种情况进行综合分类可以使问题条理化。采用抽象方法，可以发现问题的实质，抓住问题的主要矛盾，忽略其次要矛盾。需求整理可以多种手
10、段共用，如组织结构图、业务流程图、多叉树、关系矩阵、文字叙述、表格、图形等。需求描述包括组织结构与岗位定义、业务流程、处理规则、数据项、功能以及上述 5 个方面的关系。,25,2023/3/28,2 与用户沟通获取需求的方法,访谈面向数据流自顶向下求精（细化数据流图）加细前后的I/O须相同。分解到须考虑具体实现的代码时即可停止,简易的应用规格说明技术快速建立软件原型 1)废弃型 2)追加型或演化型,26,2023/3/28,3 分析建模与规格说明,需求建模是为了分析需求，以确定项目的确切需求需求建模遵循三个原则：划分：描述需求的整体部分关系；抽象：描述需求的一般化特殊化关系；投影：描述需求的多
11、维视图；定义系统模型要区分逻辑模型和物理模型。常用模型有数据建模、功能建模和过程建模。,27,2023/3/28,常用的分析方法,面向数据流的结构化分析方法(SA)面向数据结构的Jackson方法(JSD)面向数据结构的结构化数据系统开发方法(DSSD)面向对象的分析方法(OOA)等,28,2023/3/28,结构化分析方法最初只是着眼于数据流，自顶向下，逐层分解，建立系统的处理流程，以数据流图和数据字典为主要工具，建立系统的逻辑模型。扩充后，将建模技术扩展到数据建模、功能建模和行为建模，以实体-关系图、数据流图和控制流图、状态-迁移图为工具，数据字典为核心，从不同视点建立系统的分析模型。,结
12、构化分析方法,29,2023/3/28,结构化分析的分析模型,实体关系图,状态迁移图,数据流图,数据对象描述,加工规格说明,数据字典,控制规格说明,30,2023/3/28,需求规格,需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。,31,2023/3/28,软件需求规格说明的原则,从现实中分离功能，即描述要“做什么”而不是“怎样实现”采用一定的规格说明语言如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中规格说明应该包括系统运行
13、环境规格说明应该是一个认识模型规格说明应该容许不完备性并允许扩充,32,2023/3/28,需求规格说明的内容,基于IEEE 830改写的规格说明模板内容：引言a.1 目的a.2 文档约定 a.3 预期的读者和阅读建议a.4 产品的范围a.5 参考文献综合描述 b.1 产品的前景 b.2 产品的功能,33,2023/3/28,b.3 用户类和特征b.4 运行环境b.5 设计和实现的限制b.6 假设和依赖外部接口 c.1 用户界面 c.2 硬件接口 c.3 软件接口 c.4 通信接口系统特性 d.1 说明和优先级,34,2023/3/28,d.2 激励响应序列d.3 功能需求其他非功能需求 e.
14、1 性能需求 e.2 基本设施需求 e.3 安全性需求 e.4 软件质量属性 e.5 业务规则 e.6 用户文档其他需求附录A：词汇表附录B:软件需求分析模型附录C:待确定的问题,35,2023/3/28,4 实体联系图（ER图）,数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系。在需求分析阶段描述数据对象和它们之间的关系，使用了E-R 图。例如，在教学管理中，一个教师可以教授零门、一门或多门课程，每位学生也需要学习几门课程。因此，教学管理中涉及的对象有学生、教师和课程。,数据建模,36,2023/3/28,37,2023/3/28,教学数据模型,38,202
15、3/3/28,实例的关联有三种：一对一(1:1)；一对多(1:m)；多对多(n:m)。这种实例的关联称为“基数”，基数表明了“重复性”。,39,2023/3/28,40,2023/3/28,1-NF：所有属性都是原子值，即不出现“表中有表”,范式(Normal Forms)：消除数据冗余的程度,5 数据规范化,41,2023/3/28,2-NF：在 1-NF 基础上，每个非主属性都由整个主关键字决定（而非依赖于主关键字的一部分）。例：“Major”实际上由“ID”的第5、6位决定，可省去。,42,2023/3/28,3-NF：在 2-NF基础上，非主属性之间无依赖关系。,43,2023/3/2
16、8,功能建模和数据流,最初,结构化分析方法仅讨论数据流建模，目标系统被表示成如图所示的数据变换流程图。系统的功能体现在核心的数据变换中。,顶层数据流图（上下文环境图）,44,2023/3/28,数据流图中的主要图形元素,45,2023/3/28,分层的数据流图,46,2023/3/28,领书单 进书通知,购书单 缺书单,案例1：售书系统,DFD是系统中各处理功能以及它们之间数据流动的图形表示-刻划系统功能和行为,47,2023/3/28,领书单 进书通知,进书通知,购书单缺书单,F1教材存量表,F2缺书登记表,48,2023/3/28,案例2：工资计算系统的顶层(0层)数据流图,49,2023
17、/3/28,工资计算系统第一层数据流图,50,2023/3/28,工资计算系统的第二层数据流图(a)“计算工资”子数据流图；(b)“工资转存”子数据流图,51,2023/3/28,行为建模,行为建模给出需求分析方法的所有操作原则，但只有结构化分析方法的扩充版本才提供这种建模的符号。数据流图不描述时序关系，控制和事件流通过行为模型描述。在描述系统或各个数据对象的行为时，采用状态迁移图。通过描述系统或对象的状态，以及引起系统或对象状态转换的事件来表示系统或对象的行为。,6 状态转换图（状态迁移图）,52,2023/3/28,描述系统的状态如何相应外部的信号进行推移的一种图形表示。圆圈“”表示可得到
18、的系统状态 箭头“”表示从一种状态向另一种状态的迁移,状态转换图（简称为状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果，系统将做哪些动作（例如，处理数据）。,53,2023/3/28,1.组成部分及其符号表示,54,2023/3/28,状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。在状态图中定义的状态主要有：初态（即初始状态）、终态（即最终状态）和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。,55,2023/3/28,状态图既可以表示系统循环运行过程，也可以
19、表示系统单程生命期。事件是在某个特定时刻发生的事情，它是对引起系统做动作或系统状态转变的外界事件的抽象。状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。,56,2023/3/28,可得到的状态：等待，运行，就绪事件：t1 中断已处理 t2 分配CPU t3 用完CPU时间 t4 中断事件,例：当有多个申请占用CPU运行的进程时,进程的状态迁移。,57,2023/3/28,2.状态转换图实例,画出电话系统的状态图。没有人打电话时电话，电话处于闲置状态；有人拿起听筒，则进入拨号音状态，到达这个状态后，电话的行为是响起拨号音并计时；这时如果拿起听筒的人改变主意不想打了，他把听筒放下
20、（挂断），电话重又回到闲置状态；如果拿起听筒很长时间不拨号（超时），则进入超时状态；。,58,2023/3/28,59,2023/3/28,数据字典,数据字典是结构化分析方法的核心，与各模型的图形表示配合，能清楚地表达数据处理的要求。词条描述对于在模型中每一个被命名的图形元素，均加以定义，其内容有:名字，别名或编号，分类，描述，定义，位置，其它，等,60,2023/3/28,7 其它图形工具,1、层次方框图(Hierarchy)用树型结构的一系列多层次的矩形框描绘数据的层次结构。顶层代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素（不能再分割
21、的元素）。例1：,61,2023/3/28,例2：某单位职工实发工资的层次方框图,62,2023/3/28,例1：,2、Warnier 图用树型结构描绘信息，可以表明信息的逻辑组织（重复或条件出现），比层次方框图提供了更丰富的描绘手段。,63,2023/3/28,64,2023/3/28,3、IPO图(Input/Process/Output)：描绘输入数据、对数据的处理和输出数据之间的关系。在需求分析阶段可以使用IPO图简略地描述系统的主要算法（DFD中各个处理的基本算法）。,1.校验主记录2.校验事务记录3.更新主记录,旧的主文件事务文件,有效的主记录有效的事务记录更新后的主文件,例：,6
22、5,2023/3/28,改进的IPO图,66,2023/3/28,一致性：任何一条需求不能和其他需求互相矛盾。完整性：需求是否全面。现实性：技术水平能够实现。有效性：正确无错地表达需求，且满足用户的实际需求，解决用户面对的问题。,需求验证的特征：,8 验证软件需求,67,2023/3/28,需求分析评审,任务:,多方人员一起对SRS进行复核和评审，以确保SRS全面、准确、一致地反映用户需求,原则:,支持各方（用户，需求分析人员、设计人员）共同参与评审工作,68,2023/3/28,1、系统定义的目标是否与用户的要求一致2、系统需求分析阶段提供的文档资料是否齐全3、文档中的所有描述是否完整、清晰
23、、准确反映用户要求4、与所有其他系统成分的重要接口是否都已经描述5、所开发项目的数据流与数据结构是否足够，确定6、所有图表是否清楚，在不补充说明时能否理解7、主要功能是否已包括在规定的软件范围之内，是否都已充分说明8、设计的约束条件或限制条件是否实际9、开发的风险是什么10、是否考虑过软件需求的其它方案11、是否考虑过将来可能会提出的软件需求12、是否详细制定了检验标准，她们能否对系统定义是否成功进行确认13、有没有遗漏、重复和不一致的地方14、用户是否审查了初步的用户手册15、软件开发计划中的估算是否受到了影响。,需求规格说明（SRS）评审具体如下：,69,2023/3/28,小结,了解需求分析的任务和方法,掌握需求分析工具的使用：数据流图数据字典实体联系图状态转换图其它图形工具,70,2023/3/28,需求分析是发现、求精、建模、规格说明和复审的过程。需求分析的第一步是了解用户当前所处的情况，发现用户所面临的问题；接下来应该通过与用户交流，对用户的基本需求反复细化，以得出对目标系统的完整、准确和具体的需求。为了更好地理解问题，人们常常采用建立模型的方法，通常建立数据模型、功能模型和行为模型。在需求分析阶段建立起来的模型，在软件开发过程中有许多重要作用。除了创建分析模型之外，在需求分析阶段还应该写出软件需求规格说明，经过认真评审并得到用户确认之后，作为这个阶段的最终成果。,
