如何做需求用例分析-实例

3.1实例：将业务信息从软件需求中剥离

场景1：

他说：“我希望系统会很快。”
您说：“当然。”
他说：“而且使用起来很方便。”
您说：“我明白。”
他说：“所有的文档应该被集中存放在一起，就好像我们在地下室中的档案文件。”
您说：“好的。”
他说：“我们要求每一位员工在登录和注销时都签署一张卡片。但同时我们也必须遵守最近颁布的某某指导原则。”
您说：“可以。”（记录下来）

 

尽管为捕获需求所付出的努力比起记录这些需求的方式要重要的多，但是一位业务信息分析师或者需求工程师仍然要记录、归纳和总结关于这个项目的各种需求。在先启阶段通常以某种迭代的方式进行，在这期间，新的需求呈现出来，已经存在的需求则转化为某种我们所期望的类型和结构。在与用户进行有关需求的谈判（沟通）期间，我们经常会发现先前捕获的需求信息并不重要甚至已经不复存在，而一些新的需求则在这个过程中显现出来。

如何进行取舍？

1，  需求之间是否有矛盾？

2，  理由是否充分？是否有利于问题的解决？

 

 

3.2实例：将业务信息从软件需求中剥离—如何判断这些客户需求哪些与业务需要相关？哪些与软件功能相关？

       弄清需求类型的词汇

       与涉众讨论需求类型中的相互依赖性

       记录混杂在一起的不同需求的实例和指导方针

 

       业务需求（BR）是关于业务行为的陈述。

       软件需求（也称功能需求SR）关注的是“系统应该……（做什么）。”

       软件需求通常描述已经存在的或是未来的软件系统，并且应该与业务需求同步。

 

软件需求清晰地与业务需求区分开来，两者都受到过程改进机会和自动控制的影响。

 

 

3.3实例：将业务信息从软件需求中剥离—如何识别软件需求与业务需求

 

       场景1：办公自动化

计算机能够快速的完成大多数工作，在很多情况下，它们比起人工操作更加高效和可靠。更不用说它们可以不停歇的一直工作，以及在危险恶劣的环境中工作了。因此，我们试图将尽可能多的日常工作委派给计算机及其系统来完成。

例如，我们当中的许多人都使用一种时间管理系统来记录我们的工作时间。在得到时间之后，我们进入一个自动化的许可进程。即使整个进程都是电子化的，我们仍然使用“时间表单”或“工作表单”这样的称谓。通过互联网访问这个文档要远远快于在某组织某部门中寻找到那张纸制的时间表单。在这个例子中，业务需求（记录和批准时间表单）已经转换为软件需求，纸张处理过程已经被电子处理过程所取代。

 

       场景2：手工办公的需求

对于一家人寿保险公司来说，评估赔偿风险可能完全基于保险商的主观经验。并不是所有的业务需求都已被数字化了，手工处理可能会与计算机技术共同存在。在这个例子中，计算机系统将得到风险估价的结果，而不是真正进行风险估价的操作，保险商将会继续操作这些业务需求（评估风险），而系统只是记录保险商的决定。

 

 

       场景3：提高办公能力

不仅计算机系统可以取代一些活动，信息技术也可以为组织机构提供一些管理业务的新方法。例如，出纳员将产品的价格输入终端机和后台系统的方法就是一种由于条形码和扫描仪的发明而带来的新方法。在交易的最后合计价格，这种对于夫妻店仍然行之有效的业务需求，现在可以通过与扫描仪和条形码技术相关的软件需求来执行。

 

3.4实例：将业务信息从软件需求中剥离—基于业务规则（BRULE）的用例的粒度

 

场景1：开发一个自动取款机系统。

       SR1：系统根据指定数额从账户中提取现金，但是一天内最多只能取1000美元。

       SR2：系统根据指定数额从账户中提取现金，但是一天内最多只能取三次。

         我们面对两种需求结合在一起的挑战。在SR1中，“系统根据指定数额从账户中提取现金”是一种软件需求，但是最高金额为1000美元使这种陈述复杂化了。

       SR3：系统根据指定数额从账户中提取现金，但是取款后不能导致余额为负数  

 

 

       SR1：系统根据指定数额从账户中提取现金。

n  BRULE1：一天内最多只能取1000美元（24小时营业）。

n  BRULE2：一天内最多只能取三次（24小时营业）。

n  BRULE3：账户余额必须大于零

 

 

 

3.5实例：将业务信息从软件需求中剥离—规则被打破的“对策”

 

       沟通业务规则只是事情的一部分，另一部分就是“对策”，它是指一旦初始的业务规则遭到破坏（假定的情节）所需要强制采取的措施。例如，如果有人试图在24小时内第四次取款，系统应该作出何种反应？如果某种业务规则由于另外一套业务规则而遭到破坏，交易又该如何反应呢？如果交易需要将这条业务规则整合到软件之中，就必须作出规定，例如：

       BR4：在多于三次从24小时服务窗口取款之后，账户将被冻结。

 

 

