需求和设计之间存在差别，但应尽量使你的规格说明的具体实现无倾向性。理想情况是：
在设计上的考虑不应该歪曲对预期系统的描述。需求开发和规格说明应该强调对预期系统外部行为的理解和描述。让设计者和开发者参与需求审查以判断需求是否可以作为设计的基础。
不同的软件设计方法常常都会满足最终需求，而设计方法会随着性能、有效性、健壮性以及所采用的技术上的不同而变化。如果你直接从需求规格说明跳到编码阶段，你所设计的软件将会是空中阁楼，其可能的结果只能是结统的最有效的方法。考虑一下其它的设计方案将有助于确保开发人员遵从所提出的设计约束或遵从与设计有关的质量属性规格说明。
曾经参与一项项目，进行了完整的需求分析，建立了详细描述模拟摄像系统行为的8个变换过程的数据流程图。经过大量的需求分析后，我们并没有直接进行源代码的编写工作。而是以数据流程图为表示方法，创建了一个设计模型。我们立刻意识到模型中有三个步骤使用了相同的计算算法，另外三个使用不同的方程集，而剩下的两个步骤共享三分之一集合。
分析模型代表了用户和开发小组对我们正在解决的问题的理解，而设计模型则描绘了我们应该如何构造系统。通过设计期间的仔细思考，我们把核心问题简化了60%，把8个复杂的计算集合减少到3个。如果我们在需求分析之后立刻进行编码，那么在构造阶段必定会出现代码重复。但是，由于及早发现了可简化问题，节省了许多时间和金钱。设计上的返工比编码返工可能要效率高一些。
以需求为基础，反复设计将产生优良成果。当你得到更多的信息或额外的思想时，用不同的方法进行设计可以精细化你最初的概念。设计上的失误将导致软件系统难以维护和扩充，最终会导致不能满足客户在性能和可靠性上的目标。在把需求转化为设计时你所花的时间将是对建立高质量、健壮性产品的关键的投资。
在设计产品时，产品的需求和质量属性决定了所采用的合适的构造方法。研究和评审所提出的体系结构是另一种解释需求的方法且会使需求更加明确。与原型法类似，这是一种自下而上的需求分析方法。两种方法都围绕着这样一种思维过程：“如果我正确理解需求，那么这种方法可以满足这种需求。既然我手中有一个最初的体系结构（或原型），它是否有助于我更好地理解需求呢？”
在你可以开始实现各个部分需求前，不必为整个产品进行完整、详细的设计。然而，在你进行编码前，必须设计好每个部分。设计规划将有益于大难度项目（有许多内部组件接口和交互作用的系统和开发人员无经验的项目）。然而，下面介绍的步骤将有益于所有的项目
◆ 应该为在维护过程中起支撑作用的子系统和软件组件建立一个坚固的体系结构。
◆ 明确需要创建的对象类或功能模块，定义他们的接口、功能范围以及与其它代码单元的协作。
◆ 根据强内聚、松耦合和信息隐藏的良好设计原则定义每个代码单元的预期功能。
◆ 确保你的设计满足了所有的功能需求并且不包括任何不必要的功能。
当开发者把需求转化为设计和代码时，他们将会遇到不确定和混淆的地方。理想情况下，开发者可沿着发生的问题回溯至客户并获得解决方案。如果不能马上解决问题，那么开发者所做出的任何假设，猜想或解释都要编写成文档记录下来，并由客户代表评审。如果遇到许多诸如此类的问题，那么就说明开发者在实现需求之前，这些需求还不十分清晰或具体。在这种情况下，最好安排一两个开发人员对剩余的需求进行评审后才能使开发工作继续进行。