3. 系统需求

　　RUP中根据FURPS+模型将系统需求分为以下几类：

　　功能(Functionality)

　　可用性(Usability)

　　可靠性(Reliability)

　　性能(Performance)

　　可支持性(Supportability)

　　设计约束等

　　除了第一项功能性需求之外的其他需求都归之为非功能性需求。

　　3.1 需求工件集

　　用例模型主要用于描述系统的功能性需求，对于其他的非功能性需要用其他文档来记录。RUP中定义了如下的需求工件集合。

　　用例模型：记录功能性需求

　　用例图：描述参与者和用例之间的关系

　　用例规约：描述每一个用例的细节信息

　　补充规约：记录一些全局性的功能需求、非功能性需求和设计约束等

　　词汇表：记录一些系统需求相关的术语

　　在实际应用中，除了这些工件之外，我们还可以根据实际需求灵活选用其他形式的文档来补充说明需求。并不是所有的系统需求都适保合用用例模型来描述的，如编译器，我们很难用用例方法来表述它所处理的语言的方法规则，在这种情况下，采用传统的BNF范式来表述更加合适一些。在电信软件行业中，很多电信标准都是采用SDL语言来描述的，我们也不必用UML来改写这些标准(UML对SDL存在着这样的兼容性)，只需将SDL形式的电信标准作为需求工件之一，在其他工件中对其加以引用就可以了。总之，万万不可拘泥于用例建模的形式，应灵活运用各种方式的长处。

　　3.2 补充规约

　　补充规约记录那些在用例模型中不易表述的系统需求，主要包括以下内容。

　　功能性

　　功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述。有些功能性需求是全局性的，适用于所有的用例，如出错处理、I18N支持等，我们不需要在所有的用例中描述这些功能性需求，只需要在补充规约中统一描述就可以了。

原文转自：http://www.ltesting.net