在EET/Embedded.com上最近一篇题为“我不需要臭鼬的要求”作者Jon Pearson写到了处理不断变化的需求这一非常现实的问题。他接着概述了一些非常有用的步骤，以便在项目进行过程中处理这些更改。

但我对这一基本理念持异议，这一理念在这个行业几乎成为一种普遍的尖叫，即需求或多或少不能提前知道。

在我35多年的嵌入式世界中，我看到了需求不会改变。至少没有达到做网页设计的人所经历的程度。当然，还有一些调整和额外的功能请求。而且，是的，很少有革命性的转折需要重大的重新设计。但更多时候，我们抱怨的需求变化是糟糕的需求收集的产物。

有一种元模因在起作用，这种模因在当今恶性政治舞台上越来越普遍。作为一名工程师，听到一些专家或即将被定罪的政客阐述我们应该如何解决X问题，我总是感到震惊，因为X确实是一些问题的症状。专注于症状就像救助一艘漏水的船。更好的办法是：先把洞堵住。

这就是问题所在。如果在引出需求方面做得不好，其症状将是无休止地争相修补项目。创可贴，而不是一开始就避免受伤。

在嵌入式世界中，糟糕的需求收集是普遍存在的。我们过早地开始编写代码和设计电路。一些敏捷主义者赞扬这种做法；我认为这是一个错误。

在许多情况下，我们会责怪外部势力。老板希望我们今天开始上班。市场营销不断做出改变(看看我对此的看法“倾听客户的意见。”).

确实有一些力量在起作用，这可能是无法克服的，但我们往往也是罪魁祸首，要么是因为我们对开始工作的热情，要么是我们不愿意教育其他利益相关者。

令人震惊的是，我们中的许多人对需求收集知之甚少。你读过一本关于这个主题的书吗？我们中很少有人这样做。(我最喜欢的是Karl Wiegers的“软件需求”). 我扫描了几所大学的课程目录，发现没有一个CS或EE课程标题或描述包含“要求”一词

是的，当然需求会改变，我们需要应对策略。但我们有责任在一开始就做好引导他们的工作，以确保项目不会崩溃。

我想起了一个古老的寓言：在古代中国有一个治疗师家庭，其中一个在全国各地都很有名，被一位大领主聘为医生。医生被问到，他的家人中哪一个是最熟练的治疗师。他回答说：“我倾向于对病人和垂死的人进行激烈而戏剧性的治疗，有时有人被治愈了，我的名字在贵族中流传开来。

“我哥哥在疾病刚开始扎根时就治好了，他的技术在当地农民和邻居中都很有名。

“我的大哥能够感觉到疾病的精神，并在它形成之前将其根除。在我们家外面，他的名字是未知的。”

从一开始就正确地满足需求并不是什么荣耀，但这是伟大工程的本质。

杰克·甘斯勒是嵌入式开发问题的讲师和顾问。他主持嵌入式系统研讨会，并帮助公司应对嵌入式挑战。请通过与他联系。他的网站是。