需求工程软件建模与分析.docx
《需求工程软件建模与分析.docx》由会员分享，可在线阅读，更多相关《需求工程软件建模与分析.docx（45页珍藏版）》请在冰点文库上搜索。
需求工程软件建模与分析
1问题分析的主要步骤（五步）？
（1）在问题定义上达成共识；
（2） 理解根本原因,分析问题背后的问题；
（3）确定相关人员和用户;
（4） 定义解决方案的界限；
（5）确定加在解决方案上的约束.
２ 鱼骨图主要用于定性分析，帕累托图主要用于定量分析.
３ 鱼骨图、帕累托图构建的主要步骤？
鱼骨图
A选择问题
首先选择一个具体的问题或者结果。
在选择问题时，要保
证问题是专门的、定义严谨的、范围相对较小的（对于大范围
的问题往往需要考虑将其分解成相对较小的问题）,并且保证
参与人员切实理解要分析的内容.对问题定义产生出来的问题
一般都应该进行一次独立的鱼骨图分析。
B 头脑风暴
就导致问题的可能原因进行头脑风暴。
将大家提出的意
见记录下来，确认后贴到鱼骨图上。
需要注意的是不要将原因和解决方案混为一谈.在确定
原因的分类前先进行头脑风暴（一个人提,大家批），不然
思考问题的范围就会受到限制。
支持者需要引导和鼓励参与
者参与其中。
C确定问题类型
对头脑风暴的结果进行整理,确定出主要的原因类型.
一般来说,划分出来的问题不要少于2类，不要超过6类
（经验数值,仅供参考）。
经常使用的类型有:
人、设备、
材料、环境、方法、过程等。
将这些类型补充到鱼骨图上.
D分配原因
将头脑风暴中得出的潜在原因放在鱼骨图上，并且确保每
一项原因都归于适当的类别中。
如果原因看起来可以放在多个
类别中,就表示是多重原因造成的问题。
但如果多次出现多重
原因，可能就以为着分类存在问题.该阶段将形成最终的鱼骨图
E分析根本原因
对鱼骨图中罗列出来的所有潜在原因进行分析。
分析出
造成某一结果的最根本原因是什么？
找出核心所在.
方法如下:
通过参与者之间的公开讨论来分享看法和经验；
寻找重复的原因,或者与特定类有关的原因的数量;
使用检查表收集资料、制造流程图或者进行用户调查,
通过帕累托分析法测试各种原因的相对强度；
投票（真理多数情况下掌握在多数人手里）
帕累托图
在通过使用鱼骨图完成问题原因的定性描述后.仍然存在一个
问题，就是根本原因的辨识需要有经验的决策者确定，或者根
据人类固有经验（少数服从多数）确定.更好地方法是能够开
展定量分析。
帕累托分析可以帮助我们做出这样的定量分析。
帕累托分析应用就是根据鱼骨图分析的结果，通过收集相关统计
资料,通过直方图的方式显示问题的相对频度或者大小高低等定
量结果。
Ａ确定问题和相关原因
利用鱼骨图的结果。
B 收集数据
有针对性第收集数据。
例如上例中，我们可以抽取一些
废品,分析这些废品产生的原因
C绘制直方图
4上下文图画法步骤？
在绘制上下文关系图时应该采用以下步骤:
1、首先用一个矩形表示系统，写上系统的名称,将整个系统看做一个黑盒子；
2、然后找到该系统的所有Ｃｕｓｔomｅr（客户），考虑这些Custoｍer会发起什么事件，这些事件会引发Woｒkｅr（内部工作人员）的什么工作,将这些序列逐一表示出来；
３、最后在看看系统的每个Worker还有没有一些主动发起的事件。
（Cｕstoｍeｒ:
也就是该主题域的客户,它处于该主题域的外部.如，对于体检业务子系统而言，体检者显然就是一类客户,除此之外，客服中心、物资部门、财务部门的工作人员也是这个主题域的Custｏｍer。
Wｏrker：
也就是该主题域的工作人员，它处于该主题域的内部。
如，服务中心，体检科室，综合科的工作人员都是其Worker。
关键要点在于“针对本主题域”而言。
）
5需求获取的主要活动
研究应用背景,建立初始的知识框架；
根据获取的需要，采用必要的获取方法和技巧；
先行确定获取的内容和主题，设定场景；
分析用户的高（深）层目标,理解用户的意图；
进行涉众分析，针对涉众的特点开展工作。
6需求协商的几条法则的应用?
差异问题协调法则：
不同的业务层面（有时即使是相同业务层面）的用户对同样的概念或者流程
有不同的认识和理解,会出现一些差异，在需求整理时应该将这些差异明确
标识出来，并展示给用户高层管理人员，由他们来确定如何消除这些差异，
并将这些情况记录。
消除变更问题协调法则：
上面法则提到的问题，从消除变更的角度考虑仍然存在问题.仅仅将差异标
识并展示给高层并不能消除变更的可能，应该考虑这些差异形成背后的问题，
应该从开发角度考虑如何消除这些差异,并提供给高层管理人员。
要有主动性
需求协商时机法则：
不要在需求冻结前开展需求协商工作。
需求协商应该在
需求获取过程中不断开展，出现就考虑消除.如果都等到冻结前，将所有矛
盾集中体现对工作是非常不利的.
实例:
W公司开发的信息系统到了需求冻结前夕,Ａ建立拿出厚厚一本需求
协商底稿，分为重点差异协调部分，一般差异协调部分，已协调差异列表。
结果用户高层非常不满,认为这些工作需要大量时间难以短期完成.
7需求获取的主要方法
用户访谈
用户调查
文档分析
原型法（情节串联板）
模型驱动的方法
8开放式话题与封闭式话题运用
开放式话题
v优点：
–让被会见者感到自在；
–会见者可以收集被会见者使用的词汇，这能反应他的教育、价值标准、态度和信念；
–提供丰富的细节;
–对没采用的进一步的提问有启迪作用;
–让被会见者更感兴趣;
–容许更多的自发性；
–会见者可以在没有太多准备的情况下进行面谈.
v缺点：
–提此类问题可能会产生太多不相干的细节；
–面谈可能失控;
–开放式的回答会花费大量的时间才能获得有用的信息量；
–可能会使会见者看上去没有准备
封闭式话题
v优点:
–节省时间；
–切中要点；
–保持对面谈的控制;
–快速探讨大范围问题；
–得到贴切的数据
v缺点：
–使得被会见者厌烦;
–得不到丰富的细节;
–出于上述原因，失去主要思想；
–不能建立和面谈者的友好关系。
9用户访谈时问题组织的三种方式及特点?
金字塔结构
v如果会见者认为被会见者需要对话题进行预热,可以采用金字塔结构，通过逐步的引导来使得被会见者打开话匣子。
v如果会见者发现自己事先对事实的确认存在较大偏差或者被会见者看上去不情愿讨论这个话题，也可以采用金字塔结构。
v当想结束讨论这个话题的时候，使用金字塔结构的提问顺序也是有用的.
漏斗结构
v漏斗结构为开始一场面谈提供了一种容易而轻松的途径.
v当被会见者对这个话题有情绪,并且需要自由表达这些情绪的时候,需要采用漏斗型提问顺序.
v或者在会见者事先对事实了解不多时,也应该采用漏斗结构的问题组织方式。
v用这种方式组织面谈能得出很多的详细信息，以至于没有必要使用长序列的受限制问题和调查问题。
菱形结构
v使用菱形结构的主要优点是通过各种各样的问题保持被会见者的兴趣和注意力。
一旦掌握了如何在正确的时间问正确的问题，就可以多样地选择问题的顺序.
１0市场调查和需求获取在访谈与调查顺序上有何不同？
原因何在?
一般来说，在开展市场调查时，由于很难深入接触到潜在的用户。
所以
总是先调查,后访谈。
而在需求获取时,通常采用的策略是先访谈，后调查。
其实原因在于市场调查与需求获取有不同的应用背景。
一般市场调查通常
用于验证潜在客户对产品的接受程度。
而需求获取的目标是要理解客户需要解
决的问题。
也就是说需求获取时你往往还没有产品,信息不够充分，所以很难设计出
有效的调查问卷。
１1采用原型方法的三个目的？
明确并完善需求
原型作为一种需求工具,它是对部分系统的初步实现，因为我们尚没有很好地了解该系统。
研究设计选择方案
原型作为一种设计工具,涉众可以用它研究不同的用户交互技术，优化系统易用性，并评估可能的技术方案。
发展为最终产品
原型作为一种构造工具，是产品一个最初子集的完整功能实现。
１2用例描述方法
1３需求关系的根本任务是什么？
需求分析是软件需求中最核心的工作，需求建模是需求分析
的主要手段。
需求分析是软件定义时期的最后一个阶段,它的基本任务是
准确地回答“系统必须做什么？
"这个问题.
需求分析的任务还不是确定系统怎样完成它的工作,而仅仅是确定系统必须完成哪些
工作，也就是对目标系统提出完整、准确、清晰、具体的要求.
需求分析根本任务:
建立分析模型，创建解决方案。
14需求分析任务中分解策略主要包含那几种？
每种策略分别适合应用于那些系统的开发
1）业务流程为主线的分解策略;
业务流程为主线的分解策略是目前比较流行的方法,主要按照
“业务”的角度考虑分解方法。
此方法特别适合联机事务处理系
统、管理信息系统（MＩS）.
目标系统—》主题域的分解依据是“目标决定范围”；
主题域-》业务事件所做的是理清业务脉络;
业务事件—》业务活动所做的是填充细节;
业务活动－》业务步骤所做的是细化和确认工作。
2）程序结构为主线的分解策略；
方法是需求分析最常用的分解方法。
当由于其过早进入程序结
构，割裂了与问题域之间的联系，从而容易导致对问题域研究的
不足，降低了需求的质量。
目前认为此种方法仅适合于问题域比
较清晰，问题不算复杂的情况,例如工具软件、嵌入式系统等.
3）基于场景的分解策略;
对于决策支持系统、面向用户的嵌入式系统等来说，决策场景、
使用场景是主要的线索。
向上可以总结成一类相似的集合，再
总结成一系列的关注点或者功能域，向下可以分解成具体的步骤
或者操作任务.
４）基于数据的分解策略等。
上述分解策略都是从“业务”角度来组织。
但对于类似数据仓库
之类的数据类项目，业务线索并不是十分明显,或者并不重要
这是就需要以数据为主的分解策略.其中主题域仍然与“业务
流程为主的分解策略”类似。
而主题类是企业中的高层实体，
主要由一组企业的逻辑数据类来表示，而企业的逻辑数据类在
实现时又会对应于多个物理数据类。
1５ 需求分析中分解与提炼的比较？
分解是一种自顶向下的方法,当按照任何一种线索进行分解时.就会破坏其它线索的完整性。
例如,如果以“业务”为线索,就会发现数据需求分解后会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。
此种情况出现时，可能会影响需求分析人员建立全面的理解，因此需要采用自底向上的方法进行提炼。
例如将每个业务事件中的类进行提炼,抽取出共性的部分，建立针对整个系统的全局领域模型。
16构建分析模型的目的？
1将复杂的系统分解成为简单的部分以及它们之间的联系,确定本质特征
２和用户达成对信息内容的共同理解
3分析的活动主要包括识别、定义和结构化,它的目的是获取某个可以转换为知识的事物的信息
1７分析模型的建模方法？
v模型
–“模型是对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解"
–集中关注问题的计算特性（数据、功能、规则等等）
–“它是对系统进行思考和推理的一种方式.建模的目标是建立系统的一个表示，这个表示以精确一致的方式描述系统，使得系统的使用更加容易”
–建模方法
•抽象
•分解
•投影
v抽象（Abstraｃtion）
–一方面要求人们只关注重要的信息，忽略次要的内容
•通过强调本质的特征,就减少了问题的复杂性（例如学生模型）
–另一方面也要求人们将认知保留在适当的层次，屏蔽更深层次的细节
•在问题的各元素之间推断出更广泛和更普遍的关系,帮助人们寻找解决方案
v分解（Dｅｃompoｓiｔion／Ｐａrtiｔiｏninｇ）
–“分而治之”
•将单个复杂和难以理解的问题分解成多个相对更容易的子问题，并掌握各子问题之间的联系
–分解的方案往往还能提供问题的解决思路
v投影（Pｒoｊection）
–多视点方法
１８实际的建模过程中要遵循的建模原则？
在建模时,要注意考虑到计划之外的变化:
设计要文档化,只有这样，才能使不熟悉的新手也可以有效地利用设计的方案。
用可视化的模型表达现实世界，有助于理解变化所代表的含义。
在实际的建模过程中要遵循以下建模原则：
•模型是用来沟通的；
•选择创建什么模型对如何解决问题和如何形成解决方案具有深远的影响。
•每种模型可以在不同的精度级别上表示；
•最好的模型是与现实相联系的模型;
•单个模型往往不够充分，对每个重要的系统最好用一组几乎独立的模型去处理.
19需求建模的流程?
先依据获取的问题域信息建立初步的模型。
然后分析用户需求，对模型进行调整,得到一个中间形式的模型形式。
最后，对调整后的模型进行逻辑推理和验证，如果符合预期的期望,那么它就是最终的解决方案模型。
20常见的需求分析技术?
v 结构化技术
–数据建模
•实体关系图ＥnｔitｙRｅｌationshiｐDiagram
–过程建模
•数据流图DataFｌｏwDｉaｇram
•上下文图ConteｘtDiａgｒam
•微规格说明Mini－Spｅciｆicaｔion
•数据字典ＤaｔａDictionary
–行为建模
•状态（转换）图/矩阵State（Ｔranｓitiｏｎ） Ｄiagrａm/Ｍatrix
–过程/数据关系建模
•功能实体矩阵Function/EntityMatrix
–信息工程方法
•功能分解图Funcｔion DecｏmpoｓitiｏnＤｉagｒａm
•过程依赖图ProcessDepeｎｄenｃyＤiａgraｍ
v面向对象技术
–ＵML
•用例图Use-CaｓeDiagram
•类图ＣｌａsｓDiagram
•交互图（顺序图/通信图）Inｔerａction（Sｅｑueｎcｅ／Communicaｔion）Diagrａm
•活动图AcｔivｉｔyＤiaｇrａm
•对象约束语言OｂjeｃtCoｎsｔraiｎtLａnｇｕaｇe
•状态图ＳtaｔeChａrt Diagraｍ
21正确认识UMＬ
（2）（3）（4）
（２）ＵML的准确理解
UＭL是一种语言（Lanｇuagｅ）
实际上UML就是一种表示方法，它不是方法论。
ＵML是一种建模语言（MｏｄelｉngLangｕage）
它不是编程语言，而是建模语言。
它不仅包含软件建模,而且可用于业务建模、流程建模等多种领域.
UML是统一建模语言（UnifiedMｏdeｌiｎgＬａｎguａge）
它是一种标准化的、统一的建模语言,OMＧ认可的工业标准,也是如IＢM、SUN等大型公司认可的事实标准。
（３） 为什么要使用UML
UMＬ是一种统一的、标准化的建模语言，它为参与软件设计和开发的各类人员提供统一的语言，使开发人员能够基于共的模型来理解业务、需求，理解软件及其架构如何构造的。
（4）如何使用UML
UＭL2。
0标准中，共定义了1３种不同的图，这些图的功能以及与UML1．０之间的关系如下表
图名
功能
备注
类图
描述类、类特性及类间关系
UML1。
0原有
对象图
描述一个时间点上系统各个对象的一个快照
UML1.0非正式图
复合结构图
描述类的运行时刻的分解
UML２。
0新增
构件图
描述构件的结构和连接
UML1。
0原有
部署图
描述在各个节点上的部署
UML1．0原有
包图
描述编译时的层次结构
UML1．0非正式图
用例图
描述用户与系统如何交互
ＵML1.0原有
活动图
描述过程行为与并行行为
ＵＭL1。
0原有
状态图
描述事件如何改变对象生命周期
UＭＬ1．０原有
顺序图
描述对象之间的交互、重点在于强调顺序
ＵML１.0原有
通信图
描述对象之间的交互、重点在于连接
ＵML1。
0中的协作图
定时图
描述对象之间的交互、重点在于定时
ＵML2。
0新增
交互概观图
是一种顺序图与活动图的混合
UML2．０新增
如何使用ＵＭＬ-需求阶段一般常采用的图
使用频率
图名
功能
关注要点
主体
用例图
说明角色和使用场景之间的关系
人
活动图
说明业务流程，以及业务活动的步骤
事
顺序图
描述对象之间的交互
物
类图
说明业务实体之间的关系，体现结构规则
物
辅助
构件图
说明主题域划分以及他们之间的服务接口
接口
部署图
描述系统的部署环境,体现设计约束
设计约束
２2 结构化分析遵循的三条原则？
结构化分析遵循的三条基本原则：
分解
抽象
映射
23结构化分析模型的构成元素?
v数据字典（ＤＤ）
–模型核心,包含了所有数据对象的描述的中心库。
vE—Ｒ图（ERD）
–表示数据对象以及相互的关系，用于数据建模。
v数据流图（DFD）
–指明数据在系统中移动时如何被变换;
–描述对数据流进行变换的功能；
–ＤFD中每个功能的描述包含在加工规约（小说明）。
–用于功能建模。
v状态变迁图（STD）
–指明作为外部事件的结果，系统将如何动作.用于行为建模。
２4结构化建模示例—建立计算机售书系统的逻辑模型
（1）通过对现实环境的调查，获得当前系统的物理模型。
（2 ） 去掉具体模型中的非本质因素:
–抽取现实系统的实质，抽象出当前系统的逻辑模型.
（3）分析当前系统与目标系统的差别，建立目标系统的逻辑模型 。
（4）对目标系统的逻辑模型进行细化、改进与优化
（5）需求分析的验证
２５ 数据流图（DFＤ）第９章PPT第2０-69页
v数据流图（DＦD:
DataFloｗDiａgram）就是组织中信息运动的抽象，是信息逻辑系统模型的主要形式.这个模型不涉及硬件、软件、数据结构与文件组织,它与对系统的物理描述无关，只是用一种图形及与此相关的注释来表示系统的逻辑功能,即所开发的系统在信息处理方面要做什么。
v由于图形描述简明、清晰，不涉及到技术细节,所描述的内容是面向用户的,所以即使完全不懂信息技术的用户单位的人员也容易理解。
因此数据流图是系统分析人员与用户之间进行交流的有效手段,也是系统设计（即建立所开发的系统的物理模型）的主要依据之一。
v数据流图脱离系统中的物理因素（如计算机等）,表达出系统对信息的加工情况。
DＦD可以描述原系统/新系统／子系统.
vDＦD是SA的主要工具，它简单、直观，用图形、文字描述系统。
它便于使用、便于交流、便于讨论、便于形成共识，是计算机专业人员和用户单位业务人员的共同语言。
DＦD由四种基本符号组成.如下图所示.
数据流图的构成及基本元素
（1）外部项（外部实体）
源点和终点（又称端点）是系统外的实体，称作外部项。
它们存在于环境之中，与系统有信息交流，从源点到系统的信息叫系统的输入；从系统到终点的信息称系统的输出。
同一个端点可以是人或其它系统。
在DFD中引入源点和终点是为了便于理解系统,所以不需要详细描述它们。
它们可有编号，以“S”开头。
v外部实体
–外部实体是指处于待构建系统之外的人、组织、设备或者其他软件系统,它们不受系统的控制，开发者不能以任何方式操纵它们.
–需要进行建模的外部实体是那些和待构建的软件系统之间存在着数据交互的外部实体，它们是待构建系统的数据源或者数据目的地
–所有的外部实体联合起来构成了软件系统的外部上下文环境
引入外部项是为了划定系统的边界,不需严格定义。
但也要统一编号，而且要与数据字典中的编号相一致。
源点和终点可以在多处出现，用特定符号表示重复的外部项。
为了使ＤＦD清楚易懂，我们对加工、数据流、文件的命名都力求简单。
至于加工的加工逻辑、数据流的数据结构等,将在数据字典中定义。
数据字典和DＦＤ一起来描述系统。
常见的外部项（外部实体）有：
a）从待构建系统中获取数据或者为其提供数据的组织，如:
供货方，销售方等。
b）需要和待构建系统交互的个人，如：
顾客，办事员。
c）需要和待构建系统交换数据的其他软件系统。
（2）加工
v加工又称处理亦称变换，它表示对数据流的操作.
v加工的符号分成上、下两部分，从上到下分别是标识部分和功能描述部分。
v标识部分用于标注加工编号，加工编号应具有唯一性,以标识加工,以“P”开头。
v功能描述部分用来写加工名。
为使DＦD清晰易读，加工名应简单，能概括地说明对数据的加工行为，其详细描述在数据词典中定义。
v加工要逐层分解，以求得分解后的加工功能简单、易于理解。
（3）数据流
数据流由一个或一组确定的数据项组成。
数据流名应能直观地反映数据流的含义。
如产量日报表、汇款单、录取通知书、课程表等。
也可以用一组数据中的主要数据为数据流命名。
例如“考生成绩单’'由考生姓名、成绩、通讯地址等数据组成，但成绩是主要的，所以可用“考生成绩”作为数据流的名字。
数据流应统一编号,编号要与数据字典一致。
数据流经过一个加工后其数据结构/数据含义/数据的顺序一定要有所变化,否则这个加工就没有意义了。
（4）数据存储（文件）
数据存储是用来存贮数据的。
在分层DFＤ中，数据存储一般仅属于某一层或某几层,因此又称数据存储为局部文件。
现对数据存储符号说明如下:
v①数据存储名写在开口的长方框内，应概要地说明文件中的主要数据。
v②数据存储上一定要有数据流.
v③为便于说明和管理，数据存储亦应编号,编号写在文件符号左端小方格中,以“Ｄ”开头.
v④为避免DFD中出现交叉线,同一数据存储可在多处画出。
数据流图的绘制步骤
v
（1）确定所开发的系统的外部项（外部实体）,即系统的数据来源和去处。
v
（2）确定整个系统的输出数据流和输入数据流，把系统作为一个加工环节,画出关联图。
v（3）确定系统的主要信息处理功能，按此将整个系统分解成几个加工环节（子系统）确定每个加工的输出与输入数据流以及与这些加工有关的数据存储。
v（4）根据自顶向下，逐层分解的原则,对上层图中全部或部分加工环节进行分解。
v（5）重复步骤（４）,直到逐层分解结束。
v（6）对图进行检查和合理布局，主要检查分解是否恰当、彻底,ＤＦD中各层是否有遗漏、重复、冲突之处,各层ＤＦD及同层ＤFD之间关系是否合理，及命名、编号是否确切、合理等，对错误与不当之处进行修改。
v（7）和用户进行交流，在用户完全理解数据图的内容的基础上征求用户的意见。
数据流图绘制规则
（１）过程是对数据的处理，必须有输入，也必须有输出，而且输入数据集和输出数据集应该存在差异.
（２）数据流是必须和过程产生关联的,它要么是过程的数据输入,要么是过程的数据输出.
（３）DFD当中所有的对象都应该有一个可以唯一标识自己的名称.
–过程使用动词
–外部实体、数据流和数据存储使用名词
数据流图绘制过程
绘制数据流图的主要原则
v
（1）明确系统边界。
v
（2）自顶向下逐层扩展.
v（3）合理布局。
v（4）数据流图绘制过程，就是系统的逻辑模型的形成过程，必须始终与用户密切接触，详细讨论,不断修改,也要和其他系统建设者共同商讨一求一致意见。
数据流图应用示例—银行取款系统
简单银行取款应用描述
（1）储户将填好的取款单、存折交银行,银行做如下处理:
①审核并查对帐目，将不合格的存折、取款单退回储户，合格的存折、取款单送取款处理。
②处理取款修改帐目，将存折、利息单、结算清单及现金交储户，同时将取款单存档.
画出银行取款处理
升级会员 