软件需求分析过程

软件需求分析与建模,林泉软通动力信息技术（集团）有限公司2011,软件工程方法与实践,主要问题,什么是软件需求？软件需求分析有哪些过程？如何启动分析过程？什么是面向数据的建模？什么是面向数据流的建模？什么是非形式化建模、半形式化建模和形式化建模？什么是统一建模语言（UML）？什么是用例建模？什么是领域模型？,软件需求分析过程,什么是软件需求？软件需求分析有哪些过程？如何启动分析过程？需求规格文档有哪些内容？需求分析有哪些技术？,一般把需求定义为“（正在构建的）系统必须符合的条件或具备的功能或能力”。电气和电子工程师学会使用的定义与此类似。著名的需求工程设计师MerlinDorfman和RichardH.Thayer提出了一个包容且更为精练的定义，它特指软件方面-但不仅仅限于软件：1、软件需求可定义为：用户需解决某一问题或达到某一目标所需的软件功能。2、系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。,5.1什么是软件需求,需求工程基本任务,需求工程,需求管理,需求开发,需求获取,需求分析,需求规格说明,需求验证,变更管理,需求分析的基本任务,需求分析的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。,需求分析模型,系统实现模型,目标系统,当前系统,物理模型,逻辑模型,逻辑模型,物理模型,模型化,抽象化,实例化,具体化,理解需求,表达需求,导出,做什么,怎么做,需求分析的主要工作,系统流程图或高层DFD图,DFD图、STD图、E-R图、用例图、类图、顺序图等,目标系统,描述现实系统是如何在物理上实现的。,描述新系统的主要业务功能和用户新的需求，无论系统应如何实施。,描述新系统是如何实施的（包括技术）。,逻辑模型物理模型(本质模型、概念模型)(实施模型、技术模型),描述重要的业务功能，无论系统是如何实施的。,现行系统,需求分析模型,软件需求曾经让我们如此狼狈,软件开发的问题分类,1、需求规格说明4、软件和测试2、管理客户需求5、项目管理3、建档6、编码问题的重要性依次降低,ESPITI(欧洲软件过程改进培训倡议）所作的一个调查，3800个被调查者认为，软件开发的主要问题、次要问题和不是问题的问题如图。一半以上的人认为，软件的二个最大问题是：1、需求规格说明2、管理客户需求相对而言，编码不是问题,需求错误的代价,“需求开发可能是软件开发中最困难、最关键、最易出错以及最需要沟通的方面”,需求变化,合理范围内的变化：用户不了解自己的需求需求本身易变，市场、技术、竞争因素不合理的变化：需求文档质量不高需求分析技能、技术和管理上的缺陷需求变化的原因：未受控制的需求变更遗漏需求用户交流不够需求规约质量差低效的需求分析,谨记一点，需求是经常变动的，只有先做好需求的分析，了解业务以后的发展趋势，做好具有拓展性的系统设计，才会给系统更大的扩展空间，从而在需求发生变化的时候可以更从容的修改。,需求分析的重要性,需求的重要性：需求是产品的根源，需求工作的优劣对产品影响最大。是系统开发的基础，质量和成败的关键国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。需求分析是通过问题识别、分析与综合、制订规格说明和评审等阶段，达到为系统设计提供依据的目标。因此，需求分析过程包括：确定对系统的综合要求分析系统的数据要求抽象出并确立目标系统的逻辑模型编写需求规格说明书,需求分析就是为了实现系统需求，并使最后交付成果与需求所要求的目标不产生：含糊性、不完整性、不可检验性、不一致性、不可追踪性和不可用性。需求分析面向下阶段系统概要设计需求分析采用自己的特定方法，达到相应的阶段要求采用的方法是尽量地让用户和开发团队都能理解并认同系统目标和范围界定的方法业务/系统模型、用例和USECASE图需求分析阶段的目标是用计算机的（而不再是用户）眼光和语言，分解需求、定义需求。但是，这个眼光不是程序设计员的眼光，是系统分析师的眼光经过需求处理后，达到需求规范要求分析的方法是一套“建模”技术,需求分析的成果,软件需求的分类,功能需求：描述系统预期提供的功能或服务对系统应提供的服务如何对输入做出反应系统在特定条件下的行为非功能需求：指那些不直接与系统具体功能相关的一类需求产品需求机构需求外部需求领域需求：源于系统的应用领域需求,功能需求,软件系统的功能需求描述可以有许多方式：文字描述图表表示功能需求可以以不同的详细程度反复编写和细化功能需求描述应该完整而且一致和准确完整性意味着用户所需的所有的服务应该全部给出描述一致性意味着需求描述不能前后矛盾准确性是指需求不能出现模糊和二义性的地方,功能需求描述：出卷系统,教师能够根据自己的要求手动或自动出一份试卷；教师可以修改试卷中不合适的题目，并能自动生成各种样式的试卷；教师可以对试题中的题目进行更新。,非功能需求,非功能需求主要与系统的总体特征相关，是一些限制性要求，是对实际使用环境所做的要求性能要求可靠性要求安全性要求可用性要求移植性要求非功能需求关心的是系统整体特征而不是个别的系统的特征，比功能需求对系统更关键。非功能需求却很难检验非功能需求与功能需求有时会发生冲突，它们之间存在着相互作用关系,非功能需求举例,一个POS系统所需的存储因为成本原因有所限制，而商品的描述和价目表的信息量很大。如果采用远程服务器，提供商品描述和价目表信息，那必然需要网络通信，而这需要网络技术。当POS机数量多时必然引起服务器处理瓶颈问题。,领域需求,领域需求反映应用领域的基本问题，直接影响到系统的可用性。例如：图书馆系统的功能需求基于标准用户界面将一些文档输出到本地打印机或网络打印机上，但因为版权限制，这些文档打印之后应立即删除。,领域需求示例：短信系统,如果短信经过终端无线模块发送之前必须经过短消息协议标准编码才能发送出去。要对短信编码，必须要对由ESTI制订的SMS规范有所了解技术实现(含编码方式)GSM03.38、GSM03.40SMS的DTE-DCE接口标准(AT命令集)：GSM07.05三种方式来发送和接收SMS信息：BlockModeTextMode：纯文本方式，可使用不同的字符集，也可用于发送中文短消息，主要用于欧美地区。PDUMode：PDUMode被所有手机支持，可以使用任何字符集，这也是手机默认的编码方式,5.2需求分析过程,需求分析过程主要是理解客户需要什么、分析要求、评价可行性、协商合理的方案、无歧义地详细说明方案、确认规格说明、管理需求以至将这些需求转化为可行系统过程包括：初步沟通导出需求分析和精化可行性研究协商与沟通规格说明需求验证变更管理,5.2.1初步沟通,业务领域的共利益者（如业务管理人员，市场营销人员，产品管理人员）定义业务用例确定市场的范围初略地可行性分析确定项目范围的工作说明,5.2.2导出需求,导出需求应理解问题：范围问题：系统的边界，是客户和开发者共同关心的部分理解问题：确定业务需求、需求冲突、说明有歧义和不可测试的需求易变问题：分清需求稳定部分和易变部分收集活动：识别真正的客户/用户正确理解客户的需求耐心听取客户意见和思考尽量使用符合客户语言习惯的表达,5.2.3分析和精化,开发一个精确的技术模型，用以说明软件的功能、特征和约束。精化是一个分析建模动作，由一系列建模和求精任务构成定义了问题的信息域，功能域和行为域,5.2.4可行性研究,可行性研究的目的是确定用最小的代价，在尽可能短的时间内确定问题是否能够解决可行性研究的输入是系统的一个框架描述和高层逻辑模型输出是一份需求开发评价报告，对需求工程和系统开发是否值得做的具体建议和意见三个问题：系统是否符合机构的总体要求？系统是否可以在现有的技术条件、预算和时间限制内完成？系统能否把已存在的其他系统集成？,可行性研究的任务,可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。必须记住，可行性研究的目的不是解决问题，而是确定问题是否值得去解决。一般来说，至少应该从下述四个方面去研究每种解法的可行性：技术可行性：使用现有的技术能实现这个系统吗？经济可行性：这个系统的经济效益能超过它的开发成本吗？操作可行性：系统的操作方式在这个用户组织内行得通吗？时间可行性：能在预定时间内完成吗？可行性研究最根本的任务是对以后的行动方针提出建议。,5.2.5协商与沟通,调节冲突和问题需求排序识别和分析与每项需求相关的风险、开发工作量、成本和交付时间,5.2.6软件需求规格,一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或以上各项的任意组合。软件需求规格（SRS，SoftwareRequirementSpecification）是需求分析任务的最终“产品”，它是客户、管理者、分析工程师、测试工程师、维护工程师交流的标准和依据。软件需求规格描述了系统的数据、功能、行为、性能需求、设计约束、验收标准、以及其他与需求相关的信息。分为：用户需求和系统需求,用户需求描述示例,2.1处理销售：完成一次销售过程。2.1.1基本流程：（1）顾客携带所购商品或服务到收银台通过POS机付款；（2）收银员开始一次新的销售交易；（3）收银员输入商品条码；（4）系统逐条记录销售的商品，并显示该商品的描述、价格和累计额；重复（3）（4），直到输入结束；（5）系统显示总额；（6）收银员告知顾客总额，并请求付款；（7）顾客付款，系统处理支付；（8）系统记录完整的销售信息，并将销售金和支持信息发送到外部的帐务系统和库存系统；（9）系统打印票据；（10）顾客携带商品和票据离开。2.1.2扩展流程：.,系统需求,系统需求是比用户需求更详细的需求描述，是系统实现的基本依据系统需求描述可能包括许多不同的模型，如对象模型和数据流模型,软件需求各组成部分之间的关系,软件需求规格说明的原则,从现实中分离功能，即描述要“做什么”而不是“怎样实现”采用一定的规格说明语言如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中规格说明应该包括系统运行环境规格说明应该是一个认识模型规格说明应该容许不完备性并允许扩充,需求规格文档标准,1引言1.1编写目的1.2项目背景（单位和与其他系统的关系）1.3定义（专门术语和缩写词）2任务概述2.1目标2.2运行环境2.3条件限制3数据描述3.1静态数据3.2动态数据3.3数据库描述3.4数据字典3.5数据采集,4功能需求4.1功能划分4.2功能描述5性能需求5.1数据精确度5.2时间特性5.3适应性6运行需求5.1用户界面5.2硬件接口5.3软件接口5.4故障处理7其他需求（检测或验收标准、可用性、可维护性、可移植性、安全保密性）,5.2.7需求验证,需求验证是软件需求阶段的一个重要环节，未经验证的需求给项目成功带来较大的需求风险需求验证对需求文档和制品进行质量评估，确保需求说明准确、完整包括以下内容：正确性一致性完整性可行性必要性可检验性需求的可跟踪性最后签字,需求变更的原因多种多样，但管理变更，应确立以下原则：（1）认识到变更是不可避免的，为变更指定计划；（2）确定需求基线；（3）建立控制变更的唯一渠道（4）使用变更控制系统来控制变更过程；（5）分层次地管理变更。,5.2.8需求变更管理,需求变更管理,需求变更管理是组织、控制和文档化需求的系统方法建立基线以便在客户和开发人员之间建筑一个约定需求管理从标识开始，建立跟踪表需求跟踪表可以跟踪需求的特征、来源、依赖、子系统和接口等关系,通用跟踪表,5.3启动分析过程,确定共利益者：直接或间接从正在开发的系统中获益的人。例如，POS机系统中的共利益者有：收银员，售货员，顾客，公司，经理，支付授权服务，帐务系统和库存系统等识别视点：从不同的视角看待该系统。比如，收银员关心准确、快速生成一次销售，且没有支付错误；售货员关注销售提成协同工作：共利益者之间的协作首次提问：集中于客户和其他共利益、整体目标、收益等,5.4非形式化需求分析技术,会谈：正式会谈：提出一些可自由回答的问题非正式会谈：提出一些事先准备好的议题情景分析：需求分析从对场景的评论中得到信息，然后再将其以形式化方式表示出来。使用调查表制定调查表分析建立原型界面执行过程,场景分析,分析员与项目相关人员共同识别出情景，并捕获这些情景的细节。把细节加入到一个纲要的需求描述中时，情景特别有用情景是对交互实例片断的描述，每个情景可能包含一个或多个交互，它们能在不同的细节层次上提供不同类型的情景信息情景开始于一个框架，在导出过程中，细节被逐渐增加，直到产生交互的一个完整的描述,情景,一个情景可能包括如下内容：在情景开始部分有一个系统状态描述；一个关于标准事件流的描述；一个关于哪儿会出错，以及如何处理错误的描述；有关其他可能在同一时间进行的活动的信息；在情景完成后系统状态的描述,5.5实例分析5.5.1出卷系统,用户：教师：关注如何出一份合理的试卷，并能根据样式打印与输出。学生：关注如何通过生成一些模拟试题，并在线学习和检查学习结果。题库维护人员：关注试题的添加、更新和删除等工作。视点：教师关注自动出卷、手工出卷、试卷编辑和试卷输出。学生关注随时抽卷、联系试卷和评价分析。题库维护人员关注试题管理。,出卷系统的功能需求,自动出卷：系统根据教师的要求自动生成一份合理的试卷。手动出卷：教师手动从候选的试题中挑选题目。随机抽卷：系统随机抽取试题生产一份试卷。在线练习：学生可以在线做练习和查看答案。在线评价：系统在线评价学生练习的情况。试题管理：管理人员维护题库中的试题。试卷编辑：更新试题。试卷输出：根据某个样式输出试卷。,5.5.2POS机系统,收银员：能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其薪水众扣除。售货员：自动更新销售提成。顾客：希望以最小代价完成购买活动并得到快速服务。便捷、清晰地看到所输入的商品项目和价格。得到购买凭证，以便退货。公司：希望准确地记录交易，满足顾客要求。确保记录了支付授权服务的支付票据。有一定的容错性。能够自动、快速地更新记帐和库存信息。经理：能够快速执行超控操作，并易于更正收银员的不当操作。支持授权服务：依据正确的通信格式进行授权服务。库存系统：正确的方式更新库存信息。记账系统：能够准确地记录每次销售支付信息。,POS机系统主要功能需求,处理销售：收银员完成一次销售记录，并出具票据和更新库存系统和帐务系统。处理支付：完成一次销售对应的支付，包括现金支付，信用卡支付和支票支付。处理退货：根据顾客请求完成商品退货处理。办理会员卡：注册、注销和更新会员记录。,5.5.3图书馆系统,图书馆系统的共利益者与视点有：图书流通管理：负责图书借还工作。用户：希望快速得到借书，还书服务，能够续借、预约图书，以及查询个人和图书信息。编目管理员：负责图书的管理、用户管理和处理罚金等。,图书馆系统的主要功能需求,图书借出：管理员完成一次借书过程。图书归还：管理员完成一次还书过程。图书预约：用户查询要借的图书，若不能借，可预约该图书。图书续借：用户可以将图书的归还日期延长一段时间。图书管理：添加新书。更新图书馆信息，销毁图书。用户管理：注册新用户，更新用户信息，注销用户。处理罚金：用户缴纳罚金吼，系统将罚金数额清零。,5.5.4短信系统,本系统共利益者和视点有：收发人员：负责发送短信给用户或接受用户的短信。用户管理：添加用户，更新用户信息，删除用户。本系统主要功能需求有：短信发送：填写发送内容，选择发送用户，并指明是否要回执，然后发送短信。（通过无线终端或短信网关）短信接收：从无线终端或短信网关读取短信内容，并显示查看。用户管理：添加新用户，更新用户信息，删除用户。,5.5.5ATM系统,银行客户:接受系统服务；银行的代表:银行间自动柜员机有互惠协议；支行管理者:从该系统中获得管理信息；支行柜台职员:负责系统日常运转和处理客户意见；数据库管理者:负责系统和客户数据库集成；银行信息安全管理者:负责保证系统信息安全；银行市场开发部:将该系统视为银行市场开拓手段；硬件和软件工程师:负责硬件和软件维护及升级。,ATM系统主要功能需求,存款：从ATM机上存钱到指定账户上。取款：从指定账户上取一定数量的货币。转账：从一个账户取出一定数量的货币，然后转存到另一个账号上。查询余额：察看指定账户的余额。修改密码：修改账户密码。,总结需求分析流程,需求分析通信途径,系统分析（详细业务调查）,1、原则：1）自顶向下；2）用户参与；3）工程化；4）全面与重点相结合；5）友善的工作方式。,2、调查范围1）组织机构与功能业务；2）数据和数据流程；3）业务流程；4）决策方式及过程；5）可用资源与限制条件6）现存问题及改进。,3、调查方法1）召开调查会；2）访问；3）发调查表；4）参加业务实践。,某出版社系统调查表,组织结构与功能分析,组织结构图是一张反映组织内部之间隶属关系的树状结构图。组织业务关系图,业务流程分析,需求：组织的某些部分不能完整地反映该部分所包含的所有业务，所以要改变随着生产的发展，生产规模的扩大和管理水平的提高，组织的某些部分业务范围越来越大，功能也越来越细，由原来单一的业务派生出许多业务。这些业务在同一组织中由不同的业务人员分管，其工作性质已经逐步有了变化。这些变化将引起组织本身的变化，裂变出一个新的、专业化的组织，由它来完成某一类特定的业务功能。以功能为准绳来设计和考虑系统，系统将会对组织结构的变化有一定的独立性。以业务功能分析为基础，获得一张业务功能表所以：系统必须以业务为中心，业务功能与组织结构保持相对的独立性从组织结构直接转变为系统功能结构是初级系统分析师的第二个常犯的错误,业务功能图,销售系统管理,销售计划管理,成品库管理,销售合同管理,销售核算管理,市场预测,销售历史资料管理,编制年度销售大纲,编制销售计划,合同有效性审查,合同执行情况分析,合同登记和变更,销售利润核算,销售统计分析,出入库管理,库存统计,市场预测,市场分析,建立业务流程图,业务流程图表示系统的操作控制和数据流。业务流程图包括：a指明数据存在的数据符号，这些数据符号也可指明该数据所使用的媒体；b定义要执行的逻辑路径以及指明对数据执行的操作的处理符号；c指明各处理和（或）数据媒体间数据流的流线符号；d便于读、写系统流程图的特殊符号。,业务流程图示例银行文件处理系统,需求分析过程举例,(1)通过对现实环境的调查，获当前系统的具体模型(物理模型),需求分析过程举例,(2)去掉具体模型中的非本质因素，抽象出当前系统的逻辑模型,学生购买教材的逻辑模型,学生,学生,购书申请,购书单,发票,领书单,书,审查有效性,开发票,开领书单,发书,需求分析过程示意,(3)分析当前系统与目标系统的差别，建立目标系统的逻辑模型,计算机售书系统的逻辑模型,学生,学生,购书单,发票,领书单,审查并开发票,开领,书单,无效书单,小结,需求分析也称为需求工程，是一个非常重要而有很复杂的，需要交替进行，反复迭代的过程。软件需求分为功能需求和非功能需求。功能需求描述系统所预期提供的服务，而非功能需求描述与系统不直接相关的一些需求。领域需求是一种特有的功能需求，反应应用领域的基本问题。软件需求规格说明文档描述了系统的数据、功能、行为、性能需求、设计约束、验收标准以及其他于需求相关的信息，它有可能成为客户与开发商之间的合同。需求分析过程通过执行初步沟通、需求导出、分析与精化、可行性研究、协商和沟通、规格说明、验证和变更管理八个不同的活动来完成。非形式技术主要包括会谈、调查表和场景技术，用于获取用户需求和系统需求。,作业，P525，9，10,第6章结构化分析建模,分析模型元素结构化需求分析面向数据的建模方法案例分析,结构化开发方法,面向对象开发方法,软件开发方法,结构化分析建模,需求分析的任务就是准确地指出“软件目标产品必须做什么”需求分析的一个重要过程就是需求建模的过程结构化分析方法是一种传统的系统建模技术，其过程是创建描述信息内容和数据流模型，依据功能和行为对系统进行划分，并描述过必须建立的系统要素。结构化分析：使用数据流程图、数据字典、结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档需求规格说明书。结构化体现在将软件系统抽象为一系列的逻辑加工单元,各单元之间以数据流发生关联。该方法的要点是：面对数据流的分解和抽象；把复杂问题自顶向下逐层分解,6.1分析模型,分析模型的目的是为基于计算机系统提供必须的信息、功能和行为域的说明模型是对系统某个方面的抽象，抛弃了具体细节，对系统中最突出的特征作简化,6.1.1分析模型元素,使用不同的表现模型来描述分析模型分析模型元素：基于场景的元素基于过程的活动序列的元素基于类的元素行为元素面向信息流的元素基于数据的元素,6.1.2分析模式,分析模式：在软件开发领域，在特定的应用领域内某些事物在所有的项目中重复发生。分析模式可以使用标准的模板来表现，模板采用模式名、目的、动机、外因和环境、解决方案、结论、设计、已知应用和相关模式的格式描述分析模式信息。例如，ERP（EnterpriseResourcePlan）软件就是一个高层分析模式，形成一套开发ERP软件的分析模式。,6.1.3分析模型的目标与原则,分析模型必须实现三个主要目标：描述客户需要什么；为软件设计奠定基础；定义在软件完成后可以被确认的一组需求。分析模型的所有元素都可以直接映射到设计模型创建分析模型时应遵循的原则：模型应关注在问题或业务域内可见的需求，抽象的级别相对高；分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解；基于基础机构和其他非功能的模型应推延到设计阶段再考虑；最小化整个系统内的关联；确认分析模型为所有共利益者都带来价值；尽可能保持模型简洁,6.2结构化需求分析,用户需求一般用自然语言描述系统需求必须用较专业的方式来描述模型是软件设计的基础，也是创建规约的基础需求分析原则：必须表示和理解问题的信息域；必须定义软件将完成的功能；必须表示软件的行为（作为外部事件的结果）；必须划分描述信息、功能和行为的模型，从而使得可以以层次的方式揭示细节；分析过程应该从要素信息移向细节实现。,6.2.1结构化分析方法,结构化分析（SA，StructuredAnalysis）方法是20世纪70年代，由E.Yourdon等人倡导的一种适用于大型数据处理系统的、面向数据流的需求分析方法。结构化需求分析方法指导性原则：在开始建立分析模型之前先理解问题。开发模型，使用户能够了解将如何进行人机交互（使用原型技术）。记录每个需求的起源和原因，保证需求的可追踪性和可回溯性。使用多个需求分析视图，建立数据、功能和行为模型给需求赋予优先级，优先开发重要的功能，提高开发生产效率。删除含糊性。,6.2.2结构化分析模型,系统模型从以下不同的角度表述系统：从外部来看，它是对系统分析上下文或系统环境建模；从行为上看，它是对系统行为建模；从结构上看，它是对系统的体系结构和系统处理的数据结构建模。结构化的需求分析模型：系统行为模型：数据流模型，用来描述系统中的数据处理过程状态转换模型，用来描述系统如何对事件做出响应实体关系模型：关心的是寻找系统中的数据及其之间的关系，却不关心系统中包含的功能。,结构化分析模型结构,结构化分析模型结构,分析模型结构的核心是数据字典（DD，DataDictionary），包含了软件使用或生产的所有数据对象描述的中心库。分析模型结构的中间层有三种视图：数据流图（DFD，DataFlowDiagram）服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能。实体关系图（E-RD，Entity-RelationshipDiagram）描述数据对象间的关系，用来进行数据建模活动的记号。状态转换图（STD，StateTransitionDiagram）指明作为外部事件的结果，系统将如何动作。DFD用于功能建模，ERD用于数据建模，STD用于行为建模,结构化分析模型结构,分析模型结构的外层是规约描述：在实体关系图中每个数据对象的属性可以使用数据对象来描述。在数据流图中出现的每个加工/处理的功能描述包含在加工规约中。软件控制方面的附加信息包含在控制规约中,6.3面向数据的建模方法,系统建模的一个重要方面就是要定义系统处理的逻辑结构。最广泛采用的数据建模技术是实体-关系模型，它描述数据实体、关联及实体属性。实体关系模型可用ERD（Entity-RelationshipsDiagram实体关系图）来表示：实体关联实体属性基数,实例分析：出卷系统,试卷由一组题目组成，而题目来自试卷库中被挑选的题目。试卷根据出卷要求选择项目。,实例分析：出卷系统,实体的属性：试题：编号、科目、题干、题干图、答案、答案图、题型、知识点、难度、抽取时间试卷：编号、科目、出卷人、年级、性质、总分、难度、题目*出卷要求、总分、总难度、总题型、总知识点题目：编号、题干、题干图、答案、答案图、题型、知识点、难度,实例分析：图书馆系统,实体：图书、借书者、管理员、借书目录、预约记录、书目,实例分析：图书馆系统,实体的属性：借书者：借书者编号、姓名、性别、借书数、最大借书数、罚金金额、有限期图书：图书号、书目号书目：书目号、书名、作者、出版社、丛书名、收藏数、在馆数、预约数借书记录：图书号、借书者编号、借出日期、应还日期、续借次数预约记录：书目号、借书者编号、预约日期,实例分析：POS机系统,实体有销售、支付、商品、商品描述关联：销售包含一组商品；每个商品都有相应的描述信息；每个支付对应一个销售。,实例分析：POS机系统,实体的属性：销售：编号、总价、1商品*，日期支付：编号、支付客户、找零、销售编号商品：编号、数量商品描述：名称、产地、厂家、单价,6.4面向数据流的建模,面向数据流的建模是结构化需求分析方法之一采用自顶向下逐层分解，描绘满足用户要求的软件模型表示：数据流图：描述系统处理过程数据字典：模型中的数据信息集合状态转换图：描述系统对内部或外部事件响应的行为模型,6.4.1数据流图(DFD),任何软件系统（或计算机系统）从根本上说，都是对数据进行加工或变换的工具。数据流图DataFlowDiagram：一种结构化分析描述模型，用来对系统的功能需求进行建模，它可以用少数几种符号综合地反映出信息在系统中的流动、处理和存储情况指明数据在系统中移动时如何被变换描述对数据流进行变换的功能DFD中每个功能的描述包含在加工规约中,数据流图符号,数据流：表示数据和数据流向，三个重要属性:流向(从加工出发或流向加工)数据组成数据流名字,数据流程图的另一种基本符号,数据流图的构成数据流,数据流（DataFlow）由一个或一组确定的数据组成。数据流名应能直观地反映数据流的含义。数据流的流向数据流可以同名，也可以有相同的数据结构，但必须有不同的数据或具有不同的含义。两个符号(加工、外部项、数据存储)之间可以有多个数据流存在，DFD并不表明它们之间的任何关系，诸如次序、主次等。避免错误的数据流命名方法,数据流图的构成加工,加工又称处理亦称变换，它表示对数据流的操作。加工的符号分成上、下两部分，从上到下分别是标识部分和功能描述部分。标识部分用于标注加工编号，加工编号应具有唯一性，以标识加工，可以用“P”开头。功能描述部分用来写加工名。为使DFD清晰易读，加工名应简单，能概括地说明对数据的加工行为，其详细描述在数据词典中定义。加工要逐层分解，以求得分解后的加工功能简单、易于理解。,数据流图的构成数据存储,数据存储是用来存贮数据的。在分层DFD中，数据存储一般仅属于某一层或某几层，因此又称数据存储为局部文件。现对数据存储符号说明如下：数据存储名写在开口的长方框内，应概要地说明文件中的主要数据。数据存储上一定要有数据流。为便于说明和管理，数据存储可以编号，编号写在文件符号左端小方格中，可以用“D”开头。为避免DFD中出现交叉线，同一数据存储可在多处画出，可以用下图所示符号表示数据存储重复。,数据流图的构成外部项,外部项：源点和终点(又称端点)是系统外的实体，称作外部项。它们存在于环境之中，与系统有信息交流，从源点到系统的信息叫系统的输入；从系统到终点的信息称系统的输出。同个端点可以是人或其它系统。在DFD中引入源点和终点是为了便于理解系统，所以不需要详细描述它们。它们可有编号，以“S”开头。,分层数据流图,数据流图的绘制步骤,（1）确定所开发的系统的外部项（外部实体），即系统的数据来源和去处。（2）确定整个系统的输出数据流和输入数据流，把系统作为一个加工环节，画出关联图。（3）确定系统的主要信息处理功能，按此将整个系统分解成几个加工环节（子系统）确定每个加工的输出与输入数据流以及与这些加工有关的数据存储。（4）根据自顶向下，逐层分解的原则，对上层图中全部或部分加工环节进行分解。,数据流图的绘制步骤,（5）重复步骤（4），直到逐层分解结束。（6）对图进行检查和合理布局，主要检查分解是否恰当、彻底，DFD中各层是否有遗漏、重复、冲突之处，各层DFD及同层DFD之间关系是否争取及命名、编号是否确切、合理等，对错误与不当之处进行修改。（7）和用户进行交流，在用户完全理解数据图的内容的基础上征求用户的意见。,数据流图的绘制原则与注意事项,绘制数据流图的主要原则明确系统界面。自顶向下逐层扩展。合理布局。数据流图绘制过程，就是系统的逻辑模型的形成过程，必须始终与用户密切接触，详细讨论，不断修改，也要和其他系统建设者共同商讨一求一致意见。绘制数据流图的注意事项关于自顶向下、逐层分解数据流必须通过加工数据存储环节一般作为两个加工环节的界面来安排编号,数据流图举例1工厂采购系统,设一个工厂采购部每天需要一张定货报表。定货的零件数据有：零件编号、名称、数量、价格、供应者等。零件的入库、出库事务通过计算机终端输入给定货系统。当某零件的库存数少于给定的库存量临界值时，就应该再次定货。数据流分析：数据源点：仓管员（负责入库或出库事务给定货系统）；数据终点：采购员（接收每天的定货报表）；数据流：事务，定货；数据存储：定货信息，库存清单；处理：处理事务，产生报表。,数据流图举例1采购系统,画基本系统模型,采购员,事务,定货报表,数据流图举例1采购系统,第一步求精,定货信息,库存清单,定货信息,库存信息,采购员,定货报表,产生报表,仓管员,处理事务,事务,数据流图举例1采购系统,第二步求精,仓管员,采购员,处理入库事务,入库事务出库事务,定货报表,处理定货,定货信息,处理出库事务,产生报表,定货信息,库存清单,库存信息,第一层数据流程图（环境图）,数据流图举例2汽车配件公司之配件销售系统,汽车配件公司：第二层数据流程图,顾客,供应商,销售,订货单,发货单,配件库存,P1.1,采购,P1.2,订货单,发货单,到货通知,会计,P1.3,收据,应付款通知,向供应商的订货单,数据流图举例2汽车配件公司,D2,D1,顾客,采购,编辑订货单,订货单,配件库存,P1.1.1,确定顾客订货,P1.1.3,产生暂存订货单,P1.1.5,对照暂存订货单,P1.1.6,业务员,开发货单并修改库存,P1.1.4,不合格,顾客,D3,D1,可发订货,不满足的订货,登录新顾客数据,P1.1.2,暂存订货单,D4,到货通知,新顾客,编制销售和库存报表,P1.1.8,销售历史,D5,应收款明细账,D10,配件库存,D1,合格的订货单,检索库存,P1.1.7,经理,询问库存,库存状态,汽车配件公司：第三层数据流程图之“P1.1销售”,发货单,6.4.2数据字典,数据字典(DD，DataDictionary)是分析模型中出现的所有名字的一个集合，并包括有关命名实体的描述数据字典有以下两个作用：它是所有名字信息管理的有效机制作为连接软件分析、设计、实现和进化阶段的开发机构的信息存储数据字典应该由四类元素的定义组成：数据流数据流分量数据存储处理,数据字典,应对组成的数据元素定义进行自顶向下的分解。分解的原则是：当包含的元素不需要进一步定义，且每个和工程有关的人都清楚时为止数据字典中应该包括关于数据的信息：一般信息（名字、别名、描述等）定义（数据类型、长度、结构等）使用特点（值的范围、使用频率、使用条件、使用方式、条件值等）控制信息（用户、使用特点、改变数、使用权等）分组信息（文档结构、从属结构、物理位置等）,数据字典,三种类型的任意组合定义数据字典中的任何条目。顺序：顺序连接两个或多个分量元素。一般用加号表示顺序连接关系。选择：从两个或多个可选的分量元素中选取一个。选择运算符用方括号表示，对于多个可供选择的元素，用“|”符号分隔。例如，A-1|A-2|A-3表示三个可选数据元素。重复：描述的分量元素重复零次或多次。例如，都表示数据元素A的下限为1，上限为5。,数据字典卡片方式示例,名字：定货报表别名：定货信息描述：每天一次需要定货的零件表定义：定货报表=零件编号+零件名称+定货数量+价格+1供应者3位置：输出到打印机,名字：零件编号别名：描述：惟一标识一个特定零件的关键组成定义：零件编号=8位字符位置：定货报表、定货信息库存清单,名字：定货数量别名：描述：某个零件一次定货的数目定义：定货数量=1|2|3|4|5位置：定货报表定货信息,名字：价格别名：价格范围描述：某个零件目前参考价格或者上下限定义：价格=1零件单价2位置：定货报表定货信息库存清单,举例说明：怎样编写各类数据的字典条目,数据字典由数据流、文件（数据存储）和数据项（数据元素）三类条目组成：数据项:数据的最小单位，描述数据的静态特性数据流:由一个或一组固定的数据项组成。数据文件:描述数据的逻辑存储结构。所以，数据字典是关于数据流程图内所包含的数据元素（数据存储、数据流、数据项）的定义及说明的集合。,数据项条目说明举例,数据项名:系编号别名:取值：2数字2注释:,例如:01,12,数据项条目说明举例,数据项名:专业和班编号别名:取值：3数字3注释:,例如:305，401,数据项条目说明举例,数据项名:年级别名:取值及含义:freshmen,一年级sophomore,二年级junjor,三年级senior,四年级注释:F,M,J,S可分别用1,2,3,4代替,例如:F，3,数据项条目说明举例,数据项名:书号别名:取值:字母数字注释:,例如:，,数据流条目说明举例,数据流名:发票别名:购书发票组成:(学号)姓名书号单价数量总价书费合计数据量:100次/天高峰值：开学期间400次/天,例如:,数据存储条目说明举例,文件名:各班学生用书表别名:组成：系编号专业和班编号年级书号组织：按系、专业和班编号从小到大排列存取要求:关键字是专业和班编号,例如:,6.4.3状态转换图,状态模型是一种描述系统对内部或者外部事件响应的行为模型。它描述系统状态和事件，以及事件引发系统在状态间的转换。与功能、数据模型不同的是，行为（状态）模型重点描述系统状态和行为（控制）的模型，既：用来描述系统与某些要素（如时间）相关的动态行为与系统的控制逻辑，描述对象彼此间经过相互作用后，随要素（时间）改变的不同运算顺序这种模型适用于描述实时系统,6.4.3状态转换图,状态模型一般采用状态转换图（State-TransitiondiagramSTD）（简称状态图）的标记方法状态图描述了系统中某些复杂对象的状态变化状态是可观察的行为模式，用圆角矩形表示；变迁表示状态的转换，用箭头表示；事件是引发变迁的消息，用箭头上的标记表示。状态图还可以用事件后的方括号表示先决条件，只有当这个条件为真时，才会发生状态变化；用状态自身的弧线箭头表示先决条件不为真时，状态不会改变。,状态（行为）模型表示方法,状态图：状态和事件的网络，侧重描述每一类对象的动态行为。,举例：复印机控制软件状态图,举例：饮料自动售货机系统的状态图,4加工逻辑的描述,加工逻辑也称为过程说明，用于描述数据流图中加工逻辑的处理算法或过程。对数据流图的每一个基本加工，必须有一个基本加工逻辑说明基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则加工逻辑说明必须描述实现加工的策略而不是实现加工的细节加工逻辑说明中包含的信息应是充足的，完备的，有用的，无冗余的用以下三种工具：过程描述语言（PDLProceduralDescriptionLanguage）判定表判定树,1.过程描述语言,介于自然语言和形式语言之间的一种半形式语言，使用有限的词汇和有限的语句来描述加工逻