需求和用例

本文主要介绍以下几个方面的内容，需求类型和用例，以下内容是上课所讲的一些比较有价值的内容，以便后期的回顾。

一，需求

需求是一个项目必须具有的功能和所需要满足的条件。它是软件项目的主要挑战之一，据调查37%的软件问题是由需求导致的，一个软件开发的功能中30%的功能几乎没怎么用过，19%的功能很少用，只用%7的功能一直在用，其他的功能则是有时在用或经常用。这种发现，给我们软件开发带来了启发，以前传统的瀑布模型是将整个需求分析完之后再开发，而现在则是先解决主要矛盾，进行迭代开发，将用户一直会使用的需求中的7%先开发完。

需求类型（FURPS+）：

• 功能性（Funcational）
  如安全，功能，特征。
• 可用性（Usability）
  对用户来说，高效，易学，好用。
• 可靠性（Reliability）
  系统提供服务的稳定性。
• 性能（Performance）
  响应时间，资源的使用率
• 可支持性(Supportability)
  可维护的，可配置，可国际化
• 辅助需求（+）
  资源，语言，硬件的限制等辅助需求。

在软件开发过程中有哪些方式来分析需求了？
首先，我们讨论的需求是系统需求，它主要分为功能性需求和非功能需求，对于功能性需求，一般使用用例模型，而非功能性需求使用补充说明的方式。

---

二，用例

用例的几种定义：

• 站在用户角度定义软件系统的外部特征。
• 可表示系统所提供的服务或可执行的某种行为。
• 用例是一种把现实世界的需求捕获下来的方法。
• 就是一组相关的成功和失败场景（参与者和系统之间的一系列特定的活动和交换，也称用例实例）集合，用来描述参与者如何使用系统实现其目标。

总之，就是从用户的角度（系统的外部）观察到得系统的行为（使用系统的过程或和系统交互的过程）

用例特征：

• 用例都是相对独立的。这就是说，它不需要与其他用例交互就可以独自完成参与者的目的。也就是从功能上来说是相对比较独立的。一个用例从本质上说，体现了参与者的愿望，不能完整表达参与者愿望的不能称为用例。比如说，创建项目这是一个用例，但是在创建项目的过程中有选择分类这个步骤，那么选择分类就不能称为一个用例，因为如果不创建项目，是不需要选择分类的。选择分类只是创建项目的一个步骤，不创建项目，选择分类对用户来说，没有任何意义。因为选择分类不能单独存在，不具备相对独立性，所以不是一个用例。

• 第二 用例的执行结果对参与者来说是可观测的和有意义的。比如，后台有个日志记录程序，专门记录指定模块的操作日志，虽然它是个系统必须的组成部分，但是它在需求阶段却不应该作为用例出现。因为这只是一个后台程序，对参与者来说，是不可观测的，它只是一个系统需求在补充规约中定义，而不是一个单独的用例。又比如说，取钱是一个用例，但是输入密码却不是，很好理解，因为单纯输入密码是没有任何意义的，没有一个人专门去输入密码，而不进行任何业务操作。

• 第三 任何用例必须有一个参与者执行。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另外一个用例。如果你画出的用例模型中发现某个用例没有参与者，这时你就应该注意了，好好检查下用例的识别是否有问题。可以根据用例的这些基本特征来识别。

• 第四 用例必然是以动宾短语形式出现的。比如录入报表数据这是一个用例，但是录入和报表单独都不是一个用例，因为用例都是参与者可以执行的，参与者能执行录入吗？没有录入的对象显然不行，同样只有报表数据，也不是一个用例，因为参与者不知道要对报表数据做什么，打印报表数据，还是录入报表数据，还是统计报表数据，不清楚。其实这个特征对用例识别时很有帮助的。而且，要记住，用例的名称要严格用动宾结构的短语命名，有这样的经历，有的需求分析员，他对用例的识别时正确的，但是他命名不标准，常用统计，记录这些单独的动词命名用例，虽然意思他自己明白，但是别人不一定可以看明白，对看文档的读者造成理解上的困难。

业务用例与系统用例的区别：
业务用例就是要完成的业务，系统用例是系统要做的事情，在业务用例模型中，业务角色代表企业外的角色，业务员工代表企业内的角色。例如对于商店来说顾客就是它的业务角色，而售货员就是它的业务员工。
业务用例是用例思想的延续，只是改变了使用场合。用例是从使用者的角度定义“软件系统”需求。而业务用例不研究“软件系统”需求，它更关心一个“业务组织”对外提供哪些服务。如住房公积金中心是一个业务组织，你或许就是一个业务参与者（如果你准备向住房公积金贷款）。那么办理住房公积金贷款就是一个业务用例。这个业务用例会描述什么呢？它会描述类似如下内容(由于内容复杂仅作示意)：

• 职工准备相关资料去住房公积金中心办理货款。业务用例开始。
• 职工向中心提交准备贷款的相关资料，中心工作人员对资料进行初审。
• 若审核通过，职工准备办理抵押合同，中心工作人员委托担保公司与职工签订抵押合同。
• 担保办理完成后，职工与中心签订理借款合同，中心工作人员要求职工办理银行卡并提供卡号。
• 借款合同签订后，中心工作人员要求贷款合同必须办理公证，职工与中心一道办理公证。
• 职工办理完公证后，中心发放贷款。业务用例结束。

可见，此处的业务用例描述的是业务参与者（职工）如何使用业务组织（中心）提供的服务的过程。因此业务用例实际上是一种业务流程。它以业务组织外部业务参与者的角度定义业务组织提供的服务。当然业务用例还包括一些内部流程，它可能不是由业务参与者启动的，如采购流程等。因此，业务用例只是使用了用例的思想和形式而已，研究的主题是完全不同的。用例研究软件系统，借助用例定义软件系统需求。而业务用例研究一个目标组织，借助业务用例定义目标组织应该具有哪些业务流程，以及这些流程应该是什么样子的。

用例与功能的区别：
功能的特点：

• 功能是脱离使用者愿望存在的
• 功能是孤立的－－只要按下开关就亮灯
• 如果非用从功能的角度解释用例，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场景，这些“功能”体现不同的组合方式

两种常见的误区：

• 用例就是功能点
  这是一个很大的误区，也是技术人员容易犯的一个错误。功能点是站在软件开发的角度来说的，而用例是站在用户的角度来说的。获取用例是领域专家干的活，而最后的功能实现是技术专家干的活，不同的角色。所以获取用例的关键就是要站在用户角度看问题。
  怎么获得用例？首先确定位于系统边界之外的主角是谁？他的期望和目的是什么？这个期望和回报要求在系统之内。所以，用例是帮助确定系统边界的一个好方法。用例也是获取需求的一个方法。
• 用例和步骤混淆
  举例来说，用户输入密码，要有密码错误提示，并且三次错误自动锁定用户，最后登录成功。“输入密码”是一个步骤，不是用例。整个过程是一个用例：“用户登录”。中间步骤和场景可以有很多。比如输入密码是一个步骤；“要有密码错误提示”这是一个业务需求，不是用例；“并且三次错误自动锁定用户”这是一个业务需求，也不是用例。
  用例的特征：有目的，有用户期望，有回报预期。当结果不可定义或不清晰时不能用Use Cases，意思是如果目标成功或目标失败不能有一个明确的定义，那就不是一个用例。举例来说，用户输入密码，这是不是一个用例？用户输入密码的目的是什么？是为了输入密码吗？不是的，是为了登录系统，所以，用户登录是一个用例。