六、如何进行有效的需求开发过程?
需求描述了客户需要或目标,或者描述了为满足这种需要或目标,产品必须具有的条件或能力,它是种特性,要求产品为涉众提供价值。
系统需求是系统必须完成的功能和局限性。功能需求是描述系统必须完成的活动或过程的一种系统需求,它就是系统要投入的商业应用。用户需求(User Requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(Use Case)文档或方案脚本(Scenario)说明中予以说明。功能需求(Functional Requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。而所谓特性(Feature)是指逻辑上相关的功能需求的集合,给用户提供处理能力并满足业务需求。
系统分析阶段的活动则有如下几种(表1),同时列举了其对应解决相应的关键问题。
表1
分析阶段的活动 |
关键问题 |
收集信息 | 是否已经拥有了全部的信息来定义系统所必须完成的工作? |
定义系统需求 | 需要系统做什么? |
构建可行性的发现原型 | 可以证明此种技术能够实现想让它完成的那些功能吗? 是否已经构建出一些原型让用户能够完全理解新系统的潜在功能? |
产生评估方案 | 创建系统的出色方案是什么? |
与管理部门一起复查各种建议 | 是否应该继续设计和实现我们提出的系统? |
解决关键问题的方法,大致如下:
(1) 搞清楚系统相关者,通过组织结构图找系统角色,他们是系统的主要使用力量。
(2) 系统开发的分析阶段的目标是理解商业功能和获得系统需求。
(3) 在改正旧系统到新系统的转换过程中,关键是新系统。通过调查问卷,面谈去理解新系统的限制。通过复查现有文档,去理解信息的过程。通过研究商业过程和供应商,去理解新系统的功能。最终是为新系统开发出系统需求和模型。
以上的描述是一种系统分析的流程,下面介绍从需求角度看分析师的业务问题。
需求开发依先后顺序可以分为:需求获取(Elicitation)、分析(Analysis)、编写规格说明(Specification)和验证(Verification)四个阶段。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。
需求开发活动包括以下几个方面:
(1) 确定产品所期望的用户类。
(2)获取每个用户类的需求。
(3) 了解实际用户任务和目标以及这些任务所支持的业务需求。
(4)分析源于用户的信息,以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。
(5)将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件。
(6)了解相关质量属性的重要性。
(7)商讨实施优先级的划分。
(8)将所收集的用户需求编写成规格说明和模型。
(9)评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都要弄清楚。
需求分析(Requirement Analysis)包括提炼、分析和仔细审查已收集到的需求,以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析的目的在于开发出高质量的需求,这样你能做出实用的项目估算并可以进行设计、构造和测试。
通常把需求中的一部分用多种形式来描述,如同时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题,这是单一视图无法提供的。分析还包括与客户的交流以澄清某些混淆,并明确哪些需求是更为重要的。其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。下面是需求分析中经常使用的方法:
(1)绘制系统上下文示意图
这种示意图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。
(2)创建用户接口原型
当开发人员或用户不能确定需求时,开发一个用户接口原型———个局部的可能实现——这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间的所有冲突之处。
(3)分析需求可行性
在允许的成本、性能要求下,分析每项需求实施的可行性,明确与每项需求实现相联系的风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。
(4)确定需求的优先级别
应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时,在特定的版本中加入每一项变更,并在那个版本计划中作出需要的变更。
(5)为需求建立模型
需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系,以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
(6)创建数据字典
数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。
(7)使用质量功能调配
质量功能调配(Quality Function Deployment,QFD)是一种高级系统技术,它将产品特性、属性与对用户价值联系起来。该技术提供了一种分析方法以明确哪些是客户最为关注的特性。QFD将需求分为三类:期望需求,即客户或许并未提及,但如若缺少会让他们感到不满意;普通需求;兴奋需求,即实现了会给客户带去惊喜,但若未实现也不会受到责备。
系统分析师需要掌握需求捕获、需求分析和需求确认方法,并且要有一定的实践经验,因为需求分析是门需要实践的学问。
需求捕获的方法其实有多种,你可以熟悉每一种方法。通过文档概要、面谈、观察、原型、调查表、供应商调查、联合应用会议等等方法是可以获得需求的。但在实际中,你不必十八般武艺样样都要使出来, 本质上持续不断的捕获高质量的需求的方法只有一个,就是和业务人员打成一片,这样,不再是你去找需求,需求可能会来找你了,这是一种主动需求的方法,所以系统分析师一般都需要有良好的人际互动能力。
当然,需求捕获还是有其自身的方法的, 要讲需求捕获必先谈到收集信息, 信息不足则“巧妇难为无米之炊”。其实这里有三个经典的问题,会是系统分析师经常用到的或提到的问题。由信息收集到需求捕获,再到需求分析是需求开发的中轴线,而能否收集到必要的有效的需求信息, 请仔细体会如下三个问题。
(1)商业过程和操作是什么,即你要干什么
系统分析师核心是理解商业过程,一般用户只会对现状回答,但分析师要能识别在改进的系统中哪些要保留,哪些要删除。这个问题是沟通的第一步,回想当年笔者第一次就这样问用户:“你的流程是什么?你有什么问题”,何其愚也,从问用户的问题可以看出这个分析师是不是有经验。
(2 )商业过程应该怎样完成,即系统分析师该如何完成它,或者说需要哪些步骤
用户谈的是老系统的完成办法,而系统分析师的核心是新系统应该如何支持这项功能,而不是在现有系统下如何执行。分析师重要的是超越现在,使新技术带来的商业处理方法更高效。
(3)需要什么样的信息,即为了完成商业过程,系统分析师要使用哪些信息,使用什么样的表单或报告。
有价值的系统分析师有一套需求捕获的手法,有价值的系统分析师一定会从理论到实际仔细研究需求分析的过程。
笔者在上面介绍的一些概念和理念,并不是使您成为一个优秀系统分析师的“金科玉律”或“武功秘笈”。笔者想借助此文与读者和同仁交流沟通。