sun_abc的专栏

http://www.leadge.com/zhuanti/2008.1.7.htm

<br />【聚杰网需求管理】软件需求的关键是分解用例场景      做软件需求最重要就是分解用例场景，没有用例就不是需求。 <br /><br />　　软件工程这类书要学，不过软件工程软件需求最关键就是用例场景的合理建立，这条，好象没有什么大学教科书谈到，仿佛中国的大学计算机科学系教师统统没有做过软件项目的，完全没有这个概念。所谓的软件需求，如果不是变成走不通的伪代码，就是用不上的美工方案，程序员对此除了干瞪眼是没辄的。 <br />　　其中最大的原因就是从事网站或者类似的软件需求的许多人

【聚杰网需求管理】IT项目中客户需求定义的原则和方法　　在企业的销售队伍中，经常听到的抱怨是“我们的客户不需要”“我们的客户没有钱”“客户说要等一段时间”……等等一些无法开发和征服客户的声音，根本的原因是由于不了解客户的真实需求，销售人员在销售时盲无目的地向客户介绍或者演示产品，结果徒费口舌，不但没有把自己产品的特色向特定的消费者阐述清晰，还误导了其他的销售人员，致使整个销售队伍萎靡不振，不去主动地开发客户，只在消极的应对工作。　　　事实上，成功的销售不是如何去说服客户，而是对客户的需求作出

<br />业务建模时期（上）<br />　　有非常重要的意义。不同的人、不同的方法对这项工作有不同的描述，在我们的文章中，根据UP的思想，称之为"业务建模".所有的项目都有业务建模时期1. 业务建模是什么业务建模（BusinessModeling），业务建模是一个复杂的过程，对其下一个准确的定义是困难的事情。在RUP的词汇表中将其解释为："包含您可用来对业务进行可视化建模的所有建模方法。这些是您可用于执行业务工程的方法的子集。"从定义中可以看出，它是一种建模方法的集合，目的是对业务进行建模。这

<br />　　和上一篇的理论不同，这一篇文章更注重于实际，举出了在业务建模简短需要注意的一些原则和实践，每一条都来自于实践之中，也都有理论的支持。其中的很多内容更是经过多次的失败才总结出来的。相信大家如果能够理解这些原则和实践的某些方面，至少能够避免重蹈覆辙。<br /><br />　　原则（Principle）<br /><br />　　1. 谁才是"上帝" <我们说客户是上帝，是因为客户的重要性，客户占有决定性的地位。可是在软件开发中，到底是谁有决定权呢？是出资方，还是项目经历，或是程序员？<

<br />【聚杰网需求管理】软件项目需求调研过程管理小议<br />    一、需求调研准备： <br />    在需求调研过程中，应该做好三种准备，保持两种心态，做到五种提高： <br />    三种准备 <br />    1） 调研前应该将所有项目前期资料进行汇总，与相关的前期销售人员进行交流，以便对项目有一个基本轮廓的认识。 <br />    2） 做好调研前使用资料的准备，如需求调研模板，需求调研问题列表等。 <br />    3） 做好不怕一切困难的准备。 <br />

<br />    在“需求分析”中一般可以从三个方面去考虑：<br />    1、功能需求——产品应该完成哪些功能，即向用户提供的功能，一般来说这个都是比较硬性的标准；<br />   2、非功能性需求——用户可能不能明确告诉你的一些需求，比如说性能达到什么要求，可靠性方面，响应时间，扩展性，性能方面等，这块的内容并不是说用户需要，而是说不知道需要做成什么样的，我们不能不做，做了只会对自己受益。要不然等到后期用户使用感觉这慢，那不爽，那倒霉的还是是自己；<br />    3、一些约束——在需求

<br />【聚杰网需求管理】细谈软件需求分析过程 提取-抽象-升华 <br />　　软件的需求分析必须要有对原业务的一个深入了解、提取、抽象、升华的过程，管理软件需求分析尤其如此。<br /><br />　　软件的需求分析是从用户的业务中提取出软件系统能够帮助用户解决的业务问题，通过对用户业务问题的分析，规划出我们的软件产品。这个步骤是对用户业务需求的一个升华，是一个把用户业务管理流程优化，转化为软件产品，从而提升管理而实现的质的飞跃，这一步是否成功，直接关系到开发出来的软件产品能否得到用

<br />【聚杰网需求管理】项目范围管理是项目成败的关键<br />　　引子<br />　　一个项目从其一成立开始，项目各方干系人都会期望项目能够根据既定的计划一步步顺利地导向最后的成功。影响项目的最后成功的因素是多方面的，包括项目管理的九大知识领域（包括项目的整体管理、范围管理、时间管理、费用管理、质量管理、人力管理、沟通管理、风险管理和采购管理），无一对项目的最后成功不产生积极影响。然而，要这九大知识领域对项目成功产生的影响的轻重程度上进行比较的话，我认为其中项

在论坛里看到zandb提问到：“作为软件产品的需求分析，我们是否应该注重具体的实现？对需求文档的撰写、需求描述，是否应该涉及到具体的实现呢？还是应该在功能上给予说明即可？”    　这是个很好的问题，关于需求分析粒度的问题。   　 zandb举了一个例子，例如OfficeWord里的“替换”功能。“对于这个功能的需求描述，是否应该写成：选择‘编辑’，在下拉式菜单中单击‘替换’，显示替换窗口，在替换窗口中‘查找内容’中输入想要被替换的字符串，在‘替换为’编辑框中输入希望替换的字符串，单击‘全

