活动:
|
目的
|
角色: 系统分析人员 |
频率:按照要求,一般对于先启和精化中的每个迭代访问一次,如果需要的话可以在后续阶段再访问。 |
步骤 |
输入工件: | 结果工件: |
工具向导: |
工作流程明细: |
要获得问题的定义的共识,其中一个最简单的办法就是把问题写下来,看看是不是每个人都表示同意。
问大家:问题是什么?
然后再问大家:问题到底是什么?
不要接受问题的第一次陈述。继续问“为什么?”找出“真正”的问题。
有时大家可能太聚精会神想解决方案,就很难让他们明确地说出根本问题到底是什么。在这种情况下,先探讨解决方案的好处,然后再尝试查找这些好处解决的问题,这样做会有好处。然后你们就可以探讨那些问题是不是组织中“真正”的问题。
用于查找问题背后的问题的常用方法是自由讨论、
鱼骨图和
排列图。
根据开发团队的领域专长的不同,识别涉众这一步可能不重要或者可能很重要。一般情况下,这一步只涉及与决策者、可能的用户和其他相关团体进行面谈。下列问题很有帮助:
开始制订系统的可能(或实际)用户的概要文件。这些概要文件将映射到正在开发的系统的人员参与者的角色。关键用户以及他们的环境的初始信息应该记录在远景文档中。
系统边界定义解决方案以及围绕解决方案的真实世界之间的边界。换句话说,系统边界描述了一个包含解决方案系统的包络。信息以输入和输出的形式在系统和位于系统外的用户之间来回传递。与系统的所有交互都通过系统和外部世界之间的接口进行。
在许多情况下,系统的边界是很明显的。例如,运行在 Microsoft Windows® 上的单用户、紧缩型个人联系管理器的边界相对来讲就定义得很好。只有一个用户和一个平台。用户和应用程序间的接口由用户接口对话框(用户访问这些对话框将信息输入系统)和任何输出报告和通信路径(系统使用这些报告和路径记录或传送结果信息)组成。
使用参与者来定义和描述系统的边界通常很有效。请参阅活动:查找参与者和用例。
要考虑各种约束来源。这些信息中有很多会记录在补充规范工件中。以下是可能的来源和要问的问题列表:
这里收集的信息将是如补充规范中所定义的设计约束的初始输入。
与所有小组成员一起研究框架图,并为识别的每个问题填写以下模板:
问题<描述问题>
影响<受问题影响的涉众>。
其影响是<问题的影响是什么>。
一个成功的解决方案将<列出成功的解决方案的一些主要好处>。
该模板的目的是帮助您将解决方案/答案与问题区分开来。
问题:客户服务问题没有得到及时、恰当的解决
影响:我们的客户、客户支持代表和服务技术人员。
其影响是:客户不满、可以觉察到的质量欠缺、员工不高兴以及收入的流失。
一个成功的解决方案将:支持代表提供对故障排除数据库的实时访问,并帮助及时将服务技术人员分派到真正需要他们帮助的地方。
基于问题陈述中列出的好处,制订您希望系统拥有的特性的列表。简单地描述这些特性,并将属性赋予它们,以帮助定义它们在项目中的一般状态和优先级。
在这个阶段您应该检查“远景”来验证您的工作是否在正确的轨道上,而不是详细复审。考虑活动:复审需求中的“远景”文档的检查点。
Rational Unified Process
|