辽工大邱云飞老师需求工程复习资料 - 图文 下载本文

好地理解和阐明他们自己的信息需求。

(3) 用一段话向Flo Chart建议:一个具备原型特征的交互式Web站点缘何能解决Flo关于捕获用户信息需求的问题。

解答:(1)答案主题

(1)根据需要确定原型类型;(2)进行原型开发;(3)获得用户反馈;

(4)定义所得需求

(2)答案要以“隐含知识”和“用户表述时的主观加工”为主题

(3)原型化方法利用直观化的界面来最快程度的得到用户的反馈,通过

用户的反馈 来获知其实际的需求

2. “我有一个绝妙的主意!”Bea Kwicke宣布,他是系统团队的一位新来的需

求工程师,“让我们跳过所有的SDLC垃圾,直接为一切设计原型。我们的项目会进展的更快,还可以节省时间和金钱,并且所有的用户会感到我们似乎很在意他们,而不是连续几个月不与他们交谈。”

(4) 列出你(作为与Bea同一个团队的成员)用来劝阻她不要试图放弃

SDLC,而直接为所有项目设计原型的原因。

(5) Bea对你所说的话很失望。为了鼓励她,用一段话向她说明,你认为

适用于原型化方法的情形。

解答:(1)主要原因:原型仅仅是开发当中使用的一种手段,它利用得当可以加速开发的进程,但不能代替软件开发中的所有工作。

原型开发最大的缺点就是:成本太高,高的让人难以接受。所以原型

方法只在必要的时候使用原型方法。通常来说,如果用户需求出现了模糊,不清晰,不完整等具有一定不确定性的特征,就可以考虑使用原型方法。

原型方法的复杂性使得它会给项目引入了新的风险。

(2)情形见下表,尤其是其中红色的部分 废弃型 演化型 阐明并细化用例和功能性需实现核心用例 求 水平型 根据优先级实现其他用例 识别遗漏功能 使得系统适应快速变化的需要 研究用户界面方法 实现并扩充核心功能 实现并扩充核心算法 测试并调整性能 垂直型 演示系统可行性 用户需求出现了模糊,不清晰,不完整等一定不确定性的特征,就可以使用原型。 如果开始是以缺陷需求为起始点,需要不断调整的情况,就可以使用探索式原型开发

如果开始拥有清晰地用户需求,但是开发者对这些需求的实现方法,实现效果和可行性没有太大的把握,则可以使用实验式原型的方法

如果开始有清晰的需求也有项目积累下来的原型资产,这样的情况可以使用演化式原型开发

~ 17 ~

3. Itall多年来一直担任Tun-L-Vision公司的系统分析员。在你加入该系统分

析团队以后,建议在目前项目中把原型化方法作为SDLC的一部分,Itall说:“当然可以,但是你不能太在意用户所说的话。他们也不知道自己需要什么。我会做原型化工作,但是我不会‘观察’任何用户。” (1) 在不明确否决Itall的前提下,尽可能巧妙地说明原型化过程中观察用户反应、用户建议和用户创新的重要性的原因。

(2) 用一段话描述,如果系统的某部分已经被原型化,并且在后续系统中没有考虑用户的反馈信息,可能会出现什么情况?

解答:原型只是手段,目的是为了验证系统功能,所以为了修正原型,要观察用户反应、用户建议和用户创新的重要性 用户不满意,延期改进,功能过于简单,默认知识等

解答:(1)通过观察用户的反应会得到比较多的信息,比如说观察到用户总是出错则说明设计有问题,用户在某个界面停留很久这就说明软件的导航有问题,通过观察发现用户老是从一个位置移到另一个位置,说明界面中按钮放置的有问题,有的时候用户使用的方式超出了我们的想象(用户创新),像这些都要通过观察得到。在评估中,用户会对原型系统的人机教会和功能设置提出建议,这些建议可以帮助开发者们改进,改变或调整原型,从来可以是原型更接近于它的目标实现。对于用户的创新则是用户潜在的需求,这些可以通过观察还有用户的反馈中得到,做到以上,我们可以获得很多信息,使我们的原型更加完善。 (2)如果系统的某部分已经被原型化,但是在后续系统中没有考虑用户的反馈信息,这个原形都不能算是一个符合要求的原型。这样会导致开出来的原型根本就不符合用户需求,开发出来以后用户不满意可能会受到用户的抵制。可能在后期才被发现,开发方需要做很大的调整修改,导致项目延期,严重者可能会导致项目的失败。

4. Nordic Designs 是一家专营Scandinavia 当代家具的连锁企业,它已经发

