目的
  • 获得需要解决的问题的共识。
  • 识别系统的涉众。
  • 定义系统的边界。
  • 描述系统的主要特性。
角色: 系统分析人员 
频率:按照要求,一般对于先启和精化中的每个迭代访问一次,如果需要的话可以在后续阶段再访问。
步骤
输入工件:   结果工件:  
工具向导:  

工作流程明细:  


获得要解决的问题的共识 回到页首

要获得问题的定义的共识,其中一个最简单的办法就是把问题写下来,看看是不是每个人都表示同意。

问大家:问题是什么?

  • 人们往往会急着直接确定解决方案,而不会先花时间去把问题弄明白。把问题写下来,看看您能否让每个人都同意问题的定义。

然后再问大家:问题到底是什么?

  • 查找根本原因(或者叫“问题后面的问题”)。真正的问题往往隐藏在表面问题的后面。

不要接受问题的第一次陈述。继续问“为什么?”找出“真正”的问题。

有时大家可能太聚精会神想解决方案,就很难让他们明确地说出根本问题到底是什么。在这种情况下,先探讨解决方案的好处,然后再尝试查找这些好处解决的问题,这样做会有好处。然后你们就可以探讨那些问题是不是组织中“真正”的问题。 用于查找问题背后的问题的常用方法是../workguid/wg_brnst.htm -- This hyperlink in not present in this generated website自由讨论../workguid/wg_fish.htm -- This hyperlink in not present in this generated website鱼骨图../workguid/wg_paret.htm -- This hyperlink in not present in this generated website排列图

识别涉众 回到页首

根据开发团队的领域专长的不同,识别涉众这一步可能不重要或者可能很重要。一般情况下,这一步只涉及与决策者、可能的用户和其他相关团体进行面谈。下列问题很有帮助:

  • 系统的用户是谁?
  • 谁负责出资购买系统?
  • 还有谁受系统生成的输出的影响?
  • 当系统交付和部署时谁将评价系统?
  • 系统有没有其他内部或外部用户的需求需要满足?
  • 维护新系统的人是谁?
  • 还有其他人吗?
  • 好,还有其他人吗?

开始制订系统的可能(或实际)用户的概要文件。这些概要文件将映射到正在开发的系统的人员参与者的角色。关键用户以及他们的环境的初始信息应该记录在远景文档中。

定义系统边界 回到页首

系统边界定义解决方案以及围绕解决方案的真实世界之间的边界。换句话说,系统边界描述了一个包含解决方案系统的包络。信息以输入和输出的形式在系统和位于系统外的用户之间来回传递。与系统的所有交互都通过系统和外部世界之间的接口进行。

在许多情况下,系统的边界是很明显的。例如,运行在 Microsoft Windows® 上的单用户、紧缩型个人联系管理器的边界相对来讲就定义得很好。只有一个用户和一个平台。用户和应用程序间的接口由用户接口对话框(用户访问这些对话框将信息输入系统)和任何输出报告和通信路径(系统使用这些报告和路径记录或传送结果信息)组成。

使用参与者来定义和描述系统的边界通常很有效。请参阅活动:查找参与者和用例

识别要施加到系统上的约束 回到页首

要考虑各种约束来源。这些信息中有很多会记录在补充规范工件中。以下是可能的来源和要问的问题列表:

  • 政治:有没有内部或外部政治问题影响可能的解决方案?部门之间呢?
  • 经济:适用的财务或预算约束有哪些?销售的货物成本或产品定价方面有没有要考虑的问题?有没有什么许可问题?
  • 环境:有没有环境或规章制度方面的约束?法律方面的呢? 我们是否受其它标准的约束?
  • 技术:我们在技术的选择上受约束吗?我们只能受限于在现有的平台或技术条件下工作吗?我们在新技术的使用上受到阻碍吗?
  • 可行性:规定了时间进度吗?我们受限于现有的资源吗?我们可以使用外面的劳动力吗?我们可以扩展资源吗?临时资源? 永久资源?
  • 系统:解决方案要建立在我们现有的系统上吗?我们必须维护与现有解决方案的兼容性吗?必须支持哪些操作系统和环境?

这里收集的信息将是如补充规范中所定义的设计约束的初始输入。

形成问题陈述 回到页首

与所有小组成员一起研究框架图,并为识别的每个问题填写以下模板:

问题<描述问题>
影响<受问题影响的涉众>。
其影响是<问题的影响是什么>。
一个成功的解决方案将<列出成功的解决方案的一些主要好处>。

该模板的目的是帮助您将解决方案/答案与问题区分开来。

示例:

问题:客户服务问题没有得到及时、恰当的解决
影响:我们的客户、客户支持代表和服务技术人员。
其影响是:客户不满、可以觉察到的质量欠缺、员工不高兴以及收入的流失。
一个成功的解决方案将:
支持代表提供对故障排除数据库的实时访问,并帮助及时将服务技术人员分派到真正需要他们帮助的地方。

定义系统的特性 回到页首

基于问题陈述中列出的好处,制订您希望系统拥有的特性的列表。简单地描述这些特性,并将属性赋予它们,以帮助定义它们在项目中的一般状态和优先级。

评价您的结果 回到页首

在这个阶段您应该检查“远景”来验证您的工作是否在正确的轨道上,而不是详细复审。考虑活动:复审需求中的“远景”文档的检查点。



Rational Unified Process   2003.06.15