不存在可以确定所有业务需求的简单公式。应根据与需要软件解决方案的风险承担者之间的合作、您自身对该业务领域的了解并发挥创造性思维来确定业务需求。
本节介绍定义业务需求时需要考虑的一些因素。
业务分析应明确阐述部署项目的目标。清晰的目标有助于突出设计决策的重心,从而防止项目误入歧途。将业务目标与当前业务进行对比也有助于确定设计决策。
业务需求应阐明部署项目的范围。确保您的目标区域能够找到解决方案,避免提出目标不明确或根本无法达到的没有结果的要求。范围定义不明确会导致部署设计不能充分满足业务需要或浪费资源。
制定目标的优先级可以确保优先实现部署中最重要的方面。受资源限制,可能需要延缓或修改某些目标。例如,大规模、复杂的部署通常要求将解决方案分阶段实现。为使部署设计能够通过风险承担者验收,可能需要作出某些决策,而通过阐明优先级,可帮助制定决策。
确定成功的决定性因素,以使风险承担者和设计者集中精力拟定最重要的标准。
设定业务目标时,不仅应考虑组织的当前需要,还要预见这些需要长期的变化和增长趋势。没有人想要一个可能过早被淘汰的解决方案。
解决方案的设计以业务分析阶段所作的假设为基础。由于各种原因(如数据不足、判断错误或意料之外的外部事件),这些假设可能不正确。应确保在业务目标和整体规划中预留一定的保险余量,以使设计的解决方案可以应对意外事件。
进行必要的调查,了解解决方案的目标用户类型、他们的需要以及预期可为用户带来的益处。例如,下表提供了一种对用户进行分类的方法:
仅限当前员工
当前和先前员工
管理员
活动客户
所有客户
成员站点
公众
受限访问
向用户明确阐述预期益处有助于制定设计决策。例如,以下是解决方案可为用户提供的一些益处:
远程访问公司资源
企业协作
简化日常任务
使远程团队得以共享资源
提高生产率
最终用户自我管理
操作要求表述为一组具有明确目标的功能性要求。通常,可为以下领域创建操作规范:
最终用户功能
缩短响应时间
可用性和正常运行时间
降低错误率
信息存档和保留
将操作要求表述为所有风险承担者都可理解的可量化条目。避免含糊不清的语句,如“充足的最终用户响应时间。” 操作要求的示例如下:
可在停电 10 分钟内恢复服务
可重放最近 48 小时内的传送的入站消息
高峰期间,可在 60 秒内完成在线事务处理
高峰期间,可在四秒内完成最终用户身份验证
将现有使用模式表述为可清晰量化的目标。以下问题可帮助确定上述目标。
当前服务的使用情况如何?
使用模式是什么(例如,偶尔使用、经常使用或过量使用)?
用户通常连接哪些站点?
用户一般发送多大的消息?
用户每天或每小时通常完成多少事务?
研究访问您服务的用户。用户何时访问现有服务以及访问持续时间等因素是确定您的目标的关键。如果以您组织的经验不能确定这些模式,可研究类似组织的经验。
要求分析应考虑企业文化和政策的各个方面。未充分考虑企业文化因素,可能会导致无法接受或难以实现解决方案。
确定能够从提议解决方案的成功中获取既得利益的个人和组织。所有风险承担者均应积极参与业务目标和要求的确定。如果风险承担者不参与或不了解计划的更改,则计划可能存在严重缺陷。这样的风险承担者甚至可能阻碍部署的实现。
确保了解需要解决方案的组织的标准和策略。这些标准和策略可能会影响设计的技术层面、产品选择及部署方法。
示例之一是可能由人力资源部门或部门经理所有和控制的人员数据的保密性。另一个例子是公司的更改管理流程。更改管理策略会极大地影响解决方案的接受,并影响实现方法和时间表。
监管要求的差异极大,具体要求取决于业务的性质。研究和了解任何可能影响部署的监管要求。许多公司和政府机构要求符合可访问性标准。部署全球解决方案时应考虑外国的法律和法规。例如,许多欧洲国家对存储个人信息有严格的控制。
您确定的某些目标可能存在需要重视的隐性安全问题。明确解决方案所必需的具体安全目标。例如:
专有信息的授权访问
以基于角色的方式访问机密信息
远程位置间的安全通信
在本地系统上调用远程应用程序
与第三方企业和组织的安全交易
安全策略的执行
站点的地理分布和站点间的带宽可以影响设计决策。另外,某些站点可能要求本地管理。
这些地理方面的考虑会增加项目的培训成本、复杂性等。清楚阐明由站点的地理分布而产生的要求。确定对设计成功至关重要的站点。
通常将软件解决方案视为一个完整的综合系统。不过,实际运作中往往会将完整系统的部署分为几个可衡量的步骤,以渐增方式完成。
采用渐增式方法时,通常要设计一个路线图,其中给出通往最终的综合解决方案的重大事件点。此外,可能还必须考虑制定针对综合解决方案随后实施的各方面的短期计划。
这种渐增式方法具有以下优势:
能够根据业务增长所带来的要求变化做出调整。
可在向最终部署实现过渡的过程中充分利用现有基础结构。
能够适应资本支出要求。
能够充分发挥少量人力资源的作用。
能够为集成合作伙伴方案做准备。
服务级别协议 (Service Level Agreement, SLA) 指定了最低性能要求以及未能满足此要求时必须提供的客户支持级别和程度。服务级别协议基于业务分析过程中定义的业务需求,在随后的技术要求阶段,这些业务需求将被指定为服务级别要求。SLA 在部署设计阶段中的项目核准期间签署。
应根据正常运行时间、响应时间、消息传送时间和灾难恢复等领域制定 SLA。SLA 应说明系统概述、支持组织的角色和责任、如何衡量服务级别、更改请求等项目。确定您的组织对系统可用性的预期是确定 SLA 范围的关键。