需求与实现职责划分怎样合理！

最近因为判定系统缺陷到底是在需求阶段引入还是开发阶段引入的问题和同事总是发生争执，大家在争执的过程中，总是纠结于这是谁的责任，却不花时间思考一下为什么总是会这样争执，应该如何去解决。

BA、SA使用一致的语言来沟通，对常识类的问题达成一致共识，才能保证对需求的理解达成一致，而不是在每个项目的需求文档中反复累述，需求中没有强调的，SA没考虑就就可以豁免。

我们需要不断的累积这些常识，形成系统设计的规范，才能提高效率，提高系统质量。就如同，我们现有有了编码规范，SA就不用在每个项目的设计文档中重复描述，developer都会知道有这个要求，这是SA和developer之间达成的共识，所以BA和SA之间也要形成这样的共识。

同时我们也要考虑一下，为什么需求中没有提到的细节，测试人员会在系统测试中测试到，而开发人员却意识不到，说明测试人员已经形成了这些共识，开发人员还没有。

这么说，并不是要推卸BA的责任，BA应该推动这些共识的达成，形成设计规范（包括UI规范）

这里提到的共识可以包括几类：

1. 生活常识类（BA和SA都应该要有意识）

举例：用户在系统中记录完成某事件的开始时间、结束时间，则通常会有校验规则：

          开始时间<=结束时间

2. 技术常识类（SA要负责不断总结）

举例：在系统中，不论是记录用户的信息，还是记录业务对象的信息，通常都会有“唯一编号”和“名称”来描述人或事物；

“系统”主要使用“编号”来识别人或物，而“人”通常是使用名称来识别人或物。

因此系统在UI上呈现人或物的信息给用户来浏览时，通常都是要显示“名称”来供用户识别的。单纯的显示一个编号，通常是不能被用户理解的。

3. 业务常识类（BA要负责不断总结，然后交由SA形成设计规范）

在一个特定的行业，或者特定的领域，或者特定的区域（地区、或公司/部门）范围内，都会有一些约定俗成的术语，无需反复解释，大家都会理解这个术语背后所代表的所有信息，来提高沟通的效率。

举例：国际贸易中会通过价格术语（FOB、CIF等）来界定买卖双方的各自应承担权利、责任、和风险。因此如果是开发第一个该领域系统，BA确实应该详细描述每一个术语所代表的完整含义/信息和及应具备的设计约束，但如果组织内已经开发过几十个这样的系统，大家都已经完善熟悉这些术语背后代表的含义和信息，BA却还在需求文档耗费精力中不断解释，就是浪费时间了，除非是某个特定系统中，大家已习惯的这些术语因某些原因有了特殊的变化，才需要特别描述这些发生变化，与大家通常的理解不一致的地方及原因。

顺便提出一点：

UI设计并不是BA的职责，在我的理解中UI设计属于系统实现的范畴，并不属于需求的范畴。因为同样的需求完全可以有不同的UI呈现方式，且都是用户可以接受的。

BA与用户在讨论需求的过程中，为了提高与用户沟通需求的准确性和效率，确认双方的理解达成一致，会借助UI demo这个“工具”来辅助沟通（这里强调“工具”，就说明这只是手段，不是目的，目的不是为了得到UI设计，目的是为了得到需求），且只会对用户与系统交互的主要界面，容易存在分歧的界面，或者容易隐藏潜在业务规则的页面来沟通，并不会对系统的每一个界面去逐一确认。需求沟通中使用的UI demo也并不会落实到界面上的每一个细节都完全确定。因此在系统设计过程中是要包含UI设计这个环节的。

因此在测试过程中，不能一碰到UI上的设计不合理、不完整、或有改进的意见时候，就认为是BA在需求阶段没有说清楚，应该属于新需求或者需求变更。