- 具体指定数据需求
数据字典是共享的，定义了应用中所用数据元素的含义、构成、数据类型、数据长度、数据格式以及允许的取值。
哪里有功能，哪里就有数据。
系统背景图中的输入/输出流。
这些输入/输出流从高层抽象表示主要的数据元素，业务分析师在需求获取阶段也能够对它们进行进一步完善细化。
对数据关系进行建模
数据流图解释了系统中发生的加工（处理）。就像数据流图一样，一个数据模型描述了系统数据间的关系。数据模型提供的是系统数据的高层视图；数据字典提供的则是详细视图。
实体-关系图或者ERD(Robertson and Robertson 1994）。
并不意味着产品一定包含一个数据库。在设计阶段创建ERD时，其实也是在定义系统数据库的逻辑结构或者物理（实现）结构。
实体本来可以代表物理上的实体（包括人）、对待分析业务或者待实现系统至关重要的数据聚合。在ERD中，实体被命名为一个单数名词，显示在一个矩形内。
ERD中的菱形表示关系，它代表一对实体之间的逻辑关系。
每个关系上的数量关系（基数或者多个）以一个在连接实体关系间连线上的数字或者字母来表示。
数据字典
数据字典是应用中会用到的关于数据实体的详细信息之集合。数据的构成、数据类型、允许的取值等信息收集成一个公共资源。
在需求分析阶段，数据字典中的信息表示应用领域中的数据元素以及数据结构。
将数据字典保持在最新状态，那么在系统运行生命周期甚至更长的时间里它都将是一个有价值的工具
数据字典的维护是事关质量的严肃工作。
独立的数据字典可以使我们很容易找到需要的信息，而不像项目文档那样数据定义被分散在文档的各个不同部分。数据字典也有助于避免数据的冗余与不一致。
数据字典中数据实体可以表示的数据元素的类型如下。
>>原始类型（Primitive)
原始类型的数据元素将来不会再进一步分解或者没有必要再进一步分解。可以在数据字典的另外一列中描述原始类型数据的数据类型、长度、取值范围、允许的取值列表以及其他的相关属性。
>>结构类型（Structure）
一个数据结构（或者记录）有多个数据元素构成。可以在数据字典中“数据构成或者数据类型”一列中列出构成该数据结构的元素，每个数据元素用加号（+）分割。
如果数据结构中的某个元素是可选项（就是不强制用户或者系统必须提供该项数据），就用圆括号来包含它们。
>>重复的数据组（Repeating group）
如果一个数据结构中某个数据元素的实例能够出现多次，就应该用大括号来包含它们。在大括号前面用“最小值：最大值”的形式来表示允许的可能重复的个数。
数据分析
CRUD矩阵是一种严格的数据分析技术，可以检测出遗漏的需求。CRUD代表创建（Create），读取（Read)，更新（Update)和删除（Delete)。CRUD矩阵将系统行为与数据实体联系在一起，表示每个重要的数据实体应该如何创建、读取、更新以及操作。（有些人在矩阵中也使用L和M，L表示一个实体
报表的规范说明
报表的内容和格式是需求开发中需要考虑的重点。报表规范说明横跨需求（报表怎么使用数据，怎么组织数据）和设计（报表的外观样式）两个部分。
获取报表需求
定义一个信息系统的报表需求，向客户提出以下问题：
>当前使用的是什么报表？（一些报表取自现有的系统，还是从业务手工生成，现有的报表需要在新系统中重复使用吗？）
>现有的报表中哪些需要做进一步修改？（新的信息系统项目或者修订项目使我们有机会修改不能满足当前需要的报表）
>当前生成了哪些没有用处的报表？（也许在新系统中不需要实现它们）
>可以描述报表必须遵守的任何部门标准或者组织标准或者政府标准吗？比如提供一个一致的版式或者遵循一个规章？（获得一些标准的副本或者与之相符的现成报表样例）
下面几个问题可以用于探究客户需要的所有报表。
第一组问题解决的是报表的内容及其用途。
>报表名称是什么？
>报表的目的或者业务上的意图是什么？
>报表的使用者如何使用这些信息？
>谁会依照报表来做出什么决策？
>报表是手动生成的吗？如果是，又由哪个用户类型生成？多久生成一次?
>报表是自动生成的吗？如果是，生成的频率如何？他们报表生成的驱动条件或者事件是什么？
>报表的标准大小或者最大大小是什么？
>我们需要一个能够展示多个报表和/或图表的显示面板吗？如果是，用户还需要对显示面板上的数据元素进行具体查看或者概览吗？
>报表生成以后放在何处？是将它显示在屏幕上、发送给接收者、导出到电子表格还是将它自动打印出来？
>为了以后读取报表，需要将它保存或者归档到某个位置吗？
>在访问报表时是否存在一些安全上的、隐私方面的或者管理上的限制，而这些限制是针对某些特定的个人，还是用户类型？或者说有没有这些方面的限制使生成报表的人可以决定报表要包含哪些数据？
>识别出涉及安全的所有业务规则。
以下几个问题将获得有关报表本身的一些信息。
>数据源有哪些？从库中拉取数据的过滤条件是什么？
>用户可以选择的参数有哪些？
>需要哪些计算或者其他数据变换？
>排序、分页和数据求和的标准是什么？
>生成报表过程中，一个查询如果没有数据返回，系统会对此做出怎样的响应？
>对于临时报表，报表的基础数据对用户来说可见吗？
>这个报表可以作为一系列相似报表的模板吗？
对报表需求规范的几点思考
业务分析师在探究报表需求时，下面这几个建议可能有帮助。
>>考虑其他变量
摘要报表能够将具体的结果细节聚合成一个更为简洁的概要视图。“数据挖掘”的意思是生成一个报表来显示总结性数据的源数据明细。
>>找到数据
保证有供系统生成报表的必要数据。
还要识别出将要应用于计算输出数据的业务规则。
>>预期的扩大
随着时间推移，系统也会随着演变，原来在少量数据下工作良好的报表可能会变得不再能够胜任。
>>寻找相似性
是否存在一个报表，它有一定的灵活度来满足不同需求从而不需要我们重复开发以并节省重复的维护成本。
>>区别静态报表和动态报表
静态报表会打印或者显示某一时间点的数据。动态报表提供的是交互的、实时的数据。
原型报表
为演示一个可能的方案借此激发用户反馈时，仿制一个报表通常是很有价值的，或者为演示一个预期的布局而使用现成的相似报表也是一个好方法。
在仿制报表中使用合理的数据能够让评估它的用户感觉更加真实。
报表规范说明模板
| 报表元素 | 元素描述 |
| 报表ID | 用来识别报表或者分类报表的编号、代号或者标签 |
| 报表标题 | 报表名称 |
| 标题在页面上的位置 | |
| 标题中包含用来生产报表的查询参数吗（比如查询的日期范围）？ | |
| 报表用途 | 对报表缘由的项目、背景、上下文或者业务需要进行简要介绍 |
| 由报表而做出的决定 | 使用报表中信息做出的业务决策 |
| 优先级 | 实现该报表功能的相对优先顺序 |
| 报表用户 | 生成报表或者用报表做决策的用户类别 |
| 数据源 | 表示数据获取源的应用、文件、数据库式数据库房 |
| 频率以及处置方式 | 它是静态报表还是动态报表？ |
| 以多久的时间频率来生成报表？每周生成还、每月生成还是有申请时生成？ | |
| 在报表生成时有多少数据会被访问？或者包括多少个事务？ | |
| 报表生成的动机条件或者触发事件是什么？ | |
| 报表是自动生成的吗？需要人工干预吗？ | |
| 报表的接收者是谁？报表是怎样接收的（显示在一个应用中、邮件发生、打印、还是通过移动设备来查看）？ | |
| 响应性能 | 当申请发生时，报表发送给用户的响应速度要求有多快？ |
| 运行报表时，什么数据才是新数据？ | |
| 直观布局 | 横屏模式还是竖屏模式？ |
| 硬拷贝报表使用的页面尺寸（或者打印机类型） | |
| 如果报表包含图表，请定义每个图表的类型、它们的样式以及参致：标题、轴向比例和轴标、数据源等 | |
| 页眉与页脚 | 下面各项常常出现在报表页眉或者页脚中某个位置。对于包括的每个元素，我们要确定它在页面中的位置和外观，包括字体的样式和大小、文本的加亮显示、颜色、大小写以及文本对齐方式。当标题或者其他内容超出分配给它的空间时，是应被截断、换行还是做其他处理？ |
| 报表标题 | |
| 报表编号与格式（比如“第×页”或者“y页中的页x”） | |
| 报表注释（比如“本报表不包含在公司工作年限不到一个月的员工”） | |
| 报表运行时间戳 | |
| 生成报表的人之姓名 | |
| 数据源（或者多个数据源），特别是一个将多个数据源合并数据的数据库房应用 | |
| 报表起始日期与终止日期 | |
| 组织标识（公司名称、部门、logo、其他图标） | |
| 保密隐私声明或者版权通告 | |
| 报表正体 | 记录过滤条件（包含什么数据和过滤掉什么数据的逻辑） |
| 需要包含的字段 | |
| 用户指定的文字或者定制字段标签的参数 | |
| 列头部、行头部的名称和格式：文本、字体、大小、颜色、加亮、大小写、对齐方式 | |
| 数据域的行和列的布局，或者图表的位置与图表或者曲线图的参数 | |
| 每个域的显示格式：字体、大小、颜色、高亮、大小写、对齐方式、数宇取舍、位数和格式、特殊字符（Y、退号、进制、前导字符、补位字符） | |
| 当数字域和文本域溢出时如何处理 | |
| 显示的数据生成过程中涉及的计算或者其他的转换 | |
| 每个域的排序标准 | |
| 过滤条件或者在运行报表前用来限制报表的参数 | |
| 分组和小计，包括总和的格式或者小计涉及的行 | |
| 分页条件 | |
| 报表结束标志 | 出现在报表结束位置的每个指示符的外观和位置 |
| 互动性 | 如果是动态生成的报表或者说在生成过程中有交互，那么用户用来修改初始生成报表的内容或外观而有哪些选项（展开和折叠视图、关联另外的报表、深入研究数据源）？ |
| 在报表的使用会话之间，有哪些报表的设置需要持久化？ | |
| 访问安全方面的限制 | 哪些个人、团队或者组织有权限生成或查看报表的任何限制，还有他们有权选择哪些数据并将其包括进来的相关限制条件 |
仪表盘报表
仪表盘报表是一个以多个文本样式和/或者图表样式为数据表达方式的屏幕显示或者打印报表。它对组织或者一个流程的进展情况提供一个统一的、多维度的视图。
确定仪表盘报表需求的过程依次涉及需求的获取活动和分析活动。
>理解他们如何使用表示出来的数据，有助于我们选择最恰当的数据显示技术。
>识别需要表达的所有数据的来源，确保应用有这些数据源的访问权限，并知道它们是静态还是动态的。
>为每一组相关的数据选择最恰当的显示类型。
基于用户查看和使用这些信息的方式，确定仪表盘中各个不同显示的最优布局和相对尺寸大小。
确定仪表盘报表中每个显示的细节。
可能要研究的另外一些主题。
>如果显示的数据是动态的，需要多久刷新一次数据或者对数据进行一次补充，以什么方式来进行？
>为了定制显示屏，用户能够改变哪些参数呢？
>基于数据的不同，用户需要一个状态格式来使显示的那一部分有变化吗？
>哪些显示需要水平滚动条或者上下垂直的滚动条？
>用户能够放大仪表盘报表中的每一个显示来查看更多细节吗？为了释放屏幕空间，用户能够最小化或者关闭显示吗？在跨用户会话时，以什么方式来持久化用户的使用习惯？
>用户想要在不同的显示之间转换吗？是不是有可能要在表格视图和图表视图之间进行切换？
>对每一个显示部分，用户都想要深入查看更多的细节或者更基础的数据吗？
- 功能需求以外
质量方面的特性能够区分一个产品是只实现了它应该有的功能，还是一款使用户非常喜悦的产品。优秀的产品可以体现出显著的质量属性最佳平衡。
许多功能性需求起源于质量属性。
软件质量属性
能够表现出来的属性是（外部质量）一类，没有直观显现出来的属性是另外一类（内部质量）（Bass，Clements，and Kazman1998）。外部质量因素的重要性主要相对于用户而言，而内部质量对开发人员和维护人员更为重要。
内部质量属性通过使产品更容易提升性能、更易于纠正、测试开更易于移植到新平台来间接增进客户满意度。
系统不同部分可能需要强调是不同的质量属性。
| 外部质量 | 简要描述 |
| 可用性 | 当在某时某地需要系统服务时，系统服务能够被有效访问的程度 |
| 可安装性 | 正确安装、卸载和重新安装应用的难易程度 |
| 完整性 | 防止系统数据错误以及数据丢失的程度 |
| 互操作性 | 系统与其他系统或者其他组件互联或者交互数据的难易程度 |
| 性能 | 系统响应用户输入或者其他事件的快慢程度以及可预见性 |
| 可靠性 | 在故障发生之前，系统正常运行时间 |
| 健壮性 | 系统如何应对非预期的操作 |
| 安全性 | 如何防止系统被破坏性损坏 |
| 防护性 | 系统如何阻止对应用及其数据的未授权访问 |
| 易用性 | 用户对系统的学习、记忆和使用的难易程度简要描述 |
| 内部质量 | 简要描述 |
| 有效性 | 系统使用计算机资源的效率 |
| 可修改性 | 维护、修改、改进以及重构系统的难易程度 |
| 可移植性 | 使系统能够在其他操作环境中运行的难易程度 |
| 可重用性 | 在多大程度上能够把组件使用在其他系统中 |
| 可扩展性 | 随着用户数量、事务、服务器或者其他扩展，系统能够随之适应的难易程度 |
| 可验证性 | 开发和测试能够对软件进行验证以查看软件是否已正确实现的便利程度 |
探究质量属性
不同的项目需要一组不同的质量属性标准
步骤1：以一个广泛的分类为起点
首先，思考一组广泛的质量属性，减少忽略重要质量属性的可能性。
步骤2：精简列表
将各方面具有代表性的项目干系人召集起来，并评估哪些属性可能是重要的项目属性。
如果没有明确的质量目标，产品就不会展现出预期的特性。
步骤3：对属性进行排序
对相关属性进行排序，能够为将来的需求获取讨论确立重点。
怎样使用Brosseau表来质量属性进行评估。对于处于两个属性交叉点的每一个单元格，想一想“如果这两个属性我只能关注其中的一个，要选择哪个呢？”如果是所在行的质量属性更重要，就在该单元格里标记一个小于号（<）；如果觉得列顶部的属性更重要，就在单元格里标记一个插字符（^）。
表格中第2列给出了每个属性计算得出的相对分值。
步骤4：获取对每个属性的具体期望
从用户在需求获取阶段所做的评论中，可以看出他们对产品质量属性的一些看法。
向用户提出系统性能期望的一些问题：（依据情况，包括不限）
1.可接受的响应时间是多少？
2.不可接受的响应时间是多少？
3.预期的平均并发用户数是多少？
4.预期的最大并发用户量是多少？
5.在一天中、一个月中或者一年中的哪些时间里，用户访问比平时更多？
项目干系人的质量目标能够分解为功能子目标和非功能子目标，也就是需求。通过这种分解，质量目标变得更加明确，也更容易测量。
步骤5：具体指定结构良好的质量需求
过分简化的质量需求，是没有用的。
过于主观也不够具体；不现实；很少需要这么做；不可测量的。
每个质量属性的相关信息制作明确的、可验证的需求。在写质量需求时，请牢记SMART。这个缩写的含义是明确(Specific)、可测量(Measurable）、可实现(Attainable）、相关的（Relevant）和高时效（Time-sensitive）。
质量需求必须是可测量的，这样才能在业务分析师、客户和开发团队之间，对质量上的预期取得一致。
如果测试人员不能对需求进行测试，就说明它还不够好。
要标明每个属性和目标的测量规模和测量单位，值和最大值。
定义质量需求
外部质量属性↓
外部质量属性描述软件运行期间能够感受到的属性。
>>可用性
可用性用来测量预先规划的可用时间，可用时间是指系统服务可用并且可以完整操作的时间。严格来说，易用性是指可用时间与全部时间（可用时间、故障时间）的比值。更严格地说，可用性等于系统的平均无故障时间（MTBF）除以平均无故障时间与故障后平均修复时间（MTTR)之和，即 MTBF/(MTBF+MTTR）。
可用性需求有时候定义成一个类似于服务等级协议的描述。
请警惕将100%作为类似可靠性或者可用性这样质量属性的期望值。
在获取易用性需求时，提出的问题要涉及以下几个要点（Miller 2009）。
>系统中哪一部分与易用性关系最大？
>如果系统对用户而言不可用，会有怎样的业务后果？
>如果必须进行周期性的例行维护，应该在什么时候进行？它对系统可用性有哪些影响？维修期的最短时间和最长时间是多少？在维护期间怎么管理用户访问请求？
>如果在系统运行期间必须进行维护或者内务处理工作，那么它们对系统的可用性有哪些影响，这些影响怎样才能降到最低、最小？
>当系统不可用时，需要有哪些必要的用户通知？
>系统的哪一部分需要有（比其他部分）更为严格的可用性需求？
>在功能性模块之间，存在哪些可用性依赖？
>>可安装性
可安装性描述的是正确安装软件的难易程度。
可安装性涉及下列活动：
>初次安装
>从一个不完整的错误的或者用户放弃的安装过程中恢复
>重新安装同一个版本
>安装新版本
>回退到上一个版本
>安装另外的组件或者升级
>卸载
可安装性的度量方式是系统安装的平均时间。
在获取可安装性需求时要提出以下几个问题。
>哪些安装操作需要在不打断用户会话的情况下进行？
>哪些安装操作需求重启应用？或者是重启机器或设备？
>当安装成功或者失败以后，应用需要做出哪些反应？
>对安装验证进行确认时，需要执行哪些操作？
>对于应用中选择的组件，用户有安装、卸载、重新安装或者修复的操作吗？如果是，可以对哪些组件执行这些操作？
>在执行安装操作之前，需要关闭其他哪些应用？
>安装人员需要具有哪些授权或者访问权限？
>对于没有完成的安装过程，系统应该怎样处理？比如因断电或者用户
>主动放弃而没有完成的安装？
>>完整性
与完整性相关的问题有防止信息丢失、输入到系统的数据正确性保证。完整性需求不能容忍任何错误：数据必须以正确的形式存在，并且受到保护。
数据完整性还涉及数据的准确性以及恰当的数据格式方面的问题：
>保证对数据的修改是完整的，而不是部分修改。这可能意味着如果在过程中操作失败，需要对数据进行回滚。
>保证在数据上实施的永久化操作正确完整。
>协调好对多个数据存储做的修改操作，尤其多个存储需要同时进行的
>操作（比如有多个服务器）以及在同一个时间点上的操作。
>保证计算机和外部存储设备的物理安全。
>执行数据备份。
>从备份中恢复数据。
>数据存档：存档什么数据？存档时间以及存档频率如何？有哪些删除需求？
>对存储或者备份在云上的数据进行保护，只允许有权限的用户访问。
>>互操作性
互操作性表示系统与其他软件系统之间交换数据和服务的难易程度以及系统与外部硬件设备集成的难易程度。
将它表述为一个外部接口需求
互操作性可能会限定使用标准的数据交换格式来便于与其他软件系统进行信息交换。
互操作性问题：
>还有其他哪些系统需要连接？它们要交换什么服务或数据？
>在与其他系统进行数据交换的过程中，有哪些标准的数据格式是必须要有的？
>哪些特定硬件设备要与系统有必要的连接？
>系统必须从其他系统或设备上接收和处理哪些消息或编码？
>互操作性，需要哪些必要的标准通信协议？
>系统必须满足哪些外部强制性互操作性需求？
>>性能
性能代表系统对各种用户查询和用户行为的响应性能力，但它包含的内容远不止这些，
有关性能的几个因素
| 绩效指标 | 范例 |
| 响应时间 | 显示网页需要的时间（以秒计算） |
| 吞吐量（流量） | 每秒钟处理的信用卡业务量 |
| 数据容量 | 在数据库中存储的最大记录数 |
| 动态容量 | 社交媒体网站上最大的用户并发量 |
| 实时系统中的可预测性 | 飞机飞行控制系统中的硬实时需求 |
| 延迟性 | 音乐录制软件中的时间延迟 |
| 在低降级模式或者过载状态下的行为 | 自然灾难导致超大量紧急电话系统呼叫 |
性能是一个外部质量属性，因为它只有在运行期间才能体现出来。
>>可靠性
可靠性是软件在指定时间段内无故障运行的概率（Musa 1999）。
与可靠性紧密相关的是健壮性和可用性。
可靠性问题：
>怎样判断系统是否有足够的可靠性？
>在执行系统的某些操作时，如果有故障发生，会有什么样的后果？
>与普通的故障相对应，你认为哪些故障是非常严重的？
>在什么情况下故障会对业务操作造成严重后果？
>没有人喜欢系统崩溃，然而系统中是否有某些部件必须超级可靠？
>如果系统宕机，在对业务操作产生重大影响之前，可以允许它离线多长时间？
一个让系统既有可靠性也有健壮性的方法是，识别异常及相应的处理方式。
>>健壮性
健壮性指系统遇到非法输入、与软件或者硬件部件连接相关的错误、外部攻击或者异常操作情况时，系统功能还能够继续正确运行的可能性。
它以一种让用户感觉合理而不是恼怒的方式来对待软件发生的错误。
与健壮性相关的其他质量属性是故障容忍度和可恢复性。
>>安全性
安全性需求与防止系统对人员造成伤害或对资产造成破坏的需求相关(Leveson 1995;Hardy 2011）。安全性需求可能由政府规定或者其他业务规则来决定，并且法规或者认证方面的条款与这样的需求相关联。安全性需求经常以严禁系统发生某些状态或行为的方式来写。
提出以下这些问题：
>在什么条件下，使用该产品的人会受到伤害？
>系统如何检测这些条件？又该如何应对？
>对可能带来伤害的故障，可容忍的最大故障频率是多少？
>哪些失败方式可能造成人员伤害或财产损失？
>哪些用户行为可能有非蓄意人员伤害或财产损失？
>是否有特定操作模式有人员或财产方面的风险？
>>防护性
防护性是指阻止对系统功能或数据的非授权访问，目的是保证软件免遭恶意攻击等。
可以考虑以下几点：
>用户认证或者权限等级和用户访问控制用户识别和用户认证。
>数据私密性。
>数据销毁、数据损坏或数据窃取，慎之又慎。
>防止病毒、蠕虫、僵尸、间谍、rootkitsyi以及其他攻击。
>防火墙和其他网络安全顾虑。
>安全数据的加密。
>对执行的操作和访问意图建立审核机制。
防护性需求往往源于业务规则，比如企业安全政策。
在写防护性需求时，尽量避免引入设计限制。
可以探究以下需求问题：
>对于来自非授权的访问，哪些敏感数据必须加以保护？
>哪些用户有权查看敏感数据，特别要具体指出哪些用户没有权限查看？
>在什么业务条件下或者在什么操作时间段允许已授权用户进行功能访问？
>为了确保用户的确是在一个安全环境下操作应用，需要做哪些必要的检查？
>软件的病毒扫描频率是多少？
>有没有必须用的特定安全认证方法？
>>易用性
用户友好程度、容易使用与否以及人体工程学，易用性就与它们有关。
有学习难易程度：可记性；错误的避免、处理和恢复；互操作的效率性；访问能力和人体工程学。
易用性指标包括：
>某特定类型用户正确完成某个任务需要的平均时间
>在指定的时间段内用户能正确完成多少事务
>不需要帮助的情况下，用户正确完成的任务占比多少
>用户在完成一个任务时犯了多少错误
>用户在完成某一个特定任务时尝试了多少次，比如在菜单的某一处寻找一个特定的功能
>执行任务时延迟或者等待了多长时间
>获得某信息或者完成一个任务需要多少次交互
内部质量属性↓
内部质量属性在软件运行期间不会直接表现出来。
查看设计或者代码的过程中能够感知到内部质量属性。
>>有效性
有效性是系统对处理器性能、磁盘空间、内存或者通信带宽使用的衡量指标。如果系统消耗太多的可用资源，用户就会遭遇性能下降。
在定义有效性、能力和性能目标时，要考虑最低硬件配置需求。
>>可修改性
可修改性指软件设计和软件代码能够理解、修改和扩展的难易程度。
可修改性与可验证性密切相关。
正在以增量或者迭代生命周期方式开发的系统，较高的可修改性至关重要。
>可修改性的几个因素
| 维护类型 | 可修改性特征 | 描述 |
| 改进型 | 可维护性，可理解性 | 修正缺陷 |
| 优化型 | 灵活性，可扩充性，可扩张性 | 为满足新业务和新需求的需要而对功能进行增强和修改 |
| 适应型 | 可维护性 | 不增加额外的功能，只是修改系统，使其可以在另外的操作环境中运行 |
| 现场支持 | 可支持性 | 修正故障、服务设备或者在其操作环境中修理设备 |
可移植性
将软件从一个操作环境中移植到另一个环境中所需的工作量可以用来衡量可移植性。
可移植性问题：
>软件需要在哪些不同的平台上运行，不管现在还是将来？
>软件中的哪些部分需要设计成比其他部分具有更强的可移植性？
>哪些数据文件、程序部件或系统中其他哪些元素需要具备可移植性？
>使软件更容易移植，可能会损害其他哪些质量属性？
>>可重用性
可重用性是指将一个软件组件用于另外一个应用时所需要的相关工作量。可重用的软件必须是模块化的、文档齐全的、不依赖于某一特定的应用和操作环境并且具有一定的通用性。
有很多项目工件都具有潜在的可重用性，包括需求、架构、设计、代码、测试、业务规则、数据模型、用户类别描述、项目干系人概要信息、词汇表。很多方法能帮助增强软件的可重用
可重用性需求问题：
>现有的哪些需求、模块、设计组件、数据或测试能够重用于这个应用？
>相关应用中的哪些功能可以满足当前这个应用的特定需求？
>该应用中的哪些部分可能可以重用于其他部分？
>为了使这个应用中的某些部分更有可重用性，需要采取哪些行动？
>>可伸缩性
可伸缩性需求指的是在不损害性能或者不影响正确性的情况下，系统可以适应更多用户、设计、服务器、地理位置、事务、网络流量、查找和其他服务的能力。
可伸缩性具有硬件和软件的双重含义。
可伸缩性与可修改性、健壮性相关.
>>可验证性
狭义地讲，可验证性就是可测试性，指为了验证系统功能是否已经正确实现，而对软件组件或者集成产品进行评估的难易程度。
可验证性问题：
>我们怎样确定某个特定计算输出的是期望的结果？
>系统中有没有不能够产生确定性输出的部分，比如很难确定它们是否正确运行？
>让测试数据集尽可能揭示出需求或者其实现中所有的错误，可行吗？
>我们可以用有哪些引用报告或者其他输出来验证系统产生的输出是否正确？
用Planguage指定质量需求
不能依靠产品评估来判断它是否满足含糊的质量需求。不可验证的质量需求并不见得比不可验证的功能性需求好。过于简单的质量和性能目标没有实际意义。
需额外参考词条：Planguage
质量属性的平衡
单元格中的加号表明，增加所在行对应的质量属性通常对对应列中的属性也有正面的影响。
单元格中的减号表明，增加所在行中的属性通常会损害所对应列中的属性。
空的单元格表明，所在行属性对所在列的属性影响很小。
所选择的质量属性之间的正负关系
质量属性需求的实现
虽然是非功能性需求，但可以衍生出功能性需求、设计原则或者能够产生预期产品特性其他类型的技术信息。
将质量属性翻译为技术性规格描述
| 质量属性 | 可能的技术信息类型 |
| 可安装性、完整性、互操作性、可靠性、健壮性、安全性、防护性、易用性、可验证性 | 功能性需求 |
| 可用性、有效性、可修改性、性能、可靠性、可扩展性 | 系统架构 |
| 互操作性、安全性、易用性 | 设计约束 |
| 有效性、可修改性、可移植性、可靠性、可重用性、可扩展性、可验证性、易用性 | 设计原则 |
| 可移植性 | 实现约束 |
缺少开发经验的业务分析师可能不明白质量需求中的技术性信息。
应该让开发人员在早期就参与需求获取和评审活动。
约束条件
约束条件制约着开发人员对设计或者实现的选择。约束可以由外部的相关人员提出，也可以产生自其他系统（这与正在创建或者维护的系统有交互）或者是来自系统生命周期中的一些活动（比如事务和维护）。
约束来源包括以下几类:
>必须要用或者要避免的特定技术、工具、语言和数据库。
>因产品操作环境或者平台而产生的约束。
>需要遵循的开发约定或者标准。
>早期产品的向后兼容与潜在的向前兼容能力。
>受法律规章或者其他业务规则决定的限制性或者合规性需求。
>硬性限制。
>由操作环境或由用户特性和局限所造成的物理性约束。
>对现有产品进行优化时要遵循的现有接口约定。
>与其他现有系统的接口，比如数据格式和通信协议。
>显示屏幕尺寸的限制。
>使用的标准数据交换格式。
用户描述 “需求”时，他们描述的实际上是为满足想象中的某个需要而讲述的某个特殊解决方案