需求工程-软件建模与分析Word下载.docx

需求工程-软件建模与分析Word下载.docx

《需求工程-软件建模与分析Word下载.docx》由会员分享，可在线阅读，更多相关《需求工程-软件建模与分析Word下载.docx（29页珍藏版）》请在冰豆网上搜索。

原因的分类前先进行头脑风暴（一个人提，大家批），不然

思考问题的范围就会受到限制。

支持者需要引导和鼓励参与

者参与其中。

C确定问题类型

对头脑风暴的结果进行整理，确定出主要的原因类型。

一般来说，划分出来的问题不要少于2类，不要超过6类

（经验数值，仅供参考）。

经常使用的类型有：

人、设备、

材料、环境、方法、过程等。

将这些类型补充到鱼骨图上。

D分配原因

将头脑风暴中得出的潜在原因放在鱼骨图上，并且确保每

一项原因都归于适当的类别中。

如果原因看起来可以放在多个

类别中，就表示是多重原因造成的问题。

但如果多次出现多重

原因，可能就以为着分类存在问题。

该阶段将形成最终的鱼骨图

E分析根本原因

对鱼骨图中罗列出来的所有潜在原因进行分析。

分析出

造成某一结果的最根本原因是什么？

找出核心所在。

方法如下：

通过参与者之间的公开讨论来分享看法和经验；

寻找重复的原因，或者与特定类有关的原因的数量；

使用检查表收集资料、制造流程图或者进行用户调查，

通过帕累托分析法测试各种原因的相对强度；

投票（真理多数情况下掌握在多数人手里）

帕累托图

在通过使用鱼骨图完成问题原因的定性描述后。

仍然存在一个

问题，就是根本原因的辨识需要有经验的决策者确定，或者根

据人类固有经验（少数服从多数）确定。

更好地方法是能够开

展定量分析。

帕累托分析可以帮助我们做出这样的定量分析。

帕累托分析应用就是根据鱼骨图分析的结果，通过收集相关统计

资料，通过直方图的方式显示问题的相对频度或者大小高低等定

量结果。

A确定问题和相关原因

利用鱼骨图的结果。

B收集数据

有针对性第收集数据。

例如上例中，我们可以抽取一些

废品，分析这些废品产生的原因

C绘制直方图

4上下文图画法步骤？

在绘制上下文关系图时应该采用以下步骤：

1、首先用一个矩形表示系统，写上系统的名称，将整个系统看做一个黑盒子；

2、然后找到该系统的所有Customer（客户），考虑这些Customer会发起什么事件，这些事件会引发Worker（内部工作人员）的什么工作，将这些序列逐一表示出来；

3、最后在看看系统的每个Worker还有没有一些主动发起的事件。

（Customer：

也就是该主题域的客户，它处于该主题域的外部。

如，对于体检业务子系统而言，体检者显然就是一类客户，除此之外，客服中心、物资部门、财务部门的工作人员也是这个主题域的Customer。

Worker：

也就是该主题域的工作人员，它处于该主题域的内部。

如，服务中心，体检科室，综合科的工作人员都是其Worker。

关键要点在于“针对本主题域”而言。

）

5需求获取的主要活动

研究应用背景，建立初始的知识框架；

根据获取的需要，采用必要的获取方法和技巧；

先行确定获取的内容和主题，设定场景；

分析用户的高（深）层目标，理解用户的意图；

进行涉众分析，针对涉众的特点开展工作。

6需求协商的几条法则的应用？

差异问题协调法则：

不同的业务层面（有时即使是相同业务层面）的用户对同样的概念或者流程

有不同的认识和理解，会出现一些差异，在需求整理时应该将这些差异明确

标识出来，并展示给用户高层管理人员，由他们来确定如何消除这些差异，

并将这些情况记录。

消除变更问题协调法则：

上面法则提到的问题，从消除变更的角度考虑仍然存在问题。

仅仅将差异标

识并展示给高层并不能消除变更的可能，应该考虑这些差异形成背后的问题，

应该从开发角度考虑如何消除这些差异，并提供给高层管理人员。

要有主动性

需求协商时机法则：

不要在需求冻结前开展需求协商工作。

需求协商应该在

需求获取过程中不断开展，出现就考虑消除。

如果都等到冻结前，将所有矛

盾集中体现对工作是非常不利的。

实例：

W公司开发的信息系统到了需求冻结前夕，A建立拿出厚厚一本需求

协商底稿，分为重点差异协调部分，一般差异协调部分，已协调差异列表。

结果用户高层非常不满，认为这些工作需要大量时间难以短期完成。

7需求获取的主要方法

用户访谈

用户调查

文档分析

原型法（情节串联板）

模型驱动的方法

8开放式话题与封闭式话题运用

开放式话题

v优点：

–让被会见者感到自在；

–会见者可以收集被会见者使用的词汇，这能反应他的教育、价值标准、态度和信念；

–提供丰富的细节；

–对没采用的进一步的提问有启迪作用；

–让被会见者更感兴趣；

–容许更多的自发性；

–会见者可以在没有太多准备的情况下进行面谈。

v缺点：

–提此类问题可能会产生太多不相干的细节；

–面谈可能失控；

–开放式的回答会花费大量的时间才能获得有用的信息量；

–可能会使会见者看上去没有准备

封闭式话题

–节省时间；

–切中要点；

–保持对面谈的控制；

–快速探讨大范围问题；

