质量要求
质量的一切问题都围绕着需求——始于需求，终于需求。需求规定了软件必须达到的技术性目标，在设计和开发过程中指导着软件的创建。这些需求是否得到满足需要通过测试来决定，测试能够证实软件的完成情况，说明预期的质量。
在介绍动态性能需求时，讲述了如何将每个质量特征的技术性需求融合到需求中，该部分的目的是 ：尽管加入性能非常重要，而且 SDLC中也经常这样做，但最好是在规划设计阶段就落实，并且要反映具体的要求和需求。
随着软件项目中利益相关者的不断增加，形式化需求的重要性也相应地越来越突出。当利益相关者就是开发人员，共同协作以创建软件的各个组件时，需求能够帮助他们确定大家是否都在按照相同的要求朝着共同的目标努力。需求能清楚地描述开发工作的内容，这使开发人员能够依靠既定的信息而不是对信息的诠释展开工作。在项目规划阶段，利益相关者对软件预期的功能和性能的看法很少一致，但借助需求，他们能够统一对软件目标和后期功能及性能的看法，开启软件项目。
如果没有统一的软件需求，那么在软件完成时，利益相关者可能对于软件是高质 量、低质量甚至是否创建完成的问题看法不一。没有公认的软件需求，利益相关者 只能对照自己的需求来评估软件，而每个人都有自己不同的看法，因此，软件的评估 缺乏客观性。而且，在 SDLC 的“范围扩展”中，不成文的需求随时都会发生变化。当软件超出或无法满足客户需求时，软件需求能够帮助避免这种偏差，如图 2-4所示，后面部分会继续讲述这一点。
图2-4 “不尽人意”和 “画蛇添足”
需要注意的是，尽管“画蛇添足”会提供一些附加的功能或性能，但这并不会提升软件的质量，因为客户不需要、未做出要求或者无法从中获得额外的商业价值。
避免“不尽人意”
在我们的职业生涯中，有些时候，“不尽人意”并不表示我们就是失败者，客户可能在看过软件之后告诉我们软件没有达到标准。我们没有满足技术要求中明确和隐含的功能性目标或性能目标，因此我们的软件没有达到预期的质量。“不尽人意”指 预期质量和实际表现的质量之间的偏差。然而，某些环境主要依赖隐含的性能需求而不是技术需求中明确表示的要求，如果在这些环境中出现了不尽人意的情况，那么这种模棱两可可能造成利益相关者的慌乱。开发人员可能认为自己给出的是预期的软件，但客户和用户会觉得功能性或性能没有达到要求。
若经理要求创建高效的软件，规定了运行时间、速度及内存利用率的阈值，但我们所创建的软件并没有满足这些目标，这时候就出现了性能差距。从功能性来看，软件是合理的，但质量差强人意，因为性能未达到要求。如果预期的性能没有通过需求明确地表达出来，而只有暗示，那该怎么办呢？经理或许会认为我们已经知道软件需要在 15 分钟之内创建完成，但他实际上并没有明确地传达这一信息，或者只是在软件规划阶段提出其他需求时有所暗示。经理需要的是“快速的SAS”，而且我们也认为自己给出的是“快速的SAS”，但由于性能需求未陈述清楚或未经过公认（以便进行评估和验证），我们在评估软件质量时要参考哪一方对“快速的SAS”的定义呢？
公认的、可评估的需求能够避免出现“不尽人意”的情况，它能够为 SAS从业人员提供一个核对表以便他们对照评估自己的代码。代码满足所有的功能性需求吗？满足 ；能满足所有的性能需求吗？满足 ；能满足正式的测试计划中所有的测试案例吗？满足。建立需求能够确保在软件规划阶段共同确定质量，在软件完成阶段共同评估和验证质量。
避免“画蛇添足”
从“SDLC中的质量”部分中的开发场景继续往下讲，我们是研究人员，需要编写 SAS软件对数据进行分类，以筛选出独特的观测结果。在软件规划阶段，我们问了自己几个与性能相关的问题，而且在终端用户开发环境中，商业价值主要通过功能性而非性能实现。因此，关键的一点是SAS软件能够筛选出独特的观测结果并生成一个详细的数据集。如果程序失败，我们作为终端用户开发人员可以重新开始，所以稳健性并不是那么重要。因为数据集不是很大，几秒就可以处理完，所以运行效率也不是首要的考虑因素。而且由于数据集不会随着时间的推移而不断扩充，因此，数据的可扩展性也不是开发过程中关注的重点。
这并不是说质量在这种情境下或在终端用户开发环境中不重要，而是指如果性能属性的添加没有任何价值，或者性能属性的缺失也不会带来负面的影响（至少在可接受范围内），则无须考虑添加性能属性。因此，在这种情况下，如果我们凭着以前的经验，花费了几小时来测试 SASIndex函数、SQL程序、混合SORT程序或 DATA步骤是否能生成运行速度最快的代码，那么完全就是在浪费时间——至少在这个项目中是如此，因为这不会带来任何额外的商业价值，而且还会拖慢软件完成的进度。即便我们确实成功地提高了利用率，软件质量显然也不会增加，因为附加的性能没有实现任何性能需求。
当软件需求缺乏明确性，留有解释或假想的空间时，就会出现“画蛇添足”的情况。一个 SAS从业人员可能会自豪地推出一个稳健、高效的程序，期望能够获得经理的赞赏，但最终等来的却是责备，因为软件不需要稳健。相反，它应该是早已完成的，而且，性能的添加实际降低了软件的价值，因为它拖慢了分析师使用合成数据集或数据产品的速度。通过在项目初始阶段提出技术性要求，开发团队能够对软件价值形成统一的认识和理解，指导 SAS从业人员只关注全体公认的、有价值的功能性和性能。
实质上，“画蛇添足”回答的问题是：我们能有太多的质量吗？是的，我们能。增添意料之外的性能有时能拉近我们与客户之间的距离——老板未要求我们提高软 件的处理速度，但我们这样做了，因为我们就是这样的善解人意，所以老板会从心底 感谢我们提升了软件的速度。但是，额外添加一些不必要的性能并不会提升软件的质 量，而且如前所述，这样做还会降低软件的价值，因为它拖慢了进度，增加了预算， 影响了有价值的功能和性能作用的发挥，所以，随意添加或改变软件是非常危险的， 需要我们慎重考虑。
对质量说“不”
避免“画蛇添足”的一个技巧是明确地规定软件中应该包含哪些性能属性，以及 不应该添加哪些质量特征。并非所有的软件都用于生产或为了获得较长的使用期限， 通常在分析环境中，许多 SAS代码片段的编写都只是权宜之计，在分析完结果之后就会被丢弃或者修改。对于这种应急的软件而言，多个性能特征的叠加未必能起到好 的作用。但如果随着时间的推移，创建该软件的目的不再是权宜之计，而是战略需要， 不再是发挥辅助的作用，而是至关重要的基础结构，那么同样的性能稍后就需要被添 加到该软件中。
这同样又说明，一些SAS 软件不需要考虑性能需求，只需功能性需求即可界定。在软件意图会随着时间推移不断变化的情况下，我们需要重新进行评估，确定软件需 求——包括功能性和性能需求是否仍然适用。但在某些情况下，比如性能不能为软件 带来任何内在价值时，我们需要考虑的就不是性能特征，而应优先考虑机会成本—— 如附加的功能或降低的项目成本。
对质量说“是”
软件意图或开发环境的某些方面能够保证软件的高效率。在某些情况下，性能如功能性一样都会获得高度重视，对软件至关重要。这主要因为附加的功能被看作是非常有用的，或者从风险管理的角度来看，优先考虑性能可以减轻或消除某些具体的风险。下面这些情况就需要软件具有高性能。
行业规定 某些行业具有具体的、必须遵守的软件开发规章制度，通常，这类软件可能会或将要由政府机构进行审查。例如，用于支撑临床试验研究的 SAS软件通常必须遵守美国食品药品监督管理局（FDA，FoodandDrugAdministration）的“软件验证通用原则”以确保满足相关的质量及性能标准。
组织内部的指导原则 除了行业规定之外，一些组织或团队通常会制定一些在软件开发中必须遵守的、纲领性的最佳指导原则，而且，这些指导原则通常要求添加质量特征。例如，一些团队要求SAS所有的宏都必须包含一个返回代码显示宏的运行或故障，以帮助我们处理异常情况，提升软件的稳健性。
支撑关键基础架构的软件 支撑数据分析架构关键组件的 ETL或其他 SAS软件就需要提升性能，以避免出现系统、软件或合成数据产品不可用的风险。
预定的软件 设定为重复执行的自动化 SAS软件需要具有较高的性能，自动化、预设的 SAS工作表示 SAS从业人员无须再手动审查 SAS 日志，因此，对可靠性及稳健性要求较高。
具有独立处理过程或用户的软件 如果 SAS 软件获得高度认可，具有独立的、依赖于该软件的处理过程或用户，那么其性能不仅要能够反映软件自身运行的故障风险，还要能反映出依赖项的故障风险。
具有预期使用寿命的软件 打算使用较长时间的 SAS软件应该具有较高的性能。静态性能需求在维持软件产品的使用中尤为重要，因为它们支撑着软件的可维护性， 软件预期使用周期越长，越能体现该投资的价值。
隐含的需求
我们讲了很多需求，可能许多读者会认为质量就意味着没完没了的文档。某些软件开发环境确实会创建许多文档，这是因为它们确实需要这样做，尤其是当出现 “对质量说‘是’”部分所提到的几个或全部特征时。然而，从ISO对质量的定义来看，软件质量包括隐含的和明确的需求。而且，敏捷软件开发四条价值中的第二条指出“工作的软件高于详尽的文档”。因此，在组织或团队层面上，利益相关者需要评估哪些类型的需求需要创建具体的文档，哪些需求能够通过对性能和需求的解读推断出来。
举例说明，在一个组织严密的团队中，所有的SAS从业人员都知道每个人的优缺点，了解并相信各自的技术能力。如果团队成员技术过硬，并且对哪些质量特征能 推进高效能软件的开发了如指掌，那么类似“通过动态SAS 宏代码模块化创建软件”的需求就显得多此一举，而且如果单独在需求文档中指明这一点，就会显得特别突兀。尤其是在那些配合高效默契的团队中（参照质量模型，确定是否在软件定义中添加技 术性需求），我们在技术中完全没有必要过多地提及性能。
