《需求提取与分析.doc》由会员分享，可在线阅读，更多相关《需求提取与分析.doc（62页珍藏版）》请在金锄头文库上搜索。
1、 39目录第1部分 需求概述11.1需求分析概述11.1.1需求定义11.1.2需求分析概述11.2需求分类21.2.1软件运行期质量21.2.2软件开发期质量31.2.3约束31.2.4不同类型需求对设计的影响31.3需求的层次性41.4需求的易变更性41.5需求捕捉的工具41.6需求分析内容51.6.1确定业务目标51.6.2确定业务领域范围及业务流程51.6.3建立用例模型51.6.4建立用例规约61.6.5确定系统非功能需求6第二部分 需求提取与需求建模72.1需求建模基本概念72.1.1参与者72.1.2用例72.1.3场景82.1.4用例规格说明92.2用例建模122.2.1识别系
2、统主要参与者122.2.2识别系统的业务和业务流程122.2.3业务流程描述工具活动图132.2.4建立基本用例模型142.2.5建立用例之间的关系152.3应用实例某汽车制造厂车辆订购用例模型162.2.1参与者分析162.3.2车辆订购业务流程分析业务建模172.3.3车辆订购基本用例模型182.3.4车辆订购用例模型优化192.4系统顺序图21第3部分 分析与领域建模233.1分析的基本任务233.2 领域模型的基本概念233.2.1领域模型233.2.2领域模型的表示233.2.3领域概念类识别253.2.4规格说明概念类273.3领域模型的重要性283.3类对象间的关系293.3.1
3、继承关系（Inheritance）293.3.2聚合关系303.3.3关联关系303.3.4关联类313.3.5受限关联313.3.6与时间间隔有关的属性的处理323.4建立领域模型323.5领域模型的优化323.6领域概念类的属性333.7使用包来组织领域模型333.8领域概念类与设计类、软件类的表示差别333.9应用实例343.9.1候选概念类提取343.9.2概念类间关系的建立353.9.3产品订购领域模型353.9.4产品订购包模型363.10 ER模型与领域模型之间的内在联系361数据库设计概述381.1数据库设计的基础性381.2 数据库设计模型381.3 基本概念381.4数据库
4、设计的内容391.5数据库设计中的误解392数据库概念模型设计402.1实体的识别412.2实体间联系的识别412.3概念模型设计应遵从的原则422.4应该注意的问题422.3数据库概念模型设计实例432.3.1五征产品订货432.3.2东风销售管理473数据库逻辑模型设计523.1转换原则523.2数据库逻辑设计应用实例533.2.1五征产品计划单数据库逻辑设计533.2.2东风汽车订购数据库逻辑设计543.2.3东风汽车销售数据库逻辑设计544数据库优化设计554.1表的合并554.3表的纵向分解564.4表的横向分解574.5中间表的使用585数据库索引585.1理论基础-数据库表索引的
5、组织585.2数据库索引的建立585.3序列号的利与弊59第1部分 需求概述1.1需求分析概述1.1.1需求定义软件需求是“用户到底需要软件为他/她做什么”。IEEE对需求的定义：1.用户所需的解决某个问题或达到某个目标所要具备的条件或能力；2.系统或系统组件为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力；3.上述第一项或第二项中定义的条件和能力的文档表述。RUP对需求的定义：需求描述了系统必须满足的条件或提供的能力，它可以是直接来自客户需要，也可以来自合同、标准、规范或其它有正规约束力的文档。根据上面的定义，需求的本质是：系统必须提供的能力和必须满足的条件。需求的表示形
6、式是：系统“应该做什么的规格说明”。需求分析的目的是：揭示系统应该做什么并达成一致。需求的最根本的挑战在于：交流并记录什么是真正需要的，并能够清楚地向用户和开发团队的成员讲解。1.1.2需求分析概述需求分析是软件工程学的经典术语之一，名符其实的含义是对用户需求进行分析，旨在产生一份明确、规范的需求定义。从这个意义上讲“分析是解决做什么而不是解决怎么做的问题”是无愧无挑剔的。通常用“做什么”和“怎么做”来区分“分析”和“设计”，但人们在“做什么”和“怎么做”的问题上总会出现理解上的含糊不清。问题的根源在于人们对软件工程中“分析”这个术语的含义有不同的理解-有时把它作为“需求分析”的简称，有时是指
7、“系统分析”，有时则作为需求分析和系统分析的总称。但迄今为止的各种分析方法（包括结构化分析和面向对象分析）中，真正属于需求分析的内容所占的分量并不大，更多的内容是给出一种系统建模方法（包括一种表示法和相应的建模过程指导），告诉分析员如何建立一个能够满足（由需求定义所描述的）用户需求的系统模型。分析员大量的工作是对系统的应用领域进行调查和研究并抽象地表示这个系统。确切地讲，这些工作应该叫做系统分析，而不是需求分析。它既是对“做什么”问题的进一步明确，也在相当程度上涉及到“怎么做”的问题。在一般的需求论述中，需求分析包括需求调研和需求分析。需求调研是需求获取（或捕捉）的过程，所以把需求调研称为“需
8、求获取”或“需求捕捉”，需求分析的目的和结果是对需求进行准确定义。所谓“准确定义”是弄清用户的真正需求，包括企业决策层的期望（开发目标）和直接使用系统的用户的需求（决策层人员可能不直接使用系统，但对系统的期望更大、更高，系统更应该努力去实现决策层的意图），把这些需求用文字和图表的形式描述出来，并且其描述没有二义性。但一般的自然语言很难做到无二义性描述，没有理论指导也可能使需求描述带有任意性，用特定的分析方法和对应的建模工具来“准确定义”需求以减少二义性，是普遍采用的方法。用这些分析方法和工具定义需求的过程称为“建模”，用结构化分析方法建立的需求模型称为系统的逻辑模型（功能模型），用面向对象分析
9、方法建立的模型称为领域（对象）模型。这些模型往往不是用于与用户交流，主要是用于系统开发人员之间的交流。在建立模型过程中和所建立的模型已经“在相当程度上涉及到怎么做的问题”，建模元素的选择和粒度的把握都与“怎么做”有关，只是在一个非常高的抽象层上考虑“怎么做”的问题，或者说是在意识上参杂了今后“怎么做”的因素。建立得好的需求分析模型与设计模型有很好的映射关系，也是在很大程度上考虑了今后“怎么做”的问题。在传统的软件工程中，需求分析作为软件生存周期的一个阶段，尽管有需求获取和分析的两个任务，这两个任务没有严格地划分时间段，在需求获取过程中要进行分析，在分析过程中要不断地进行调研和完善。那时，没有严
10、格地区分需求获取的工具是什么，需求分析的工具是什么，都是采用数据流图和数据字典。这两个任务总是交叉重复地进行，直到所建立的系统需求模型（数据流程图系统逻辑模型）达到用户要求为止，需求提取的工具和分析的工具都是相同的工具。而且也明确地指出需求分析报告主要用于用户交流，作为用户和开发者之间的契约，是需求验收的依据。在统一过程和UML提出后，特别是软件迭代开发方法提出后，把需求和分析分成了两个不同的阶段，有时也叫需求获取（或需求捕获）和需求分析，每个阶段有完全不同的目标和任务，包括建模工具和建立的模型都完全不同。需求捕捉阶段主要采用用例模型捕捉功能需求，需求分析阶段主要采用对象模型，建立领域对象间的
11、协作关系。但是，虽然把需求捕捉和需求分析划分为两个阶段，但它们却是相互伴随、交叉进行的，很难有区分的界限。需求获取所建立的模型主要用于与用户交流，需求分析模型是开发组织自己的文档，根本无法用于与用户交流，也不用于与用户交流。随着软件工程研究的发展，软件组件技术的广泛使用，软件的敏捷构造越来越受到关注。软件敏捷构造的核心是保持软件组件与领域业务的一致性，即组件与业务对齐。如果做到了组件与业务对齐，企业业务的重组只需要对软件组件间的关系重定义，这正是软件工程要达到的理想目标。要做到这一点，对软件需求提出了很高的要求需要从组织或领域体系结构要识别和捕捉领域需求。1.2需求分类需求可分为两类：（1）功
12、能性需求-系统应该提供什么功能。（2）非功能需求-系统的特定特性或约束。软件需求功能需求非功能需求质量属性约束运行期质量属性开发期质量属性系统的特定特性主要指系统的质量属性。系统质量属性可分为软件运行期质量属性和软件开发期质量属性。1.2.1软件运行期质量软件运行期质量指用户在使用软件过程中对软件质量的要求，包括易用性（人性化因素、帮助等）、性能（响应时间、吞吐量、准确性、有效性、资源利用率）、安全性、可伸缩性、持续可用性、互操作性、可靠性和鲁棒性。通常把软件运行期质量称为软件外部质量，即用户能够直接感受到的质量。易用性：指软件系统容易使用的程度。性能：指软件系统及时提供相应服务的能力。性能包
13、括响应时间（也称速度）、吞吐量（单位时间处理的交易数）、持续高速性（保持持续高速处理的能力-在网络系统中，这点是很难的）。一个系统可能保证典型操作的快速响应，但不一定能保证持续高速。性能和效率是同一问题的“表”、“理”的两个方面，性能为“表”，效率为“里”。效率指软件系统对CPU处理器和存储器这两大资源的处理效率。安全性：指软件系统同时兼顾向合法用户提供服务，以及防止非授权使用的能力。持续可用性：指软件长时间无故障运行的能力。如有的系统要求提供7*24小时服务就是持续可用性的要求。可伸缩性：指当用户数量和数据量增加时，软件系统维持高服务质量的能力。互操作性：指本软件系统与其它软件系统交换数据和
14、相互调用服务的难易程度。可靠性：软件系统在一定时间内无故障运行的能力。鲁棒性：也称健壮性、容错性。指软件系统在用户进行了非法操作、相连的软硬件系统发生了故障、以及其他非正常情况的时候，系统仍能正常运行的能力。有时也把持续可用性、鲁棒性也归类为可靠性。这时的可靠性就不是特指某种能力，而是一般意义下的可靠性。在软件开发过程中，需要对上述特性中特别指出的特性进行特殊设计，特别是要通过架构设计来保证，即成为架构设计关注的重点。1.2.2软件开发期质量软件开发期质量：为保证软件的可维护性而在软件开发过程中应该关注的软件质量属性，包括软件的可扩展性、可重用性、可移植性、易理解性、易测试性和可维护性。软件开
15、发期质量属性称为“软件内部质量属性”，即不深入到软件代码内部是无法觉察到的软件质量属性。这部分软件质量属性往往不会被用户通过需求的形式提出，而是软件开发团队应该自觉地保证，所以有的学者将其称为隐含质量属性。可扩展性：为适应新需求或需求变化为软件增加功能的能力。有时称为灵活性。可重用性：重用软件系统或其一部分的能力的难易程度。可测试性：对软件测试以证明满足需求规约的难易程度。在实际工作中主要指进行单元测试，插桩测试的难易程度。可维护性：在修改Bug、增加功能、提高质量属性等而定位修改点并适时修改的难易程度。可移植性：将软件系统从一个运行环境转移到另一个运行环境的难易程度。易理解性：设计被开发人员理解的难易程度。任何一个开发期质量属性的满足都可能增加软件开发成本。1.2.3约束系统的约束是需求获取的重要内容。约束不
