2005/9/16：现在讨论的这个事作为需求的必要补充（我认为是补充），不能替代需求。
没有现成的模式，没有看过什么需求的教科书！
负责设计部分，没有参与需求获取，但手头拿到的需求总不能满足设计的需要，从自己角度想谈一下，这样的需求的获取是否可行：
面向“界面”建模，需求部分的人，在于对方项目负责人，接触后首先聊解基本的主流程和对方的需要用新系统的解决存在于现有系统（可能不是电子化的）中的问题。由需求负责人，在获取以上信息后，对界面进行快速建模-----用.net立即构造界面，并使用简单的数据直接在程序内构建数据主要用于显示效果和对某些事件的触发（DataGrid的双击事件需要中有数据，ListBox也需要）。根据用户的描述仅仅先把，界面跳转的过程描述出来，不考虑数据存储，读取，处理的过程，也无需考虑页面之间的数据传递关系。力求在需求阶段将，系统的界面确定下来，不过界面的布局（窗体控件的大小等可以忽略），主要是保证不会少元素。这样的需求分析周期，显然会增加需求获取的周期，但个人感觉还是值得的，如果放到下阶段设计阶段去做这个事情，然后在提交用户确认，然后再返回修改，再确认，会使设计周期变得混乱而垄长。
还没有对这个模式进行尝试，不知道大家对此有什么高见，在此希望能抛砖引玉。
