根据系统需求中的描述，每个用户的权限都至少包括Read-only（READ），因此，上面的3个问题都应该确认为缺陷，测试人员分别都提交了缺陷报告。

　　在项目结束之后的总结会议上面，笔者就针对该功能的实现和GUI提出了自己的想法：假如在开发人员具体实现阶段，测试人员将评审的目的更多的放在发现缺陷上面，开发人员尽早修复其中的问题，那么该功能的实现可以更加简单高效，而测试人员后期的工作量也可以大大降低。笔者的建议包括：

　　● 根据需求的描述，Read-only（READ）应该作为每个用户UID必须具备的权限，因此将Read-only（READ）作为每个用户的默认值，不允许进行增加、修改和删除等动作；

　　● 根据上面的建议，在该功能的图形化，如图1所示中，将Read-only（READ）选项移除，因为改选项已经通过内部代码实现了，不需要操作人员进行选择。

　　假如测试人员在评审过程中发现了上述的问题，并根据上面的建议开发人员进行了修复，那么，在软件实现过程中，可以获得下面几个好处：

　　● Read-only（READ）作为每个用户的默认值，不允许增加、修改和删除，那么，在图1的示意图中直接删除Read-only（READ）选项，可以简化示意图；

　　● 按照上面的思路，代码中就可以省略针对Read-only（READ）异常处理，例如：在修改的时候，不需要判断用户是否重复选择了Read-only（READ）选项，或者没有选择Read-only（READ），直接可以节约开发人员的代码异常处理的工作量；

　　● 而对于测试人员，由于前期参与评审工作，发现了其中的一些缺陷，提高了代码的质量，可以减少后续的测试工作量；

　　假如测试人员、系统人员和开发人员在实现该功能之前，认真仔细的评审了具体的实现，那么，我相信上面碰到的问题就可以避免在系统测试过程中才被发现。另外，系统人员、开发人员和测试人员在针对该功能的评审过程中，除了可以避免将这些问题和缺陷引入到工作产品中之外；还可以帮助大家对功能的实现和期望结果有了更好的认识，并更加容易达成一致。这是不是可以更好的实现在整个团队内部的知识共享呢？