<br /> 要想说什么是好的需求分析，不如说什么是不好的需求分析，知道什么是不好的，自然也就知道了什么是好的。以下就是一些不好的情况：  <br />（１）创意和求实  <br />　　毋庸质疑的，每个人都会为自己的一个新的Ｉｄｅａ而激动万分，特别是当这个Ｉｄｅａ受到一些根本不知道你原本要干嘛的人的惊赞时。但是请注意，当你激动得意的时候，你可能已经忘了你原本是在描述一个需求，而不是在策划一个创意、创造一个概念。很多刚开始做需求分析的人员都或多或少的会犯这样的错误，陶醉在自己的新想法和新思路

　做好需求是一个软件项目成功的一半，尤其对于业务管理系统更是如此。如何更好地获取需求和分析需求，本文介绍个人的方法，不是阳春白雪的方法论，也没有很深的理论术语，但是却是很实用，供大家参考。 　　业务需求的两下两上： 　　对项目的业务需求的分析是一个项目的入口和最重要的事情，但是很多人员并不知道怎么考虑项目的业务需求。反而受项目范围管理的束缚走进了教条主义。自己认为，用户

  历尽千辛万苦，终于签署合同，IT供应商拿到了用户提供的几页“需求书”；然后就凭借自己的理解立即投入开发，等生米熬成粥才发现满足不了用户需求，接下来就是艰难、反复地修改，最后开发人员厌倦了，用户也厌倦了，当然项目款也遥遥无期。这样的案例可谓比比皆是！ 　　比起不成功的项目，一个成功的项目在开发者和客户之间往往采取了更多交流方式；IT供应商不仅与终端用户或潜在用户群交流，而且对用户

软件的需求分析必须要有对原业务的一个深入了解、提取、抽象、升华的过程，管理软件需求分析尤其如此。  　　软件的需求分析是从用户的业务中提取出软件系统能够帮助用户解决的业务问题，通过对用户业务问题的分析，规划出我们的软件产品。这个步骤是对用户业务需求的一个升华，是一个把用户业务管理流程优化，转化为软件产品，从而提升管理而实现的质的飞跃，这一步是否成功，直接关系到开发

需求实践所面临的问题需求完整性需要诸多用户的参与和确认，而且用户间需求本身也存在冲突的可能，因此需求更加强调角色和场景和划分，一个所有用户需要都能够满足的需求往往不是一个好需求。 需求过程缺乏用户的参与，我们往往是技术驱动，习惯性的跳到模块的划分导致需求本身验证困难，也导致了需求间耦合很紧，很难在后期组织有效的迭代开发。因此要考虑按流程和业务梳理需求。

作者：吴文钊 出处：ChinaByte  软件公司对从事需求调研人员的基本素质是不太注意的，企业的信息化主管经常可以看到软件公司派住的调研人员的年龄是偏低的、经验是不够的。在我与企业中、高层管理者的交流中，他们普遍都有这样的感觉：“对于企业来讲，我们不太清楚信息化调研应当怎样开始，又怎样结束，我们实际上更关心的

<br />首先声明，本人业余编程爱好者，把编程当作玩，不在IT界谋生，工作和生活圈子中也无人懂编程，好在有互联网，学了点皮毛，胡言几句，请大家拍砖。<br />软件工程本质的三句话总结：<br />　　第一句：软件工程的终极目标是复用。<br />　　第二句：复用永远要面对的问题是变化。<br />　　第三句：依赖是导致变化难以控制的主要原因。<br />　　关于第一句话，不想多做解释，当然，软件工程中还有成本控制、开发周期控制、文档管理等等，这些工作最终都要通过复用来解决。<br /

<br />问题描述：<br />客户的参与是发布一个优秀软件的关键因素，在项目的开始阶段就应该努力致力于为你的项目征求各个客户的意见。软件需求的成功，和软件开发的成功都取决于开发者是否尽可能地采纳客户的意见。为了征求客户的意见，我们该如何学习/快速掌握用户需求？<br />　精彩答案：<br />　　1、与客户保持密切关系－－关键<br />　　1）多与客户交流，切忌闭门造车。（不能见实际客户，就多与需求人员交流吧，多思考，多提问题，多理解）<br />　　2）多与实际应用的客户交流，软件的目的是为了

<br />对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”(Leffingwell1997)。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟(期望差异)—开发者开发的与用户所想得到的软件存在着巨大期望差异。<br />　　在软件工程中，所有的风险

业务流程管理定义 <br />　　业务流程管理是将生产流程、业务流程、各类行政申请流程、财务审批流程、人事处理流程、质量控制及客服流程等70%以上需要两人以上协作实施的任务全部或部分由计算机处理，并使其简单化、自动化的业务过程。[编辑]<br /> 业务流程管理的需求与产生的背景 <br />业务流程(也叫做经营流程)是为了实现一定的经营目的而执行的一系列逻辑相关的活动的集合，业务流程的输出是满足市场需要的产品或服务。根据功能、管理范围等的不同，企业的流程管理一般分为生产流