软件用例建模指南[4] 软件测试用例
关键字：用例建模 指南
3. 系统需求
RUP中根据FURPS+模型将系统需求分为以下几类：
功能(Functionality)
可用性(Usability)
可靠性(Reliability)
性能(Performance)
可支持性(Supportability)
设计约束等
除了第一项功能性需求之外的其他需求都归之为非功能性需求。
3.1 需求工件集
用例模型主要用于描述系统的功能性需求，对于其他的非功能性需要用其他文档来记录。RUP中定义了如下的需求工件集合。
用例模型：记录功能性需求
用例图：描述参与者和用例之间的关系
用例规约：描述每一个用例的细节信息
补充规约：记录一些全局性的功能需求、非功能性需求和设计约束等
词汇表：记录一些系统需求相关的术语
在实际应用中，除了这些工件之外，我们还可以根据实际需求灵活选用其他形式的文档来补充说明需求。并不是所有的系统需求都适保合用用例模型来描述的，如编译器，我们很难用用例方法来表述它所处理的语言的方法规则，在这种情况下，采用传统的BNF范式来表述更加合适一些。在电信软件行业中，很多电信标准都是采用SDL语言来描述的，我们也不必用UML来改写这些标准(UML对SDL存在着这样的兼容性)，只需将SDL形式的电信标准作为需求工件之一，在其他工件中对其加以引用就可以了。总之，万万不可拘泥于用例建模的形式，应灵活运用各种方式的长处。
3.2 补充规约
补充规约记录那些在用例模型中不易表述的系统需求，主要包括以下内容。
功能性
功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述。有些功能性需求是全局性的，适用于所有的用例，如出错处理、I18N支持等，我们不需要在所有的用例中描述这些功能性需求，只需要在补充规约中统一描述就可以了。
文章来源于领测软件测试网 https://www.ltesting.net/
