军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


软件需求规约

软件
需求
规约 软件需求规约 (SRS) 记录对于系统或系统一部分的完整软件需求。

以下的部分信息来自 IBM Corporation 所提供的内容。

主题
解释
是文档还是包？
从前景到 SRS
活动的工件
项目成员的参考标准
定义功能性需求
定义非功能性需求
1 概述
1.1 假设与问题
1.2 地理组织
2 指定
2.1 预选的应用程序包？
2.2 其他指定
2.3 特殊硬件？
2.4 现有数据？
3 标准
3.1 技术构架/战略计划
3.2 网络构架
3.3 连接策略
3.4 其他策略？
4 数量
4.1“评测单元”
4.2“业务量和大小”
4.3“业务流程性能标准”
5 可用性
5.1 可用性建议
5.2“计划中的服务时间”
5.3“服务中断成本”
5.4“可用性和恢复标准”
5.5“灾难恢复？”
5.6“需考虑的其他可用性设计事项”
6 安全性
6.1“安全性需求”
解释
软件需求规约 (SRS) 侧重于收集和组织与项目有关的所有需求。请参见需求管理计划以决定如何确定并组织需求。例如，您可能希望用一个独立的 SRS 来说明产品的某一特定版本中各项特性的全部软件需求。这可能包括几个来自系统用例模型中的用例，以此来说明此特性的功能性需求，以及补充规约中一系列相关的详细需求。

由于您可能使用几种不同的工具来收集这些需求，所以，重要的是要认识到需求可以在数个不同的工件中使用不同的工具找到。例如，您可能发现使用补充规约中的文本记录工具来收集文本需求（诸如非功能性需求、设计约束等）很合适。另一方面，您可能又发现收集用例中的一些（或所有）功能性需求非常有用，还可能发现使用满足用例模型定义需求的工具非常方便。

是文档还是包？
我们发现，并没有充分的理由需要我们注重所用工具之间的差异。毕竟，您是在收集需求，您的重点应放在有效地收集和组织需求上，而不是考虑所使用的工具。由于我们的重点是需求而不是工具，所以我们将假定 SRS 中的需求集合构成了一个信息包。对各种系统需求的详细说明包括在名为软件需求规约 (SRS) 的包中。

从前景到 SRS
很明显，SRS 包与前景文档有关。事实上，前景文档可用作对 SRS 的输入。但这两种工件却服务于不同的需要，并且通常由不同的作者来编写。在项目的这一阶段，项目的重点已经从概括地说明用户需要、目的和目标、目标市场和系统特性转移到将如何在解决方案中实施这些特性的具体细节。

我们现在需要的是用一个工件集合（或包）来描述系统的全部外部行为；例如这样一个包，它明确地说明了“为了交付这些功能，系统必须执行以下操作”。这就是我们所说的 SRS 包。

活动的工件
SRS 包并不是一成不变的大卷文档：为了确保符合 ISO 9000 标准，我们编制好 SRS 包，然后就把它放在角落里，在随后的项目过程中不再加以理会。与此相反，它是一种活动的、有生命的工件。事实上，当开发人员着手进行他们的实施工作时，它起到了很多关键的作用：它充当了所有各方之间的交流基础，例如充当了在不同开发人员之间以及在开发人员和他们必须与之交流的外部小组（用户和其他涉众）之间的交流基础。它以正式或非正式的方式代表了各方之间的契约性协议：如果不是 SRS 包中的内容，开发人员就不应处理它。如果是 SRS 包中的内容，那么开发人员就有责任交付该功能。

项目成员的参考标准
SRS 可用作项目经理的参考标准。项目经理不太可能有足够的时间、精力或能力来阅读开发人员生成的代码，并将其直接与前景文档进行比较。他们必须将 SRS 包用作与项目团队进行讨论的标准参考。

如上文所述，它可用作对设计和实施小组的输入。根据项目的组织方式，在问题解决及性能定义活动最终生成前景文档之前，实施员可能已经参与了这些活动。但在确定他们的代码必须做什么的时候，他们需要重点关注的则是 SRS 包。SRS 包充当了对软件测试和 QA 小组的输入。这些小组也应参加一些早期的讨论。很明显，这会助于他们充分地理解前景文档中所阐述的“前景”。但是，他们的职责是创建测试用例和 QA 过程，以确保所开发的系统确实满足了在 SRS 包中提出的需求。对于他们而言，SRS 包还可用作计划和测试活动的标准参考。

