从需求到设计和编码

需求和设计之间存在差别，但尽量使你的规格说明的具体实现无倾向性。理想情况是：
在设计上的考虑不应该歪曲对预期系统的描述。
需求开发和规格说明应该强调对预期系统外部行为的理解和描述。让设计者和开发者参
与需求审查以判断需求是否可以作为设计的基础。
不同的软件设计方法常常都会满足最终需求，而设计方法会随着性能、有效性、健壮性
以及所采用的技术上的不同而变化。如果你直接从需求规格说明跳到编码阶段，你所设计的
软件将会是空中阁楼，其可能的结果只能是结构性很差的一个软件。在构造软件之前，你应
该仔细考虑构造系统的最有效的方法。考虑一下其它的设计方案将有助于确保开发人员遵从
所提出的设计约束或遵从与设计有关的质量属性规格说明。
分析模型代表了用户和开发小组对我们正在解决的问题的理解，而设计模型则描绘了我们应
该如何构造系统。
设计模型是对分析模型的再整理，再分割，再包装。好的设计模型可以使软件更加结构化，更健壮，更易变更，更易复用。而且将具有相同功能的分析模型合并为一个设计模型，可以减少成本提高效率。
以需求为基础，反复设计将产生优良成果。当你得到更多的信息或额外的思想时，用不
同的方法进行设计可以精细化你最初的概念。设计上的失误将导致软件系统难以维护和扩
充，最终会导致不能满足客户在性能和可靠性上的目标。在把需求转化为设计时你所花的时
间将是对建立高质量、健壮性产品的关键的投资。
当开发者把需求转化为设计和代码时，他们将会遇到不确定和混淆的地方。理想情况下，
开发者可沿着发生的问题回溯至客户并获得解决方案。
如果不能马上解决问题，那么开发者所做出的任何假设，猜想或解释都要编写成文档记
录下来，并由客户代表评审。如果遇到许多诸如此类的问题，那么就说明开发者在实现需求
之前，这些需求还不十分清晰或具体。在这种情况下，最好安排一两个开发人员对剩余的需
求进行评审后才能使开发工作继续进行。