术的进步，还可能出现新的实现方式。例如教室预订系统中，首先要进行用户身 份识别，目前主流的方法固然是采用用户名、密码的方式，但是随着技术的进步， 有可能采用指纹识别、声音识别等形式。所以在用例中说明是身份识别，而并不 写清楚具体的密码输入手段，恰恰是一种刻画“做什么”的方式，而“怎么做”可以 留待设计时再来确定。 在用例建模时，注意不要表示成功能分解。许多初学者可能对功能分解比较 熟悉，因此，在用例建模时，他会用一个用例去包含许多子用例，子用例再包含 子子用例。这种做法是不可取的。 4.3非功能需求和设计约束 非功能需求是软件产品为满足用户业务需求而必须具有且除功能需求以外 的特性。非功能需求有许多划分方法。典型的非功能需求包括： 4.3.1可用性 可用性与用户使用该系统所需要付出的努力有关，典型的可用性的指标可以 包括： ●指出普通用户和高级用户要高效地执行特定操作所需的培训时间： ● 指出需要提供的帮助用户使用系统的文档： ● 指出在符合公认的可用性标准。 4.3.2可靠性 软件系统的可靠性指的是软件产品在规定的条件下和规定的时间区间完成 规定功能的能力。可以从以下方面定义可靠性： ●可用性一指出可用时间百分比（xxXx%): ●平均故障间隔时间MTBF)-通常表示为小时数，但也可表示为天数、月数 或年数； ● 平均修复时间(MTT℉)一系统在发生故障后平均需要多少时间才能修复。 ●精确度一指出系统输出要求具备的精密度（分辨率）和精确度（按照某一 已知的标准)： 缺陷率一通常表示为每千行代码的错误数目bugs/KLOC)或每个功能点术的进步，还可能出现新的实现方式。例如教室预订系统中，首先要进行用户身 份识别，目前主流的方法固然是采用用户名、密码的方式，但是随着技术的进步， 有可能采用指纹识别、声音识别等形式。所以在用例中说明是身份识别，而并不 写清楚具体的密码输入手段，恰恰是一种刻画“做什么”的方式，而“怎么做”可以 留待设计时再来确定。 在用例建模时，注意不要表示成功能分解。许多初学者可能对功能分解比较 熟悉，因此，在用例建模时，他会用一个用例去包含许多子用例，子用例再包含 子子用例。这种做法是不可取的。 4.3 非功能需求和设计约束 非功能需求是软件产品为满足用户业务需求而必须具有且除功能需求以外 的特性。非功能需求有许多划分方法。典型的非功能需求包括： 4.3.1 可用性 可用性与用户使用该系统所需要付出的努力有关，典型的可用性的指标可以 包括：  指出普通用户和高级用户要高效地执行特定操作所需的培训时间；  指出需要提供的帮助用户使用系统的文档；  指出在符合公认的可用性标准。 4.3.2 可靠性 软件系统的可靠性指的是软件产品在规定的条件下和规定的时间区间完成 规定功能的能力。可以从以下方面定义可靠性：  可用性—指出可用时间百分比 ( xx.xx%)；  平均故障间隔时间 (MTBF) – 通常表示为小时数，但也可表示为天数、月数 或年数；  平均修复时间 (MTTR) — 系统在发生故障后平均需要多少时间才能修复。  精确度 — 指出系统输出要求具备的精密度（分辨率）和精确度（按照某一 已知的标准）；  缺陷率—通常表示为每千行代码的错误数目 (bugs/KLOC) 或每个功能点