2010年3月30日,星期二,01:00

需求定义阶段-我们完成了吗?

撰写者

要求定义1人们经常问我"我们如何知道何时完成需求阶段?" My opinion? You are never 完全地 已经完成了需求,但确实存在标准,您可以通过这些标准评估需求的完整性并评估准备进行设计的准备程度。

标准1:让范围成为您的指南

好的,我的假设是您的项目具有定义的范围。您知道,这就是您在项目开始时生成的文档,是编写需求的基础。作为回顾,Scope的组件包括:

  • 需要:您正在尝试解决的问题或您想利用的机会
  • 目标:需要完成的事情
  • 目标:成功的标准
  • 接口:外部实体(人员,流程和系统),将向您的产品发送输入或从您的产品接收输出
  • 驱动因素和约束条件:例如,法规,标准,产品所使用的现有系统,更高级别的要求,进度,预算,利益相关者的期望
  • 运营概念:这些故事或场景从不同的利益相关者的角度描述了产品在不同生命周期阶段(例如,运营,运输,安装,维护,存储,制造,处置)的生命周期

您编写的每个需求都应该响应项目范围的一个或多个组件。如果该要求不能帮助您满足范围,则可能不需要。也就是说,请查看您的范围的组成部分并问自己,您是否已定义满足需求,目标,目标,接口,驱动因素和约束所必需的要求?您是否记录了从运营概念中得出的所有要求?如果您对所有这些问题的回答都是“是”,则可以准备对需求进行基准评估并继续进行设计,但是为了确保确定,建议您应用其他条件。

准则2:查看模型

如果您使用业务流程,面向对象或结构化分析技术来开发模型,那么您将拥有一种很好的方式来验证您是否具有完整的需求。当谈到模型时,我指的是活动图,泳道图,流程图,DFD,ERD等。我是建模的坚定拥护者。开发模型是一种使利益相关者参与并使其以不令人生畏的综合方式传达其要求的好方法。我的意思不是恐吓-画一幅图以图形方式呈现今天完成的工作或将来需要的工作有多可怕?全面?借助图片,您可以轻松地验证步骤和决策点,并识别错误和遗漏。

在评估需求的完整性时,我更喜欢从当前状态图和将来状态图进行工作。通过分析这两种状态,我提高了信心水平,即我有维持现有功能,性能和合规性需求的需求,并定义了实现既定愿景和范围所必需的需求。

标准3:查看您的模板

您是否使用标准轮廓或模板来满足您的要求?许多组织已经为不同类型的项目开发了标准模板……硬件项目,软件项目,维护,升级等。结构良好的模板列出了各种类型的项目/产品的典型需求的不同类型。组织。因此,如果您使用模板,请确保已收集并记录了所有相关要求。对不起,我指出模板中有一个明显但大的漏洞是一个很好的指示,说明您缺少某些要求。

标准4:进行需求审查

我知道...可怕的评论... 喘气 利益相关者!!!但您知道,需求审查确实 必须是一个可怕的经历,这确实是 最好 确保您具有完整要求的方法。

遵循以下简单规则,您与需求评审相关的痛苦将被最小化:

  • 确保需求文档已准备好进行审查。纠正所有错别字,语法问题,标点符号错误。另外,请确保所有要求均按照编写好的要求的规则来编写。我们希望人们专注于内容,而不是愚蠢的小错误!!
  • 在审查中包括所有项目涉众。我还建议您邀请项目外部的知识渊博的人来了解那些没有那么密切地参与产品需求开发的人。这些外部“专家”必须具有技术上的能力,并且已经在类似的开发工作中进行了工作。
  • 确保所有审阅者都了解项目的范围。如果人们在没有愿景,范围的概念的情况下审查需求,那就是在浪费每个人的时间。
  • 在分发需求文档之前,召开审核启动会议。在本次会议中,演讲主题包括:
    • 审查目的
    • 评论者的期望
    • 进行审查的规则
      • 审查标准
      • 标准品
      • 范本
      • 评论评论
      • 反馈
    • 项目范围
    • 您认为涉众需要成功执行审阅任务所需的其他信息

需求审查的目的有很多:

  • 识别并纠正错误和遗漏
  • 确认需求的正确性和完整性
  • 获得所有利益相关者的认同
  • 设定期望
  • 签收

标准5:成本/收益

好的,我承认,无论您为验证需求阶段所做的一切而做什么,您仍然会有那些“手动执行者”拒绝签发,因为他们担心您会错过一些真正重要的需求。您认为您具有所有要求,大多数利益相关者都认为您具有所有要求,但是您(可能还有其他所有人)暗暗地希望有一个指标可以尖叫您拥有 所有 需求,并已准备好基线并开始设计。抱歉,不存在此类指示符。如果您对是否满足要求感到困惑,请问自己这个问题...

什么会花更少的钱-由于我忘记了一些要求,或者为了确保已确定所有可能的要求而需要的时间,进度和资源投资,潜在的下游变化?

谨防有些人在手摇者的另一端...我称这些人为时间表商人。 Schedule Mongers是那些不管当前阶段的状态如何都坚持启动项目下一阶段的人,因为“看到它在进度表上,如果它在进度表上,我们 开始!!”在评估是否准备过渡到设计时,Schedule Monger不一定在乎是否已满足要求,并且无视或否认以下事实:没有良好要求的开始肯定会导致拖延产品交付时间,增加成本,并可能导致客户不满意,因此请当心Schedule Monger,并知道您所提出的有关进行或不进行风险(成本)的问题在处理Schedule Monger时同样适用就像是绞手一样。

结论:我们完成了吗?

路德维格·维特根斯坦(Ludwig Wittgenstein)说:“这个谜语不存在。如果可以提出这个问题,那么它也可以得到回答。”

嗯...我怀疑路德维希永远不必处理要求!!!

您将永远不会满足需求,因为事情会发生变化-业务变化,技术变化,竞争变化,人员变化。而且,由于这种不可避免的变化,我感到“我们什么时候知道我们完成了?”这个问题。无法百分百地回答。

但是,如果您在以下范围内评估需求完整性:

  • 您定义的范围,
  • 开发的模型
  • 您组织的综合需求文档模板;和
  • 您争取利益相关者的参与,以确认一套全面而正确的要求;和
  • 您用预测每个需求所需的成本来评估未来变更的潜在成本,

然后您可以回答在需求阶段我们经常听到的问题-我们完成了吗?

答案??

不,我们还没有完成 然而 但是我们完成了 足够 进行设计。

别忘了在下面留下您的评论


谢丽尔·希尔,PMP 是Compliance Automation,Inc.的首席运营官兼高级讲师,Compliance Automation是要求培训和其他服务的领先提供商,旨在帮助公司,政府组织和个人以最有效和有效的方式提出无缺陷的要求。 Cheryl与CAI的所有培训师/顾问一起,将20多年的项目管理,需求以及系统工程和业务分析的其他领域的实际经验带到了课堂上。自1990年以来,已有超过25,000名客户寻求CAI提供实用的方法来分析和管理范围和要求。在CAI,我们会在培训完成很长时间之后,为客户提供必要的培训,这对于个人和组织而言都是必不可少的,并且对他们具有价值。欲了解更多信息,请致电830-249-0308或访问我们的网址 www.complianceautomation.com.

©BA Times.com 2020

麦格雷戈徽标白色网站