Drian

概念：中间件处于应用软件和系统软件之间，是一种以自己的复杂换取企业应用简单化的可复用的基础软件。在中间件产生以前，应用软件直接使用操作系统、网络协议和数据库等开发，开发者不得不面临许多很棘手的问题，如操作系统的多样性，繁杂的网络程序设计和管理，复杂多变的网络环境，数据分散处理带来的不一致性，性能和效率、安全问题等等。这些问题与用户的业务没有直接关系，但又必须解决，耗费了大量有限的时间和精力。于是，有人提出将应用软件所要面临的共性问题进行提炼、抽象，在操作系统之上再形成一个可复用的部分，供成千上万的应用软件重复使用。这一技术思想最终形成为了中间件产品

从技术上讲，中间件是介于应用系统和系统软件之间的一类软件，它使用系统软件所提供的基础服务（功能），衔接网络上应用系统的各个部分或不同的应用，能够达到资源共享、功能共享的目的。

优点：　1应用开发：The Standish Group分析了一百个关键应用系统中的业务逻辑程序、应用逻辑程序及基础程序所占的比例，发现了一个有趣的平均百分比，其中，业务逻辑程序、应用逻辑程序仅占总程序量的30%，而基础程序却占了70%!若是以新一代的中间件系列产品来组合应用，同时配合以可复用的商务对象构件，则应用开发费用可节省至80%。
　　　　　　2系统运行：没有使用中间件的应用系统，其初期投入的资金及运行费用要比同规模的使用中间件的应用系统多一倍。
　　　　　　3开发周期：时间限制是所有应用系统开发项目的天敌，而基础软件的开发又是一件极耗时的工作，若使用标准商业中间件则可缩短开发周期50-75%。
　　　　　　4减少项目开发风险：The Standish Group对项目失败的定义是：项目中途夭折、费用远远超过预算、无法准时完成项目和偏离既定的目标。研究表明，没　　　　　　　　　　有使用标准商业中间件的关键应用系统开发项目的失败率高于90%。而且，企业自己开发内置的基础(中间件)软件是得不偿失的，项目总的开支至少要翻一倍，甚至会十几倍。
　　　　　　5合理运用资金：借助标准的商业中间件，企业可以很容易地在现有或遗留系统之上或之外增加新的功能模块，并将它们与原有系统无缝集合。
　　　　　　6应用集合：依靠标准的中间件可以将现有的应用、新的应用和购买的商务构件融合在一起。
　　　　　　7系统维护：每年维护自我开发的基础(中间件)软件的开支是当初开发费用的15%至25%，每年应用程序的维护开支也还需要当初项目总费用的10%至20%。
　　　　　　8质量：基于企业自我建造的基础(中间件)软件平台上的应用系统，每增加一个新的模块，就要相应地在基础(中间件)软件之上进行改进。The Standish Group在调研过程中，曾在某个企业中的一个应用系统里，发现了有多达1万7千多个模块接口，而标准的中间件在接口方面都是清晰和规范的，可以有效地保证应用系统质量及减少新旧系统维护开支。
　　　　　　9技术革新：企业对自我建造的基础(中间件)软件平台的频繁革新是不容易实现的，也是不实际的，而购买标准的商业中间件，则对技术的发展与变化可以极大地增强其适应性。
　　　　　　10增加产品吸引力：不同的商业中间件提供有不同的功能模型，合理地使用，可以让用户的应用更容易增添新的表现形式与新的服务项目，从而使得企业的应用系统更完善、更出众。

分类：　消息中间件，交易中间件，应用服务哭，安全中间件等　

业务需求一般由最终用户或者领域专家从业务的角度提出，具有以下特点：直觉，凌乱，片断，模糊，无条理，甚至是自相矛盾，主要内容涉及业务发起人，业务流程，业务实体，业务规则等。所谓业务，并不一定是指做生意，举个例子，编译系统的领域专家就是编译原理的专家。

系统需求一般由系统分析师或者架构师从软件系统的角度提出，依据业务需求以及系统其他涉众的需求，包括系统开发成本进度，系统环境的限制，法律法规的规定，业务数据量，系统管理和维护，系统安全性，易用性，维护性，扩展性，重用性，可靠性等等要求，系统分析师必须平衡所有这些需求，将业务需求涉及的业务发起人，业务流程，业务实体，业务规则有选择的映射到系统中，提出细化的，一致的，可追溯的，可测试的系统需求规范。 系统需求不是静止不变的，随着系统设计开发测试的进行，系统需求会不断完善，但这不能成为系统分析师逃避责任的借口，系统分析师必须掌握系统需求的主导权，想客户所未想，做好需求管理工作，否则开发人员就会有沦为码农之虞。 相对于系统需求，业务需求更稳定。

系统需求可进一步细分为用户需求，功能需求，非功能需求。用户需求从最终用户的角度描述系统行为，一个用户需求可能会涉及一个或多个功能需求，功能需求从开发人员的角度描述系统行为，一个功能需求支持一个或多个用户需求，非功能需求支持功能需求。

业务需求与用户需求之间不是一对一的关系，一个业务需求可能对应多个用户需求，一个用户需求可能满足多个业务需求。另外并不是所有用户需求都与业务需求有直接关系。

在实际的需求分析过程中，系统分析师必须清醒的认识到客户很难区分业务需求和用户需求的差别，搞清楚客户背后的真正的业务需求。