暂且叫这个项目叫FM。FM项目采用敏捷模式，需求的表现形式是Story. 此项目需求收集过程如下：

亮点：在公司第一次实践敏捷。用Story 而非 需求说明文档呈现需求。

败笔：没有处理好Story 和UI的关系。UI prototype 做完后，又将UI的需求写入了已经审批过的Story. 因为UI相对功能更容易变化，如果将UI需求写入story, 会导致Story 的频繁更新。且常有多个story 共用一个部分UI的情况。如果用另外独立的文档结合UI prototype 描述UI需求可以减少Story的更新频率，也可以避免同样的UI在不事的story里重复描述，而且Word 文档结合prototype描述UI, 图文并茂，更容易理解。

需求收集实例三之 FM