• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

需求分析概述

发布: 2008-8-05 16:15 | 作者: 网络转载 | 来源: Sawin | 查看: 91次 | 进入软件测试论坛讨论

领测软件测试网

8 业务建模


很多人都没有意识到业务需求阶段应该做些什么事情,实际上业务建模是最重要的一件事情。不要觉得业务建模这个词很深奥,让人模不着头脑。其实所有做过需求分析的人都做过业务建模,比如你了解企业的运作模式就是一种你脑海中的业务建模。但是大多数人都没有科学的、系统的、文档化的做过业务建模。 

业务建模的目的在于: 

·了解目标组织(将要在其中部署系统的组织)的结构及机制。 

·了解目标组织中当前存在的问题并确定改进的可能性。 

·确保客户、最终用户和开发人员就目标组织达成共识。 

·导出支持目标组织所需的业务需求。 

上面的话是不是很抽象呢,其实没有什么复杂的:人和电脑是完全不同的思想(思维方式)。所以,原先适合人的业务流程对于计算机来说可不一定合适的,为了最大限度的利用计算机,必须要了解原先的业务流程并对此加易改造(流程自动化),当然这些动作需要得到用户的许可。有些人认为说只有ERP这种大系统才需要对业务流程进行重组,但是实际上,不论是部门级的MIS系统,还是社会级的电子商务系统,都需要对业务流程进行改造,所不同的只是改造的程度。 

业务建模很重要的一点是在分析企业流程的同时分析出基础企业对象(Common Business Object)(这个词我翻译的不好,如果大家有更好的翻译,请告诉我)。任何企业都有最基础的一些元素,例如银行的CBO就有帐户,制造业的CBO就有订单等。有一次我的一个在企业应用方面研究多年的朋友告诉我一个秘诀,他说,企业的CBO无非是4个:客户、员工、产品和供应商(银行的供应商应该称为同业)。其他的所有CBO都是在这四个CBO的基础上发展起来的。比如说CBO中客户和产品是多对多的关系,根据关系数据的理论,任何多对多的关系都可以拆分成多个一对多或一对一的关系。你就可以在这两个类之间引入订单类,客户和订单之间是一对多,订单和产品之间又是一对多,这样一个多对多的关系就拆分成两个一对多的关系,而新的订单类也就顺理成章的产生了。在订单类产生时,你可能还会加入一个关联类:业务员类。而业务员类又是从员工类继承下来的。所以呢,企业的四种CBO通过不同的组合,不同的关系,能够形成企业运作的许许多多的CBO。 CBO是做业务建模的基础,在此基础上,通过评估业务状态,说明当前业务,确定业务流程,改进业务流程的定义,设计业务流程实现,改进角色和职责,研究流程自动化,开发领域模型等一系列在RUP中定义的工作流程实现业务建模的目标。 



9 方法


需求分析都包括了哪些方法呢?这里列举出在《需求分析》一书中推荐的一些方法, 

1. 绘制系统关联图,这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。 

2. 创建用户接口原型,当开发人员或用户不能确定需求时,开发一个用户接口原型—一个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。 

3. 分析需求可行性,在允许的成本、性能要求下,分析每项需求实施的可行性,明确与每项需求实现相联系的风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。 

4. 确定需求的优先级别,应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时,在特定的版本中加入每一项变更,并在那个版本计划中作出需要的变更。 

5. 为需求建立模型,需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。 

6. 创建数据字典,数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。 

7. 使用质量功能调配,(QFD)是一种高级系统技术,它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。QFD将需求分为三类:期望需求,即客户或许并未提及,但如若缺少会让他们感到不满意;普通需求;兴奋需求,即实现了会给客户带去惊喜,但若未实现也不会受到责备(Zultner 1993;Pardee 1996)。 

记住一点,不要试图在你的项目中把这些方法都用上去,四个现代化并不是一夜就可以实现的。同样,尝试着使用你认为对你很有帮助的方法,确实收到效果之后,在考虑继续学习方法。因为上面提到的都是需求分析的大方法,事实上还有很多很多的方法可以采用,例如,采用SRS模板、指明需求的来源、为每项需求注上标号、记录业务规范、创建需求跟踪能力矩阵、审查需求文档、以需求为依据编写测试用例、编写用户手册、确定合格的标准。 

文章来源于领测软件测试网 https://www.ltesting.net/

44/4<1234

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网