在哪一个阶段画出操作界面

今天上午项目组内部开了一个会议，讨论需求文档的模板。大部分内容大家都比较一致，比如分成功能性需求和非功能性需求。功能性需求中主要以用例分析为主线，辅助以各个层次的工作流程图以及系统流程图。另外加入业务实体的各种信息等等。
但是在一个问题上面，项目组成员与我的引导无法达成一致：多数项目组成员认为系统操作界面不是需求阶段的产物。而应该是系统概要设计甚至详细设计阶段的产品。理由如下：需求的主要内容应该集中于业务分析，而系统界面更接近于设计的工作。而且在需求阶段需要画出页面的话，需求文档的工作量过大，需求评审阶段如果包括界面的话，那么需求阶段的时间会过长。
我无法说服大家的固有习惯，甚至无法说服大家仅仅写一些重要业务的操作界面。最终只能以大家的多数意见为准了。

这种情况显然是项目组内部对当前的OOAD技术缺乏经验所导致的。我的观点与大家相反，确认操作页面的工作越早越好！

• 需求分析需要分为三个层次：战略目标需求（高层访谈），业务逻辑需求（中层访谈）以及操作需求（一线操作层访谈）。
• 操作页面的确认工作应该是在需求访谈过程中同步进行的，而不是项目组内部闭门想出界面，然后拿给客户进行评审。
• 画界面的工作不会因为推后而减少。
• 需求访谈中对界面的访谈与分析有可能比用例分析还要早一步。示意图方式的界面会很大的消除需求的歧义。会给用户最直观的感受，是我们认识系统的第一个门户。
• 更早的对操作页面进行确认会减少项目的风险。如果在概要设计评审的时候发现有一些界面设计的不合适，然后发现修改这些页面居然还会导致上一阶段的需求分析结果进行改动的话，这样的返工成本就要大很多了。时间压力也会更大。