定义功能性需求
请参见指南：用例模型和指南：用例，以详细了解在用例模型和用例中定义功能性需求的推荐方法。

定义非功能性需求
对系统的非功能性需求应记录在工件：补充规约中。 在定义这些需求时，需要遵循以下原则。

1 概述
1.1 假设与问题
当收集并验证非功能性需求时，应维护一个“假设与问题”列表。

有些活动将无法为您提供令人满意的答案。这可能是由于缺少信息，也可能只是因为您考虑到该答案会危及设计的可行性。因此，应创建两个列表，并通过以下的设计研究来维护这两个列表：

您在需求和设计流程中作出的所有假设，包括这些假设的基本原理或思维过程。可能用来确定此项目之外（或之后）的相关子项目或工作项的假设。

所有主要问题（可能会中断项目进行的重要事项）。

在每个阶段结束时，应该与客户一起对这些问题进行复审。这些假设也需要在每个阶段结束时进行复审，但是对于不太重要的假设，客户有可能并不是合适的复审人选。

假设与问题适用于所有工件，但对于非功能性需求尤为常见。

1.2 地理组织
记录客户的地理组织。

记录受该系统影响的业务部分所处的地理位置。定义中还应包括那些未受影响但安装有主要 IT 设备的工作地点。特别要记录组织中的所有移动工作部门。例如，将四处旅行并使用工作站的销售部门。记录下您可能需要提供特殊的自然语言支持 (NLS) 的所有地理位置。

2 指定
2.1 预选的应用程序包？
需求是否指定使用任何应用程序包？有些指定可能会强烈要求作出一些系统设计决策，其中的一项非常重要的“指定”就是使用可提供预定义软件逻辑和数据组织的特定应用程序包。有些软件包比较灵活，允许进行大量的定制，而有些则非常固定，不允许进行定制。包可能会要求如下构件和决策：

工作站类型
连接方法
处理器和 DASD 类型
系统控制程序
数据组织、存放和管理
编程语言
批接口
进程和数据关系
业务逻辑
屏幕设计和最终用户界面
性能和可用性特征
任何现有或必需的打印构架，如首选的打印数据格式（例如 PostScript、PCL、IPDT）
国家语言支持 (NLS)
务必要意识到：影响任何指定程序包的因素也将会影响您的设计。如果您有一个“指定”包，则应确保您能获得有关该包的适当技能和知识。这些技能和知识可能来自：

包的厂商
外部顾问
经过专门培训的设计团队成员
不要认为这些知识很容易获得。要确保您能够在需要时获得这些知识。

2.2 其他指定
在需求中记录下将限制设计灵活性的任何其他指定。

如果您在早期活动中没有明确地考虑到有些可能会限制设计灵活性的特定需求，现在您就要确定并记录所有这些需求。例如，确定并记录以下需求：

使用现有的处理器或操作系统映像
使用现有的工作站设备
使用现有的网络
使用现有的系统管理惯例
使用特定的模型，例如：“要在设计中清楚地显示表示/业务/数据访问逻辑以及它们相互作用的位置和方式，您就必须使用客户机/服务器系统模型”。
这些指定是否将影响新的系统？如果新系统将在现有的处理器、操作系统映像或网络配置上运行，现有的平台和工作量特征是否将影响新系统？

现有的工作量已经包括了多少连接和处理容量？

现有工作量使用的是什么安全性控件？记录下这些内容，并在您考虑新系统的安全性需求时对照需求检查这些内容。

现有工作量具有什么可用性特征？

记录下可能会影响随后进行的新系统可用性设计的所有事项。例如，现有工作量是否一定要求在每天晚上关闭整个处理器？

2.3 特殊硬件？
需求是否指定要使用任何特殊的硬件？

这可以用一般性的术语来陈述（“系统必须支持高速平板绘图仪”），也可以更具体些（“系统将支持现有的 Panda Corp ATM”）。尽量记录以下内容：

