毕业论文需求分析的方法与建模doc36毕业设计管理资料.docx
《毕业论文需求分析的方法与建模doc36毕业设计管理资料.docx》由会员分享，可在线阅读，更多相关《毕业论文需求分析的方法与建模doc36毕业设计管理资料.docx（30页珍藏版）》请在冰豆网上搜索。
毕业论文需求分析的方法与建模doc36毕业设计管理资料
南开大学
本科生毕业论文（设计）
题目：
____需求分析的方法与建模__
学号：
____0010127____________
姓名：
____方春强___________
年级：
____2000级___________
学院：
____软件学院___________
系别：
____软件工程___________
专业：
____软件工程___________
完成日期：
____2004-5-24__________
指导教师：
____林晓旻___________
需求分析的方法与建模
软件学院软件工程系软件工程专业方春强学号：
0010127
指导教师：
林晓旻讲师
摘要:
需求分析作为软件工程的开始，具有相当的难度去把握它。
为了更好的了解软件需求，人们发展了许多方法和建模技术。
借助这次中远船员信息管理系统需求分析实践机会，尽量的在作分析的过程中运用了解的方法、掌握的建模技术，不仅能够有效的分析软件需求，还能加深知识。
关键字：
分析，领域，方法学，建模技术，需求
Abstract
Therequirementanalysistookthesoftwareengineeringthestart,hasthesuitabledifficultytograspit.Inordertounderstandingsoftwarerequirementbetter,peoplehavedevelopedmanymethodsandthemodelingtechnology.WiththeaidofthisCSISrequirementanalysispracticeopportunity,usingtheunderstoodmethodandmodelingtechnologyintheanalyzingprocessasfaraspossible,notonlycanmakethesoftwarerequirementanalysiseffective,butalsocandeepenourknowledge.
KeyWords：
Analysis,domain,methodology,modelingtechnique,requirement
第五章技巧与心得28
第一章绪论
什么是软件需求
目前，所有国家都在使用复杂的计算机系统。
越来越多的产品把计算机和控制软件以一定的方式结合起来。
软件工程作为一门工程学科，其目标在于使软件系统向高性价比发展。
所有的软件工程都具有以下基本活动：
1．软件描述软件的功能以及软件操作上的约束必须定义。
2．软件设计和实现软件一定要按照描述来生产。
3．软件有效性验证软件要被确定是有效的，能做客户想要的事情。
4．软件进化软件一定按客户需要的变更来进化。
其中，软件描述，目标是确定软件系统需要哪些服务以及开发和运行期间受到哪些约束。
对服务和约束的发现、分析、建立文档、验证活动现在常称为需求工程。
需求工程对于软件过程是一个特别关键的阶段，这个阶段的错误将不可避免地带到后续的系统设计和实现阶段中。
需求工程阶段的独特之处在于很少有现成模式或特制的文档可供参考。
后续阶段可以建立在前期所做工作基础上（各种相关模型至少在一定程度上可以衍生导出），而需求工程阶段的成果却是靠创建而来的———几乎就是从无到有。
需求的过程
需求工程本身就是一个过程，这个过程产生用以描述系统的需求文档。
通常需求在这个文档中被分成两个层次描述：
最终用户和客户需要高层次的需求描述；而系统开发人员需要比较详细的系统描述。
图需求工程过程
分析问题
定义系统
理解涉众需求
改进系统定义
管理需求变更
管理系统规模
新的输入
新系统
现有系统
错误问题
正确问题
无法完成
范围之内
更多迭代
完成需求
需求过程的四个主要阶段：
1．可行性研究指明现有的软件、硬件技术能否实现用户对新系统的要求。
从业务角度来决定系统开发是否划算以及在预算范围内能否开发出来。
可行性研究是比较便宜和省时的。
结果就是要得出结论，该系统是否值得进行更细致的分析。
2．需求的导出和分析这是一个通过对现有系统分析、与潜在用户和购买者讨论、进行任务分析等导出系统需求的过程。
也可能需要开发一个或多个不同的系统模型和原型。
这些都会帮助分析员了解所要描述的系统。
3．需求描述需求描述就是把在分析活动中收集的信息以文档的形式确定下来。
在这个文档中有两类需求。
用户需求是从客户和最终用户对系统需求的抽象描述；系统需求是对系统要提供的功能的详尽描述。
4．需求有效性验证这个活动检查需求实现、一致和完备。
在这个过程中，不难发现需求文档中的错误，然后必须加以改正。
当然，需求过程中的各项活动并不是严格按顺序进行的。
在定义和描述期间，需求分析继续进行，这样在整个需求工程过程中不断有新的需求出现。
因此，分析、定义和描述是交替进行的。
软件系统需求
常常分为功能需求、非功能需求和领域需求：
功能需求包括对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。
在某些情况下，功能需求可能还需要明确申明系统不应该做什么。
理论上，系统的功能需求描述应该既全面又具有一致性。
全面意味着用户所需的所有服务都应该给出描述。
一致性意味着需求描述不能前后矛盾。
在实际过程中，对大型而又复杂的系统而言，要做到需求描述既全面又一致几乎是不可能的。
一方面是因为系统固有的复杂性，另一方面是因为观点不同，需求也会发生矛盾。
非功能需求对系统提供的服务或功能给出的约束。
包括时间约束、开发过程约束、标准等。
非功能需求愿于用户的限制，包括预算上的约束、机构政策、与其他软硬件系统间的相互操作，还包括如安全规章、隐私权利保护等外部因素。
主要有的类型如图非功能需求的类型
.
机构需求
可用性
效率
可靠性
移植性
交付
实现
标准
互操作
道德
法律
。
。
。
产品需求
外部需求
非功能需求
领域需求这是来自系统的应用程序领域的需求，反映了该领域的特点。
他们也可能是功能需求或非功能需求。
软件需求文档
有时叫做软件需求描述（SRS）是对系统开发者要求的正式陈述。
IEEE标准为需求文档提出了以下结构：
引言（目的、范围、缩略词等），一般描述（产品透视、功能、用户特征、约束等），专门需求（功能、非功能、接口），附录，索引。
图需求文档的形成
业务需求
用户需求
质量属性
非功能需求
系统需求
功能需求
约束条件
项目视图和范围文档
使用实例文档
软件需求描述文档
第二章方法论
问题域（应用领域）
问题所存在的现实世界中的那个部分。
问题域是需求分析员所要研究的首要对象。
就一个电梯控制系统来说，它将包含任何现存的硬件（电梯、指示器、传感器、按钮等）、建筑物特征（楼层和电梯井的数目）、预期的使用模式、用户特征、使用约束（如限制短途搭乘）等等。
在这个问题域内，问题可以确定为“让电梯在建筑物中更有效使用的控制系统”。
为了解决问题，‘解系统’显然有必要在问题域内产生某些效果，构成软件需求的正是这些想要获得的效果，也就是为何做软件需求的原因和目的。
图问题域与解系统的相互关系
上图中也定义了三个主要软件开发活动的阶段任务。
分析，关注问题域和存在于其中的问题，目的在于真实的了解问题域。
规格说明，关注问题域与解系统之间的相互关系，定义了系统预期的目标。
设计，关注解系统内部的运作实现，构建计算机中的“现实世界”即软件（不属于需求工程部分）。
到现在为止，我们得到初步论点。
在构建一个新软件系统之前，最好先决定它应当能够做些什么又不要做些什么；从问题域的研究入手，获得问题的描述，以及新的解系统在其中将产生效果的陈述（即需求）；确定新系统所需的行为，以便让它在问题域内产生所需要的效果。
需求分析
通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明。
需求分析旨在揭示一个现有的系统（问题域）的结构，而内部设计则是要创建出一个尚未存在的软件系统（解系统）的结构。
对于这一重要任务其特性如下：
分析关注问题域及对其建立的模型，而不是解系统；
主要目标是要获得对问题域及存在于其中的问题本质的理解；
分析在本质上先于解系统行为的规格说明（尽管有重叠和反复的过程）。
方法论
方法不只是一种技术，它是解决任务的一种途径，并且通常由一组技术组成。
任何分析方法，要使它得到很好的利用，都应当要求并且做到便于描述以下几个方面：
1.问题域的结构，根据其子域及其相互间的关系；
2.问题域数据，语法和语义方面
3.问题子域的内在属性和行为；
4.问题域中的重要事件及现象；
5.需求，解系统在问题域中应产生的效果。
结构化分析（SA）
结构化分析（SA）是一种具有相当长历史的分析方法，其演化的方式既微妙又显得很重要。
如同结构化编程一样，它致力于系统范围内的事物处理，数据流以及存储数据结构的建模。
建模主要包括数据流模型（DFD），数据字典（DD），实体关系图（ERD）。
结构化分析所用的原型，无论是对开发者还是客户都显得直观易懂，若将初始重点放在对原有系统的建模是对实现理解问题域这一基本的分析目标的有力支持。
结构化分析方法和人们的思维方式和相似，注重的是事物的过程和方面。
利用结构化分析很容易去理解一个刚刚接触的问题域，适合对比较生疏领域做软件需求。
面向对象分析（OOA）
面向对象方法最初只是一种系统的结构进行建模的方式，后来扩展到了内部设计，如今也已经开始广泛应用于分析阶段。
面向对象分析基本思想是：
如果把对象类的建模限定在需求问题域，那么面向对象的基本原理、模型以及表示法均可以用于分析。
OOA（面向对象分析）算不上一种真正的需求方法，OOA的起点是一份原有的需求文档，或者甚至是一份行为规格说明，并且OOA隐含的假设问题域分析已经完成，即分析员已经了解了所要研究的事物。
OOA的真正本质意义是作为解系统的高层体系结构的设计，并且有利于系统的下一步开发设计（如果是OOD开发的话）。
OOA的大致方法是
●标识出问题域中的对象类；
●定义这些类的属性和方法；
●定义这些类的行为；
●对这些类间的关系建模。
面向问题域分析（PDOA）
面向问题域分析
面向问题域的分析（PDOA）是一种新技术。
PDOA更多的强调描述，而较少的强调建模。
描述大致划分为两个部分：
一部分关注于问题域，而另一部分关注于解系统的待求行为。
一般建议同时有两个单独文档：
第一文档含有对问题域相关部分的描述以及一个需求在该域中求解的问题列表（即需求）；第二文档（规格说明书）包含的是对解系统的待求行为的描述以解决需求。
其中第一文档才是通过做分析产生的；第二文档推迟到后续的规格说明任务中。
PDOA整个方法过程的基本步骤：
●搜集基本的信息并开发问题框架（一种模型），以建立问题域的类型
●在问题框架类型的指导下，进一步搜集详细信息并给出一个问题域相关的特性描述
●基于以上两点，收集并用文档说明新系统的需求
问题框架
问题框架是将问题域建模成一系列互相关联的子域。
一个子域可以是那些可能算是精选出来的问题域的任一部分。
问题框架的目标就是大量地捕获更多有关问题域的信息。
基于不同问题子域的本质及存在于问题子域间的关系，可以把问题框架分类：
●工件系统——系统必须完成针对只存在于系统中的这些对象的直接操作。
●控制系统——系统控制部分问题域的行为，包括待求行为框架和受控行为框架。
●信息系统——系统将提供有关的问题域的信息，包括，信息是自动提供的，和，信息只在响应具体的请求时提供。
●转换系统——系统必须将某种特定格式的输入数据转换成相应的、另一种特定格式的输出。
●连接系统——系统必须维持那些相互没有直接连接的子域间的通信。
问题框架法在应用时，建议采用直截了当的策略：
●抽象问题域：
1.标识子域
2.标识子域间的交互
3.刻画每个子域的特征
4.生成一个上下文图
●识别出相关的标准框架
●调整框架，尽可能使之适用于问题
●使用关于相关框架的内容技术表来指导进一步的分析与文档编制任务。
问题域的描述与必须满足的需求二者之间有着明显的区别，对新的解系统的行为创建与定义应单独处理并且推迟到下一步的规格说明阶段。
方法的对比
结构化分析及其相应的派生方法，曾一度风行了许多年头。
它最初的版本主要是围绕对数据流以及问题域的数据结构进行建模，而现代的SA则直接将重点放在开发解系统的模型。
描述问题域的SA可以算是想当不错的，所产生的功效可见一斑。
然而，它对其他方面的支持却不够完善，在处理一些其他类型问题时显得有些笨拙。
面向对象分析是当今主流的方法。
OOA要求所有的系统均可以按照对象的特点来建模。
它也继承了很多结构化分析的思想体系。
OOA不能对问题域有个清楚的了解，因而它的起点若是有一份原需求文档，便可大大简化问题域的分析。
OOA并不区分问题域描述与解系统描述之间的差异，而是直接交付出新的解系统的高层设计。
SA和OOA还是有几点相同特性的：
●主要模型是结构模型（关于模型，在下章有详细介绍）。
●通常焦点集中在对解系统的建模上。
●两中方法都较少地应用于需求获取领域。
●分析与内部设计之间没有明显差异。
面向问题域分析被认为是一种较为理想的方法。
PDOA特点是重新将重点定位在问题域及需求上，通过对问题域的分类，向分析人员提供具体问题的相关指南。
并且它将规格说明作为另行的任务处理，它的成果只是一份问题域的全面描述和一份需求列表而已。
PDOA丰富和完善了现今的“分析”方法，然而人们对它的了解和掌握还差一大段距离。
因地制宜的应用三种方法，不仅能够如实的认识问题域，创建出健全的解系统，还能够向用户和设计人员都提供满意的需求文档。
第三章建模技术
系统建模总的来说是软件开发过程中、尤其是需求工程中的一个极其重要的部分。
相关建模技术之间的最重要区别在于他们是构成系统的外部模型还是构成系统的内部模型。
表建模技术对比
外部建模
内部建模
功能的
结构的
黑盒
白盒
行为的
非行为的
外部模型
外部模型可进一步划分为建模系统外观的模型和建模系统行为的抽象模型。
表示模型是对系统外观进行的模仿，相当于描述可见的输出，最有效的表示法通常是画图。
这种技术特有的优点是易于获得工具支持、模糊性低、不易出错和可理解性高。
对软件系统定义而言，它并不是全部的内容，只是一个从中起着有效作用的基本元素。
原型法
原型在其他工程领域有着历史悠久的传统，但在软件工程中，使用原型是最近几年的事情。
合算的开发原型需要相对强有力的开发平台，好在现在已经没有了技术障碍，原型开发得到了快速的采用。
原型可以为各种目的而购造，与需求工程相关的是那些试图绘制所需系统的外观和一些可能的行为的原型。
对原型一个普遍认同的分类：
探索性原型——帮助需求获取或细化需求，也称为一次性原型，一旦需求工程完成后，它便没有用处。
定义原型——形成部分所需行为的定义，即部分规格说明。
结构原型——用于评价可能的内部设计方案，例如检查性能。
虽然是用于设计阶段，但也用于需求阶段可行性的检查。
演化原型——通过逐步求精过程，原型最终成为了产品。
需求工程主要关注的是前两种原型，原型开发隐含着迭代。
如在需求获取中：
初始原型将向用户演示，获得的反馈将用于细化原型，在实践中这种迭代会出现好几次。
迭代中可能会增加新内容，也可能减少内容。
原型在需求工程中主要作用是对用户接口进行建模，尤其是当这些接口相当复杂、关键、新鲜时。
原型开发的一个潜在好处是：
可以促进潜在用户的参与和客户的承诺，但有个副作用：
真实原型的早期外观会误导人们认为该项目比实际情形先进得多，随着最终产品的出现就会感到失望。
行为（功能）建模
行为模型只是系统行为的抽象。
行为建模有很多种，我们就较一般的可能用到的简单介绍几个：
1.功能声明与分解
功能声明也许是最简单、常用的行为定义技术。
声明使用文本方式，描述输入和输出之间的因果关系。
功能分解可以说是一种高级策略，通过许多其他方式实现，如Use-Case、DFD、结构图。
基本思想相当简单，通常系统功能性的详细定义是按层次结构来实现的，即通过把功能分解为若干低层的、更为详细的功能集。
该技术也称为功能求精或功能组合。
2.任务分析
任务分析，涉及的是人的任务性能的分析或外部设计，特别用于人机接口（HMI）。
任务分析从人们所希望获得的目标开始。
任务是获得这些目标的高级机制，操作是实现任务的交互。
3.用例与脚本
用例（use-case）描述所设计的解系统与一个或多个端子之间的某种特定的交互。
用例在面向对象领域主要作为一种分析和规格说明的技术。
对新系统将投入使用的环境进行分析相当于研究该系统所必须满足的要求。
事实上，情形可能是客户和潜在用户确实发现用例易于理解，因此，用例就有助于客户/用户与开发者之间的交流。
大多数用例都有“执行者”，可以是人，也可能是系统的软硬件设施。
用例文档可以用文本或UML图来描述。
用例的应用和构造具有相当大的灵活性，人们可能认为它不够严格，但是应用指定的合适的指导原则可以解决这个问题。
4.有限状态机
有限状态机（FiniteStateMachines，FSM）通过输入与输出之间的因果关系对系统的行为进行建模。
（1）系统可看作有若干个相互区别的稳定状态；
（2）当条件改变时，系统从一个状态改变到另一个状态；
FSM的设计规则
●转移总是起始于一个状态并终止于一个状态。
●一个转移总是有一个相关的触发器。
●一个转移可以有一个或多个相关动作。
●同一个触发器可能对多个状态有效。
内部模型
内部模型是对系统内部的构造或体系结构的建模技术。
可以很简单的把解系统的内部分成两方面：
数据和操作。
根据建模所侧重的方面，可以划分为三种内部建模技术。
1.面向处理技术
抽象的把所考虑的系统建模成一组通信子系统，重点放在它们实施的处理上。
（1）通信并发处理
这个模型把子系统看成是并行运行的，现实世界中的各种事物也是通常是如此的，因此它具有相当的直观性。
最常采用的方法是“数据流图”，即DFD。
DFD的开发需要大量的专门知识，以消除建模中可能导致的二义性和错误。
好的DFD后面的解释是较为直观的，因而可理解性是比较良好的。
以下规则可以用来检查DFD的有效性：
●数据不能直接在数据存储之间流动；
●数据在端子之间的流动不显示；
●处理和数据存储通常至少有一个输入和一个输出。
（2）通信顺序处理
虽然真实事物一般都是一个并行的系统，就如同一个人可以同时做很多事情一样。
但是，大部分计算机以顺序的方式处理，特别的在软件设计的时候（即使是面向对象设计）。
对通信顺序处理建模的常用表示法有树状图或结构图，另一种主要方法是伪码。
2.面向数据结构的技术
数据结构建模是所有信息系统最重要的技术，也常称为数据分析，关注的是静态数据的结构。
实体属性关系建模，则是数据库应用系统的通用方法。
当进行数据分析时，通常起始点是搜索需求获取记录，选出候选实体。
识别有意义实体的好方法是问问：
“哪些相关信息与这个实体相联系？
”。
与实体相关联的信息即为实体的属性。
实体间的关系有三种：
一对一，一对多，多对多。
3.处理/数据相结合
该技术集中在对发生的处理和处理的数据的建模上，采用了一种完整的观点，却抽象更加复杂。
主要的两种模型是实体生命历史（ELH）和面向对象建模。
实体生命历史建模起的是辅助性的作用，它从数据分析和数据流建模继续而来，实体来自于ERD，实体处理来自DFD，然后为每个实体的有关处理顺序进行建模。
ELH的作用是在其他模型之间充当一个交叉的检查和一种集成。
面向对象建模把所考虑的系统建模为一组相互通信的对象。
一个对象是存储数据和对其数据上的操作进行抽象。
识别和定义对象只是一部分工作。
还必须探讨对象间的关系。
选择技术
可以从两个方面来选择技术：
1.特定的目的需要什么技术
2.特定的技术适合什么目的
特定的目的或许更多的需要我们去挖掘、思考，而熟悉各种技术的常见应用领域将会有很大帮助。
表常见应用领域表
上下文图
问题框架
一次性原型
功能分解
用例
任务动作法
F
S
M
D
F
D
结构图
E
R
D
E
L
H
面向对象
D
D
（B
N
F）
需求获取
√
√
问题域（PD）概述
√
√
问题域结构
√
√
√
PD数据模型
√
√
√
I/O问题数据
√
√
子域行为
√
子域状态
√
√
功能需求
√
性能需求
√
约束
SS外观
√
I/O解数据
√
SS行为（ER动作）
√
√
√
√
√
SS状态
√
√
定时
√
√
第四章需求分析实践
项目介绍
在现有《中远船员综合管理信息系统》操作平台的基础上，用不到一年的时间，设计开发中远通用、技术先进、功能全面、人性化与智能化突出的“中远船员信息系统”（以下简称CSIS），同时建立起以集团为核心的，联结各家系统的中远船员信息管理网络，在中远系统内实现船员信息的高度共享。
按照系统功能划分，工作小组下设7个业务组，分别为调配管理组、证件培训组、劳动工资组、工资核算组、费用报销组、集团平台组、船员平台组。
（由于在做需求过程种，发现报销与工资有很多相近之处，因此已经合二为一）
进度
2004年4月–6月，完成系统需求调查；
2004年7–8月中旬，在前期需求调查基础上，拿出系统设计初步方案；
2004年8月中旬–8月底，征求各家单位对初步方案的意见，修订方案；
2005年9-12月，进入系统实质开发阶段，在此期间还需反复征求各家单位意见。
········
需求调查阶段分四个小组：
调配、工资、劳资、证培。
我所在的小组是工资（包含报销）。
获取需求
需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。
需求获取只有通过有效的客户——开发者的合作才能成功。
分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与软件有关。
为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。
对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。
需要用户去了
升级会员 