OO系统分析员之路--用例分析系列（8）--如何编写一份完整的UML需求规格说明书[整理重发]

 终于到了快结束的时候了，这将是用例分析系列的最后一篇，结果是得到需求规格说明书，以结束需求分析的过程。经过前面七篇的工作，我们从最初的业务用例获取入手，获得了业务用例模型，这是我们的业务范围；经过分析得到了业务场景，这是我们的业务蓝图；经过规划，得出用例实现视图，这是我们的系统范围；经过再次分析，得到了用例实现以及领域模型，包括用例规约，业务规则和业务数据，这是我们的概念模型。仅从需求所需的必要元素来说，我们基本上已经完成了需求分析的工作。诚如上一篇结尾所说，为了让我们的需求更完美，这一篇所要做的工作也是必不可少的。这一篇将要讨论到的内容包括：用例补充规约，系统原型，以及需求规格说明书

先说说用例补充规约。

之前我们得到的用例规约是功能性的，它们是针对Actor完成目标业务所需的功能性Feature的描述。然而我们所面对的系统除了功能性的Feature之外，总有一些是与业务功能无关的，这部分需求就是补充规约要涉及的内容。

什么样的需求与业务功能无关呢？一般来说，就是系统需求，例如可靠性，可用性，扩展性，易用性等等。用户提出，系统必须提供7*24小时的服务，它应该有一定随业务变化而适应的能力，系统的界面应当简单易学，具备基础计算机知识的人可以不经过培训就能使用它等等。这些需求与具体业务要求无关，哪怕一个不实现，系统也能Run起来。但是这些需求又是如此重要，它们是系统达到用户期望必不可少的。甚至在用户看来，某些补充规约要求比业务要求还重要，某个业务要求没做好，用户或许能宽容，如果你说系统不能提供7*24小时的服务，用户肯定是