什么是软件需求，什么是功能需求？

当今社会，已经步入信息时代，无论你身处何种职场，都离不开信息技术的支撑。大公司、国有单位一般都有自己的信息化专门机构和设施，小微公司、个体户们每天基本上都要与支付巨头、外卖巨头、快递巨头等等打交道，其中信息技术是少不了的。那么，你知道信息技术背后的基础设施是什么？

今天，我们就了解一下什么是IT基础设施。

IT基础设施的定义

IT基础设施定义千差万别，但一般认为是包括运营整个组织所必需的一系列物理设备和应用软件的集合，也包括由管理层预算所决定的组织范围内的人和技术能力的服务集合。我们经常提到的信息技术硬件、软件、服务方面的投资，其实就是IT基础设施。对于企业来说，这些设施，能够为客户服务、供应商联系和内部管理提供基础。

不要小看这些基础设施，它们往往占了大型企业信息技术支出的25%-30%。

IT基础设施的快速演化

IT基础设施已经走过了近60年的道路，大体可以分为5个阶段：

通用主机及小型计算机阶段（1959年至今），主机拥有非常强大的功能，能够支持数千个远程终端，采用高度集中的计算模式，计算机系统由专业的程序员和系统 *** 作员集中控制，通常就是在数据中心完成相关工作。之后又出现了小型计算机，就是我们所说的小机，价格比主机便宜，也便于分散部署，逐渐发展为网络的一个组成部分。

个人计算机阶段（1981年至今），这个阶段国人都比较熟悉，Windows *** 作系统、Intel微处理器的个人计算机，伴随个人计算机普及出现的office软件，在全世界运用都非常广泛。

客户机、服务器阶段（1983年至今），其实我们每天都在打交道，我们用个人计算机，访问某个网站，其实就是这个阶段的典型代表。

企业计算阶段（1992年至今），主要是一些大型企业和机关事业单位，从上世纪末开始，应用一些网络标准和软件工具，将分散的网络与应用进行整合，形成覆盖整个企业的基础设施网络体系，以便信息在组织内部以及不同组织间自由流动。

云计算及移动计算阶段（2000年至今），这是我们重点要说一说的阶段。所谓云计算，实际上就是通过网络访问计算资源共享池的一种计算模式。其中，计算资源包括计算机、存储、应用和服务，都可以按需使用的方式，从任何联网的设备和位置进行访问。为了支持此种类型计算，产生了安置上万台计算机的云数据中心，为那些希望在远程维持IT基础设施的企业提供计算能力、数据存储和高速互联网连接服务。

需要注意的是，这五个阶段是交叉的，从某种程度上每个阶段的典型代表之间也是残酷竞争的，还没有那个阶段的典型产品彻底退出历史舞台。

项目管理者联盟文章 在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。 1问题分析 问题分析可以通过了解问题及涉众的最初需要，并提出高层解决方案来实现。它是为找出“隐藏在问题之后的问题”而进行的推理和分析。问题分析期间，将对“什么是面临实际问题”和“谁是涉众”等问题达成一致。而且，您还要从业务角度界定解决方案，以及制约该解决方案的因素。您应该已经对项目进行过商业理由分析，这将便于您更好地预计能从构建中的项目中得到多少投资回报。项目管理培训 2理解涉众需要 需求来自各个方面，比如来自客户、合作伙伴、最终用户或是某领域的专家。您需要掌握如何准确判断需求应来源于哪方面、如何接近这些来源并从中获取信息。提供这些信息主要出处的个人在本项目中称为涉众。如果您正在开发一个在您公司内部使用的信息系统，那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员。通常讨论将在业务模型这一级上展开，而不是在系统这一级上展开。如果正在开发一个要在市场上出售的产品，那么您可以充分调动营销人员，以便更好地了解该市场中用户的需要。获取需要的活动可使用这样一些技巧：访谈、集体讨论、概念原型设计、问卷调查和竞争性分析等。获取结果可能是一份图文并茂的请求或需要列表，并按相互之间的优先级列出。 3定义系统 定义系统指的是解释涉众需求，并整理为对要构建系统的意义明确的说明。在系统定义的初期要确定以下内容：需求构成、文档格式、语言形式、需求的具体程度(需求量及详细程度)、需求的优先级和预计工作量(不同人在不同的实践中通常对这两项内容的看法大不相同)、技术和管理风险以及最初规模。系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。系统定义的结果是用自然语言和图解方式表达的系统说明。

我们的软件产品或者项目，其需求都有三个层级和三个方面。一、我们首先看需求的三个层次软件需求包括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培训主要就来简单讲解一下，当我们获得这些用户需求之后，如何根据不同的商业目的进行需求分类整理呢？

我们在进行需求分类的时候，一般有两种方式同时进行。

一、横向分类

首先来说，为什么我们拿到需求后，要把需求进行分类因为产品在不同时期，对于不同类别的需求，会有不同的权重。我们常说，产品有起步期、发展期、稳定期。而需求根据每个公司或者产品经理的定义，可能将需求分类为：功能类、bug修复类、体验类、运营类、数据类等。

(1)产品的起步期

在产品的起步期，我们会将核心功能的需求放在权重高一些的位置，把产品的地基打好，骨架搭好，快速上线来验产品模式。别连房子还没盖好，就在纠结地砖的颜色。此时的产品经理一定要控制好自己完美偏执狂的内心冲动，对于增加新功能和体验上的需求要做好排序，此时开发核心功能，快速投入市场试错才是我们的目标。

(2)产品的发展期

到了发展期会让产品尽快做完善，或根据市场反馈对产品方向进行一定的调整，此时bug修复类、运营类的需求就放在首位了。产品投入市场后，可以收集各渠道的用户反馈，有没有切实解决目标用户的问题产品的方向是不是正确的在产品发展期，完善产品的过程中，对于需求更是要有把控力，做需求分析最后输出的结果就是做需求决策，学习乔帮主做简约主义者，决定不做什么比决定做什么更加重要，往往鸡肋需求，开发出来上线容易，但是要去掉，就没那么容易了。

(3)产品的稳定期

再到了产品的稳定期，产品趋于成熟，用户数也多起来了，产品不断迭代，此时提升用户体验和数据类的需求就变得很重要了。比如A/Btest，在用户量小的时候，得到的数据会有较大的出入，是不可取的。在产品的稳定期，有比较大的用户量时，可以用数据来驱动产品的迭代。

以上就是关于什么是IT基础设施呢全部的内容，包括:什么是IT基础设施呢、如何做好IT项目之需求管理、什么是软件需求，什么是功能需求等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！