我们的软件产品或者项目，其需求都有三个层级和三个方面。一、我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户需求和功能需求。业务需求 （Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业 务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。用户需求 （user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。功能需求 （functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什 么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标 得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用 户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。系统需求 （system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。业务规则 包 括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁 能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能 需求进行追溯时，会发现其来源正是一条特定的业务规则。功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库 或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试 、质量保证、项目管理和其他 相关的项目功能都要用到 SRS。除此之外，对于需求层次，我们还有其它的分法：组织级需求->业务需求->用户需求->功能需求（有时也叫行为需求）。组织级需求： 一 般代表着组织的愿景和目标。对于大的公司，一般是通过资深的咨询顾问和咨询公司得出的，呈现的方式是咨询报告。比如在ITSM或者企业信息化这方面。典型 的组织级的需求是：降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。业务需求： 是要完组织的使命，达成组织的愿景的各个业务流程和业务单元具有的需求。业务需求服从于组织需求。用户需求： 用户级的需求，是在业务级的需求下，各个岗位协作完成业务而具有的需求。我们在软件需求规格说明书中表述的需求其实主要是这一部分需求。功能需求： 同样，它代表着产品或者软件需求具备的能力。 一般是管理人员或者产品的市场部门人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。所有的用 户需求都必须符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能需求和非功能需求设计解决方案，在约束条 件的限制范围内实现必需的功能，并达到规定的质量和性能指标。当一项新的特性、用例或功能需求被提出时，需求分析员必须思考一个问题：“它在范围内 吗？”。如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定： 是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。二、需求的三个方面 除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。质量属性 （quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或 开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。还有一项称为可用性（usability）的质量属性，它规 定了业务需求中“有效”（efficiently）一词的含义。约束（constraint）限制了开发人员设计和构建系统时的选择范围。约束，在产品的架构设计中，是需要被首先考虑的问题。如果说产品的功能代表了产品的能力，那么产品的质量属性代表了产品的品质，产品的约束代表了产品必须去满足的或者适应的条件！用人说“用户体验”是产品的 灵魂，对于个人级的软件这么说或许很恰当，当对于企业级甚至是行业级的产品，其灵魂有两个：一个是产品带个用户的价值，另一个是产品的品质，简单的说，就 是价值和品质。但其成为一个产品的前提应该是满足约束，否则就不应该设计、开发、进入市场而成为一个垃圾。用户需求 功能需求 区别简单的就是： 用户需求。用户需要在应用系统中实现什么东西，为实现这个目标，需要用户提供的全部的详细的业务说明，业务流程，表格样式等。 功能需求。将用户需求归类分解为计算机可以实现的子系统和功能模块，用设计语言描述和解释用户的需求，以达到可以指导程序设计的目的。
概念模型是什么？
信息化建设的成功除了有赖于符
合未来整体发展战略的业务实现模式和业务逻辑、符合业务模式和业务逻辑的信息技术架构和平台，还需要相应的信息管理组织去支撑业务信息系统的规划、实施、运营、维护和管理。怎样构建企业IT运营管理体系，使得企业信息管理模式与企业业务管理模式和企业应用特点能够有机的融合，是企业信息组织建设的关键，同时也决定了企业未来在信息化建设方面顺利推进的重要保障。
1 对企业IT管理使命的理解
在充分理解和融合企业业务管理战略的基础上，运用先进的管理思想和信息技术，推动企业改革与发展；建立满足企业需要的一流的IT基础设施，迅速地提升企业IT能力和应用水平，满足企业未来发展战略的需要。为此，建立高效的IT运营管理体系是首要任务。一般来说IT运营管理基本定义应包括以下内容：
·IT运营管理基本原则：应作为企业集团IT运营管理体系的基本指南；
·IT运营管理策略：用于确定企业集团各种IT活动间关系的基本原则和出发点； ·IT运营管理组织：明确企业集团各项信息技术活动的授权和责任； ·IT运营管理流程：明确信息技术活动的程序以保障高效的运作； ·IT运营资源和技能管理：提供企业IT管理运作所需要的技能资源；
·IT运营体系的运行与维护：保障企业IT运营体系服务的成本效率和操作性。
2 IT运营管理基本原则
IT运营管理基本原则是指为加强企业在信息技术方面的战略执行能力而提出的基本的准则和指导性的方针。根据信息技术发展的特点结合企业信息化的发展需求，其基本原则框架应由七个部分组成：
总方针
战略的融合：信息技术因素需要渗透到企业战略的制定中去；
业务伙伴关系：企业的IT将与业务用户在工作上建立伙伴关系，以了解和达成企业的业务实现目标；
IT项目应视为投资：信息技术项目应该被视为一项投资，它应以支持业务需求为基础； 以客户为中心：信息化管理应以服务水平为基础，重点应关注在满足业务部门的需求； IT组件配置：应遵从IT体系结构和IT标准；
IT资源共享：IT资源应被视为企业的一项资产，每一个企业员工都有责任和义务正确的使用和保护这些资产；
IT策略和规划的沟通：IT的策略和规划应在企业集团内部进行有效的交流和沟通。
信息组织和流程
熟练和专业的工作团队：保持一个熟练和专业的工作团队管理整个体系结构，以确保达成业务目标, 业务部门从组织上参与信息部门的管理；
策略和规划的管理：为适应业务和技术的变化，有必要对策略、规划、管理、信息服务目标实现的成效作周期性审查和改进；
流程与职责：流程和职责分配要被明确清楚定义。
技术管理
技术创新的使用：主动进行技术创新，以增强企业的核心竞争力；
行业标准的使用：当存在相应的行业标准并能满足所涉及的业务需求时，应采用相应的行业标准；
因特网技术的作用：未来的应用系统和服务的交付要考虑使用互联网/企业内部网/局域网技术。
IT运营服务管理
未来的企业，在信息技术硬件和软件的应用方面会愈来愈集中，即通常所说的物理集中和业务逻辑的集中。信息中心的职能在这种高度集中的模式下，其定义相应地发生了改变。从组织层面上来看，信息管理组织将企业的IT部门从成本中心转化为服务中心；从具体IT运作层面上来看，它不是传统的以职能为中心的IT管理方式，而是以流程为中心，对复杂的IT
管理活动进行管理，比如事故管理、问题管理和配置管理，将这些流程规范化、标准化，明确定义各个流程的目标和范围、成本和效益、运作步骤、关键成功因素和绩效指标、有关人员的责权利，以及各个流程之间的关系。它的根本目标体现在：
（1）提供以业务为中心的信息服务； （2）提供高质量、低成本的服务； （3）提供的服务如需要是可准确计价的。 数据
数据获取：每个数据将仅在企业第一次出现的时间和地点被获取一次，以后在整个企业内部共享；
数据分布：数据分布应遵守完整性和应用的需求，数据容量、数据需求共享、网络能力和数据安全同样也需考虑；
数据词典：应有一个对企业所有应用程序存取并遵循的、全公司范围的数据定义； 数据共享：应用程序应共享已有的数据，除非必须要坚持满足特殊的安全性和完整性需求； 数据所有权：每一个信息单元都需指派拥有者，负责定义数据的使用规则和保护规则； 数据质量：所有的数据在概定的频率内均可得到，保存时间长短要按时间而定，还应经过标准验证流程验证，确保数据的准确性和完整性。
应用系统
用户需求：所有的应用系统的采纳或设计都必须依照用户业务需求，并要得到业务赞助人的认可；
公共评价标准：对企业内部所有的应用系统（包括软件包）将采用一套公共的评价标准进行评价；
引进与管理：采用标准软件包。对于新应用系统供应商的引入需要建立相应的控制策略及制度，建议重点考虑国际领先的标准软件包。 网络
外部连通性：网络必须使外部连接更方便；
行业标准：行业标准将被用于企业内部和对外的沟通；
单一的逻辑网络：将只有一个逻辑、用于实际运作的网络为各互联系统提供应用和数据存取；
也称信息模型，它是按用户的观点来对数据和信息建模。概念模型是现实世界到机器世界的一个中间层次。表示概念模型最常用的是实体-关系图。概念模型是对真实世界中问题域内的事物的描述，不是对软件设计的描述。概念的描述包括：记号、内涵、外延，其中记号和内涵（视图）是其最具实际意义的。概念模型用于信息世界的建模，它是世界到信息世界的第一层抽象，它数据库设计的有力工具，也是数据库开发人员与用户之间进行交流的语言。因此概念模型既要有较强的表达能力，应该简单、清晰、易于理解。目前最常用的是实体-联系模型。在管理信息系统中，概念模型：是设计者对现实世界的认识结果的体现，是对软件系统的整体概括描述。让读者更易理解，读时有个参考的东西。概念模型设计的常用方法是实体关系方法（E-R方法）。用实体关系方法对具体数据进行抽象加工，将实体集合抽象成实体类型，用实体间的关系反映现实世界事物间的内在关系。首先可以进行局部E-R模型，然后把各局部E-R模型综合成一个全局的E-R模型，最后对全局E-R模型进行优化，最后得到的。在数据仓库中的含义总的来说，数据仓库的结构采用了三级数据模型的方式，即概念模型、逻辑模型、物理模型。概念模型:也就是业务模型,由企业决策者,商务领域知识专家和IT专家共同研究和分析企业级的跨领域业务系统需求分析的结果。在数据仓库项目中,物理模型设计和业务模型设计象两个轮子一样有力地支撑着数据仓库的实施,两者并行不悖,缺一不可。实际上,这有意地扩大了物理模型和业务模型的内涵和外延，因为，在这里物理模型不仅仅是数据的存储,而且也包含了数据仓库项目实施的方法论、资源以及软硬件选型，而业务模型不仅仅是主题模型的确立,也包含了企业的发展战略,行业模本等等更多的内容。一个优秀的项目必定会兼顾业务需求和行业标准两个方面,业务需求既包括用户提出的实际需求,也要客观分析它隐含的更深层次的需求,但是往往用户的需求是不明确的,需要加以提炼甚至在商务知识专家引导下加以升华,和用户一起进行需求分析工作。如果不能满足用户的需求,项目也就失去了原本的意义。关于概念模型概念模型设计是在原有的业务数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中有什么、怎样组织的和如何分布的等，然后再来考虑应当如何建立数据仓库系统的概念模型。一方面，通过原有数据库的设计文档以及在数据字典中的数据库关系模式，我们可以对企业现有的数据库中的内容有一个完整而清晰的认识另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。它的工作主要是界定系统的边界和确定主要的主题域。界定系统边界将决策者的数据分析的需求用系统边界的定义形式反映出来。确定主题域是对每个主题域的内容进行较明确的数据仓库建模技术在行业中的应用描述，其内容包括:主题域的公共码键、主题域之间的联系以及充分代表主题的属性组。
以上就是关于业务需求，用户需求，功能需求是什么意思？有什么区别全部的内容，如果了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
