1、中山大学博士学位论文基于回答集语义复杂信息系统软件需求模型的研究姓名：万海申请学位级别：博士专业：计算机软件与理论指导教师：李磊20060401中文摘要界面完成的操作，包括：对表单中的表单项（宾语） 实 施的原子动作（谓语）、接收消息、发送消息和打印操作；界面的先后关系利组成界面操作的并发关系用状语（）表示。以忍和为核心描述需求，较好地把握了需求描述的粒度，可以自然、全面地描述功能性与非功能性需求。本文提出的需求获取方法与过程可以实现需求阶段的小步骤和平滑过渡。在正确获取和描述需求规格说明的基础上，可以将基于。的需求规格说明转换为回答集逻辑程序，进行多层次规划和检测：在业务流程层检测业务流程的
2、合理性，并对单 流程业务进行规划：在多流程交互层检测消息的一致性与合理性，并根据流程问消息的类型与交互方式对表单间数据源向关系进行规划：在业务结构层检测宾语一致性、消息和打印数据、以及界面的合理性，并进行需求定位规划和主语角色权限规划。利用回答集逻辑程序求解器，本文开发了（需求工具。实现了图形化输入、需求规格说明自动生成，可以对需求规格说明进行规划和检测，实现需求规格说明的原型化验证。本文的研究来自工程项目实践的总结与提高，研究成果得到具体的应用。最后，总结全文并提出了下一步研究工作。关键词：复杂信息系统，回答集，需求工程，元模型，需求规格说明，规划与检测第页，共页英文摘要、，（），。（），。
3、，（），（），。口，第页共页，（。酚），（），：）（），。，忍，。，：，第受，共页插图插图需求演化、迭代过程示意网开发参与人员分工与职责示意图彤式化方法在需求阶段的作用林方真的问题，问题状态一动作转换图“主谓宾状”需求元模型忌。示意图复杂信息系统需求模型兄层次结 构表单状态表单业务基本动态行为关系表单状态一表单业务扩展动态行为关系表单状态问同前提关系与同结果关系五类典型界面表单业务特例，流程交互异步关系与同步关系典型流程交互方式，异步交互方式，司步交互方式主流程与子流程协作伺服条件决定主语操作权限取款审批业务不同需求描述方法需求获取与分析 过程，“订单验证、 处理流程”业务示意图订购单业务流程
4、示意图信用卡查询业务流程示意图订单业务流程示意图订单明细单业务流程示意图典型接收消息与发送消息界面，表单数据源向关系示意图，体系结构部门图元第页，共页，笛拍卯驰锣钾豇观轮舄钳巧卯鼹毋的他弭艿；舛眇捅图主语、宾诏圈元，业务流程图元界丽逻辑网元表荦单流程规划统计示意图表单交互流程规划统计示意图第页。共页表格表格需求阶段结构化方法与面向 对象方法比 较分析需求工程工具、按形式化方法的理论基 础分类按所描述系统的特性分类，按形式化规格技术的描述特征分类与比较分析业务相关部门、用户角色和主语表单、表单项和宾语订购单表单状态汀单表单状态订单明细单表单状态表单单流程规划结果统计表单交互流程规划结果统计，本文
5、提出方法与其它方法比较分析第页，共页，心挖加仍乃弭弭乃舛鲐第一章引言第一章引言高品质的软件设计源自彻底的软件需求，完整、正确的需求规格说明对于复杂信息系统软件项目开发的成败至关重要。本章通过分析复杂信息系统的特点明确需求阶段的内容与任务，对需求工程的研究现状、典型方法与支持工具进行综述；分析应用于需求工程的形式化方法与理论，提出本文的研究内容与研究方法。复杂信息系统的软件需求复杂 信息系统的特点随着以实现业务流程自动化、为企业或事业单位提供综合信息化平台为特征的复杂信息系统（：），用户需求问题空问向广度和深度不断扩展（如：分布式应用、继承遗留系统或配合业务过程重组实现业务流程柔性配置等）应用规
6、模和复杂度不断提高（从数据集成、过程集成到应用集成【 】），解空 问技术的不断 进化（如：工作流技 术、 组件技术、复用技术、再工程技术和中间件技术等），正确地获取和描述用户需求、无二义地向系统设计人员说明需求、管理需求并维护其一致性对于 软件项目开发的成败至关重要。本文主要对软件项目开发如何进行需求获取、描述、分析和验证进行研究。开 发（一直是信息化技术、软件工程和需求工程领域的研究热点，大致经历了：（）、（）、（）、（）、（）、（）、电子商务和电子政务等阶段；功能日益扩展，从最初的信息检索、数据集成到业务流程自动化处理、业务集成和功能集成，具有不同于传统软件的特征。复杂信息系统的主要功能特
7、点体现在：系统应用涉及多个单位或部门的不同用户，应用规模较大；提供综合信息录入和检索平台：提供跨单位或跨部门的数据融合、集成和共享平台；继承现有遗留系统，实现无缝集成；配合业务过程重组，实现业务流程柔性配置和自动化处理；用户需求具有个性化特征，软件系统需要专门定制或二次开发；业务流程与表单（如：表格、单据或任务说明等）的处理过程密切相关。开发和应用对提升企业或事业单位的管理水平意义重大，现有研究大多集中在软件体系结构或具体实现技术的研究，（如：工作流技术研究如何根据过程规第页共页第一章引言则，完全或者部分自动执行业务过程，使得文档、信息或任务能够在不同的执行者之间传递与执行【，）。但是需求 阶
8、段的工作没有引起足够的重视，也没有形成一套完整、良好的需求获取、定义、描述以及分析的理 论 和方法。由于开发涉及的部门和用 户众多，与 业务紧密相关的表单数量庞大，需要自动化处理的业务流程又常存在二义性描述和经常性修改，这会导致所获取、描述的需求不准确或不全面。另外，在需求获取与需求描述、需求分析与系统设计等不同阶段采用不同的描述语言会导致描述转换错误；由于错误的积累和放大作用，通常需求阶段的错误会 倍地放大到系统实施或维护阶 段，导致系统开发常常出现项目实施拖延、返：甚至中止。因 为 项目实施直接关系每个用户的具体业务，如果系统设计 不完善或不合理，会直接影响日常业务，甚至造成负面影响。产生
9、这些问题的原因在于对用户需求的获取、描述不够准确和全而，对业务流程理解不够深刻。在 实际软件开发项目中，近一半以上的软件项目失败都涉及需求阶段的问题】：公司的报告 显示，从年至年美国全国范围内的大型软件系统（大部分具有特征）的开发与研制中，的项目是失败的，的项目因故取消，其中涉及需求 阶段的原因占】；文献：；指出需求阶段是软件开发的重要阶段，当项目失败时，需求问题通常是主要原因之一。正是由于问题空间研究内容的增多与扩展，解空 间新技术的不断出现， 给需求阶段的研究提出了新的课题， 传统方法已不再适用。本文希望通 过分析的特点提出一套合理的、实用的、 针对项目开发的需求 获取、描述与分析方法；应
10、用人工智能领域知识表示和推理方法对需求规格说明进行规划和检测，保证输入到软件设计阶段的需求是完整的和正确的。需求阶段的内容与任务需求阶段是软件设计开发的输入阶段， 贯穿整个软件生命周期，是需求工程（露：）研究的重要课题；通过捕获用户需求，设计并用一种语言描述需求（需求规格说明），在用户和系统设计人员之问形成契约，回答“系统必须做什么”；支持需求演进，实现软件需求的跟踪管理利控制】。需求工程研究划分为需求开发和需求管理【】；需求工程可分为系统需求工程（由软硬件共同组成的系统）和软件需求工程（专门针对纯软件部分）。需求阶段的研究内容属于针对特定应用领域的软件需求工程。需求阶段的内容与任 务由本身的
11、特点决定，常划分为三个层次，：系统需求与业务需求，反映部门或用户对软件系统高层次的目标要求；业务流程的用户需求，描述用户使用软件系统必须要完成的任务：软件系统执行的功能需求（软件功能）和非功能需求（解决方案的约束条件）。本文把与需求阶段的相关因素概括 为三个方面：采用的技术、需求阶第页共页第一章引言段涉及的元素、实施需求工程的过程；又可划分为二个层面：需求管理层面（说明：“每人每天每件事”）、需求技术层面（说明：“何人采用何种方法或过程如何完成何种工作”）。本文主要研究需求技术层面的内容。对需求阶段所涉及因素进行形式化分析，假 设：问题空间，包括：部、用 户、遗留系统、表单、表单项、操作、业务
12、流程、操作条件与规则肋、用户需求与目标等：解空间，包括：数据关系、用户角色权限、操作流程、系统模块配置、界面等：需求规格说明；需求阶段的任务可以理解为在问题空间的过程，形式化表示为：。通过描述需求，得到解空间需求分析人员获得是建立在问题空间与用户目标的基础上，形式化表示为印，（）系统设计人员以为依据进行 设计和开发，形式化表示为：，（）总结以上分析，可以得到需求阶段的特点：是需求阶段的总结，又是设计阶段的输入；需求过 程的复杂性在于： 问题空间的元素繁多、关系复 杂、描述困 难，如：操作是由用户实施， 业务流程涉及 对表单、表单项的操作，操作条件与规则舰可以看作是业务流程的约束条件，用户需求与
13、目标的确定和部、业务流程或遗留系统等有直接关系；问题空间与解空间的各个元素之 间存在映射关系，如：，。，等，但要详细、全面地刻画这些映射关系却又是十分复杂的和困难的。需求阶段划分定义需求工程生命周期由：需求定义和分析、需求决策、形成需求规格说明、需求 实现与验证、需求演 进管理五阶段组成；文献【】将需求工程活动划分为：需求获取、需求建模、形成需求、需求验证和需求管理。公第页、共页第一章引言司提出了（）模型：公司提出了（）模型。根据需求阶段的内容与任务，本文把需求阶段划分为两个阶段：第一阶段，需求分析人员引导户描述问题空间，形成需求规格说明；第二阶段，通过向系 统设计 人员描述需求，在了解的基础
14、上初步规划解空问。第一阶段：通过与用户交流获取需求，观察问题空间并分析需求一需求获取：引导用户描述问题空间，尽可能全面地捕获需求：一需求分析：根据所获取需求，为问题空间和目标任务建立模型；一需求描述：对模型进行细化分析，形成需求规格说明：一需求验证：根据需求规格说明与用户沟通，逃一步细化需求并修正错误，保证准确、无二义：第二阶段：依据需求规格说明，向系统设计人员描述需求一需求说明：根据需求规格说明向系统设计人员说明任务，明确需求边界，使系统设计人员准确、无二义地了解用户需求与目标任务：一初步验证：以需求规格说明为输入，通过符号执行、系统模拟或快速原型等手段，验证需求规格说明的正确性和可行性。尘
15、越女；蹩盈砬：墼图，需求演化、迭代过程示意 图盖奠盔雠需求管理贯穿需求 阶 段全过程，最终目标是准确、全面地了解问题空间，初步规划解空间，需求演化、迭代 过程可以用图来说明。需求阶段由对需求第页，共 页第一章引言规格说明非形式化自然语言描述、半形式化图形描述到形式化描述的需求说明维，需求描述从初步、模糊的到精确、准确和无二义的需求内容维，需求分析人员从用户获取需求到向系统设计人员说明需求的一致认同维等三维构成：共同组成从获取需求阶段到说明需求阶段逐步迭代、反复求精、不断演化的时间维。需求阶段人员分工开发要面对众多用户和不同角色，具有一定规模和复杂性。当项目较小的时候，由少数几个开发人员就可以实
16、施；但是由于问题空间十分复杂，即使同个问题由不同人员来分析都会有不同的见解；因此，有必要界定软件开发中各参与方所担任的角色，明确参与人员的分工与职责。本文将各参与人 员分为三类：用户、系 统设计人员和联系二者的需求分析人员（如图所示）。特征对应物有效性需求规格说明庐碲茬莲壁盘孟旌越签藤巡一篇庶钒趔幽一一点鸿图开发参与人员分工与职责示意图间用户一用户可细分为：软件投资者、客户方高层管理人员和软件用户，其中软件投资者、客户方高层管理人员是系统需求与业务需求的提供者，软件用户是业务流程的用户需求、功能需求和非功能需求的提供者：一从用户角度的需求定义是：从外部发现目标系统满足用户要求的特点、功能及属性
17、；需求分析人员一需求分析人员获取和分析用户需求、编写需求规格说明、验证需求、向系统设计人员说明和管理需求：通常认为需求分析人员属于系统开发人员，第页，共页第一章引言但是由于他们是沟通用户与系统设计人员的桥梁，本文将其单独列出；一从需求分析人员的需求定义是：引导用户对问题空间、目标系统的功能和性能进行描述，为系统设计人员理解用户需求与设计目标提供最初模型；系统设计人员一系统设计人员可细分为：项目负责人、系统分析和设计人员、编程与测试人员、质量保证人员、维护人员等；虽然他们处于软件生命周期的不同阶段，但是他们的工作都是依据需求规格说明来进行的：一从系统设计人员角度的需求定义是：需求是指明系统必须实
18、现什么的规格说明，描述了系统的行为、特征和属性，是开发过程中对系统的约束。需求规格说明需求阶段完成的任务是以需求规格说明来体现，也是连接需求分析与系统设计的桥梁，直接决定系统开发的成败与否。合格的需求规格说明应该具有如下特征：正确性、无二义性、完整性、一致性、可验证性、可修改性、可跟踪性、易理解性、整体性、及时性、面向用户客户、描述元数据、领域相关和可用性等】。需求 规格说明的描述方法可分为：形式化方法、半形式化方法和非形式化方法。无论采用那利，方法，编写需求规格说明的目的在于：帮助用户和需求分析人员确认需求的正确性和完整性：便于系统设计人员无二义地理解用户需求；作为软件系统设计与开发的依据；
19、易于验证需求的一致性与完整性。为什么需求规格说明对于开发起到至关重要的作用？这主要是由于目标系统规模较大和功能较复杂决定的。需求规格说明可以在需求和可执行代码之间提供中间确认过程，并保证这一过程的精确和无二义；是目标系统功能和性能的精确描述，验证可执行代码正确性的基础。通 过对需求规格说明的有效性检查可以帮助系统设计人员较早发现错误并进行改正，有助于降低编码、测试和维护的成本，系统设计人员对将要开发的目标系统会更加充满信心。现在软件设计人员都能认识到编写合理、完整、正确的需求规格说明意义重大，但是新的问题是如何编写符合要求的需求规格说明、编写什么样的需求规格说明、以及怎么样对需求规格说明进行验
20、证， 这也是本文研究的主要问题。研究现状与存在不足目前，需求工程已经成为一个独立的研究领域，但针对需求 阶段的研究却没有成熟。虽然有大量方法和工具，例如： 针对系统开发，用第页，共 页第一章引言描述系统 功能需求 】：利用现有商业系统（）按用户需求构建集成系统是近年研究的热点】；提出（）需求的获取与开发新系统有显著的区别，并提出对象过程建模方法【；为了规范和推进电子政务的实施，国家也推出了一系列标准，如：电子政务业务流程设计方法通用指南【】，电子政务系统总体设计要求（征求意见稿）【；本章第二节会对相关研究进行详细讨论。但是在需求阶段应用这些方法和工具仍然存在一些问题，具体体现在：（）对本身的特
21、殊性认识不足开发具有复杂性、不一致性、可变性、不可见性、在规模和应用深度上越来越复杂等特点，；需求工程是从定义不完备的问题空间为解空间确定定义良好的需求描述，这可以看作是创造性的过程；从而导致需求过程的特殊性与复杂性，正确获取需求的难度加大或者所获取的软件需求不能满足软件设计的要求，体现在：与客户沟通困难、需求 边界确定困难、需求不清晰或不完整、需求易变化或不一致。（）对问题领域的复 杂性把握不住需求工程与问题领域密切相关，首先不同行业或领域，以部、用户、业务流程、 遗留系统、表单等为特征的问题空间有显著差异，需求分析人员对本领域的熟悉程度决定了他对问题空间的把握和定位能力，这也是软件开发越来
22、越具有专业化和行业化特征的原因；另一方面，即使在同行业或领域中，用户需求与目标、操作条件与规等也存在较大差异，如：软件应用规模（部门级与企业级应用的差异），软件应用方式（分布式与集中式应用的差异）等。（）对问题空间与解空间的映射关系分析不透问题空间与解空间各元素之间存在着紧密关系，但是这种关系却是复杂的；如：部、用户与用户角色权限之间存在某种映射关系，但这种关系与业务流程是紧密相关的；表 单与数据关系也存在某种映射关系，但与部、用户或业务流程都紧密相关；我们不能将问题空间与解空间的各个元素分割开进行需求分析，但是综合这些元素进行分析又增加了难度。（）现有需求分析方法与工具支持不够为了解决需求工
23、程存在的复杂问题，人们提出了各种需求分析方法与工具，但是这些方法往往适用面较宽，在应用到具体领域时未能将问题领域基本规律抽取出来，领域支持度不高。第页，共页第一章引言需求工程研究的启示需求工程方法需求工程方法的研究核心是：需求获取与表示的方法，编写需求规格说明及质量保证机制， 需求规格说明的验证机制，需求元模型的研究。本文根据不同方法的特点，概括如下：（）面向功能分解方法体现在分析过程是从问题空间的需求描述到解空间功能模块的映射，提出“任务分割”的概念以降低需求分析的复杂度【，传统的结构化分析方法（）】、（）都属于这类方法，强调按“自项向下、逐步 细化”的方式进行需求分析。（）面向过程方法强调
24、在需求分析过程中以数据流向或操作过程为依据描述业务流程；典型方法如：利用数据流图（）描述 业务 流程，（）采用顺序视图或状态机视图表示操作流程】，工作流常采用活动图、状态图、活动网络图或网等进行业务流程建模】。（）面向数据方法以数据结构的形式描述和分析用户需求，如：面向数据结构的（）、（）方法【和基于实体关系模型的方法都属于这类方法。（）面向控制方法通过描述动作或事件的触发、同步、死 锁、互斥、并 发、激活或挂起等来确定业务需求，这种方法常与面向过程方法结合描述需求，如：和方法都具有面向控制方法的特征。（）面向对象方法需求分析是建立在对象及对象问交互的基础，这是近年研究的热点，通过对象及其属性
25、、分类结构和集合结构来获取和定义需求，并用对象模型、动态模型和功能模型描述需求；其中代表性的己经 得到较广泛应用。（）基于多视点方法强调从问题空问和目标任务的不同角度对需求进行描述，获取尽可能完整的信息，然后进行相容性 检验和综合；通常分为：视点划分、视点描述和视点集成三个步骤【】，文献给出视点间不一致性检查和视点集成的方法。在需求阶 段常采用二种方法： 以面向功能分解、面向 过程和面向数据为特征的结构化需求分析方法，以通过用例视图、静态视图、活动视图或交互视图第顶共页第一章引言描述需求为特征的面向对象需求分析方法。在具体应用时，这两种方法都存在优势与不足，本文通过表对这两种方法进行比较分析。
26、比较项目结构化需求分析方法面向对象需求分析方法基本特点基于功能分解，从功能上模拟客观世界对象的直接映象，从客观世界内部结构模拟客观世界常用工具图，将复杂处理分解来简用例视图、静态视图、活动视化问题图或交互视图适用项目适用于数据较少、业务 操作频适用于对象特征清晰、易于按繁的项目操作与属性分类的项目主要优点需求规格说明的可读性较好，采用了 继承的概念，需求规格容易理解，有利于与用户交流说 明整体性和稳定性较好业务流程利用图的数据流向与数据用例 图描述业务需求的动宾关操作描述业务和分解业务系，状态机视图、活 动视图和交互视图描述系统的动态行为需求规格结台自然语言进行图形化描结合自然语言进行图形化描
27、说明述，功能分解和模块划分的差述，会因为需求边界模糊而 难异性较大以确定对象存在不足对功能需求比较敏感，功能 变由于其封装性，使得系统内部化往往导致重新描述需求：冗控制不清晰，不容易理解：在余描述较多需求分析初期要抽象出对象或类是比较困难的需求规格说明描述方法根据需求规格说明形式化程度的不同可分为三类：形式化方法、非形式化方法和半形式化方法【，具体的特点是：（）非形式化方法非形式化方法指使用无限制或有格式约束的自然语言描述需求，如：常采用的问卷法、国标规定的软件需求说明书、对编写需求规格说明书的指南等。非形式化方法的优点是自然语言符合人们习惯，易于理解、掌握和使用；但由于其具有二义性，难以保证
28、描述的正确性，可维护性较差，更难以用计算机进行自动化需求验证；非形式化方法表达不严密，需求规格说明差异性较大，需求分析人员或系统设计人员对需求规格说明的理解可能与用户有较大的偏差。（）半形式化方法半形式化方法在宏观上对语法和语义有较精确的定义，在局部允许使用非形式化的自然语言辅助描述；通常将表格和图形符号看作半形式化方法，也称为图形化方法，常采用数据流图或定义的各种视图描述需求。由于表格和图形符号简单明了，便于交流，用户较容易了解所开 发系统是否满足自己的要求，所以半形式化方法也最受欢迎。半形式化方法可以看作是向形式化描述过渡的中间阶段，许多需第页，共页第一章引言求：具都可以将图形自动转换成形式语言或程序语言。（）形式化方法形式化方法具有严格、坚实的数学基础，具有准确、无二义的特点，易于验证需求的有效性和完整性，但要求书写者和阅读者有一定的理论基础。形式化方法最早可追溯到世纪年代后期研究编译技术出现的各种语法分析程序和编译方法；研究高潮始于世纪年代后期，针对当时出现的“软件危机”人们提出各种解决方法，可归纳为 两类：采用工程方法来组织、管理软件的开发过程，这导致“软件工程”的出现和发展；深入探讨软件开发过程的规律、建