–得到贴切的数据

–使得被会见者厌烦；

–得不到丰富的细节；

–出于上述原因，失去主要思想；

–不能建立和面谈者的友好关系。

9用户访谈时问题组织的三种方式及特点？

金字塔结构

v如果会见者认为被会见者需要对话题进行预热，可以采用金字塔结构，通过逐步的引导来使得被会见者打开话匣子。

v如果会见者发现自己事先对事实的确认存在较大偏差或者被会见者看上去不情愿讨论这个话题，也可以采用金字塔结构。

v当想结束讨论这个话题的时候，使用金字塔结构的提问顺序也是有用的。

漏斗结构

v漏斗结构为开始一场面谈提供了一种容易而轻松的途径。

v当被会见者对这个话题有情绪，并且需要自由表达这些情绪的时候，需要采用漏斗型提问顺序。

v或者在会见者事先对事实了解不多时，也应该采用漏斗结构的问题组织方式。

v用这种方式组织面谈能得出很多的详细信息，以至于没有必要使用长序列的受限制问题和调查问题。

菱形结构

v使用菱形结构的主要优点是通过各种各样的问题保持被会见者的兴趣和注意力。

一旦掌握了如何在正确的时间问正确的问题，就可以多样地选择问题的顺序。

10市场调查和需求获取在访谈与调查顺序上有何不同?

原因何在？

一般来说，在开展市场调查时，由于很难深入接触到潜在的用户。

所以

总是先调查，后访谈。

而在需求获取时，通常采用的策略是先访谈，后调查。

其实原因在于市场调查与需求获取有不同的应用背景。

一般市场调查通常

用于验证潜在客户对产品的接受程度。

而需求获取的目标是要理解客户需要解

决的问题。

也就是说需求获取时你往往还没有产品，信息不够充分，所以很难设计出

有效的调查问卷。

11采用原型方法的三个目的？

明确并完善需求

原型作为一种需求工具，它是对部分系统的初步实现，因为我们尚没有很好地了解该系统。

研究设计选择方案

原型作为一种设计工具，涉众可以用它研究不同的用户交互技术，优化系统易用性，并评估可能的技术方案。

发展为最终产品

原型作为一种构造工具，是产品一个最初子集的完整功能实现。

12用例描述方法

13需求关系的根本任务是什么？

需求分析是软件需求中最核心的工作，需求建模是需求分析

的主要手段。

需求分析是软件定义时期的最后一个阶段，它的基本任务是

准确地回答“系统必须做什么?

”这个问题。

需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些

工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

需求分析根本任务：

建立分析模型，创建解决方案。

14需求分析任务中分解策略主要包含那几种？

每种策略分别适合应用于那些系统的开发

1）业务流程为主线的分解策略；

业务流程为主线的分解策略是目前比较流行的方法，主要按照

“业务”的角度考虑分解方法。

此方法特别适合联机事务处理系

统、管理信息系统（MIS）。

目标系统-》主题域的分解依据是“目标决定范围”；

主题域-》业务事件所做的是理清业务脉络；

业务事件-》业务活动所做的是填充细节；

业务活动-》业务步骤所做的是细化和确认工作。

2）程序结构为主线的分解策略；

方法是需求分析最常用的分解方法。

当由于其过早进入程序结

构，割裂了与问题域之间的联系，从而容易导致对问题域研究的

不足，降低了需求的质量。

目前认为此种方法仅适合于问题域比

较清晰，问题不算复杂的情况，例如工具软件、嵌入式系统等。

3）基于场景的分解策略；

对于决策支持系统、面向用户的嵌入式系统等来说，决策场景、

使用场景是主要的线索。

向上可以总结成一类相似的集合，再

总结成一系列的关注点或者功能域，向下可以分解成具体的步骤

或者操作任务。

4）基于数据的分解策略等。

上述分解策略都是从“业务”角度来组织。

但对于类似数据仓库

之类的数据类项目，业务线索并不是十分明显，或者并不重要

这是就需要以数据为主的分解策略。

其中主题域仍然与“业务

流程为主的分解策略”类似。

而主题类是企业中的高层实体，

主要由一组企业的逻辑数据类来表示，而企业的逻辑数据类在

实现时又会对应于多个物理数据类。

15需求分析中分解与提炼的比较？

分解是一种自顶向下的方法，当按照任何一种线索进行分解时。

就会破坏其它线索的完整性。

例如，如果以“业务”为线索，就会发现数据需求分解后会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。

此种情况出现时，可能会影响需求分析人员建立全面的理解，因此需要采用自底向上的方法进行提炼。

例如将每个业务事件中的类进行提炼，抽取出共性的部分，建立针对整个系统的全局领域模型。

16构建分析模型的目的？

1将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征

2和用户达成对信息内容的共同理解

3分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息

17分析模型的建模方法？

v模型

–“模型是对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解”

–集中关注问题的计算特性（数据、功能、规则等等）

–“它是对系统进行思考和推理的一种方式。

建模的目标是建立系统的一个表示，这个表示以精确一致的方式描述系统，使得系统的使用更加容易”

–建模方法

•抽象

•分解

•投影

v抽象（Abstraction）

–一方面要求人们只关注重要的信息，忽略次要的内容

•通过强调本质的特征，就减少了问题的复杂性（例如学生模型）

–另一方面也要求人们将认知保留在适当的层次，屏蔽更深层次的细节

•在问题的各