任何硬件或软件先决条件
厂商及其支持组织
国家语言 (NLS) 考虑事项
加密设备
2.4 现有数据？
需求是否指定要使用现有数据？如果这样，这一指定就将影响到您的系统设计。应记录：

数据当前位于什么系统上
现有数据的结构（如关系型文件或平面文件）
大小
目前哪些用户和系统在使用这些数据
可用性考虑事项（例如，由于进行数据库维护或批处理活动而导致数据不可用的时间段）
这些数据是否可以移动或复制？
3 标准
3.1 技术构架/战略计划
客户是否具有技术构架和/或 IT 战略计划（或等同的标准集合）？

技术构架大致等同于：

企业技术平台
企业技术基础设施
技术构架
在技术构架中，您可能会发现已定义了如下内容：

计算中心的数量和用途
企业的网络连接性 (WAN)
某些设施的局部连接性 (LAN)
客户机/服务器基础设施服务（中间件）覆盖范围
• 跟踪网络资源和属性的目录及命名服务
• 防止网络资源受到正在注册用户非法使用的安全服务以及此类用户的权限级别
• 校准整个网络的日期与时间的时间服务
• 协调网络中各种系统的资源恢复活动的事务管理服务

将用于新应用程序的开发方法
已接受的可支持产品集，例如：
• 硬件
• 系统控制软件
• 常用的应用程序，如“Office”
• 帮助台使用
• 安全规则

打印子系统构架
该列表可能会涉及非常广泛的内容，其中的所列项可能会非常严格地实施，也可能根本不执行。

记录任何明确要求使用（或排除）某些子构架的需求，例如：

OSI 或 SNA
UNIX**
SAA
使用 OS/2* EE 的 PS/2*
因使用封装的应用程序解决方案而需要的特殊构架。请记住，某些应用程序包本身就可形成构架定义。

记录客户所需的开放程度（即厂商独立性和互操作性）。如果存在技术构架，那么几乎可以肯定，您的设计将必须与它保持一致。您应该阅读技术构架文档，以了解将影响系统设计的规则。

3.2 网络构架
客户是否有任何网络构架需要该系统必须与之相符？网络构架是一组公用的高层连接性规则，外加一个公用传输基础设施。它可能包括对主干网络（包括集线器和线路）的定义。如果存在这样的构架，则应了解基本的规则和拓扑，并记录：

物理拓扑方面的考虑事项（例如，网络基本上位于农村还是大城市，以及网络附属装置是密集分布还是松散分布）。

当前网络基础设施支持哪些高层连接功能。

使用哪些通信标准（例如 SNA、OSI、TCP/IP）来支持这些连接功能。

支持哪些编程接口。

对客户机/服务器层或基本系统模型层之间连接性的任何网络构架定义，例如：

客户机工作站和 LAN 关系型服务器之间的关系型数据访问必须要借助于特定关系数据库产品的协议。
表示逻辑必须始终在工作站中，而数据访问逻辑则必须始终在集中式主机系统中。
3.3 连接策略
客户是否规定了任何连接策略？

即使您没有技术或网络构架，但您仍然可能有一些连接策略。

记录与以下内容有关的任何策略：

使用特殊的协议或通信设备（以便在单独的建筑物内，或者在建筑物或组织以外的地方实现连接）。
是否隐含地要求用任何特定的协议来支持现有的设备或软件。
是否将使用现有的物理连接设备（例如电缆或电线、网络或外围控制器，以及常用的载体）。如果不使用，则可能是因为可使用的物理设备类型存在约束（政策、政府法规、物质空间、房产所有权、第三方的参与）。请记录下这些内容。
如果可能需要安装或修改物理设备，则可能需要一个或多个第三方（如承包商或公用通讯公司）的参与。了解应该如何进行承包或职责管理。如果业务交互将涉及国际性连接，这种管理就尤为重要。
对移动用户的支持。
3.4 其他策略？
客户是否有任何其他策略、标准或规则没有在其需求中明确声明？例如：

