修正方法

    笔者曾经参加过一个项目。这个项目非常重视数据，相对来说用户任务和规则则比较少。公司有使用指定技术的需求开发流程，但是却没有用于以数据为中心的开发项目的方法。当时，逻辑数据模型是分析的重要工具。我们确定了用户任务，但这些用户任务却没有包含在用例中。信息的状态会促使用户采取相应的行为——不管是“确认”、“审查”、“通过”或是其它状态。 所以，我们开发了一个阶段-步骤表，在表中把变化转换为状态，然后相应的用户就会采取与状态对应的行动。

    这个方法实施得不错，但是需求管理小组还是找我们谈话了。于是我们集合到一起——业务赞助人、项目经理和需求分析师、架构设计师、开发人员等。我们解释说，我们用上面描述的方法进行标准的需求开发，但是很快却发现这个方法无法让我们对这个以数据为中心的项目的需要有一个准确、清晰的了解。

    然后我们重新整理记录需求的方法。需求管理小组的人听完我们的说明，问了两个问题，第一个是问业务赞助人：“这些需求是否代表了你的需要？”答案是：“当然，我还亲自写了一些。”第二个是问开发人员：“你知道该构建什么东西吗？” 答案是：“当然，我们动作很快。通常只需要改动很少的地方。”如果需求管理小组的人是“警察”，那么我们可能已经“被捕”了。不过，这两个问题却恰到好处地反映了修正过的方法是否行得通。

    总结

    回到主题，要构建正确的系统，开发人员必须知道一些东西。

    如果没有这些信息或信息不明确，那么初始开发可能并没有向着目标发展，而在测试过程中则可能发现新需求。在项目最后阶段、需求完成之前，一定要检查可能出现的问题。

    除了一些比较正规的需求记录方法，还可以采取一些基本措施来保证开发人员对系统开发需求有一致而清晰的认识：

    需求类型/方法

    ·了解需求的各种类型以及互相之间几乎确定的关系

    ·确定统一的方法

    ·提供针对需求类型及所用描述方法的培训

    ·简单地描述需求完整性、合规性和一致性的预期目标

    ·检查每一项工作成果，保证预期目标的达成。

    系统开发的职能

    ·为每个系统开发职能编写能够清晰地描述任务和预期目标的职能说明（并非职位说明）

    ·找出那些天生具有符合职能的技能的人

    ·为每种职能提供可以提高技能的培训