系统必须遵循的条件或性能规范。
其它关系:  扩展者:
角色: 需求指定者 
可选/发生: 多次发生通常包括在一个容器工件中。应只在系统符合性能或条件时使用。
模板和报告:
     
示例:
     
UML 表示: 可以使用各种构造型,如 <<用例>> 和 <<业务规则>>。
更多信息:  
活动的输入:   活动的输出:  

用途 到页首

记录软件需求,以尝试指定:

  • 用户为实现目标而解决问题所需要的软件性能
  • 系统或系统组件为服从合同、标准、规范或其它从形式上强加的文档而必须符合或具备的软件性能
    [THA97]

这是软件开发中的基本工件,虽然在许多环境中,通常某一部分需求仍然记录得并不完整。RUP 解决该问题的方法是在多次迭代中控制软件开发和允许随着时间来展现重要的需求。

简短概述 到页首

创建 软件需求 工件时,应考虑工件的各个方面,包括:

  • 可提供需求的不同兴趣组或涉众
  • 需要考虑的不同需求类型(类别、规模)

属性 到页首

属性名 简述
标识 用于标识该软件需求的独特名称。 
简述 对需求的简述,尽量简明扼要。 
理由 对于需要该需求的原因及其代表的利益或价值观的解释。 
UML 表示 各种构造型,例如 <<用例>>、<<业务规则>>
详细描述 对需求的详细说明。 
复原和恢复过程 实现测试环境配置的复原或恢复所需的过程。 

计时 到页首

在先启阶段早期,当小组响应涉众请求和系统远景而开始定义系统范围时,确定了(简要概述某一部分需求)软件需求。在精化和构造阶段继续详细描述大多数需求,而在移交阶段定义和处理有限的一部分需求。

职责 到页首

需求指定者 角色主要负责该工件。

定制 到页首

该工件通常包括在软件需求规范用例中或其它需求规范工件中。



Rational Unified Process   2003.06.15