布了一则夸耀其配送信息系统原型的公司简讯。简讯报道声称:“我们的配送信息系统原型一发布就投入使用了。绝对没有任何修改的必要,经理们说它是追踪家具配送的最佳解决方案。不久就可以你们商店中接触原型了。” (1) 这则报道的作者对原型化方法概念明显存在什么样的误解?用一段话解释它。

原型的目的,原型是为了在最终物件之前,避免特殊性,不是为了投入使用,也不是为了不修改

(2) 如果用户期望原型“绝对没有任何修改的必要”的话,列出原型设计者可能会面临的问题。

解答:(1)这则报道中提到“我们的配送信息系统原型一发布就投入使用了”

~ 18 ~

可以看出作者误解了一点:开发出的原型不是最终的软件,原型不能直接发布使用,我们使用原型的目的是获取需求的内容,而不是获取原型的代码,原型代码最终应该是会被抛弃的。作者还说“绝对没有修改的必要”这句话显然有问题,原型开发的过程中腰不断地根据评估者反馈的不足进行原型的修改,调整完后还要准备再次原型评估,如果不能通过,则在根据反馈,观察进行原型修正,所以不能说“绝对没有任何修改的必要”。

(2)首先原型是本来就是用来获取需求的,最终代码一定要被抛弃,不然开发出来的软件质量会很差。 如果用户期望原型“绝对没有修改的必要”的话,也就是说一次就获取完需求,显然这样的方法是不可行的,不能获取到完整明确的需求,这样会导致配送系统漏洞多,不能满足用户的需求,不受用户的欢迎甚至抵制,严重的可能影响到业务 花费大力气在原型上,时间花费过大

第9章 需求获取方法之观察与文档审查

复习题

1. 情境性事件。定义,特性。解决方法。

情境性事件,是指某些事件只有和它们发生时的具体环境联系起来,才能得到合理的理解。对于此类事件,需要将它们放在发生时的情景中进行解释,才能明确其意图。

? 突现性——并发突现 ? 局部性——此地 ? 暂时性——此时 ? 涉身性——此人 ? 开放性——开放外延

? 模糊性——无法精确定义,基于潜知识

解决:

? 理解复杂的系统事件 ? 获取工作中的异常处理

? 获取与用户认知不一致的实际知识 ? 了解用户认知 ? 获取潜知识

2. 采样观察的两种方法;优缺点. 时间采样(随机性) 通过随机的观察减少偏差 对频繁发生事件取代表性事件进行观察 事件采样 (流程性) 允许在行为展开过程中观察 允许对指定的重要事件进行观察 优点 ~ 19 ~

缺点 用分段的方式来收集数据不能提供全面信息的时间 漏掉不经常发生却很重要的事件 发现异常流程 验证用户知识和实际工作的一致性 消耗大量时间 漏掉频繁发生事件的代表性样本 获取默认知识 验证用户知识和实际工作的一致性 适用情景 案例题

1. “我知道你有很多材料。那些材料里到底有什么?”Betty Kant问道,她是MIS特别工作组的负责人。MIS特别工作组是你的系统团队联络Sawder家具公司的桥梁。你拖了一大堆材料,正准备离开这栋楼。

“哦,是过去6个月的一些财政决算、生产报表,还有Sharon给我的一些业绩报表,业绩报表涵盖了过去6个月的目标和工作业绩。”你在回答时,有些纸掉到了地上,“你为什么问这个问题呢?”

Betty为你拾起纸并把它放到最近的桌子上,回答道:“因为你根本不需要这些垃圾。你来这里要做一件事情,就是和我们这些用户谈话。从这些材料中得不到任何有益的信息。”

(1) 只有告诉Betty你从每份文档中找到的东西才能使她相信每份文档都是

重要的。用一段文字解释文档为需求工程师提供了什么帮助? 二玉哥哥语:看看书上 文档采样 那部分就知道了 参考答案:

不同的文档为需求工程师提供了不同的帮助,譬如:

? 需求规格说明书:帮助需求工程师发现需求信息,从而进行需求的

重用

? 硬数据:通过研究和阅读也可以发现需求的相关信息 ? 客户的续修文档:可以得到粗粒度的需求 通过分析这些文档,可以获取组织业务的问题域信息、业务工作流程的业务细节中存在的问题等。一个有经验的需求工程师会从现有的文档中获取事实,理解问题域。 文档类型 文档审查方法 描述 相关产品的需求规格说明 需求重用 分析相关产品的规格说明,发现可以移植到到新产品中的需求信息,进行需求的重用 问题域信息 用户界面特征 业务需求、组织策略、政策法规 ~ 20 ~