软件要求
reddish
虽然有许多产品功能，但在许多系统中，只有一小部分需要认真考虑。
虽然有许多产品功能，但在许多系统中，只有一小部分需要认真考虑。 如果开发人员知道哪些功能对项目的成功至关重要，他们就可以选择软件工程方法来实现特定的质量目标。 根据设计，可以对质量属性进行分类。 对属性进行分类的一种方法是区分在运行时可识别的特征和不可识别的特征。 另一种方法是区分对用户很重要的可见功能和对开发人员和维护者重要的不可见功能。 对开发人员很重要的属性使产品易于更改、验证和移植到新平台，从而间接满足客户的需求。
产品的不同部分具有所需的质量特性的不同组合。 效率对于某些部件可能很重要，而可用性对其他部件也很重要。 区分应用于整个产品的质量属性与特定部件、用户类或特殊使用环境的质量属性。 将任何全局属性要求记录到 RS 中，并将特定目标与 RSS 的功能、用例或功能要求联系起来。
在确定质量属性时，它们必须基于用户对系统的期望。 量化重要属性有助于明确用户期望，并帮助设计人员提出最合理的解决方案。 但是，大多数用户不知道如何回答诸如“互操作性对您有多重要？ “或者，”软件应该有多可靠？ 等等。
在一个项目中，分析师提出了可能对不同用户类很重要的属性，并根据每个属性设计了许多问题。 他们使用这些问题来要求每个用户类的代表将每个属性分类为 1 到 5（极其重要的属性）。 这些问题的答案有助于分析人员确定哪些质量特征最重要，可以用作设计标准。
然后，分析师与用户合作，确定每个属性的具体、可衡量和可验证的要求。 如果质量目标无法验证，则无法判断它们是否已实现。 在适当的情况下，指定每个属性或目标的测量级别或单位，以及最大值和最小值。 如果你不能定量地识别出对你的项目很重要的某些属性，那么你至少应该优先考虑它们。 IEEE软件质量测量方法标准提出了一种在全面的质量测量基准系统下定义软件质量要求的方法。
定义属性的另一种方法是识别与质量期望冲突的任何系统行为。
通过定义不良行为（反向要求），您可以设计强制系统表现出这些行为的测试用例。 如果你不能强迫系统这样做，那么你可能已经达到了你的财产目标。 这种方法最适合安全关键型应用，在这些应用中，系统错误可能导致危及生命的应用。
有效性是指系统在计划的启动时间内实际可用并完全运行的时间百分比。 正式地，有效性等于系统的平均故障时间 （MTTF） 除以平均故障时间和修复时间的总和。 有些任务比其他任务更耗时，如果用户在执行任务时系统不可用，他们可能会感到沮丧。 因此，需要询问用户对有效性的需求，以及是否需要在任何给定时间满足业务或安全目标。
有效性要求的陈述可能是：“在工作日当地时间早上 6 点到午夜之间，系统的有效性至少为 99。5%，下午 4 点到 6 点，系统的有效性至少为 9995%。”
效率是衡量系统充分利用其处理器、磁盘空间或通信带宽的程度的指标。 如果系统用完所有可用资源，则用户可能会遇到性能下降，这是效率降低的标志。 较差的系统性能可能会激怒等待数据库查询结果的用户，或者可能会对系统的安全性构成威胁，例如过载的实时处理系统。 为了在发生不可预见的情况时实现安全缓冲，可以将其定义如下：“在预期的峰值负载条件下，必须留出 10% 的处理器容量和 15% 的系统可用内存作为备份。 “在定义性能、功能和效率目标时，重要的是要考虑硬件的最低配置。
灵活性类似于我们所知的可扩展性、增强性、可扩展性、可扩展性，它表示向产品添加新功能所需的工作量。 如果开发人员能够预见到系统的可扩展性，他们就可以选择合适的方法来最大限度地提高系统的灵活性。 对于通过一系列连续版本、增量和重复方式开发的产品来说，灵活性非常重要。
例如：“具有至少 6 个月相关工作经验的软件维护工程师可以在不到一个小时的时间内将新的打印输出就绪设备添加到系统中。 ”
完整性（或安全性）主要涉及四个方面：防止未经授权访问系统功能、防止数据丢失、防止病毒入侵和防止私人数据进入系统。 完整性已成为通过 www 执行的软件的重要问题。 电子商务系统的用户担心保护信用卡信息，网络浏览者不希望他们的私人信息或访问记录被非法使用。 对完整性的需求必须是万无一失的，即必须通过特定方法充分保护数据和访问。
用精确的术语描述对完整性的需求，例如身份验证、用户权限级别、访问限制或需要保护的确切数据。 完整性要求的示例可以描述如下：“只有具有审核员访问权限的用户才能查看客户交易历史记录。 ”
互操作性表示产品与其他系统交换数据和服务的难易程度。 为了评估所需的互操作性级别，您必须知道用户使用哪些其他应用程序连接到您的产品以及他们正在交换哪些数据。 “文字处理系统”的用户习惯于使用商业工具绘制组织结构图，因此他们有以下互操作性要求：“文字处理系统应该能够从Microsoft Visio和SmartDraw工具导入任何有效的组织结构图。 ”
可靠性是软件在一段时间内无故障运行的概率）。稳健性和有效性有时可以被视为可靠性的一部分。 衡量软件可靠性的方法包括正确执行的操作比例、系统在发现新缺陷之前运行的时间长度以及缺陷发生的密度。 可靠性要求是根据故障对系统的影响程度以及实现最大可靠性的成本是否合理来定量确定的。 如果软件满足其可靠性需求，那么即使软件仍然存在缺陷，也可以认为它已经达到了其可靠性目标。
鲁棒性是指系统或其组件在相关软件或硬件组件发生非法数据输入、缺陷或异常运行条件的情况下能够继续正常运行的程度。 强大的软件可以完好无损地从相关环境中恢复，并容忍用户错误。 当从用户那里获得鲁棒性目标时，您需要询问系统可能遇到的错误情况，以及用户希望系统如何响应。
可用性也被称为“易用性”和“人体工程学”，它描述了构成“用户友好性”的许多因素。 可用性衡量准备输入、操作和理解产品输出所需的工作量。 您必须在易用性和学习如何操作产品的易用性之间取得平衡。 “文字处理系统”的分析师会问用户这样的问题：“快速简单地创建、编辑和格式化文档对您来说有多重要？ “以及”您认为创建新文档需要多长时间？ “这只是一个简单的起点，用于定义许多使软件易于使用的功能。 对可用性的讨论可以导致可衡量的目标，例如“训练有素的用户应该能够在平均 3 分钟或最多 5 分钟内创建新文档。 ”
可维护性表示纠正缺陷或更改软件的难易程度。 可维护性取决于理解、更改和测试软件的难易程度，而可维护性与灵活性密切相关。 对于那些周期性变化或快速开发的产品来说，高可维护性很重要。 您可以根据修复问题所需的平均时间和修复正确的百分比来衡量可维护性。
可移植性是衡量将软件从一个运行时移动到另一个运行时所需的工作量的指标。 软件可移植性的设计方法类似于软件可重用性的设计方法。 可移植性对项目的成功并不重要，对项目的结果也不重要。 可移植目标必须说明产品中可移植到其他环境的部分，并标识相应的目标环境。 因此，开发人员可以选择适当提高产品可移植性的设计和编码方法。
从软件开发的长期目标来看，可重用性表示软件组件除了在最初开发的系统中使用之外，还可以在其他应用程序中使用。 开发可重用软件将比创建只打算在一个应用程序中使用的组件更昂贵。 可重用软件必须是标准化的、有据可查的、独立于特定应用程序和操作环境的，并且是通用的。 确定新系统的哪些元素需要以便于重用的方式进行设计，或者将可重用组件库指定为项目的副产品。
可测试性是指在测试软件组件或集成产品时发现缺陷的难易程度。 如果产品包含复杂的算法和逻辑，或者存在复杂的功能相互关系，则可测试性设计非常重要。 如果产品经常更改，可测试性也很重要，因为产品将经常进行回归测试，以确定更改是否破坏了现有功能。
有时，不可避免地要对某些属性进行权衡。 用户和开发人员必须确定哪些属性比其他属性更重要并确定其优先级。 当他们做出决定时，他们总是遵循这些优先事项。
例如，增强软件可重用性的设计方法还可以使软件更灵活、更易于与其他软件组件连接、更易于维护、更易于移植和更易于测试。 单元格中的减号表示单元格所在的行的属性增加了对单元格所在列的属性的不利影响。 高效率对许多其他属性有负面影响。 如果编写最紧凑、最快的，并且使用特殊的预编译器和操作系统，那么移植到其他环境就不容易了，并且很难维护和改进软件。 同样，优化操作员易用性或试图灵活、可用且与其他硬件和软件互操作的系统也将以性能为代价。
例如，与使用具有完整图形**的旧应用程序系统相比，使用外部通用图形引擎工具生成图形计划将显著降低性能。 您必须在性能成本和建议的解决方案的预期收益之间进行权衡，以确保做出合理的权衡。
为了实现产品特性的最佳平衡，您必须在需求获取阶段识别、确定相关质量属性并确定其优先级。 为项目定义重要的质量属性时，请防止与目标冲突的行为。 以下是一些示例：
如果软件要在多个平台上运行（可移植性），那么不要对可用性持乐观态度。
可重用软件普遍适用于各种环境，因此不能满足特定的容错（可靠性）或完整性目标。
对于高安全性系统，很难全面测试其完整性需求; 可重用的类组件或与其他应用程序的互操作性可能会破坏其安全机制。
在软件中，它本身并不能实现质量特性的合理平衡。 在需求获取过程中，包括对质量属性的期望的讨论，并在软件需求规范中包括您所知道的内容。 通过这种方式，可以提供满足所有项目利益相关者的产品。
本文同时发表在《软件需求探索》上。