需求提取与分析.docx
《需求提取与分析.docx》由会员分享，可在线阅读，更多相关《需求提取与分析.docx（106页珍藏版）》请在冰点文库上搜索。
需求提取与分析
目录
第1部分需求概述1
1.1需求分析概述1
1.1.1需求定义1
1.1.2需求分析概述1
1.2需求分类2
1.2.1软件运行期质量2
1.2.2软件开发期质量3
1.2.3约束3
1.2.4不同类型需求对设计的影响3
1.3需求的层次性4
1.4需求的易变更性4
1.5需求捕捉的工具4
1.6需求分析内容5
1.6.1确定业务目标5
1.6.2确定业务领域范围及业务流程5
1.6.3建立用例模型5
1.6.4建立用例规约6
1.6.5确定系统非功能需求6
第二部分需求提取与需求建模7
2.1需求建模基本概念7
2.1.1参与者7
2.1.2用例7
2.1.3场景8
2.1.4用例规格说明9
2.2用例建模12
2.2.1识别系统主要参与者12
2.2.2识别系统的业务和业务流程12
2.2.3业务流程描述工具—活动图13
2.2.4建立基本用例模型14
2.2.5建立用例之间的关系15
2.3应用实例—某汽车制造厂车辆订购用例模型16
2.2.1参与者分析16
2.3.2车辆订购业务流程分析—业务建模17
2.3.3车辆订购基本用例模型18
2.3.4车辆订购用例模型优化19
2.4系统顺序图21
第3部分分析与领域建模23
3.1分析的基本任务23
3.2领域模型的基本概念23
3.2.1领域模型23
3.2.2领域模型的表示23
3.2.3领域概念类识别25
3.2.4规格说明概念类27
3.3领域模型的重要性28
3.3类对象间的关系29
3.3.1继承关系（Inheritance）29
3.3.2聚合关系30
3.3.3关联关系30
3.3.4关联类31
3.3.5受限关联31
3.3.6与时间间隔有关的属性的处理32
3.4建立领域模型32
3.5领域模型的优化32
3.6领域概念类的属性33
3.7使用包来组织领域模型33
3.8领域概念类与设计类、软件类的表示差别33
3.9应用实例34
3.9.1候选概念类提取34
3.9.2概念类间关系的建立35
3.9.3产品订购领域模型35
3.9.4产品订购包模型36
3.10ER模型与领域模型之间的内在联系36
1数据库设计概述38
1.1数据库设计的基础性38
1.2数据库设计模型38
1.3基本概念38
1.4数据库设计的内容39
1.5数据库设计中的误解39
2数据库概念模型设计40
2.1实体的识别41
2.2实体间联系的识别41
2.3概念模型设计应遵从的原则42
2.4应该注意的问题42
2.3数据库概念模型设计实例43
2.3.1五征产品订货43
2.3.2东风销售管理47
3数据库逻辑模型设计52
3.1转换原则52
3.2数据库逻辑设计应用实例53
3.2.1五征产品计划单数据库逻辑设计53
3.2.2东风汽车订购数据库逻辑设计54
3.2.3东风汽车销售数据库逻辑设计54
4数据库优化设计55
4.1表的合并55
4.3表的纵向分解56
4.4表的横向分解57
4.5中间表的使用58
5数据库索引58
5.1理论基础--数据库表索引的组织58
5.2数据库索引的建立58
5.3序列号的利与弊59
第1部分需求概述
1.1需求分析概述
1.1.1需求定义
软件需求是“用户到底需要软件为他/她做什么”。
IEEE对需求的定义：
1.用户所需的解决某个问题或达到某个目标所要具备的条件或能力；
2.系统或系统组件为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力；
3.上述第一项或第二项中定义的条件和能力的文档表述。
RUP对需求的定义：
需求描述了系统必须满足的条件或提供的能力，它可以是直接来自客户需要，也可以来自合同、标准、规范或其它有正规约束力的文档。
根据上面的定义，需求的本质是：
系统必须提供的能力和必须满足的条件。
需求的表示形式是：
系统“应该做什么的规格说明”。
需求分析的目的是：
揭示系统应该做什么并达成一致。
需求的最根本的挑战在于：
交流并记录什么是真正需要的，并能够清楚地向用户和开发团队的成员讲解。
1.1.2需求分析概述
需求分析是软件工程学的经典术语之一，名符其实的含义是对用户需求进行分析，旨在产生一份明确、规范的需求定义。
从这个意义上讲“分析是解决做什么而不是解决怎么做的问题”是无愧无挑剔的。
通常用“做什么”和“怎么做”来区分“分析”和“设计”，但人们在“做什么”和“怎么做”的问题上总会出现理解上的含糊不清。
问题的根源在于人们对软件工程中“分析”这个术语的含义有不同的理解--有时把它作为“需求分析”的简称，有时是指“系统分析”，有时则作为需求分析和系统分析的总称。
但迄今为止的各种分析方法（包括结构化分析和面向对象分析）中，真正属于需求分析的内容所占的分量并不大，更多的内容是给出一种系统建模方法（包括一种表示法和相应的建模过程指导），告诉分析员如何建立一个能够满足（由需求定义所描述的）用户需求的系统模型。
分析员大量的工作是对系统的应用领域进行调查和研究并抽象地表示这个系统。
确切地讲，这些工作应该叫做系统分析，而不是需求分析。
它既是对“做什么”问题的进一步明确，也在相当程度上涉及到“怎么做”的问题。
在一般的需求论述中，需求分析包括需求调研和需求分析。
需求调研是需求获取（或捕捉）的过程，所以把需求调研称为“需求获取”或“需求捕捉”，需求分析的目的和结果是对需求进行准确定义。
所谓“准确定义”是弄清用户的真正需求，包括企业决策层的期望（开发目标）和直接使用系统的用户的需求（决策层人员可能不直接使用系统，但对系统的期望更大、更高，系统更应该努力去实现决策层的意图），把这些需求用文字和图表的形式描述出来，并且其描述没有二义性。
但一般的自然语言很难做到无二义性描述，没有理论指导也可能使需求描述带有任意性，用特定的分析方法和对应的建模工具来“准确定义”需求以减少二义性，是普遍采用的方法。
用这些分析方法和工具定义需求的过程称为“建模”，用结构化分析方法建立的需求模型称为系统的逻辑模型（功能模型），用面向对象分析方法建立的模型称为领域（对象）模型。
这些模型往往不是用于与用户交流，主要是用于系统开发人员之间的交流。
在建立模型过程中和所建立的模型已经“在相当程度上涉及到‘怎么做’的问题”，建模元素的选择和粒度的把握都与“怎么做”有关，只是在一个非常高的抽象层上考虑“怎么做”的问题，或者说是在意识上参杂了今后“怎么做”的因素。
建立得好的需求分析模型与设计模型有很好的映射关系，也是在很大程度上考虑了今后“怎么做”的问题。
在传统的软件工程中，需求分析作为软件生存周期的一个阶段，尽管有需求获取和分析的两个任务，这两个任务没有严格地划分时间段，在需求获取过程中要进行分析，在分析过程中要不断地进行调研和完善。
那时，没有严格地区分需求获取的工具是什么，需求分析的工具是什么，都是采用数据流图和数据字典。
这两个任务总是交叉重复地进行，直到所建立的系统需求模型（数据流程图—系统逻辑模型）达到用户要求为止，需求提取的工具和分析的工具都是相同的工具。
而且也明确地指出需求分析报告主要用于用户交流，作为用户和开发者之间的契约，是需求验收的依据。
在统一过程和UML提出后，特别是软件迭代开发方法提出后，把需求和分析分成了两个不同的阶段，有时也叫需求获取（或需求捕获）和需求分析，每个阶段有完全不同的目标和任务，包括建模工具和建立的模型都完全不同。
需求捕捉阶段主要采用用例模型捕捉功能需求，需求分析阶段主要采用对象模型，建立领域对象间的协作关系。
但是，虽然把需求捕捉和需求分析划分为两个阶段，但它们却是相互伴随、交叉进行的，很难有区分的界限。
需求获取所建立的模型主要用于与用户交流，需求分析模型是开发组织自己的文档，根本无法用于与用户交流，也不用于与用户交流。
随着软件工程研究的发展，软件组件技术的广泛使用，软件的敏捷构造越来越受到关注。
软件敏捷构造的核心是保持软件组件与领域业务的一致性，即组件与业务对齐。
如果做到了组件与业务对齐，企业业务的重组只需要对软件组件间的关系重定义，这正是软件工程要达到的理想目标。
要做到这一点，对软件需求提出了很高的要求—需要从组织或领域体系结构要识别和捕捉领域需求。
1.2需求分类
需求可分为两类：
（1）功能性需求----系统应该提供什么功能。
（2）非功能需求----系统的特定特性或约束。
开发期质量属性
系统的特定特性主要指系统的质量属性。
系统质量属性可分为软件运行期质量属性和软件开发期质量属性。
1.2.1软件运行期质量
软件运行期质量指用户在使用软件过程中对软件质量的要求，包括易用性（人性化因素、帮助等）、性能（响应时间、吞吐量、准确性、有效性、资源利用率）、安全性、可伸缩性、持续可用性、互操作性、可靠性和鲁棒性。
通常把软件运行期质量称为软件外部质量，即用户能够直接感受到的质量。
易用性：
指软件系统容易使用的程度。
性能：
指软件系统及时提供相应服务的能力。
性能包括响应时间（也称速度）、吞吐量（单位时间处理的交易数）、持续高速性（保持持续高速处理的能力--在网络系统中，这点是很难的）。
一个系统可能保证典型操作的快速响应，但不一定能保证持续高速。
性能和效率是同一问题的“表”、“理”的两个方面，性能为“表”，效率为“里”。
效率指软件系统对CPU处理器和存储器这两大资源的处理效率。
安全性：
指软件系统同时兼顾向合法用户提供服务，以及防止非授权使用的能力。
持续可用性：
指软件长时间无故障运行的能力。
如有的系统要求提供7*24小时服务就是持续可用性的要求。
可伸缩性：
指当用户数量和数据量增加时，软件系统维持高服务质量的能力。
互操作性：
指本软件系统与其它软件系统交换数据和相互调用服务的难易程度。
可靠性：
软件系统在一定时间内无故障运行的能力。
鲁棒性：
也称健壮性、容错性。
指软件系统在用户进行了非法操作、相连的软硬件系统发生了故障、以及其他非正常情况的时候，系统仍能正常运行的能力。
有时也把持续可用性、鲁棒性也归类为可靠性。
这时的可靠性就不是特指某种能力，而是一般意义下的可靠性。
在软件开发过程中，需要对上述特性中特别指出的特性进行特殊设计，特别是要通过架构设计来保证，即成为架构设计关注的重点。
1.2.2软件开发期质量
软件开发期质量：
为保证软件的可维护性而在软件开发过程中应该关注的软件质量属性，包括软件的可扩展性、可重用性、可移植性、易理解性、易测试性和可维护性。
软件开发期质量属性称为“软件内部质量属性”，即不深入到软件代码内部是无法觉察到的软件质量属性。
这部分软件质量属性往往不会被用户通过需求的形式提出，而是软件开发团队应该自觉地保证，所以有的学者将其称为隐含质量属性。
可扩展性：
为适应新需求或需求变化为软件增加功能的能力。
有时称为灵活性。
可重用性：
重用软件系统或其一部分的能力的难易程度。
可测试性：
对软件测试以证明满足需求规约的难易程度。
在实际工作中主要指进行单元测试，插桩测试的难易程度。
可维护性：
在修改Bug、增加功能、提高质量属性等而定位修改点并适时修改的难易程度。
可移植性：
将软件系统从一个运行环境转移到另一个运行环境的难易程度。
易理解性：
设计被开发人员理解的难易程度。
任何一个开发期质量属性的满足都可能增加软件开发成本。
1.2.3约束
系统的约束是需求获取的重要内容。
约束不是行为，是设计或项目的限制条件。
这些限制条件也属于需求，但通常称为约束来强调其限制性。
这些约束是在系统开发前已经存在的一些事实或因素，新系统的开发无法回避这些事实或因素。
约束主要包括：
系统开发的资源约束：
如网络环境、操作系统、数据库管理系统、开发工具、硬件等。
新系统的开发必须以这些现有资源为基础，软件架构（特别是系统的运行架构和物理架构）必须考虑这些资源的有效利用和限制（实现技术的限制）。
接口约束：
如与本系统关联的系统是哪些，其接口约束是什么。
新系统可能接受其它系统提供的数据作为输入，其输出数据作为其它系统的输入。
操作约束：
如系统操作环境中的管理要求。
如身份认证必须通过第三方认证机构的认证，以网络为基础的业务处理，在网络不通的情况下如何处理业务等。
政策约束：
行业标准，企业标准，法律法规、政府规章等。
在现行的软件开发中，软件需方单位的信息化往往不是从零开始，而是有相当的基础，他们对新系统的开发具有极大的约束。
如开发的系统是某个大系统的子系统，大系统已经开发了一部分，该子系统必须满足于已开发部分的相互约束关系，必须为后续子系统奠定某些基础。
新开发的系统可以直接从某个或某些现有系统中获得原始数据等。
这些都是新系统开发最重要的约束。
1.2.4不同类型需求对设计的影响
功能需求影响软件架构，而软件架构必须适应功能需求的变化。
但功能需求并不决定软件架构。
质量需求主要影响系统的架构设计，在功能需求确定的情况下，系统架构设计主要针对非功能需求。
在软件设计中，软件架构设计对功能性需求的主要考虑是高适应性。
约束性需求将直接影响系统的架构设计；此外，有的约束性需求将转化为功能需求，如“银行系统必须执行统一的利率”是对开发银行系统的一条约束，该约束使待开发的系统必须提供调整利率的使用功能；约束还可能转化为质量束性需求，如系统预期用户的计算机应用水平普遍不高，因此要求待开发的系统有较高的易用性。
实践证明，忽略质量属性和约束性要求，必然导致系统失败。
结论：
软件架构要主动适应功能需求的变化，要从根本上支持软件质量属性要求，必须遵守约束的限制。
1.3需求的层次性
组织的不同层次人员对需求有不同的要求。
由不同层次人员的需求构成需求的三个层次：
业务需求：
组织要达到的目标—业务目标
用户需求：
用户使用系统来做什么
行为需求：
开发人员需要实现什么
对高层管理人员而言，希望软件系统能帮助他们达到业务目标。
对系统实际使用人员而言，希望系统提供的能力能辅助他们更好地完成日常业务工作。
对开发人员来说，为了满足用户诸多需求、或满足不同用户需求、或满足不同层次用户需求，而觉察到的需求（如果不补充这些需求，要满足用户觉察到的需求就显得比较困难）。
高层管理人员的需求与系统实际使用人员的需求可以起到相互验证和印证的作用。
通过实际使用者的需求来印证达到高层管理人员的业务目标要求，从中可以发掘出一些需求。
用管理者的业务目标要求来验证实际使用者需求的范围和合理性（业务流程）。
需求层次的关注在于在需求之间建立起“可跟踪性”，避免因遗漏需求而造成软件“达不到要求”，也避免开发人员一厢情愿地为用户“制造”没有实际意义的无用功能。
从需求的层次性看，需求并不完全是“用户的要求”，除了直接使用系统的“用户”的要求外，还包括并不直接使用系统的“高层管理人员”的要求，和开发系统的开发人员的要求。
在系统开发过程中，他们的要求同样要得到满足。
如果不关注“高层管理人员”的要求，系统开发就没有明确的目标，系统的功能将是零散而脆弱的，极易受到变更的冲击。
不满足开发人员的要求，软件的开发、维护和移植变得非常困难。
开发人员、开发管理人员和维护人员非常关心开发期质量属性，但最终用户不会提出、一般也提不出这类质量要求。
通常称这类质量属性为隐含质量需求。
运行期质量属性是软件系统在运行期间，最终用户可以直接感受到的一类质量属性，这些质量属性直接影响用户对软件产品的满意度。
可以认为，运行期质量需求来自使用系统的用户，开发期质量需求更多来自系统维护人员，即开发的系统更便于维护。
1.4需求的易变更性
需求的变更是最让人头痛的事。
任何需求变更意味着时间和金钱的消耗。
同时需求变更引起对系统的修改将降低开发期质量属性的质量，并引入更多bug，从而降低运行期质量属性的质量。
软件架构设计的重要目标是：
使软件架构能支持业务功能在一定范围内“随需应变”。
不同需求的易变更性不同：
●功能需求最容易变化。
在架构设计中，应划分少量长期稳定的功能，同时也应区分功能点本身趋于稳定，只是功能行为常常变化的功能。
●质量属性需求最为稳定。
●约束性需求的稳定性则稍差。
技术趋势发生变化、法律法规重新界定和用户组织调整改组等都可能引起约束性需求变更。
1.5需求捕捉的工具
（1）传统工具----业务流程图和数据流程图
对于复杂的系统，如管理信息系统，先通过业务流程图对业务过程进行描述，再将其转换为数据流程图。
数据流图是系统业务功能及其数据流动的描述，是系统的逻辑模型。
（2）UML提供的工具----活动图和用例模型
活动图可以有效地描述业务流程。
用例模型包括用例图和用例规格说明。
用例捕捉功能需求，其非功能性记录在用例规格说明中。
后面只考虑UML描述工具。
1.6需求提取内容
1.6.1确定业务目标
一个项目要被开发，要拨款立项，一定有它的业务目标。
对于一个系统开发，业务目标占有非常重要的位置，它明确规定了建立该软件系统的最终目的。
业务目标是组织或客户方的高层对未来系统的期望。
业务目标的确定需要从企业信息化的全局来考虑和规划，使其开发的系统成为企业信息化系统中相对独立的、支持全局应用的、不可替代的重要组成部分。
避免开发的系统解决的问题的层次太低，随着对信息化的要求的提高而很快过时。
项目业务目标通常由需方高层领导参与确定。
要避免业务目标太抽象、太空洞，如“实现XX信息化”。
一个项目管理系统的业务目标定义为：
帮助项目经理更好地控制项目
帮助项目经理更有效地分配资源
帮助项目成员之间更流畅地协作
还可以通过进一步细化业务目标，对每个业务目标列出一组高度概括的功能性需求。
这种高度概括的功能性需求通常称为“特性”，表明“为了达到所期望的业务目标，未来系统应该在大方向上具有哪些方面的特性，每个特性再有一组功能来支撑。
”如业务目标“帮助项目经理更好地控制项目”的特性有：
任务管理
跟踪进度
查看报表
任务分配和重分配
对应每个特性的功能可以用“用例”来描述，即一个特性对应一组用例。
1.6.2确定业务领域范围及业务流程
业务目标的实现需要通过具体的业务领域（有时也称职能域）以及具体的业务及流程来体现，使业务目标落实到实处。
这将引起企业组织机构的调整和业务流程重组，以满足业务目标的要求。
1.6.3建立用例模型
所谓用户需求，就是用户希望软件系统能为他做什么。
用例图技术是捕捉用户需求最合适的技术。
用例名是用户需求最直观、最简便的反映。
业务流程分析将捕捉到大部分用例，但不是全部用例，还需要补充一些与管理人员相关、但与具体业务活动不一定直接相关的用例和与信息查询相关的用例。
1.6.4建立用例规约
用例从一个较高层次描述了用户功能需求，解决了软件系统要“做什么”的问题，但还需要知道用户“希望如何做”的行为需求，否则还是不知道如何开发系统。
这里的“如何做”是从用户角度看他们“希望如何做”，而不是软件系统是如何做，所以还是属于需求捕捉的内容。
用户“希望如何做”是软件系统“如何做”的依据。
因此，用例规约中对系统行为的描述是以用户为中心展开的，便于与用户交流。
在用例规约中，将详细定义用户对用例运行期间的质量要求和约束。
不一定所有用例都要建立用例规约。
有的用例使用“用例简述”就足够了。
如果一个用例基本事件流对需求分析人员来说不是很清楚，而且可能涉及到非功能要求，就需要用“用例规约”来详细描述。
在需求分析阶段可以通过用例界面的“预设计”可以更好地描述用例。
真正设计是从实现角度来考虑问题，“预设计”是从与用户交流角度来考虑问题。
用例实现：
用例实现不是真正编码实现用例对应的功能，而是考虑为了实现用例定义的功能，需要哪些类，以及这些类的对象之间如何交互来完成最终的功能。
用例实现是从功能需求向设计方案过渡的纽带，通过分析一组关键用例的用例实现，可以获得未来系统的理想化的职责模型。
这个职责模型是规划架构机制、满足高质量属性要求的基础。
用例规约也称用例规格说明。
1.6.5确定系统非功能需求
通过对用例规约的分析和总结，归纳出系统的非功能需求，特别是用户对系统运行期的质量需求和约束。
用例规约是系统运行期质量需求和约束的主要来源。
一般来说，开发期质量属性需求主要来自系统开发人员和维护人员。
第二部分需求提取与需求建模
2.1需求建模基本概念
需求提取的建模包括业务建模和用例建模。
业务建模是确定项目对应的业务领域所包含的业务和业务流程，并用所选择的业务流程描述工具进行描述。
用例建模是以用例为基本单位来描述用户的功能需求。
与用例模型相关的概念包括：
参与者，用例，场景
2.1.1参与者
参与者：
直接与系统交互的外部事物所扮演的角色。
该定义强调了3点：
①参与者对系统而言是外部的；
②参与者直接与系统交互，即参与者要直接使用系统来支持他的业务工作。
③强调参与者所扮演的角色，而不是特定的人或事物。
一个特定的人可能扮演几种角色，可以作为系统的多个参与者。
时间可以作为参与者，通常用时间发生器来表示。
有些系统的功能是通过系统设定的时间来驱动的。
这里的参与者主要指系统业务功能的使用者。
系统管理员不是这种意义的参与者。
因为他不是使用系统功能完成与单位业务有关的工作。
他使用系统的辅助功能实现对特定的人及其角色的管理，使参与者在自己角色范围内使用系统。
每个参与者使用一个具有业务意义的名称命名。
为了把系统的用户都考虑到，有时使用“主要参与者”和“次要参与者”的提法，主要参与者使用系统实现自己的业务目标。
次要参与者为系统提供服务。
系统管理员就是系统的次要参与者，其目标就是管理主要参与者，使他们按照事先的约定使用系统，保证系统有效运行。
需求获取的首要任务就是识别主要参与者。
主要参与者驱动了用例。
用例总是有参与者开始的。
用例从参与者的角度来编写的。
识别参与者是需求提取的首要任务，谁是系统的客户，他们需要系统做什么，他们希望在什么时候、什么地点做什么，这些都是系统设计要考虑的重要因素。
2.1.2用例
用例就是需求。
从根本上说，用例就是功能需求。
用例是一种被广泛使用的用于发现和记录需求的机制。
被认为是一种最好地理解需求和描述需求的技巧。
在统一过程中，用例被推荐作为发现和定义需求的主要方法。
用例为项目相关人员提供了一种简单而易懂的机制来了解目标和系统需求。
用例图描述的是软件系统为用户或外部系统提供的（系统级）服务，清晰地界定了系统的功能范围，有利于从宏观上反映系统功能的大局。
1、用例的定义
用例：
参与者想要系统做的事情。
具体表现为用户如何使用系统来达到其目标的一组情节。
例如在超市，“处理销售”的用例描述为：
一个顾客携带欲采购的商品到达收费口。
收银员使用系统输入商品信息，系统给出商品的清单和累加值。
顾客交款。
收银员输入支付信息，系统对付款信息进行计算，更新库存信息，并给出余额信息；系统打印购物清单。
顾客得到收据，然后携带商品离开。
只有对用例表现出的情节进行真实、完整、准确地描述，才能捕捉到对系统需求有价值的东西。
2、用例的粒度
参与者想要系统做的事情有大有小，有抽象的事情，有具体的事情。
参与者想要系统做的什么样的事情那些可以作为一个用例，哪些事情又不能算一个用例。
这实际上涉及到用例的粒度问题。
指导原则1：
在进行需求获取时，应专注于“基本业务过程”（EBP）级别的用例。
基本业务过程：
由一个人在某个时间某个地点执行的一项任务，这个任务是对某一个业务事件的反应，而且可以增加可度量的业务价值，并且能够保持数据状态的一致。
用例
升级会员 