任务:制定远景
此任务描述了如何制定系统的整体远景,包括要解决的问题、关键的项目干系人、系统范围/边界、系统的关键特性和所有约束。
规程:需求
用途

此任务的目的是:

  • 获得需要解决的问题的共识。
  • 确定系统的项目干系人。
  • 定义系统的边界。
  • 描述系统的主要特性。
关系
角色主执行者: 其他执行者:
输入必需: 可选:
输出
流程使用情况
主要描述

制定“远景”时,请记住以下方面:

步骤
获得需要解决的问题的共识

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

问大家:问题是什么?

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

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

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

不要接受问题的第一次陈述。继续问“为什么?”了解问题的本质。

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

确定项目干系人

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

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

开始制定系统的可能(或实际)用户的概要文件。关键用户以及他们的环境的初始信息应该记录在远景文档中。

定义系统边界

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

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

确定要施加在系统上的约束

要考虑各种约束来源。以下是可能的来源和要问的问题列表:

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

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

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

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

示例:

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

定义系统特性

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

评估结果

在这个阶段您应该检查“远景”来验证您的工作是否在正确的轨道上,而不是详细复审。对于远景文档,请考虑核对表(核对表:远景)。



更多信息