关于质疑采用MBD的其他有用的论点介绍以下：

·工具太昂贵了！这就是为什么为了给定的目的而决定工具的适应性，如当MBD有回报时它才可被引入，必须考虑到MBD的目标、驱动因素和内容。

·模型很难发展、理解，经不起分析和综合！这可能是真的。然而，这也许反映出MBD技术的错误匹配。错误匹配可能与MBD使用背景有关，包括可能是训练用户不足，或者仅仅是因为选择的MBD技术是不成熟的。

·用户说：“我没有时间建模或记录档案，因为我需要工作。”这句话可以与上述不匹配联系起来，这也/或阐明了用一个与工作实践对齐的、合适流程来支持MBD的必要性。对于一个有价值的MBD方法来说，它应该可以拓展有关建模和记录需求的理性争议。

·模型从来没有捕捉到现实，何必（引进MBD）呢？根据经验可以很好地证明，模型可以研发用于多种用途来充分捕捉现实。然而，开发模型是昂贵的，所以建模工作必须聚焦，且技术必须匹配。

·MBD恰好是生成代码。还有MBD的许多其他方面。对于OEM，从嵌入式系统规范过渡到实际执行是一个大的步骤，且具有许多含义，包括车载软件的维护和可能的更大责任。另一方面，这也使OEM更好控制汽车至关重要的功能。(www.daowen.com)

·代码生成器可以被信任吗？根据模型的代码生成器已经遇到阻力，就像几十年前从集成过渡到高级编程语言那样。其基本思想是相同的——它们为设计人员提供了更强大的工具，从而为他们减少了不必要的细节。之前提出的担忧，就是编译器是否能够产生高效率和可靠的编码。现在有时会出现同样的担忧，就是根据模型的代码生成。实施的差距不容小觑，但是这并不意味着编译器和代码生成器工作不称职。所需的品质包括生成代码的性能也是相对于应用代码生成的域而言的。生成的代码已经用于汽车甚至飞机上。

·对模型和工具的过度信任。这是一个来自现实的常见缺陷和教训，这个应该在使用MBD的时候作为一般忠告来考虑。分析仅仅像模型一样好：“进来时如果是垃圾，出来也会是垃圾”。模型验证和设计师的经验是MBD非常重要的一部分。毫无疑问，要保持一定的批判态度和持续检查模型和分析结果的可信性。

·太详细的模型。这也是一个来自实际的重要教训，且这个也应该在使用MBD的时候作为一般忠告来考虑。需要经验来判断所需的详细程度——再一次强调工作必须集中。在20世纪80年代和90年代信息建模的过程中，在大多数情况下设置的范围过于广泛。模型中的每一个东西包含太多细节将导致极其复杂的模型，因而就没有一个清晰的思路针对使用模型来支持研发。

·通信10年前就走进了UML（统一建模语言）的陷阱——汽车行业现在正面临同样的问题？希望不是这样，但答案不明显！许多心血都倾注于对UML的调整，从而改善其限制，例如，改进语义，并将它与嵌入式系统其他所需模型集成到一起。然而，UML仍然是一个非常复杂的结构，且使用的配置文件产生了过多的区域性语言，这将妨碍UML成为一个标准。UML仍然需要证明它在传统领域之外。