软件设计通过软件统设计模型来表示（参见《再议模型》），软件设计评价是对软件系统设计模型的评价。在这里，我们使用源系统表示软件要实现自动化的系统，它处于实体空间；目标系统表示要实现的软件本身，它处于形式空间。软件表示模型（即系统分析模型和系统设计模型，参见《再议模型》）是沟通源系统和目标系统的桥梁。表示模型的形成需要一个过程，我们称其为过程空间。下面我们使用图形方式来描述：
这样，软件设计评价应该具有三类标准，分别是实体空间标准、过程空间标准和形式空间标准。
实体空间标准以源系统做为标准来度量系统设计模型。这依赖于我们对于源系统的认识程度，我们知道应该具有这样一个标准，但实行起来非常困难。设计的合理性就是实体空间标准，它没有一个具体的内容和形式。
过程空间标准在设计评价中经常被使用。它可以看作实体空间的间接标准，基于分析模型和设计模型是出于同一实体，其中具有自然的关联。我们说，设计是否附合需求，就是检验设计模型和分析模型的一致性。
形式空间标准以目标系统的角度检验系统设计。从上述两种标准，可以保证目标系统的功能满足源系统，但不能保证目标系统在运行状态下的质量属性。所以形式空间标准是从目标系统的质量出发来考察系统设计的。考虑到质量，我们使用McCall/GE质量模型，它围绕产品改进、产品运行、产品移交三种使用情况来组织质量属性，可以看出是基于目标系统的。国际上有很多现行的基于质量评价系统设计的方法，我们后面会参考其中的部分。
虽然从理论上我们可以知道软件设计评价具有三类标准，但却没有办法真正按照这些标准去检验一个软件的设计。
实体空间标准应该是一个软件设计最终应该附合的标准。但是，这个标准很难直接应用于软件设计模型上，因为软件设计是思维的产物，在实体上检验这个产物是否正确，恐怕只能说“实践是检验真理的唯一标准”了。只有在错误非常明显的情况下，这个标准才会起作用。
过程空间标准相对好一些。通过和软件生产过程前期阶段产物进行对比，可以找到其中不一致的地方，这可能就是设计上的问题了。同时，现代软件开发一般采用迭代的方式进行，设计活动可能分多次进行。这种迭代也要求我们检查设计对需求的覆盖情况。
通过形式空间标准对软件设计进行检验时，往往并不存在一个唯一的检验标准。这是因为实际软件的质量要求不是唯一的，不同的软件有不同的质量属性要求。而特定软件的质量要求，是在需求分析、设计的过程中逐步形成的。这些质量要求，最终成为我们检验软件设计的标准之一。
根据这些标准，我们现在设计一个软件设计评价表模版：
软件设计评价表
软件名称 迭代周期
设计人员
评审人员
设计合理性
需求附合度
功能点覆盖率（FPC）?%重点功能点覆盖率（IFPC）?%
优先功能覆盖率（PFPC）?%需求一致度(Should be 100%)?%
质量属性
模块性权重在过程中确定权重分数，100分制，下同
可修改性权重权重之和应为100%
可扩展性权重下同
性能权重
可靠性权重
可用性权重
可移植性权重
可维护性权重
灵活性权重
可重用性权重
可理解性权重
弹性权重
安全性权重
容错性权重
评审结论
在设计合理性方面，主要考虑以下内容：
类的职责单一、明确
模块结构清晰、完整
活动、行为描述清晰
实体关联清楚，状态合理
对需求附合度的要求要在评价之间确定。
质量属性的评价权重一般在设计开始之前确定，这个工作多数在架构设计时刻完成。最后，
根据质量属性的权重，可以计算设计的总体质量分数。这些都是最终评审结论的素材。
一般来说，对于设计的评价通过建立场景的方法来实现。比如评价可修改性，一般先建立一个修改的场景，
对设计进行模拟修改，观察其是否易于修改。有些质量属性无法通过这种方法检验，只能通过对设计模型进行观察得出
结论。