软件工程需求分析--需求分析

2020/4/211第5章需求分析可行性研究通过以后，下一步就要根据草拟的开发计划，展开详细的需求分析活动。软件需求分析，是详细分析需求，并建立需求分析模型的阶段2020/4/212第5章软件需求分析•5.1需求分析概述•5.2结构化分析方法•5.3数据流图的绘制•5.4编制数据字典•5.5加工逻辑的分析与表达•5.6需求验证与评审2020/4/2135.1需求分析概述•5.1.1需求分析的任务、特点、主要困难•5.1.2人员组成•5.1.3分析师的角色•5.1.4需求分析的活动和原则2020/4/2145.1.1需求分析的任务1.完成“分析建模”;2.拟定“确认测试”计划3.修订“开发计划”4.编写“需求规划说明书”5.需求评审2020/4/2151.分析建模•针对用户要求实现的软件功能、性能等目标，与开发人员进一步澄清、达成共识、形成规约;•准确讲，需求分析是发掘需求、分析求精、逻辑建模、形成规约的过程。2020/4/2161.分析建模①发掘需求——调查需求、挖掘潜在需求、预测未来可能的需求；②需求求精——对模糊不清的用户需求明确、精化；③逻辑建模——在现行系统逻辑模型的基础上，考虑新的用户需求、限制和约束的基础上导出新系统的逻辑模型；④形成规约——将双方达成共识的需求文档化、模型化，这份文档被称为“需求规约”和“需求规格说明书”，它将是后需活动开发方努力实现的目标2020/4/2172.拟定“确认测试”计划•有了共同的需求约定以后，就可以制定“确认测试”计划，它是用户验证软件是否满足需求的依据；•这个计划到综合测试后期执行。2020/4/2183.修订开发计划•系统调查与可行性研究阶段的最后，草拟了初步的开发计划，当时由于需求尚不详细，现可有了详细的需求分析结果以后，应该使开发计划更准确一些。2020/4/2194.编写“需求规划说明书”•需求分析阶段的成果集中体现在“需求规格说明书”中，这是一个里程碑；•有明确的格式和内容2020/4/21105.需求评审•需求评审是“质量保证活动”的内容；•体现出瀑布模型的“文档驱动”特点•由项目经理、用户、分析员、前一阶段（可行性研究）的主要人员和后一阶段（概要设计）的主要人员组成评审小组；2020/4/2111阶段性成果（主要文档）包括：•需求规格说明书•细化的项目计划•确认测试计划2020/4/2112主要特点:–面向问题域（即用户业务领域）–只关注“逻辑”，不考虑“物理”•只研究应该“做什么？”，暂不考虑用什么手段、如何实现，即“怎么做”的问题；–用数流据图、数据字典、加工描述等工具建立逻辑模型2020/4/2113面临的主要困难•需求分析活动面临的挑战：①使用有效的软件工程方法克服复杂性②建立分析员与用户的有效沟通③使用有效的工具，克服需求表述的二义性2020/4/21145.1需求分析概述•5.1.1需求分析的任务、特点、主要困难•5.1.2人员组成•5.1.3分析师的角色•5.1.4需求分析的活动和原则2020/4/21155.1.2人员组成•如果是一个企业信息系统开发项目，那么项目团队成员应包括用户和开发人员；•参与团队的用户包括：–企业负责人、部门负责人、专业岗位上的员工；•参开团队的开发人员包括：–系统分析师、数据管理员；•在需求评审时，还需要”可行性分析“和”系统设计“阶段的主要人员参与；2020/4/21165.1需求分析概述•5.1.1需求分析的任务、特点、主要困难•5.1.2人员组成•5.1.3分析师的角色•5.1.4需求分析的活动和原则2020/4/21175.1.3分析师的角色•是用户与开发人员的桥梁；•与项目经理合作，是开发团队的领军人物；•具体业务主要集中在可行性研究和需求分析阶段；•个人素质方面：–具有领导才能，善于沟通；–具有实干作风；–知识面宽，重在广度而不是深度；–技术全面；–有时分析师是一个团队，由若干人承担；2020/4/21185.1需求分析概述•5.1.1需求分析的任务、特点、主要困难•5.1.2人员组成•5.1.3分析师的角色•5.1.4需求分析的活动和原则2020/4/21195.1.4需求分析的活动和原则•活动主要分为：–需求获取；–分析建模；–需求评审2020/4/2120需求获取的目标•对用户需求进行鉴别、综合，清除用户需求的模糊性、歧义性和不一致性；•把对原始问题的理解和软件开发经验结合起来，鉴别由于用户的片面性或短期行为所导致的不合理要求，发现用户尚未发现的但具有真正价值的潜在需求；2020/4/2121需求获取中风验•需求获取隐藏着很大的风险•因为任何错误的需求描述，都必然造成错误的设计、错误的编程和错误的软件结果，而实际情形是这种潜在的风险是客观存在的2020/4/2122总的原则•分析师关注的焦点是“做什么（What）”，而不是“怎么做How”，系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会遇到什么约束？等。•这一阶段主要精力集中在获取和分析系统的逻辑功能上。不要把“用计算机如何实现”这样的物理因素牵扯进来，影响逻辑功能的分析。2020/4/21235.1.4需求分析的活动和原则•活动主要分为：–需求获取；–分析建模；–需求评审2020/4/2124分析建模•用户往往会从不同的角度、不同的抽象级别阐述对原始问题的理解和需求，相对比较零乱，有必要借助模型。•一方面，模型用于精确地记录用户从各个视角、不同抽象级别上对原始问题及目标软件的描述；另一方面，它将帮助分析人员去伪存真、由表及里地挖掘用户需求。•建模不仅是描述系统的工具，也是用户与开发人员进行交流的工具。在结构化分析方法中，数据流图是建模的主要工具。逻辑模块不仅是描述问题的图形工具，同时更是分析问题的一种工作方法。2020/4/2125•调研阶段产生的文档，是需求分析的起点，是目标软件系统逻辑模型的雏型。•在需求分析阶段，分析师将进一步对它进行细化、扩充，直到足够具体为止。在分析的过程中建立数据字典，对模型进行注解。•逻辑模型是分析师与用户交流的主要工具，也是需求分析阶段的成果的主要体现。2020/4/21263.需求评审•需求审查和管理复审是需求分析的最后一个环节，通过了这一环节，就等于暂时为需求分析阶段画上了一个“句号”。尽管后期可能还会有些对需求分析的反复，但有了这个“句号”，就可以进入设计阶段了。•经过审批之后的文档，在整个项目范围内，相当于用户与开发人员之间达成了一份合约，后期的系统设计和系统测试，都将以这份“规约”为准。•任何对合约的修改，都将影响到整个项目的工期和开发成本，都需要经过严格的审批和签约。2020/4/2127例家庭保安系统问题描述：家庭保安市场正以每年40%的速度增长。希望建立一种基于微处理器的家庭保安系统，它能够识别异常事件并采取相应的防护措施。这些异常事件包括：非法侵入、火灾、水淹等。一旦异常情况被传感器探测出来，系统应自动通过电话向监控中心报警。此外，应允许户主对系统行为进行程序控制。2020/4/2128家庭保安系统分析初期联合小组的工作程序联合小组首先制定工作制度：每次会议开始前必须有确定的议程，参加者必须针对各项议程进行充分的准备，并用文字表示。经过会议讨论，明确问题的范围、问题与环境的关系，并就开发软件产品的必要性达成共识。2020/4/2129例家庭保安系统•小组负责人要求每位参加者列出问题及环境中的有关对象，对这些对象施行的操作以及对象间的相互作用。列出的操作和对象尽可能完全，如，控制面板、电话机、监控中心、烟雾传感器、门窗监视器、警报器等对象，以及用户编程控制、电话拔号、报警等操作。•负责人应要求小组成员对接收传感器事件、用户编程控制、电话报警等操作进行更详细的描述，必要时可用流程图表示。2020/4/2130例家庭保安系统•用户可能提出一些条件，如造价不能超过3，000元，对传感器事件必须在1秒内作出响应，事件必须按优先级进行处理等。会后小组负责人对这些信息进行综合、整理，形成文档，该文档应能反映“家庭保安系统”的全貌。•联合小组分成两个小组，分别处理用户编程控制和传感器监测两个子系统。目的是对子系统的软件需求进行细化。对出现的新对象、新操作、新约束应及时添加到相应的子系统。2020/4/2131例家庭保安系统•确定子系统需求并形成文档•联合小组讨论子系统的集成及需求验证标准。子系统集成包括子系统接口的一致性检查、系统功能和行为的完整性检查。需求验证标准应该是可测试的，以便开发人员在代码生成后能够通过测试结果向用户表明软件系统已完整地实现了用户需求。•初步分析活动应形成结论性文档，该文档将作为后续分析活动的基础。2020/4/2132例家庭保安系统初步分析生成的“家庭保安系统”部分需求文档(不包括约束条件和测试标准)•“家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与用户进行信息交互。•配置操作(1)指定每一传感器的种类和编号；(2)设置开、关机密码；(3)指定报警电话号码；(4)指定报警延迟和电话重拔延迟时间(以秒为单位)。2020/4/2133例家庭保安系统•当软件系统接收到传感器发出的数据后，判别是否出现异常事件。如果是，则在指定的延迟时间内拔报警电话号码，拔号操作将按照重拔延迟反复进行，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。•开机后软件系统负责显示当前工作状态，接收并处理用户指令。2020/4/2134第5章软件需求分析•5.1需求分析概述•5.2结构化分析方法•5.3数据流图的绘制•5.4编制数据字典•5.5加工逻辑的分析与表达•5.6需求验证与评审2020/4/2135什么是结构化方法？•软件工程方法论：–面向对象方法论–面向过程方法论——结构化方法•解决复杂问题的方法——分解–面向对象——按“负责”分解问题，找承担责任的对象–结构化方法——按“功能”分解问题，划分模块2020/4/21365.2结构化分析方法•5.2.1结构化分析的概念•5.2.2细化数据流图•5.2.3数据流程图应用实例2020/4/21375.2.1结构化分析的概念•用一组标准的工具和策略从事系统分析与设计，以便提高系统分析与设计的质量和效率2020/4/2138•结构化分析方法的直接目的就是撇开物理因素，在综合分析用户对系统各项要求的基础上，最终导出新系统的逻辑模型。•用数据流图作为主要工具，进一步审查用户的真实需求和新系统必须完成的功能，逐步细化数据流图，直到把“数据流”、“加工”和“数据存贮”分析分解到足够具体为止，最终得到的就是系统的基于功能的逻辑模型。2020/4/2139•在对数据细化的过程中，要建立数据字典，对“数据元素”、“数据结构”、“数据流”、“数据存贮”和“加工”都要加以详细的定义和注释。•加工的处理逻辑描述，还需要用到专门的分析和表达工具：结构式语言、判定树和判定表等工具2020/4/2140•综上所述，结构化系统分析的过程，大致归纳为以下几步：•细化数据流图（DFD），必要时，对实时系统还要绘制控制流图（CFD）；•编制数据字典；•用户复查；•修正开发计划；•整理文档；•审查和复审。2020/4/21415.2结构化分析方法•5.2.1结构化分析的概念•5.2.2细化数据流图•5.2.3数据流程图应用实例2020/4/21425.2.2细化数据流图•1．沿数据流图回溯，挖掘想要的内容•2．自顶向下逐层分析的分析策略2020/4/21431．沿数据流图回溯，挖掘想要的内容•系统输出的数据流是由哪些数据元素组成的？每个数据元素又是从哪里来的？对这些问题的回答，迫使我们必须从数据流图的输出端开始，沿数据流的方向回溯。•既然它们是系统的输出，显然不是从外面输入到系统中来的就是通过加工产生出来的。沿数据流图从输出端向输入端回溯，一定能够找出每个数据元素的来源。同时确认某个数据流是由某个加工产生的，就可以从用户那里调查分析得到该加工的逻辑算法。2020/4/2144•记住一个准则：“数据流”一定是和“加工”有关联的。