《软件工程》课件第四章-需求分析

第四章系统分析主要内容2.1系统分析2.2需求分析2.3结构化分析方法2.4快速原型化方法2.5需求定义与评审2.1系统分析如何识别、获取需求?你能够采取何种手段与用户进行交流沟通?何为需求建模?你如何理解模型与建模?2.1系统分析基于计算机的系统的系统元素包括硬件、软件、人、数据库、文档和过程。系统分析的目标1)识别用户要求2)评价系统的可行性，进行经济和技术分析3)把功能分配给硬件、软件、人、数据库和其它系统元素4)建立成本和进度限制5)生成系统规格说明识别用户要求分析员必须考虑以下问题：识别希望的功能和性能范围;确定系统的功能、性能、约束和接口;功能和性能可靠性和质量总的系统目标成本与进度限制制造需求市场与竞争情况有效的技术将来可能的扩充2.2软件需求分析：“做什么？”需求分析的过程是开发人员与用户共同协商，准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。并且使用软件开发人员和用户都能理解的语言准确地表达出来，即用需求规格说明书规范的形式准确地表达用户的需求。软件需求重要性例子☻“喂，是Jack吗？我是人力资源部的Tom,我们在使用你编写的职员系统时遇到一个问题，一个职员想把她的名字改成SparkleStarlight,而系统不允许，你能帮帮忙吗？”“她嫁给了一个姓Starlight的人吗？”Jack问道。☻“不，她没有结婚，而仅仅是要更改她的名字，”Tom回答，“就是这问题，好象我们只能在婚姻状况改变时才能更改姓名。”“当然这样，我从没想到谁会莫名其妙地更改姓名，我也不记得你曾告诉我系统需要处理这样的事情。”Jack说。☻Tom说：“我想你当然知道每个人只要愿意都可以随时合法更改其姓名。但不管怎样，你在本周五之前解决这问题，否则Sparkle不能支付她的帐单。”“这不是我的错！我现在正忙着做一个新的系统，还要做一些别的需求变更请求。很抱歉，只能下周才能修改。”……故事带给我们的启示……影响：作为客户，很恼火，因为软件系统不能进行一项基本的操作。哪怕开发者给其解决了，也不会感谢他。作为开发者，也很烦人，迫使你增加了当前的工作，又要你优先处理。原因：由于收集、编写、协商、修改需求过程的手续或方法失误带来的。这里是非正式信息的收集、未确定或不明确的功能、未发现或未经交流的假设、不完善的需求文档，以及突发的需求变更过程所造成的。解决办法：重视需求分析，派经验丰富的人员做，最大程度的减少类似情况发生。需求分析是一项软件工程活动，其目的是：清楚地理解所要解决的问题，完整地获取用户要求；刻划出软件的功能和性能；指明软件与其他系统元素的接口；建立软件必须满足的约束。1.软件需求分析的目的需求分析的特点老问题：☻问题的复杂性☻交流障碍（讲究技巧和原则）☻不完备性和不一致性☻需求易变性（动态性）派经验丰富的人去干！系统分析员软件需求的任务——理解、分解、表达、评审1.问题识别：双方确定问题的综合需求。☻功能需求：系统必须做什么？☻性能需求：做得怎样？例：responsetime,memory,back-upmemory,……☻环境需求：运行环境、软硬件配置等。☻用户界面需求☻可靠性、安全性、保密性、可移植性和可维护性等方面的需求。☻将来可能提出的要求共同理解！软件需求的任务2.分析与综合:导出软件的逻辑模型。对获取的需求进行一致性的分析检查，在分析、综合中逐步细化软件功能，划分成各个子功能。也对数据域进行分解，分配到各个子功能上，并用图文结合的形式，建立起新系统的逻辑模型。软件需求的任务3.编写文档：☻编写需求说明书☻编写初步用户使用手册☻编写确认测试计划☻修改完善项目开发计划需求文档用户需求报告需求规格说明书对外的，验收依据对内的，设计依据是合同的产物是立项建议书的产物由用户需求报告可产生需求规格说明书当前系统，目标系统目标系统（数据字典，算法分析）软件需求的任务需求分析研究的对象是用户的要求。必须全面理解用户的各项要求，准确表达被接受的用户要求。只有经过确切描述的软件需求才能成为软件设计的基础。4.技术审查和管理复审软件需求的任务验证需求的一致性验证需求的完整性验证需求的现实性验证需求的有效性方法：人工审查开发原型系统－探索型使用软件工具——完整性、一致性基线4.技术审查和管理复审软件需求分析的原则需要能够表达和理解问题的信息域和功能域信息流：数据和控制通过一个系统时的变化方式。两个功能之间的数据/控制传递就确定了功能间的接口。信息内容：单个数据或控制对象，它们构成了某个更大的由软件变换生成的信息的集合。信息结构：各种数据和控制项的内部组织。描述作为外部事件结果的软件行为，建立行为模型对描述信息、功能和行为的模型进行分解，用层次的方式展示细节需求分析的步骤需求获取需求提炼：分析建模(导出软件逻辑模型)需求描述：编写需求规格说明书需求验证需求获取的目的清楚地理解所要解决的问题完整地获取用户需求学习用户的有关业务知识，在用户帮助下了解用户的软件或子系统业务流程，结合软件开发和应用的经验提出新的用户需求。方法：进行调查研究调查研究的目的：是了解用户的真正需要调查研究的方法访谈：正式访谈和非正式访谈。分发调查表。开会—讨论—确认的方法。•建立分析小组领域专家：主角系统分析员：导演某出版社系统调查表编号提出问题1您在哪个部门工作？2出版业务流程是什么？3您每日都处理那些文件、数据、报表？4工作中手工处理特别麻烦的事情是什么？5工作中手工处理什么问题解决不了？影响效率的问题有哪些？6您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些办法？某出版社系统调查表编号提出问题7您的部门需要成本核算和统计的内容有哪些？8您的部门采用计算机管理工作情况如何？9如何改进业务流程使之更合理？10哪些问题是目前传统手工方法根本无法解决的？11出版社计算机管理信息系统需要解决什么问题？需求获取的内容1)业务需求反映了组织或客户对系统、产品高层次的目标要求，它们一般在项目视图和范围文档中给予说明。2)用户需求描述用户使用软件需要完成哪些任务，它们可通过使用实例图或脚本说明加以阐明。3)功能―非功能需求定义了开发者必须实现的软件功能，而非功能需求如表所示:非功能性需求表：性能要求实时性;其他时间要求，如响应时间、处理时间、包传送时间等;资源配置要求;精确度、处理量等要求可靠性要求有效性;数据完整性安全保密要求安全性;保密性运行要求使用频度、运行期限;控制方式;对操作员要求产品要求物理要求系统的规模等开发类型实用性开发或试验性开发项目估算开发工作量估计开发方法质量控制标准;里程碑和评审;验收标准优先顺序权衡各种质量目标要求，排定优先实现次序过程要求可维护性可理解性、可测试性、可修改性、可移植性2.两类需求包括的内容(1)功能(2)性能(3)环境(4)界面(5)用户或人的因素(6)文档(7)数据(8)资源(9)安全保密(10)软件成本消耗与开发进度(11)质量保证系统做什么？系统何时做什么？系统何时及如何修改或升级？软件开发的技术性指标。例如：存储容量限制、执行速度、相应时间、吞吐量硬件：机型、外设、接口、地点、分布、温度、湿度、磁场干扰等。软件：操作系统、网络、数据库有来自其它系统的输入吗？到自其它系统的输出吗？对数据格式有规定吗？对数据存储介质有规定吗？用户类型？各种用户熟练程度？需受何种训练？用户理解、使用系统的难度？用户错误操作系统的可能性？需哪些文档、针对哪些读者输入、输出数据的格式？接收、发送数据的频率？数据的准确性和精度？数据流量？数据需保持的时间？软件运行时所需的数据、软件。内存空间等资源。软件开发、维护所需的人力、支撑软件、开发设备等需对访问系统或系统信息加以控制吗？如何隔离用户之间的数据？用户程序如何与其它程序和操作？系统隔离？系统备份要求？开发有规定的时间表吗？软硬件投资有无限制？系统的可靠性要求？系统必须监测和隔离错误吗？规定系统平均出错时间？出错后，重启系统允许的时间？系统变化如何反映到设计中？维护是否包括对系统的改进？系统的可移植性？需求获取过程需求获取包括以下活动：1)发现和分析问题发现问题症结，并分析问题的原因/结果关系。2)获取需求根据对问题的理解定义需求。a)使用调查研究方法收集信息；b)遵循需求获取框架，按照三个成分观察：即数据、过程和接口。3)需求归档以草稿形式归档调查结果。形式有用例、决策表、需求表等。需求获取技术的基本特征好的需求获取技术，对于规范需求获取活动，高效准确地获取需求定义，是十分重要的。好的需求获取技术，应具有如下基本特征：提供便于沟通的工具，如易于理解的语言和直观的图表；提供定义系统边界（交互）的方法；提供支持抽象的机制，如“分解”、“映射”等；软件工程29鼓励分析员使用面向问题的术语思考问题，编写文档；为分析员提供多种可供选择的解决方案；适应需求的变化。适于以上特征的需求获取方法：基于数据流图的结构化分析方法；基于用例（usecase）的建模方法。需求获取技术的关键点在于：a.深入浅出需求获取要尽可能全面、细致。软件工程30需求获取技术的关键点在于：a.深入浅出需求获取要尽可能全面、细致。获取的需求是个全集，系统真正实现的是个子集。分析时的调研内容并不都纳入到新系统中，目的在于以后的扩充。b.以流程为主线在与用户交流的过程中，应该用流程将所有的内容串起来。如信息、组织结构、处理规则等。这样便于交流沟通。流程描述有宏观，也有微观。既要强调总体的业务流程、全生存周期的业务流程，又要对流程细化，有分支的业务流程。需求获取应遵循的原则抽象和分解是在人们认识世界和改造世界的长期实践中总结出来的行之有效的原则，在需求获取的过程中需遵循的三个原则：a.分解：捕获问题空间的整体–部分关系。如问题／子问题分解；b.抽象：捕获问题空间的一般化–特殊化关系。如问题的不同变型；c.投影：捕获问题空间的多维视图。即从不同角度考察。需求获取的步骤软件开发项目和组织文化的不同，对于需求开发没有一个简单的、公式化的途径。下面9个步骤，针对信息系统的需求获取。1)定义项目的视图和范围包括组织结构图、各部门的岗位/角色列表。2)确定用户类包括人员/责任矩阵。3)确定目标系统的业务工作流包括物流、资金流、信息流，建立业务工作流模型。4)运用需求获取技术开发反映主要业务规则的用例（或数据流图）并设置优先级。5)收集来自用户的质量特性信息和其他非功能需求将性能、安全性、可靠性等需求和其他设计约束结合业务规则，形成功能需求。6)分类在用例（或数据流图）中涉及的数据包括数据的组成和数据之间的关系。7)详细拟订用例（或数据流图）的规格说明，建立功能模型，并进行审查，用以澄清需求获取的参与者对需求的理解。8)开发并评估界面原型设想输入设备、输出设备、显示风格、显示方式、输出格式等，建立接口规范和信息流传输规则。9)从功能描述中开发概念测试用例用测试用例来验证用例（或数据流图）、功能需求和原型。需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。表现在：需求的不稳定性：在整个软件生存周期内软件需求会随着时间的推移发生变化；需求的不准确性：用户和开发人员的认识会随着使用系统实现业务流程的实践逐步提高，一开始不可能设想得面面俱到。需求获取只有通过有效的客户/开发者的合作才能成功。需求整理与表达的方法采用穷举方法可以避免遗漏。采用归纳方法，通过对各种情况进行综合分类可以使问题条理化。采用抽象方法，可以发现问题的实质，抓住问题的主要矛盾，忽略其次要矛盾。需求整理可以多种手段共用，如组织结构图、业务流程图、多叉树、关系矩阵、文字叙述、表格、图形等。需求描述包括组织结构与岗位定义、业务流程、处理规则、数据项、功能以及上述5个方面的关系。4.需求建模需求建模是为了分析需求，以确定项目的确切需求。需求建模遵循三个原则：划分：描述需求的整体–部分关系；抽