正如您所说,这两个只是示例。实际上,此类所有非功能性需求都可能相互冲突。在“ Building Evolutionary Architectures”一书中,有一张大约有一百个这样的“ -ilities”表(它们通常也被称为)。
对于软件架构师来说,考虑其中任意两个之间的潜在冲突是一种练习。您可以基本上确定其中哪些对您的项目很重要,然后跟踪这些冲突。
回到精确的示例,并查看robustness
Wikipedia中术语的定义:
在计算机科学中,健壮性是计算机系统在执行过程中应对错误[1] [2]并应对错误输入的能力。
从定义中可以看出,健壮性涉及错误。另一方面,您要具有正确性,这基本上意味着没有错误。
为了使冲突更加明显,让我们考虑一个简单的输入字段。根据正确性要求,最容易拒绝用户的任何错误输入。但是,鲁棒性要求您能够使用此输入,这可能并不完全正确。
将其带到您的书中:现在可以接受的权衡是什么?假设您编写了一个科学应用程序,用户可以在其中输入电压量(包括幅度)。因此正确的输入应该是“ 10 kV”或“ 200 mV”。可接受的权衡取舍包括允许输入“ 10kV”,“ 10kVolt”,甚至只是“ 10”,并且为了正确起见,将它们映射到有效电压值。请注意,这仍然是一个折衷,而不是“两全其美”的事情。考虑大写还是小写:“ 10 kV”和“ 10 KV”可能很好,但“ 10 mV”和“ 10 MV”可能不行。由于您不确定现在是毫还是兆,因此正确性变得可疑,