RUP 需求概述
一、在RUP 中与需求定义相关的核心工作产品主要包括：
- 《愿景》(Vision )
- 《用例模型》(Use Case Model) 及《用例规约》(Use Case Spec)
- 《补充规约》( Supplementary Spec )
- 《术语表》( Glossary )
在《愿景》中主要描述待开发产品可以为客户带来什么利益，产品的市场定位如何，以及基于以上背景产品应具备的关键特性。在产品类公司中，《愿景》是营销体系与软件研发体系之间的纽带。如果你的公司是在做产品，那么《愿景》将致关重要。如果你所开发的是客户定制类系统，那么《愿景》的重要性就可以打折扣了，不过用来记录软件系统的一些关键特性还是很有意义的。
对于大部分企业应用，《用例模型》和《用例规约》都是非常重要的，它记录了系统的大部分需求。《用例模型》主要展现使用系统的主要角色及这些角色需要使用系统完成自己的哪些任务。《用例规约》是对用户扮演某个角色时如何使用系统完成特定任务的详细描述。
《补充规约》用来记录《用例模型》和《用例规约》之外的几乎所有其他需求。补充规约可以记录的需求类型包括功能性需求（F ）、易用性需求（U ）、可靠性需求（R ）、性能需求（P ）、支持性需求（S ）及接口、约束等其他需求（+ ），简言之FURPS+ 。
《术语表》主要用来记录和解释核心业务领域概念及可能会造成理解分歧的领域词汇。在分析设计中，《术语表》中的术语是领域对象或实体对象的主要来源之一。另外，描述细致的《术语表》也可以在一定程度上起着数据字典的作用。
二、在RUP 中与需求定义相关的核心任务包括：
- 制定愿景
- 查找参与者和用例
- 详细描述用例
- 制定补充规约
- 结构化用例模型
尽管所有待建系统都有愿景，但不是所有项目都编写了详细的愿景。不编写愿景的原因多种多样，也许你正在为客户定制系统，愿景不掌控在你的手里也不由你负责；也许不管你多么努力，你都没有能力编写出愿景；也或许是你刚刚使用RUP ，你的关注点还不在愿景。但不管怎么样，请记住制定愿景的目的是要研究客户问题及为解决这个问题系统应该提供什么样的方案（即为解决这个问题系统应具备什么样的关键特性）。这是你的产品可以顺利销售出去并赚钱的重要保证。
确定参与者有助于确定系统范围，也有助于发现系统用例。通过确定下来的参与者及与参与者交互的用例可以概述系统的主要功能。参与者代表使用系统的人或物，用例则是参与者为完成某个特定任务而使用系统的动作序列。通过查找参与者和用例，系统分析师可以概括性地建立起系统的总体功能需求，并初步确定系统范围。
在查找参与者和用例的过程中，参与者和用例已经概要描述了。接下来，需要对用例划分优先级，并按优先级依次详细描述用例。在用例中，最为核心的内容是事件流，事件流描述参与者如何使用系统完成任务。事件流中参与者可以顺利的完成任务的动作序列称为基本流，而因各种意外或其他选择而产生的分支流程称为备选流。在实际操作中，用例描述可繁可简，规范度较高的团队用例编写需要很完整，而敏捷团队，用例可以只概要描述事件流，甚至只保留对用例的一句概要性描述。
补充规约中记录了用例之外的其他需求，这也是补充规约中“补充”二字的由来。补充规约中的需求一般以特性的方式进行定义，不存在用例事件流的形式，而且补充需求以非功能性需求为主，这些需求记录了系统质量要求及系统约束等。补充规约中也包括一些不适合使用用例描述的功能性需求。
通过查找参与者和用例，系统分析师初步建立起用例模型。用例模型需要不断演化才能成熟，这也是结构化用例模型这项任务核心目的。在结构化用例模型过程中，你可以对参与者进行调整和抽象，对用例之间建立起抽象、包含和扩展关系。好的用例模型不担可以清晰的描述需求，也是架构分析的重要输入。
三、在RUP 中与需求定义相关的核心角色包括：
- 系统分析师
- 用例细化人员
- 项目涉众
系统分析师主要负责总体性和关键性工作，如：
- 制定愿景
- 查找参与者和用例
- 制定补充规约
- 结构化用例模型
系统分析师可以、甚至应该不担任参与者和用例的详细描述工作，而应该将主要精力放在愿景、用例模型及补充规约的制定上来。愿景关系到是否在建立一个正确的系统，用例模型关系到系统的功能范围、用户价值，补充规约则关系到系统在整体范围内质量要求、构造约束等。这些工作要么需要较高的工作能力，要么需要进行全局性思考，不适做大规模的分工安排，由担任系统分析师的一个或少数人完成较好。
系统分析师应对以下工作产品负责：
- 《愿景》
- 《用例模型》（参与者及用例的总体部分）
- 《补充规约》
- 《术语表》
用例细化人员的核心工作是详细描述用例及参与者（如果需要）。详细描述用例工作量大、需要关注很多细节、同时用例与用例之间相对独立，因此比较适合分工并行工作。用例细化人员虽然不需要系统分析师那么强的综合能力，但也需要充分关注用户使用系统的背景、目的等要素，这是编写好的用例的前提。用例区别于其他需求形式的最大优点在于它能够以用户为中心、从用户角色定义需求。要想真正以用户为中心，了解用户使用系统的背景、目的、及用户的工作职责则是非常关键的。
用例细化人员主要对《用例规约》负责。
软件架构师也部分参与系统分析工作，他的主要工作是与系统分析师一道确定用例的优先级。当然这里的软件架构师和系统分析师都是一种角色，实际项目中，较小项目 的 软件架构师和系统分析师可能是同一人。对于较大的项目，项目中的担任架构师（特别是应用架构师，技术架构师可以不参与或少参与）职位的人可能同时也是系统分析组的重要成员。
本文概要描述了RUP 需求定义中的核心任务、工作产品和相关角色。下面的一系列文章将借助案例详细描述如何完成这些任务。为了增强易理解性，描述方式将采用从入门到精通的渐进式方式。在入门阶段会忽略一些重要但不易理解的内容，如愿景等，在提高和精通阶段会逐渐增加这些内容。入门将注重形式和操作，而精通则更注重思想和内涵。