在线等！软件工程 需求获取期间什么是最有用的信息来源

（1）开发一个系统取代现有的销售订单处理系统。

答：跟销售人员的沟通很必要，试着了解他们的销售量，并且他们的销售流程，以及旧系统所存在的问题。跟客户的沟通也很必要，了解他们的需求，同时从不同类型的客户咨询。观察旧系统的一个 *** 作流程，同时了解可能的潜在用户，改进现在的工作流程，以追求实现利益最大化。

不仅是在新产品开发时需要通过市场调查研究获取用户需求，从而转化为产品需求，产品上市后需要定时对产品迭代升级（特别是互联网产品），同样需要收集用户需求，还包括运营需求。切记，无论在任何时候，需求都不能是产品经理或领导层的“拍脑袋”决定，即使在产品上市后。产品上市后的需求来源更加，呈现出多元化，因此需要产品经理对需求来源进行梳理，确保不要遗漏，从而更好的做出需求管理及迭代计划，避免临时抱佛脚，到处救火。结合我10年的工作经验和社群其他产品经理的经验，我们汇总了产品需求的主要需求来源途径，供大家参考，如图7-1所示。

图7-1 产品需求主要来源途径

以上的需求来源方式多数已在前文中做过介绍，在此不再一一列举详加阐述。在此我将产品上市后的需求来源分为四类：用户体验反馈、业务发展需要、产品数据分析、竞争对手分析，具体实践如下。

1 用户体验反馈

产品在上市后交付用户后，用户的使用情况、体验、满意度反馈对企业来说十分重要，因为这是衡量产品价值及成功的最直接体现。通过用户反馈，我们可以及时的对产品进行改进提升以满足用户的需求，赢得口碑。为避免产品缺陷带来的市场灾难，试销是解决这一问题的最佳途径。即使产品全面上市后，依然要对定时进行市场调研获取用户反馈，对B端客户更要亲临现场听取客户意见和观察用户使用情况。对于互联网产品而言，一定要提供在线用户反馈通道，确保724小时听取客户意见及建议。来自客户的反馈是最真实的，最有效的需求，一定要高度重视，但同时要避免用户带有感情色彩，以偏概全。建议针对用户反馈的问题要进行进一步的研究，找出问题的根本所在：是缺陷的要立刻补救；是体验的要尽力提升；是个性化需求的要研究分后再做决策。

2 业务发展要求

在市场环境下，企业根据战略要求，按照既定的产品路线图和技术路线图对产品进行升级迭代，比如比如苹果手机每年都会推出新款手机，增加性能或提升性能。这一是为了满足市场的需求，二是为了加强市场竞争力。在互联网领域，由于产品和运营是密不可分的整体，因此运营人员为了推动产品发展，也会提出大量需求，用户看到的是前端服务，而为了支持前端服务需要一个庞大的后台，比如电子商务类产品，很多功能结构都需要依赖于自身的业务决策，并不是想怎么做就怎么做的。这些都是业务发展的具体需求表现，通常都是由内部提出来的。

3 产品数据分析

产品上市后就要严密的关注产品各项表现数据，为产品的迭代升级提供支撑，为产品经营策略决策提供依据。非互联网行业可以通过ERP等产品流通数据管理软件来收集分析产品经营数据，互联网行业可以通过专业的统计工具来收集，如Google、Anlystic、百度统计、站长统计、友盟统计等等，再有用户的访问数据，包括浏览痕迹、点击痕迹、在每个页面上的浏览时长，整体的浏览顺序等等，这些需要预先埋点，等于说必须要在设计的时候就考虑到后期的这种数据收集的需求，从而为数据分析打下基础，否则获取不到数据，何谈分析呢？有了数据之后还要注意分析的方法，所以产品经理要稍微知道一点数据分析和数据挖掘的知识，能够从数据当中寻找关联，发现关系，从而得出结果）。另外，还可参考一些公共调研机构出具的一些数据分析报告，比如艾瑞资讯等对互联网行业里面所做的一些数据分析，很多都很有参考价值，有些数据是我们收集不到的，但这些专业的调研机构可以，这样就能形成互补。

4 竞争对手分析