最终用户的所有新系统接口必须根据面向对象原则进行设计，允许拖放操作。
所有新系统必须基于客户机/服务器应用程序模型。
所有新系统必须按照公开标准进行定义。
国家语言支持 (NLS) 的标准和政策，尤其是象从右向左文本操作这样的标准。
定义用户身份验证、访问控制和数据保护的管理职责与标准的安全性策略。
可能需要使用特殊的连接或安全设备的应用程序交换标准（如 UNEDIFACT 或 VISA）。
如果存在其他策略，则务必要理解这些策略并且有权使用它们，以便使您的设计在设计流程的后期达到这些标准。使用封装的应用程序解决方案时，可能会引入一些隐含的标准。

对于用户或部门是否可以在以下系统中添加和/或开发他们自己的本地程序，实施的是什么策略？

工作站
服务器（尤其是对磁盘空间的使用）
如果不加以控制，您可能发现本地程序会很快耗尽生产系统所需的资源，而本地构件原本是为了这些生产系统而购买的。到最终准备首次公开展示生产系统时，您可能发现该系统无法安装。

4 数量
4.1“评测单元”
与应用程序开发人员合作，将业务流程细分为更小的单元，如更小的业务流程或事务。

这样做的原因是，您将在下一个问题中记录数量，因而必须确定您的计数对象。

要注意到，一个业务流程可能会启动几个更小业务事务（例如各个客户订单中的多项订购商品）的实例，当记录数量时应记住这些乘数。但也不必过分地深究细节，尤其对于复杂的系统更无此必要。

通常，一个业务“流程”（如客户订单处理）将由一个“应用程序”（IT 术语）来实施，但它也可能由多个应用程序来实施。在每个应用程序中，通常会有很多 IT“事务”，例如，“查询库存水平”或“生成客户信函”。

不同的人群会使用他们各自的名称来标识我们试图一致认同的单元。例如，“事务”对于具有应用程序开发背景的人来说可能是一种意思，而对于基础设施团队来说则会是另一种完全不同的意思。因此，务必要通过相互协作使名称相互关联关系，然后再进行信息收集。

4.2“业务量和大小”
确定并记录 4.1“评测单元”中每个单元的业务量和大小信息，例如：

预计在一般时间和在高峰期将各有多少用户使用各个业务流程或应用程序？
什么时候是高峰期（根据情况确定每天、每周、每月等的高峰期）？
在高峰期和一般时间将各需要以什么速度处理事务？
在每个数据组中数据元素和实例的数量以及它们的大小。
4.3“业务流程性能标准”
客户可能指定了部分或所有业务流程的性能标准。但还要注意记录系统支持流程（如系统备份）和应用程序开发流程的性能目标（如果已确定）。对于每一类别，应记录：

对各类别的响应/周转需求
将在哪里对其进行评测
在不同时间（例如非高峰时间/夜间）是否可以接受不同的标准
在恢复或应急期间是否可以达到标准
是否需要性能保证
如果没有达到性能需求，将对所有各方产生什么影响
表述业务流程被认为可用的最低性能条件（也就是说，在该点以下，系统将被认为是“不可用”而不是“缓慢”）。
如果已经选择了一个封装的应用程序解决方案，则务必知道如何访问它的性能特征。您现在可能根本不需要这些性能特征，但是将来一旦需要，您应该知道从哪里找到它们。让第三方提供您需要的数字可能也要花费一些时间，所以现在就应提出要求。
5 可用性
5.1 可用性建议
下面是确定可用性需求的推荐方法：

确定系统的真实最终用户、他们正在执行的业务流程以及最终用户执行这些流程的时间（小时）
分析服务可用性（或不可用性）将如何影响最终用户完成其业务目标的能力
指定适当的可用性需求，以直接反映最终用户为了完成其业务目标而具有的需求
请注意，如果已经选择了封装的应用程序解决方案，那么它的结构和设计可能会对最终用户所看到的应用程序可用性特征产生重大影响。未被设计来进行连续操作的包可能很难进行连续操作，尤其是在维护和批窗口等方面。
当您确定可用性需求时，应考虑以下原则：

以较小的间隔（例如按照各个流程、用户组、数据组等）来指定可用性需求，而不要指定整个系统的“全局”需求。这样，设计人员就能够更加灵活地满足最终用户的需要。如果系统具有非常高的连续可用性需求，这就尤其重要。
下面是一些示例：

