界面原型用于需求启发与验证

用例图和用例规约梳理出的需求，仍然容易漏掉客户和用户自己一开始都没意识到的细节需求——用文字和图表和客户交流，客户很难凭空”感受”到系统建成后到底是什么样子，这时最有效的办法是在需求分析期间就提前开始界面设计，把界面草图甚至可执行原型用于和客户交流，增加实感、方便沟通，帮助客户”发现”自己真正想要的功能，而不是让客户被动等到系统交付才发现”这不是我要的”。书中用一个真实案例说明这个机制如何生效：在最初讨论”添加项目任务”这项需求时，开发方和用户都没有意识到两个需求细节——用户希望能为每项任务指定优先级（方便承担多项任务的成员在时间不够时权衡取舍）、用户对确定任务细节的时机有极高的灵活性要求；后来在界面图和可执行原型的辅助下，用户才比较容易地意识到”令人不满的地方到底在哪儿”，明确提出了这两项此前被遗漏的细节，开发方也据此更新了界面原型，让用户既可以只输入任务名称和所属项目创建任务、也可以同时指定详细信息。这个案例揭示的机制是：需求的表达能力和感知门槛成反比——原型把抽象的需求描述转化成用户可以直接”用”起来评价的具体对象，大幅降低了用户识别自身隐性需求的认知门槛。需要注意的边界是：界面设计的成果一般不应放入《需求文档》，因为它们本质上是设计产出而不是需求本身，只是被借用作需求启发和确认的辅助手段。