同样,开发工程师也希望及早介入需求,在 FRD 并未确认的时候就了解需求,进而将商业
需求和功能需求转化为开发工程师看得明白的开发需求清单(这个清单,大部分叫做 UC,即 USE
CASE),当这份清单由工程师需求分析师——在过去,这个角色被叫简称为 RA,但是目前已经取
消此专门的职位,而是由开发工程师代表担纲此环节工作,为了便于描述,在此文里,我仍然将
做这件事情的人称为 RA——交付给具体的执行工程师后,执行工程师基本上可以当作一条条的
checklist 开始高效工作,而不必再思考商业逻辑和需求。同样,测试工程师也需要编写具体的
文档去指导很多测试人员在开发后高效测试,这也是基于 UC 和 FRD 去撰写的。
所以,开发需求分析是个很重要的环节。那 RA 是如何来完成需求分析工作的呢?
● 前期介入,对 PD 进行开发需求评估支持;
● 如何写一份交互说明文档参与每次的 FRD 评审会;
● 详细审阅 FRD 文档并不断与 PD 确认。
对于做这件事情的人来说,足够详尽的 FRD 是非常重要的。所以一份 FRD 虽然是 PD 产出,
但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。而设计需求的传递,却存在很
多问题。除了线框图,没有“详尽的说明性的文档”告诉他们。比如:
一方面,交互设计师对产品经理说:这块由我们来考虑,你的文档不必包含设计上的说明,
这随时会调整的。
另一方面,线框图的评审有时会让 RA 参与,有时却没有叫他们。即使叫上了他们,他们也
会发现交互设计的需求变化要比 FRD 变化快。另外,他们会认为 UC 不必写太多关于交互设计的
需求。
在某个大型项目结束后,作为交互设计师,我进行了一些调研,听听这相关人员是怎么表
述问题的:
开发部门的需求分析师:
● 每次变动都很痛苦,设计变了之后,我就要跟着改 UC,改截图,有时候 UED 改了还忘
了通知我们,导致 UC 有问题„„
● 页面交互的需求容易漏掉,因为 UC 里面不可能写太多交互方面的东西。