语句“系统必须每天 24 小时为纽约和香港的用户提供服务”为设计人员提供的设计灵活性就不如语句“从纽约时间上午 7 点到下午 7 点，纽约用户必须能够对他们的数据执行事务处理；从香港时间上午 7 点到下午 7 点，香港用户必须能够对他们的数据执行事务处理”。在后一种情况中，即使一个时区仍然处于其工作日的工作时间，设计人员也可以对另一个时区的数据或系统构件进行维护，这就具备了更大的灵活性。
在一个 ATM 应用程序中，在星期一上午 3:00 能够执行存款和取款功能可能是很重要的，而在这个时间是否能够准确地提供帐户余额信息则可能不太重要。
应区分开希望的可用性特征和强制的可用性特征。例如，“ATM 必须能够每天 24 小时接受存款和取出现金。希望 ATM 能够每天 24 小时为客户提供准确的帐户余额信息；不过，在帐户余额查询过程中可以有偶尔的中断，但中断持续时间必须少于 10 分钟，并且只能发生在上午 3:00 到上午 4:00 之间”。
如果未达到特定的可用性目标也不会对用户完成其业务目标的能力产生直接的影响，那么该可用性目标就可能不适合于作为系统的可用性需求。
如果可用性需求只是间接地反映了最终用户所感受到的可用性（例如“必须建立 IMS 控制区域”），这样的可用性需求通常不如那些直接反映可用性的需求有用（例如“银行出纳员必须能够执行流程 X 和 Y”）。
5.2“计划中的服务时间”
对于每个业务流程和必须执行这些业务流程的用户组，应确定用户必须能够执行该流程的时间。对于那些与用户组并不直接相关的流程，也要确定其执行时间。

如果用户组位于不同的时区（如前面的纽约/香港示例），则应将他们当作单独的用户组。

同时要说明是否将存在可能不需要应用程序的偶然时间段（例如业务假期）。（这样，设计人员就可以灵活地在这些时间段进行大规模的维护）。在预计的应用程序生命期内，这些服务时间将会发生什么变化？

当系统与其他系统进行相互作用时，该系统的服务时间还可能会受到这些系统的服务时间的影响。

该系统的计划服务时间在其预计的生命期内将会发生什么变化？

5.3“服务中断成本”
了解在计划服务时间内发生的服务中断将带来的相关业务影响、财务成本和风险。

要确定对于该系统非常重要的可用性需求，应考虑业务流程集和用户组，并确定以下情况将对业务造成的影响：

在计划时间内发生短暂的中断或出现响应极其缓慢的时间段。当定义“短暂”和“极其缓慢”这两个短语时，应考虑到所使用的特定应用程序（请参见“业务流程性能标准”）。
在上面的时间内出现各种延续时间更长的服务中断（1 分钟、数分钟、15 分钟、30 分钟、1 小时、2 小时、4 小时等）。
长时间的服务中断（一次换班、一天、许多天等）。
还要考虑与用户组不直接相关的任何流程（例如夜间票据交换）。
在评估每种中断的影响时，应确定应急过程并考虑这些过程如何能减少中断对业务所造成的实际影响。

尽量从财务上量化这种影响（员工或设备生产效率降低的成本、失去当前业务的价值损失、因客户不满意而对未来业务造成的估计损失、利息开支、法规性处罚等）。

尽量提供较多的应对方案。这些方案必须反映因中断情况不同而产生的相关成本和风险差异。这些不同的中断情况包括：中断持续时间长短不同、中断在一天中发生的时段不同、计划中断或意外中断、中断影响的业务流程或用户不同等等。

在预计的系统生命期内，服务中断对业务/财务的影响将会发生什么变化？

对这些已认同的重要业务流程逐一复审，以确定当系统的某些部分暂时不可用时，可以采取哪些替代方案来使这些流程中最关键的元素继续运行。要减少关键流程和数据间的相互依赖性对可用性产生的影响，可以进行业务功能缩减的临时操作。

下面是一些示例：

完整功能 1：读取和更新股票记录。
缩减功能 1：输入股票记录的更新数据，并排队等待以后的更新。
完整功能 2：读取最新的客户余额。
缩减功能 2：从可能不很新的备选来源中读取客户余额。
完整功能 3：更新计算机日记。
缩减功能 3：更新日记的硬拷贝。
请记住，当系统在缩减功能状态下工作时，对于业务流程可接受的缩减功能可能会有所限制。例如，过时的客户余额信息的过时时间不得超过 24 小时。

