使用屏幕界面模型进行需求获取有哪些优缺点？
屏幕UI界面模型在恰当的时间引入时可支持需求收集过程，但如果过早引入则可能出现问题。以下是分析师应该记住的几个关键点：
1）屏幕模型是很好的，因为它们可以帮助业务代表或客户将系统功能可视化。这可以帮助分析师和利益相关者尽早发现问题。然而，如果在这个过程中引入得太快，那么业务代表/客户自然倾向于尝试成为屏幕设计师。他们不是说系统应该支持“x”，而是开始说他们需要一个下拉框来捕获“y”，以及一个按钮来完成“z”。客户不是UI设计者，事实上也很少有业务分析师是真正的UI设计者，因此这可能导致屏幕设计缺乏可用性。类似地，在屏幕上指定所需的控件会偏离系统的真实需求，并且常常导致围绕为什么系统必须支持某些功能的讨论不够充分。
2）在没有支持需求列表的屏幕模型中捕获需求时，无法知道早期的屏幕设计决策是出于支持必要的需求或是出于某种其他原因。分析师和开发人员无法知道他们是否可以在不失去重要需求的情况下消除或改变屏幕功能。诸如“我们是否真的需要在此屏幕上拥有控件，或者我们是否可以在此过程中捕获数据？”之类的问题？在不回到原始利益相关者的情况下变得无法回答。而且，在复杂的项目中，没有任何一个利益相关者可以回答这个问题。
3）单独的屏幕模型无法捕获通过系统的流程变量。通常，分析师会在屏幕模型中附带一个书面说明，说明在点击某些按钮时或在字段或下拉列表中输入某些值时会发生什么。这些描述很有帮助，但它们没有描述系统必须支持的端到端流程。需要进一步的文档记录，例如流程或用例，但在需求收集过程中过分强调屏幕模型时，往往会忽略这些文档。虽然参与屏幕模型化过程的分析师和利益相关者可能对所支持的过程有基本的了解，但开发人员和测试人员却不会。
最终，UI模型的引入可能非常有用，但这应该仅在详细列出功能和使用场景（系统需要支持哪些业务流程）之后才会发生。只有这样才能生成UI模型而不会引入重大缺陷。