软件需求规范(SRS)注重于收集和组织与您的项目有关的所有需求。如果有需求管理计划,则应该参阅需求管理计划以确定需求的正确位置和组织。例如,可能希望用单独的
SRS 描述产品特定发行版中的每个 特性的完整软件需求。这可能包含几个来自系统用例模型中的用例,以此来说明此特性的功能需求,以及补充规范中的一系列相关详细需求。
由于您发现可使用几种不同的工具收集这些需求,因此意识到可能要在几种不同的工件和工具中收集需求是很重要的。例如,您可能发现使用补充规范中的文本记录工具收集文本需求(如非功能需求、设计约束等)是很适合的。另一方面,您可能又发现收集用例中的一些(或所有)功能需求非常有用,还可能发现使用满足用例模型定义需求的工具非常方便。
我们发现侧重于所用工具之间的差别并没有很大的必要。毕竟,您正在收集需求且应真正注重于有效地收集和组织需求,而不必考虑手边的工具。既然是侧重于需求而不是工具,那么假定 SRS 中的需求集合构成一个信息包。一个称为软件需求规范(SRS)的包中包含了系统各需求的精化。
SRS 包显然与远景文档相关。事实上,远景文档充当 SRS
的输入。但这两个工件服务于不同的需要,并且通常由不同的作者撰写。在项目的这个阶段,项目的侧重点从宽泛地陈述系统的用户需要、目的和目标、目标市场和特性转移到详细说明将如何在解决方案中实施这些特性。
现在所需要的是描述系统完整外部行为的工件集合或工件包 - 即明确指出“这里是系统为实现那些特性而必须执行的操作”的包。而这个包就是我们所说的 SRS 包。
SRS 包不是一本尘封的书,后者的生成是为了确保遵循 ISO 9000,然后就被弃置一边并忽略,而项目继续进行。相反,它是激活的活动工件。事实上,当开发人员着手实施工作时,它有多种用途:作为各方通信的基础 -
即在开发人员之间和开发人员与必须作为沟通对象的外部组(用户和其他项目干系人)之间。它正式或非正式地表示各方之间的约定协议,如果该协议不在 SRS 包中,开发人员则不应使用它。而如果它在 SRS 包中,则开发人员负责实现该功能。
SRS 可用作项目经理的参考标准。项目经理不太可能有时间、精力或技能来阅读由开发人员生成的代码并与远景文档直接进行比较。他或她必须将 SRS 包用作与项目团队进行讨论的参考标准。
如之前所提到的,SRS 包充当设计和实施组的输入。根据项目的组织方式,在问题解决及特性定义任务最终生成远景文档之前,实施者可能已经参与了这些任务。但他们需要关注 SRS 包来确定他们的代码必须做什么。它充当软件测试和 QA
组的输入。这些组还应参与某些较早期的讨论,而这明显有助于他们很好地理解“远景”文档中展示的“远景”。但他们的职责是创建测试用例和 QA 过程,以确保已开发的系统的确满足 SRS 包中所展示的需求。对于他们而言,SRS
包还可用作计划和测试任务的标准参考。
请参阅指南:用例模型和指南:用例,以获取有关在用例模型和用例中定义功能需求的推荐方法的完整讨论。
对系统的非功能需求应记录在工作产品:补充规范中。在定义这些需求时要遵循以下原则。
收集和验证非功能需求时,维护假设和问题列表。
有些任务将无法为您提供令人满意的答案。这可能是由于缺少信息或只是因为您认为答案危及设计的可行性。因此,创建两个列表并在设计研究过程中进行维护:
您在需求和设计过程中所作的任何假设,包括那些假设背后的理由或思考过程。假设可用于确定该项目范围以外或该项目之后的相关子项目或工作项。
任何主要问题(可能会造成中断的重大问题)
在每个阶段结束时,应当与客户一起复审问题。假设也需要在每个阶段结束时复审,但客户并不总是复审那些次要问题的合适人选。
假设与问题适用于所有工作产品,但对于非功能需求尤为常见。
记录客户的地理组织。
记录受该系统影响的业务部分的地理位置。定义还应包括那些不受影响的站点,那些站点主管主要的 IT 设施。对组织的任何移动部分作特殊注释。例如,将要到处出差和使用工作站的销售队伍。请注意您必须提供特殊本地语言支持(NLS)的任何地理位置。
需求指定使用任何应用程序包吗?有些指定可能会强烈要求作出一些系统设计决策,其中的一项非常重要的“指定”就是使用可提供预定义软件逻辑和数据组织的特定应用程序包。某些软件包是灵活的并允许进行大量定制;而某些软件包则非常固定且不允许定制。包可能会要求如下组件和决策:
-
工作站类型
-
连接方法
-
处理器和直接访问存储设备(DASD)类型
-
系统控制程序
-
数据组织、放置和管理
-
编程语言
-
批处理接口
-
流程和数据关系
-
业务逻辑
-
屏幕设计和用户界面
-
性能和可用性属性
-
任何现有或必需的打印体系结构,如首选的打印数据格式(例如,PostScript、PCL、IPDT)
-
本地语言支持(NLS)
了解任何给定包将对设计产生的影响是很重要的。如果您有一个“指定”包,则应确保您能获得有关该包的适当技能和知识。 这可能来自:
不要假定该知识是现成可用的。要确保在您需要时可用。
记录那些需求中将限制设计灵活性的任何其他给定事项。
如果您在早期任务中没有明确地考虑到有些可能会限制设计灵活性的特定需求,现在您就要处理所有这些需求。例如,考虑以下所有需求:
-
现有处理器或操作系统映像的使用
-
现有工作站设备的使用
-
现有网络的使用
-
现有系统管理实践的使用
-
特定模型的使用,如:“对明确显示演示/业务/数据访问逻辑以及对接位置和方法的设计,必须使用客户机/服务器系统模型”。
有任何这些给定条件会影响新的系统吗?如果新系统将在现有处理器、操作系统映像或网络配置上运行,那么现有平台和工作负载的属性会影响新系统吗?
现有工作负载已占用了多少连接和处理容量?
现有工作负载使用的是什么安全性控制?记下这些控制,并在考虑新系统时针对其安全性需求检查这些控制。
现有工作负载的可用性属性是什么?
请注意可能影响新系统以后的可用性设计的任何因素。例如,现有工作负载坚持要求每天晚上关闭整个处理器吗?
这些需求指定使用任何特殊硬件吗?
这可以用一般性的术语来陈述(“系统必须支持高速平板绘图仪”),也可以更具体些(“系统将支持现有的 Panda Corp ATM”)。尽可能记录:
-
任何硬件或软件先决条件
-
供应商及其支持组织
-
本地语言(NLS)注意事项
-
加密设备
这些需求指定使用现有的数据吗?如果有所指定,则将影响您的系统设计。记录:
-
数据当前所在的系统
-
其结构(如关系文件或平面文件)
-
其大小
-
当天使用这些数据的用户和系统
-
可用性考虑事项(例如,由于进行数据库维护或批处理任务而导致数据不可用的时间段)
-
这些数据可以移动或复制吗?
客户端具有技术体系结构和/或 IT 策略计划(或等价的一组标准)吗?
技术体系结构大致相当于以下几项:
在技术体系结构中,您可能发现以下各项的一些已经定义:
-
计算中心的数量和使用
-
企业的网络连接(WAN)
-
某些设施的本地化连接(LAN)
-
客户机/服务器基础结构服务(中间件),包括
· 跟踪网络资源和属性的目录和命名服务
· 通过注册用户和用户权限级别来保护网络资源免受未授权使用的安全服务
· 在网络中调节日期和时间的时间服务
· 跨某一网络中的多个系统协调资源恢复的事务管理服务
-
将用于新应用程序的开发方法
-
已被接受的一组支持产品,如:
· 硬件
· 系统控制软件
· 常用的应用软件,如“Office”
· 帮助台使用
· 安全性规则
列表的范围可能很广,并且其中的项可能是受严密控制的,也可能根本没有强制实行。
记录明确要求或排除使用如下子体系结构的任何需求:
-
OSI 或 SNA
-
UNIX**
-
SAA
-
PS/2*,装有 OS/2* EE。
使用打包应用程序解决方案可能会包含的特殊体系结构。请记住,某些应用程序包有权进行体系结构定义。
记录客户端所要求的开放度(即供应商独立性和互操作性)。如果存在技术体系结构,则您的设计将几乎总要符合该体系结构。您应该理解该体系结构并了解将影响该系统设计的规则。
客户端具有此系统必须符合的网络体系结构吗?网络体系结构是一组通用的高级连接规则以及通用的传输基础结构。这可能包括主干网络(包括集中器和线路)的定义。如果存在这样的体系结构,则请理解基本规则和拓扑并记录:
物理拓扑的注意事项(即,网络本质上是针对农村还是城市的,以及网络连接是密集分发还是松散分发的)。
当前的网络基础结构支持哪些高级连接功能。
使用哪些通信标准(如 SNA、OSI、TCP/IP)支持这些连接功能。
支持哪些编程接口。
客户机/服务器层或基本系统模型层之间连接的任何网络体系结构定义,如:
-
客户机工作站与 LAN 关系服务器之间的关系数据访问必须通过特定关系数据库产品的协议来进行。
-
表示逻辑必须始终位于工作站中,并且数据访问逻辑必须始终位于集中式主机系统中。
客户端具有任何已规定的连接策略吗?
即使您不具有技术或网络体系结构,仍可具有某些连接策略。
记录任何有关以下事项的策略:
-
使用特定协议或通信设施(用于一座大楼内部或者大楼或组织外部的连接)。
-
为了支持现有设备或软件,是否隐含地需要任何特定协议。
-
是否要使用现有物理连接设施(即电缆或电线、网络或外围控制器以及公用通信公司设施)。如果不使用,则对可使用的物理设施的类型可能会有限制(政策、政府法规、物理空间、场地所有权以及涉及第三方)。记录这些内容。
-
如果可能需要安装或修改物理设施,则可能需要涉及一家或多家第三方(如承包商或公用通信公司)。要了解如何处理承包或职责。如果业务交往将涉及到国际联系,这一点就尤其重要了。
-
支持移动用户。
客户端还有其他策略、标准或规则未在需求中明确陈述吗?例如:
-
用户的所有新系统接口必须根据面向对象原则进行设计,允许拖放操作。
-
所有新系统都必须以客户机/服务器应用模型为基础。
-
所有新系统都必须用开放标准来定义。
-
本地语言支持(NLS)的标准和策略,特别是如从右到左文本操作之类的事项。
-
安全策略,定义用户认证、访问控制和数据保护的管理职责和标准。
-
应用程序交换标准(如 UNEDIFACT 或 VISA),可能包含使用针对连接或安全性的特殊设备。
如果存在其他策略,则确保理解这些策略并有权访问它们,这样就可保证您的设计在设计流程的以后阶段符合标准。如果使用打包应用程序解决方案,则很可能会给它带来某些隐含的标准。
什么策略允许用户或部门在以下位置添加和/或开发其本地程序:
如果不加控制,您会发现本地使用很快用完生产系统所需的资源,而本地组件原本是为生产系统购买的。您还会发现,当最终准备展示生产系统时,却无法安装生产系统。
4.1 “评测单元”
与应用程序开发人员协作,将业务流程细分为更小的单元,如更小的业务流程或事务。
这样做的原因在于要获取下一个问题中的数字,并且必须决定要计算的对象。
请注意,一个业务流程会启动较小业务事务的几个实例(例如,每个客户订单有多个商品订单),并在记录数字时应记住这些乘数。但是,不要为过多的细节所牵制,特别是对于复杂的系统。
通常,一个业务“流程”(如客户订单处理)将由一个“应用程序”(IT 术语)来实施,但它也可能由多个应用程序来实施。在每个应用程序中,通常会有很多 IT“事务”,例如,“查询库存水平”或“生成客户信函”。
不同的团体使用各自的名称标识正试图认同的单元。例如,“事务”对于具有应用程序开发背景的人来说可能是一种意思,而对于基础结构团队来说则会是另一种完全不同的意思。协同合作以使名称相互关联并随后收集信息是很重要的。
4.2 “业务量和大小”
确定并记录 4.1“评测单元”中每个单元的业务量和大小信息,例如:
-
按平均和高峰时间,预计有多少用户将使用每个业务流程或应用程序。
-
何时为高峰期(每天、每星期、每月等,适可而定)。
-
在高峰期和平均情况下,处理事务所需的速率。
-
每个数据组中数据元素和实例的数量和大小。
4.3 “业务流程性能条件”
客户端可能为某些或所有业务流程指定了性能条件。但还请记住,记录系统支持流程(如系统备份)和应用程序开发流程的性能目标(如已确定)。对每个类别,记录:
-
每个类别的响应/周转需求。
-
在何处评估这些类别。
-
是否在不同时间(例如非高峰期/夜间)可接受不同的条件。
-
在恢复或回退期间是否要符合条件。
-
是否需要性能保证。
-
如果不符合性能需求,将对任一方有何影响。
-
表述业务流程被认为可用的最低性能条件(也就是说,在该点以下,系统将被认为是“不可用”而不是“缓慢”)。
-
如果已选择打包应用程序解决方案,则请确保您有权访问其性能属性。您现在可能根本不需要这些性能特征,但是将来一旦需要,您应该知道从哪里找到它们。让第三方提供您所需的数字也可能要花很长时间,故请立即索取这些数字。
确定可用性需求的建议方法如下:
-
确定系统的真实用户、他们正在执行的业务流程以及用户执行这些流程的时间(小时)
-
分析服务可用性(或不可用性)对用户完成其业务目标的能力的影响
-
指定适当的可用性需求,以直接反映用户为了完成其业务目标而具有的需求。
-
请注意,如果已经选择了封装的应用程序解决方案,那么它的结构和设计可能会对用户所看到的应用程序可用性特征产生重大影响。如果未设计成连续运作,包可能很难连续运作,特别是对于维护和批处理窗口。
在形成可用性需求时,考虑这些指南:
-
与其指定整个系统的“全局”需求,不如以较小的粒度(例如按各个流程、用户组、数据组等)来指定可用性需求。这样,设计人员就能够更加灵活地满足用户的需要。这对于具有很高连续可用性需求的系统尤其重要。
一些示例:
-
语句“系统必须每天 24 小时为纽约和香港的用户提供服务”为设计人员提供的设计灵活性就远不如语句“从纽约时间上午 7 点到下午 7 点,纽约用户必须能够对他们的数据执行事务处理;从香港时间上午 7 点到下午 7
点,香港用户必须能够对他们的数据执行事务处理”。在后一情况下,设计人员可对一个时区的数据或系统组件灵活地进行维护,与此同时其他时区仍处于工作日中。
-
在 ATM 应用程序中,在周一凌晨 3 点接受存款和取款是至关重要的,而在该时段提供确切帐户余额的能力可能并不那么重要。
-
区分“希望的”和“必需的”可用性属性。例如,“ATM 必须能够每天 24 小时接受存款和取款。希望 ATM 能够每天 24 小时为客户提供准确的帐户余额信息;不过,在帐户余额查询过程中可以有偶尔的中断,但中断持续时间必须少于 10
分钟,并且只能发生在凌晨 3:00 到凌晨 4:00 之间”。
-
如果不符合特定可用性目标的影响不会直接关系到用户实现业务目标的能力,则可能不适合将该目标定为系统的可用性需求。
-
如果可用性需求只是间接地反映了用户所感受到的可用性(例如“必须建立 IMS 控制区域”),这样的可用性需求通常不如那些直接反映可用性的需求有用(例如“银行出纳员必须能够执行流程 X 和 Y”)。
5.2 “计划的服务时段”
对于每个业务流程和必须执行这些流程的用户组,确定用户必须能够执行该流程的时段。记住也要对那些不直接与用户组相关的流程执行该步骤。
如果用户组处在不同的时区(比如前面的“纽约/香港”示例),则将他们视为不同的用户组。
还显示是否存在可能不需要应用程序的特殊时期(比如业务节假日)。(这使设计人员能灵活地利用那些时期进行扩展维护)。在应用程序的计划生命期中的这些服务时段,预计会有什么变更呢?
该系统的服务时段也可能受与该系统对接的其他系统的服务时段的影响。
在该系统的计划生命期内,系统的预设服务时段预期会如何变化呢?
5.3 “服务中断成本”
了解在预设服务时段,与服务中断相关的业务影响、财务成本和风险。
要确定对该系统真正重要的可用性需求,请考虑一组业务流程和用户组并确定以下情况的业务影响:
-
在预设时段,短暂中断或一段慢得无法接受的响应时间。当定义“短暂”和“极其缓慢”这两个短语时,应考虑到所使用的特定应用程序(请参阅“业务流程性能标准”)
-
在以上服务时段内的各种较长期中断(一分钟、几分钟、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. 存在可能影响该系统可用性的任何非技术注意事项(如某个业务策略指出流程 A 不得供用户使用,除非流程 B 也可用)吗?
上述设计注意事项预期会随着时间发生变化吗?
对于那些对业务至关重要的流程,确定备选方案是有用的,因为即使当该系统的某些部分暂时不可用时,备选方案也允许那些流程中最关键的元素显示作用。如果能够暂时使用减少了的业务功能运作,则可能帮助减少关键流程和数据之间相互依赖关系的可用性影响。
6.1 “安全性需求”
1. 确定要保护的数据
2. 确定每种数据所面临的威胁的类型:
-
意外毁坏或破坏
-
蓄意毁坏或破坏
-
商业间谍
-
欺诈
-
黑客
-
病毒
1. 确定对实际安全性的威胁:
2. 确定有可能成为这些威胁来源的人:
-
数据中心职员
-
其他 IT 职员(例如,开发人员)
-
组织中的非 IT 职员
-
组织外部人员
3. 确定任何特殊或异常的安全需求,特别是与以下方面有关的需求:
4. 存在可能影响该系统的安全性设计的一般政策(如信息自由条例)吗?
5. 某些打包的应用程序解决方案具有自己的安全性子系统。如果您有“给定”的程序包,则要了解它的安全性功能。
为了确定安全性需求并对其分类,可能要使用以下方法:
1. 按逻辑或物理安全性列出要求保护的对象。
2. 确定与每个对象相关的风险。典型的类别是:
-
查看访问(违反机密性),例如帐户信息、客户列表和专利。
-
更新访问,即修改数据以诈骗、掩饰和转移资金。
-
资产丧失,即资产被他人占有且不再可供所有者使用(与因灾难而引起的损失区分开)。示例有:客户和潜在客户列表、合同等。
注意,并非所有对象都容易受上述所有风险的影响。
3. 确定与您的环境相关的所有威胁。示例有:
-
心怀不满的员工
-
未授权的员工
-
公共场所的开放式终端会话
-
黑客
-
线路窃听
-
设备丢失(如便携式 PC)
4. 为每个对象确定可能适用的威胁并将其与特定风险相关联。
注意,您必须在静态位置(如在硬盘上)和在传输中(如在传输期间)均检查对象的安全性需求。
因为设计可能超出对象所在的位置而进入无保护区域,所以必须重新访问该主体。
某些系统设计在安全性方面可能要求很高。它们可能决定您的设计决策。它们可能导致无法接受其他好的结构和组件选择。因此对于正在设计的系统是否有特别高的安全性需求,请立即作出明确的选择。例如:
-
敏感的军用系统
-
巨款传送系统
-
处理机密私人信息的系统
如果您认为有特殊的安全性要求,则应确定一个安全专家或专业人员来帮助进行系统设计。
可用性需求定义用户界面必须达到多高的可用性。
可用性需求应设置为系统为了得以使用而必须达到的最低可用性级别。而不应设置为您认为系统可以达到的级别。换言之,可用性需求不应视为一个目标(即上限)。可用性需求应定义可接受的绝对最低系统可用性。因此,当达到可用性需求时,您将不必停止改进可用性。
系统为了得以使用而必须达到的级别主要取决于使用系统的备选方案是什么。要求系统应当明显比备选方案更可用,这是合理的。备选方案可利用:
-
现有的手动过程。
-
旧系统。
-
竞争产品。
-
系统的较早版本。
可用性需求也可能来自从经济上证明新系统合理性这一需要:如果客户必须为新系统支付 3 百万美元,那么他可能想施加可用性需求,这意味着由于在人力资源上降低了工作负载,他每年可能将节省 1 百万美元。
以下是某些一般可用性需求的示例:
-
最长执行时间 - 经过培训的用户执行一个普通方案所应花费的时间。
-
最大错误率 - 经过培训的用户执行一个普通方案的平均错误数。
与评估相关的错误只是那些不可恢复的、将对组织有负面影响的错误,例如损失业务或引起受监视硬件的损坏。如果错误的唯一后果只是花时间修复,那么这影响的将是所评估的执行时间。
-
学习时间 - 用户学会在指定的最长执行时间内执行方案所花的时间。
以下是“管理进入的邮件消息”用例的某些特定可用性需求的示例。
-
邮件用户应只需单击鼠标就能排列邮件消息。
-
邮件用户应只需按键盘单键就能滚动邮件消息文本。
-
阅读现有的邮件消息时,邮件用户不应被进入的邮件消息所打扰。
|