如果服务在计划时间内中断（请参见“计划中的服务时间”），则中断的影响通常会根据中断持续时间及其他条件而有所变化。有些中断可能会对用户执行其业务流程的能力产生最低程度的影响（短暂中断、在一天中使用率不高的时间段内出现的中断、只影响用户组中部分人员的中断、或存在可接受的手工应急过程的中断）。其他中断（如延续时间较长的中断、或在一天中的“重要”时间段内发生的中断）则可能会产生更重大的影响。

下面是一些示例：

一个生产线控制流程的短暂中断可能只会对生产效率产生最低程度的影响，因为可以按照先前打印的工作单继续进行工作，且可以将变更手工记录下来以便随后输入。但是，如果中断的持续时间超过六十分钟，生产线就可能会在剩下的工作时间中停止运行。
如果一个金额巨大的财务清算系统在交易的最后时间内发生中断，则可能会导致严重的利息成本损失或法规性处罚。
如果警察和消防部门的人员派遣系统无法使用，那么使用手工应急过程，他们仍然能够继续对威胁生命的紧急事件作出响应。但是，由于增加了人员派遣系统的工作量，响应时间将会增加，这仍可能危及生命安全。
当航班或旅馆的预订系统在高峰期发生中断时，如果客户暂时联系其他竞争者，则可能不会造成当前业务的损失，但是，如果客户感到很不满意，以致在下次需要这些服务时首先与其他航班或旅馆联系，那么就还会给未来的业务造成损失。
5.4“可用性和恢复标准”
确定在“正常”情况下所采用的可用性和恢复标准。

不包括“灾难”情况，例如损失严重或整个计算设备关闭。

根据在“服务中断成本”中确定的业务/财务成本和风险来制定可用性标准的规约，必须满足这些可用性标准才能避免严重阻碍用户执行他们所负责的业务流程。可以按照如下形式指定这些标准：

在给定的分钟/秒钟数内被恢复的中断所占的百分比。
在给定的周/月/年内，用户无法执行特定功能的最大时间长度。
尽量具体地反映各种必要因素，例如计划中和计划外中断之间的差异、发生中断的时间（例如，是“关键”时间段还是使用率不高的时间段）、受到影响的用户（例如，是所有用户还是少数几位用户）等。

注意不要指定不太紧迫的可用性标准，因为这会显著影响实施成本。一般来说，如果在一组给定的中断条件下无法确定重要的业务/财务成本或风险，则可能表明不应当在规定的可用性标准中包括这些中断条件。

如果“计划中的服务时间”表示计划中的服务时间有可能会发生变化，并且/或者“服务中断成本”表示与服务中断相关的业务/财务成本或风险有可能在预计的系统生命期内发生变化，那么，应该估计这些情况会使可用性标准发生什么样的变化。

如果将使用加密系统，还将有其他的恢复和可用性事项需要考虑。例如：

能够恢复可能保存在系统外的机密信息。
确保加密保护数据的恢复与相应加密密钥的恢复相互协调。
5.5“灾难恢复？”
在该设计项目的范围内，是否需要灾难恢复（在“灾难”情况下的可用性，例如在损失严重或整个计算设备关闭时的可用性）？如果需要，该恢复的标准是什么？

要知道，并不一定所有的业务流程都将需要灾难恢复设备。只应选择那些至关重要并且的确需要灾难恢复的流程。即使在这些流程内，也可能不需要包括所有功能。

服务必须在多长时间内恢复？恢复时间是从灾难发生时开始计算，还是从决定前往远处工作地点时开始计算？
组织在什么条件下会决定在远处工作地点进行恢复，而不是在本地进行？
在远处工作地点的数据必须处于怎样的更新状态才能使业务继续进行（必须时刻最新；在发生故障后的几分钟内更新；可接受前一天的数据）？
首次从远处工作地点恢复服务是什么时候？
在未来的某一时间点进行吗？
相对于依赖相同计算设备的其他业务应用程序，这组应用程序的远程恢复具有何种优先级？
注意，对于系统的不同部分或不同类型的灾难，可能会有不同的标准集。