谈到竞品分析我们首先想到的就是去研究同类产品，从中找出别人产品的优劣势，进而发现产品的突破口，即如何做到人无我有，人有我优，人优我精。可是还有一种竞品分析是大家不常用的，那就是跨行业做竞品分析，而且这种方式在创新应用上要强于同业竞品分析（同业的竞争度太高，同质化太严重）。这种方式是我在500强企业工作时，CEO教会我的。当时我们在做一款保险代理人科技赋能APP,在上一家单位的时候我主要是通过同业竞品分析，采用差异化来提升产品，当CEO要求我去做异业体验报告和竞品分析的时候，我表示非常的不能理解，但还是去执行了，在这个过程中受益匪浅。比如，我们通过研究自媒体营销，将自媒体营销工具植入到我们的APP里，开发“自媒体助手”帮助代理人构建自媒体营销矩阵传播保险内容来获取保险客户。这是非常好的跨界借鉴应用，慧择网通过这种方式构建了18000余个个人代理保险营销账号，其影响力和范围远超企业官方账号，成为保险界营销创新的一大亮点，为慧择的成功上市提供了重要的数据支撑。由此，在同质化竞争日趋激烈的市场，希望大家能将目光放的更远一些，范围更大一些，去寻找灵感，寻找有竞争力的需求点。

以上是一些常见的需求获取的来源，可能并不止于这些，还有别的方法这里没有提及到，日后大家可以相互交流补充。需求获取是产品开发的第一步，有需求了才能进行需求分析，才能进行产品定义，因此做好需求获取至关重要。

我们的软件产品或者项目，其需求都有三个层级和三个方面。 一、我们首先看需求的三个层次 软件需求包括3个不同的层次――业务需求、用户需求和功能需求。 业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。 功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。 系统需求（system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。 业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。 功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。 除此之外，对于需求层次，我们还有其它的分法： 组织级需求->业务需求->用户需求->功能需求（有时也叫行为需求）。 组织级需求：一般代表着组织的愿景和目标。对于大的公司，一般是通过资深的咨询顾问和咨询公司得出的，呈现的方式是咨询报告。比如在ITSM或者企业信息化这方面。典型的组织级的需求是：降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。 业务需求：是要完组织的使命，达成组织的愿景的各个业务流程和业务单元具有的需求。业务需求服从于组织需求。 用户需求：用户级的需求，是在业务级的需求下，各个岗位协作完成业务而具有的需求。我们在软件需求规格说明书中表述的需求其实主要是这一部分需求。 功能需求：同样，它代表着产品或者软件需求具备的能力。 一般是管理人员或者产品的市场部门人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。所有的用户需求都必须符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能需求和非功能需求设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性能指标。当一项新的特性、用例或功能需求被提出时，需求分析员必须思考一个问题：“它在范围内吗？”。如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。 二、需求的三个方面 除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。 质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。还有一项称为可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。 约束（constraint）限制了开发人员设计和构建系统时的选择范围。约束，在产品的架构设计中，是需要被首先考虑的问题。 如果说产品的功能代表了产品的能力，那么产品的质量属性代表了产品的品质，产品的约束代表了产品必须去满足的或者适应的条件！用人说“用户体验”是产品的灵魂，对于个人级的软件这么说或许很恰当，当对于企业级甚至是行业级的产品，其灵魂有两个：一个是产品带个用户的价值，另一个是产品的品质，简单的说，就是价值和品质。但其成为一个产品的前提应该是满足约束，否则就不应该设计、开发、进入市场而成为一个垃圾。

软件需求分析阶段的工作，可以分为四个方面：需求获取、需求分析、编写需求规格说明书以及需求评审。

需求获取：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。

这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、 *** 作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。

需求分析： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。

编写需求规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。

需求评审：对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作，否则重新进行需求分析。

扩展资料

软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。

业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。

功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。

作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的 *** 作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。

参考资料来源：百度百科-软件需求

参考资料来源：百度百科-需求分析

以上就是关于在线等！软件工程 需求获取期间什么是最有用的信息来源全部的内容，包括:在线等！软件工程 需求获取期间什么是最有用的信息来源、产品的需求来源有哪些、什么是软件需求包括哪些层次等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！