发布时间 : 星期三 文章辽工大邱云飞老师需求工程复习资料 - 图文更新完毕开始阅读
好地理解和阐明他们自己的信息需求。
(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 ~