我选择在我的项目中使用开发方法 RUP（Rational Unified Process）。这是我以前从未使用过的方法。我还在开发过程中包含了来自 Scrum 的一些元素。问题是需求规范应该包含在 RUP 模型中吗？是功能性需求还是非功能性需求？ RUP 的技术分析和安全要求中应该包括什么？找不到任何信息。关于这一点的注释会很有帮助。 希望有RUP经验的人可以分享一些有用的经验
【问题讨论】：
标签： methodology rup
RUP 有 3 个主要部分：
每个角色都进行一项活动，并因此产生一个工作产品...
例如分析师 [角色] 开发愿景 [活动]，因此我们将拥有愿景 [工作产品]...
除此 RUP 之外，我们还为我们提供了一些指导方针和检查表，以正确处理我们的活动和工作产品...
RUP 为我们提供了 WORK PRODUCTS 模板，但它们只是为了让我们了解它们的外观......
假设您可以使用 RUP 模板进行视觉，但您可以只使用便利贴，然后像这样写一个“elavator statement”：
对于 [目标客户] 谁 [需求或机会的陈述] （产品名称）是 [产品类别] 那 [关键声明 益处;也就是说，购买的令人信服的理由]不像[主要 有竞争力的替代品] 我们的产品 [主要声明 差异化]
甚至工作产品也可以是您在 WIKI 上编写的简单语句...它们可以是任何形式...
它们不能是“静态编写的”文档...它们甚至可以是“视频”。 假设您无需编写 Softaware Architecture docs [Architecture Notebook in OpenUP]，您只需创建一个视频，让您的团队在白板上解释主要架构......
****RUP WORKPRODUCTS 模板警告：**
不要成为模板僵尸。你不应该填写它的任何部分...... 你应该问自己，我写这篇文章会得到什么好处……如果你没有有效的答案，不要写…… 文档应该有真正的原因，不要仅仅为了“文档”而做文档......**
RUP 拥有丰富的 WORK PRODUCTS...所以选择其中的最少一个，您将获得最大的收益...
对于典型的项目，您通常会有这些需求工作产品：
愿景：我们做什么以及为什么要做？利益相关者协议...
补充规范 [OpenUP 中的系统范围要求]： 通常捕获非功能性[我不喜欢的术语]或 “质量” [我喜欢的”] 系统要求。
用例模型：将功能需求捕获为用例
词汇表：使概念清晰......
RUP 是商业的，但 OpenUP 不是...所以您可以查看 OpenUP WORK PRODUCTS 模板，以了解其中记录了哪些信息...
从和下载它 Eclipse Process Framework Project http://www.eclipse.org/epf/downloads/configurations/pubconfig_downloads.php 并从索引页开始阅读：
...-->
...--->
--->
-->
--->
....>..................................
---->.......................................
最后，您可以在 Larman 的《应用 UML 和模式》一书中以敏捷的方式找到这些 WORK PRODUCTS 的用法...
再说一遍：不要成为模板僵尸！！！
【讨论】：
尝试Wikipedia 的 Rational Unified Process 页面以获得概述。
核心要求应记录在项目描述中。 RUP 倾向于非常强调“用例”，但是非常重要的是不要忽视所有细节级别的原始需求，因为这些会回答“为什么？”问题。如果开发人员只看到用例，他们将知道什么他们应该构建（实际上是功能需求），但不知道为什么它是必需的。除非开发人员可以轻松接触到原始分析师，否则这可能会导致非常严重的问题。
【讨论】：