在预计的应用程序生命期内，以上的灾难恢复需求将会发生什么变化？

5.6“需考虑的其他可用性设计事项”
要设计出一种能够尽快恢复的系统，设计人员需要知道：在实施该应用程序的过程中，他们在满足应用程序功能性需求的同时具有什么样的灵活性。下面这些问题可能对设计人员具有一定的价值：

1. 为了能够进行必需的维护活动，系统是否可以在短时间内执行以下操作？

a. 执行查询但不进行更新。

b. 接受用户发出的更新请求，但实际上要在维护活动完成后才更新数据库。

2. 对于需要进行数据恢复的中断，以下操作是否更为重要？

c. 尽可能快地将服务还原，即使这意味着要使用并非最新的数据，或者：

d. 在将服务还原之前把所有数据恢复到它们的当前状态，即使这需要较长的时间。

3. 假如发生故障时用户请求“正在处理中”，该用户是否一定会在服务恢复后重新输入他的请求？

4. 是否存在可能影响系统可用性的非技术性事项需要考虑（例如，业务策略规定：如果流程 B 对用户不可用，流程 A 也不能对用户可用）？

在一段时间内，以上的设计考虑事项是否会发生变化？

对于业务中的关键流程，务必要确定适当的替代方案，它们应该可以使这些流程中最关键的元素甚至在部分系统临时不可用的情况下仍能继续发挥其功能。要减少关键流程和数据间的相互依赖性对可用性产生的影响，可以进行业务功能缩减的临时操作。

6 安全性
6.1“安全性需求”
1. 确定需要保护的数据

2. 确定各种数据所受到的安全威胁的类型：

意外的损坏或破坏
故意的损坏或破坏
商业间谍行为
欺骗
黑客行为
病毒
1. 确定对物理安全性的威胁：

偷窃构件
未经授权的物理访问
用户的人身安全
2. 确定哪些人可能是这些威胁的来源：

数据中心工作人员
其他 IT 工作人员（如开发人员）
组织中的非 IT 工作人员
组织外的人员
3. 确定任何特殊的安全性需求，尤其是对以下方面的需求：

对系统的访问
对数据的加密
可审核性
4. 是否有一般性的政策可能会影响该系统的安全性设计，例如《信息自由》法案？

5. 某些封装的应用程序解决方案拥有其自己的安全性子系统。如果您有“指定”的程序包，则要了解它的安全性功能。

要确定安全性需求并将其分类，最好使用以下方法：

1. 按照逻辑或物理安全性列出需要保护的对象。

2. 确定与各个对象相关的各种侵害场景。典型的类别是：

查看访问（违反保密性），例如帐户信息、客户列表、专利。
更新访问，例如为进行欺骗、掩饰和资金转移而修改数据。
资产丢失，例如，所有权被他人获得，从而对拥有者不再可用（有别于因灾难造成的丢失）。例如：客户和前景列表、合同等。
注意，并非所有对象对于上述所有侵害场景都具有敏感性。

3. 确定与您的环境相关的所有威胁。 例如：

心怀不满的雇员
未经授权的雇员
在公有场合进行公开的终端会话
黑客
电话窃听
设备丢失（如便携式 PC）
4. 对于每个对象，应确定它可能受到哪种威胁，并将其与特定的威胁场景相关联。

注意，您可能需要检查对象在静态位置（如在硬盘上）以及在移动中（如在传输期间）的安全性需求。

由于设计可能会将对象所处的位置扩展到不安全的区域，所以您可能需要再次检查该主题。

某些系统设计在安全性方面可能有非常苛刻的要求。它们会支配您的设计决定。它们可能会使在其他情况下很合适的结构和构件变得不可接受。因此，对于您所设计的系统是否具有特别苛刻的安全性需求，现在就要作出明确的选择。例如：

敏感的军事系统
高额贷币汇兑系统
处理个人机密信息的系统
如果您认为自己有特殊的安全性要求，就应该找一位安全专家或安全从业者来协助您进行系统安全性的设计。

One Aim,One God,One Life. || 最爱:偶家阳阳 || 博客:愚人camer || MSN:camellxr@hotmail.com