3.6实例：将业务信息从软件需求中剥离—非功能需求

非功能需求（NFRs）往往以“系统应该是……”这样的短语开始，紧接着使用“快速”、“易于使用”、“直观好学”等形容词，它们经常同其他需求类型混在一起。传统意义上，非功能需求适用于整个系统，例如“系统应该是用128位加密码保障安全性的”或者“系统应当提供两秒钟的反应时间”等等。但是，情况并非总是如此。

 

场景1：应该可以轻易地看到保险政策的历史

n  功能性（历史）同非功能性（易于使用）混杂在一起。

n  “易于”是一个主观的概念，是无法详细描述的。

       SR1：系统应当捕获所有政策变化的历史信息。

       NFR1:政策的历史应当很容易被找回。

  品质（鼠标点击数）：
容易 - 0次
可以 - 1次
不容易 - 2次或者更多

 

当非功能性需求的陈述包含词语“必须”时，通常是表明一个或更多的约束适用于整个系统；例如，遵守指导方针、法律或者行业规范。约束应当被从其他需求类型中分离出来，同其他类型的非功能需求一样被来区别对待。

       C1：系统必须遵守某某管理法令。

       C2：系统必须能够容忍故障发生。
   （品质：系统崩溃次数/星期）
   非常好：0-1
   可以接受：2-5
   不可接受：>5

 

 

3.7实例：将业务信息从软件需求中剥离—用例设计实例

 

场景：顾客登记

1.当顾客进入大厅时用例开始。

2.前台服务员询问顾客想要的房间类型。

3.顾客告知前台服务员想要的房间类型。

4.前台核对记录后为顾客提供一间房间。

5.顾客决定住进这间房间。

6.前台服务员请顾客出示驾照并询问其付款方式。

7.顾客出示驾照并用信用卡付款。

8.前台服务员将顾客信息记录到日历本上，并批准该信用卡在信用卡终端设备上使用。

9.信用卡终端设备允许该信用卡的使用。

10.前台服务员得到房间钥匙。

11.前台服务员将证件、信用卡以及房间钥匙一并还给顾客。

12.顾客获得房间的相关信息并拿着钥匙离开。

 

 

系统边界轮廓以及用例发展的用例表草图

 

 

 

用例分析

 

       我们再看一看上面例子中的第11步：“在顾客入住期间系统冻结这所房间，并且将顾客同该房间联系起来。”

n  正如我们前面的例子那样，一旦我们将软件需求同与其相关的业务规则之间的需求陈述分割开来，我们就能在用例描述中分离各个步骤，并将它们标记为系统中的各自独立的需求。这种新的流程如下所示：

n  11. 系统在顾客入住期间将该房间标记为已被占用。

n  12. 系统将顾客同该房间联系起来。

n  将用例的一个步骤切分为这样两个步骤可以使两种需求彼此独立开来。它们可以被分别的验证和确认，并且能够被更容易的追踪完成。

       第五步，我们从未阐明可提供的这个词语的确切含义。这个特定的旅馆可能有这样的业务规则，那就是可提供的就是特指同一档价位的房间，可连续居住（不用中途换房），或者在请求期间的所有类型的房间。这种指明了可提供性的选定的业务规则就可以同用例流程中的某一步骤联系起来，并为软件工程师在设计房间可提供性时提供了一个精确的答案 。

 

进一步用例分析

 

       当我们看到纯手工的操作例如家务管理时，就更容易发现自动控制和业务流程的改进机会。在新房间被租用之前（见图七中的第四步），房间的可用性需要被通知给前台。报告这一情况可以有不同的方式。

       例如，清扫人员可以1）拿一张清单，并在他们轮班之后将其交到前台，或者 2）他们可以在房间清扫干净之后打电话给前台。交清单方式的缺点是速度缓慢，前台将无法在第一时间得到相关信息。而第二种方法的缺点是增加了前台的工作量，影响到前台与顾客的面对面交流。

       还有第三种解决方案，它不再把房间信息的更新工作委派给前台服务员和清扫人员，一种新的“确认房间占用”业务用例的步骤C。

n  用例：“确认房间占用”

n  清扫人员从房间中呼叫电话系统。

n  清扫人员输入一段代码通知系统该房间已被清扫完毕。

n  电话系统将更新的信息传送给前台信息系统。

 

实例：将业务信息从软件需求中剥离—总结

 

需求用例分析给我们提供了一种认识世界的方法的训练的具体时间实践。（厘清目标，直面困难，调整心态，制定计划，运用技巧实现，评估结果）