用例和需求

    如果把用例作为需求来编写，那么请谨记以下两点：
    1、用例确实是需求。不必将用例转变成行为需求的其他形式。如果编写恰当，用例可以准确地对系统必须要做什么进行详细的描述。
    2、用例不是所有的需求。用例不详细地描述外部接口、数据格式、业务规则和复杂公式。用例只是需要收集地所有需求中的一部分（可能有1/3），虽然这一部分是非常重要的一部分，但毕竟仅仅是“一部分”。
    任何组织手机需求都是为了满足自身的需要。甚至制定了关于如何描述需求的标准。但在任何一个标准中，用例仅仅是所有需求文档中的一部分。
    下面的需求大纲是比较有用的大纲之一。它是通过对Suzanne Robertson和Atlantic Systems Guild发表在他们的网站和《Managing Requirements》(Robertson和Robertson，1999)一书中的模板修改而来。他们的模板以其完备性而令人生畏，因此将其简化成下面大纲中所示的形式。本书以此模板作为指导方针。就我所见过的大多数项目而言，这个模板仍然过大，因此可以在需求时对它进一步。且不管它的规模如何，其价值在于：它提出了许多有意义的问题，如果没有这个模板，这些问题是不会被发现的。例如，“人们为应对系统崩溃而做的备份是什么？”，“哪些政治因素影响了需求？”。
    需要明白的使：用例并不是全部需求，而只是描述需求中的行为部分，即必需的功能。
    需求大纲：
    第一章 目的和范围
    1a.整体范围和目标是什么？
    1b.项目相关人员（谁关心？）
    1c.什么在范围之内，什么在范围之外？
    第二章 使用的术语/词汇
    第三章 用例
    3a.主执行者及其总体目标
    3b.业务用例（操作概念）
    3c.系统用例
    第四章 采用的技术
    4a.这个系统有什么技术需求
    4b.这个系统会与哪些系统发生交互，其需求是什么？
    第五章 其他需求
    5a.开发过程
    Q1.哪些人是项目参与者？
    Q2.项目的价值反映在哪些方面（简单、及时、迅速或灵活）？
    Q3.用户或出资人希望得到什么反馈或项目可见性？
    Q4.什么是可以买到的，什么是我们必须要创建的，我们在哪些方面是竞争的？
    Q5.还有什么其他的过程需求（如测试、安装等）？
    Q6.项目运行依赖哪些条件？
    5b.业务规则
    5c.性能
    5d.操作、安全、文档
    5e.使用和可用性
    5f.维护和可移植性
    5g.还未解决的问题和推迟解决的问题
    第六章 人工备份、法律性、政治性和组织性问题
    Q1.为系统操作所作的人工备份是什么？
    Q2.有什么法律性和政治性的需求？
    Q3.这个系统完成后对人们的影响是什么？
    Q4.有哪些培训需求？
    Q5.对人类环境有哪些假设和依赖性？