Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1614054
  • 博文数量: 409
  • 博客积分: 6240
  • 博客等级: 准将
  • 技术积分: 4908
  • 用 户 组: 普通用户
  • 注册时间: 2011-06-01 00:04
文章分类

全部博文(409)

文章存档

2021年(1)

2019年(1)

2017年(1)

2016年(13)

2015年(22)

2013年(4)

2012年(240)

2011年(127)

分类: IT业界

2012-04-15 20:57:51

在一个项目过程中,需求分析是核心,需求分析做不好,设计是个屁,什么项目管控都是浮云。。。最近由于项目当中出了些问题,原因有很多,其他一个最重要的是:客户说我们做出来的东西不是他们想要的。需求分析、交流有所限制,如身份地位、地域,ui设计太烂,最终客户很不满,一味的降低成本,这不是一个明智的做法。
软件工程方法涵盖了一系列软件任务:需求分析、设计、编程、测试、维护,同时还包括了一组基本原则,控制了每一个关键过程区域。
需求分析推荐的一些方法如下:
1.绘制系统关联图
这种关联图是用于定义系统与系统外部实体之间的关联关系和接口的简单模型,如我们画的系统架构框图,描述功能模块和数据导向。
2.创建用户接口原型
当开发人员与用户不确定需求的时候,通过这种方式,通过用户直接评价原型,使项目的参与者更好的相互理解需要解决的问题。找出需求文档与原型的冲突之处。
3.分析需求可行性
在允许的成本、性能要求下,分析每项需求实施的可行性,分析每项需求实现所联系的风险,包括其需求冲突,对外界因素的依赖和技术障碍。
4.确定需求的优先级
因为用户需求不是一次性全部得出的,找到核心功能,确认优先级开始开发。
5.为需求建立模型需求的图形分析模型是软件需求规格说明书最好的补充说明。这样的模型包括数据流图、实体关系图、状态变化图、对话框图、对象类交互图、时序图。
6.创建数据字典
数据字典是系统所用的数据项和结构的定义,确保开发人员使用统一的数据定义。这部其实就是从概念模型(数据模型)转化为关系模型。数据定义要统一,不能开发人员再定义一套,名词解释,都应该先定义好,以降低沟通成本。
7.使用质量功能调配

 需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序,这些活动是相互隔开、增量和反复的。当你和客户合作时,你就将会问一些问题,并且取得他们所提供的信息(需求获取)。同时,你将处理这些信息以理解它们,并把它们分成不同的类别,还要把客户需求同可能的软件需求相联系(分析)。然后,你可以使客户信息结构化,并编写成文档和示意图(说明)。下一步,就可以让客户代表评审文档并纠正存在的错误(验证)。
还有,探讨例外的情况:什么会妨碍用户顺利完成任务?对系统错误情况的反映,用户是如何想的?询问问题时,以“还有什么能” ,”当?时,将会发生什么”“你有没有曾经想过” ,“有没有人曾经”为开头。记下每一个需求的来源,这样向下跟踪直到发现特定的客户。
有些时候,尝试着问一些“愚蠢”的问题也有助于客户打开话匣子。如果你直接要求客户写出业务是如何实现的,客户十有八九无法完成。但是如果你尝试着问一些实际的问题,例如:“以我的理解,你们收到订单后,会...”。客户立刻就会指出你的错误,并滔滔不绝的开始谈论业务,而你,就在一边仔细的聆听吧。这一招就叫做“抛砖引玉”。
需求讨论会上必须要使用笔记本电脑,还要指定一个打字熟练的人把所有的讨论记录下来,记录的同时还要做一定的整理。如果不这样做,那么你结束会议的时候就会发现,所有的讨论只剩下一个模糊的印象,需求对你来说仍然是一件遥远的事情。在座谈讨论之后,记下所讨论的条目(item),并请参与讨论的用户评论并更正。及早并经常进行座谈讨论是需求获取成功的一个关键途径,因为只有提供需求的人才能确定是否真正获取需求。进行深入收集和分析以消除任何冲突或不一致性。
尽量把客户所持的假设解释清楚,特别是那些发生冲突的部分。从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。Gause 和Weinberg(1989)提出使用“上下文无关问题”—这是一个高层次的问题,它可以获取业务问题和可能的解决方案的全部信息。客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗?”这些回答可以更直接地认识问题,而这是封闭(close-end)问题所不能做到的。

业务建模
业务分析建模
需求分析的主要工作就是通过建模方法,使组织内的不同角色可以有一个可以交流沟通的手段,最后能对业务有一个共同的理解,便于后续具体工程实施工作的开展。深入用户业务场景去分析。

业务分析的目的就是为了构建原始的业务模型。获得了模型后,分析人员就能够确定进行改进的机会,提出改进的建议,并能够预估更改对业务和现有应用程序的影响。此外,对原始模型的分析还能帮助标识现有IT系统资产,进行服务化后以供重用。

即业务流程分析,是对业务功能分析的进一步细化,从而得到业务流程图即TFD (Transaction Flow Diagram ),是一个反映企业业务处理过程的“流水帐本”。帮助确定流程工作与合作建模的基本要素,更好地分析理解其同其他要素的关系,例如业务目标、业务策略、面对的问题、产生的影响、组织机构参与者或者相关的企业架构。   业务流程分析的目的是:形成合理、科学的业务流程。通过分析现有业务流程的基础上进行业务流程重组(BPR),产生新更为合理的业务流程。

   业务流程分析主要是定义项目的内容,即对现行的管理进行仔细地回顾和描述,从而认识项目的业务和技术上的具体要求
阅读(1969) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~