Java开发工程师接受需求文档时需要注意什么？

程序员的工作源头来自需求文档。业务方提出需求，然后由专门的需求人员/产品人员根据业务来进行编写需求文档，因此需求人员其实是业务和开发中间的桥梁。

可想而知，一个好的需求人员最主要的标志就是业务精通，如果他还懂一些开发常识就更好了。

一个水平差劲的需求会给你的开发埋下定时炸弹，他的考虑不完全，可能会在上线后暴露出来，导致生产问题发生。也会严重影响你的开发进度。产品人员就比较专业了，在设计产品的时候，考虑得十分详细，各种场景推演都会被列出来，内部评审很多。

但是缺点就是需求文档定稿太慢了，为了保证进度，开发需要确定好那些一定不会变的内容，提前开发，不然无法完成既定时间目标。

需求文档一般需求团队内部会先进行评审，评审通过后，会给开发和测试进行宣讲，开发提前查看需求文档，在需求宣讲期间或者宣讲后几日内提出疑问，需求人员进行解答并修改完善。

当需求文档最终定稿后，开发根据需求文档编写设计方案（概要设计），测试人员编写测试案例，然后分别进行内部评审。评审的时候都会互相邀请参与。

资深的工程师，会需要对项目背后实现意图的了解，在进一步了解意图的基础上，根据过往的经验，可以做到深入理解需求、补充需求细节、修正需求错误。同时，往往资深的工程师，承担了进度的压力，他们还需要对需求的优先级有深刻了解，明确哪些需求是可有可无的。逻辑性的描述，对资深的工程师来说，阅读的价值一定程度降低。而优先级和实现意图，一定要明确传达出来。  

中级的工程师，已经掌握需求的实现能力，但是因为经验的局限，不一定能够做的又快又好，举例，不能细腻完成功能的实现（如输入即时提示，看过多个APP会在前一个词输入后马上显示相关提示，当提示内容需要网络请求且网络不好的时候，会造成输入的严重卡顿），碰到这种情况，需要对细节进行深入的描述（如提示请求需要背景运行，用户停顿超过0.5秒以后再做提示），但是这类需求的细节描述，往往产品设计人员未必能给出最优的方案，需要产品和技术多次探讨沟通。  

初级的工程师，在技术层面可能没有问题，但是往往会面临考虑不周，细节不注意的情况。这时，详细的逻辑流程图，界面设计，UI元素描述，就是必不可少的。