用户需求分析

1. 整体需求不变，具体细节变化。我们说需求是分层次的，整体框架、功能模块、每个操作的细节。如果用户变更到了将整个框架都推翻了，这个项目就别做了。所以整体框架是必须在需求分析阶段完成的，是日后不可能改变的。功能模块可能要变，但通常是某个部分在变，而更多的是那些具体操作的细节在变。 2. 界面风格与操作易用性是最容易发生变更的。我们说用户看到软件以后不满意，其实主要是对界面风格与操作性不满意，而不是软件功能。界面不够美观，操作不方便，不符合用户的操作习惯，都是造成用户不满意的地方。 3. 增加其它功能。软件是对现实的模拟，而现实也是复杂多变的。我们与用户在进行业务流程分析时，也许一些流程没有考虑到，或者还有特殊情况需要处理。这些是客户要求增加功能的主要动因。 经过以上分析，需求分析阶段要做到什么程度就可以清楚了：整体框架与功能模块必须确定下来，至于各个功能模块下的具体操作，尽量做，能到什么程度先到什么程度。至于界面风格与操作性，我们可以在日后迭代开发的每个迭代期，拿出样品以后再与用户确认。 OK，万事俱备只欠东风，当所有工作都完备以后，我们的需求分析工作开始进入最后收尾的阶段。我们说，需求分析阶段的产出物是需求列表与需求规格说明书，而最终结束的里程碑无疑就是需求评审会了，或者说与用户的签字确认会。 来源： https://www.cnblogs.com/shyshy/p

对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。 ---　　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。” --　　-分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。” --　　-经理觉得奇怪：“我不是刚告诉你我的需求了吗？” --　　-分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。” --　　-经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？” ---　

对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。 ---　　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。” --　　-分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。” --　　-经理觉得奇怪：“我不是刚告诉你我的需求了吗？” --　　-分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。” --　　-经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？” ---　

需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题。 　　有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 　　本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 　　 1 什么是软件需求和需求工程 　　1.1 软件需求的定义 　　在IEEE软件工程标准词汇表(1997年)中定义软件需求为： 　　1）用户解决问题或达到目标所需的条件或能力。 　　2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 　　3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标

1.实战中的软件工程——MSF的原则，MSF团队模型和开发模式，CargoCult。 MSF是什么呢？在前面的章节中讲了很多方法论和宣言，但这里介绍的是微软的一个宣言（Microsoft Solution Framework）,MSF有着九个基本原则：推动信息共享与沟通；为共同的远景而工作；充分授权和信任；各司其职，对项目共同负责；交付增量的价值；保持敏捷，预期和适应变化；投资质量；学习所有的经验；与顾客合作。下面对这些原则依次进行了介绍和理解。 首先是推动共享与沟通 。就是所有信息都保留且公开，也就是把所有的信息都共享，都用来沟通。这个原则的好处是能够让整个项目的开发流程更加的具备合理性和逻辑性。这样在管理这个项目时就更加简单了。 第二点，为共同的远景而工作 。其实就是大家一个团队的，力要往一处使，不能说每个人各做各的，到最后谁也好不了。要明白整个项目其实就是每个人的合作组成的。也就是统一思想，上下一条心。 第三点，充分授权和信任 。这一点的关键是授权。也就是每个成员都要有自己的授权，他们在有权在职权范围内完成任务。这个原则其实际是MSF模式的核心之一，团队之间要平等协作，并且各个成员之间得到充分的授权。这样的话，每个人都会负担起自己应该负担的责任，并且有足够的权利去做好自己分内的任务。 第四点，各司其职，对项目共同负责 。这点其实和第三点有着一些相似之处

学习了第八章的需求分析之后，我了解了软件需求的类型、利益相关者；获取用户需求的常用方法和步骤；竞争性需求分析的框架NABCD，四象限方法；项目计划和估计的技术。我们在做产品的时候要明确它所需要满足的各种功能和他的所属类型：杀手功能，外围功能，必要需求，辅助需求。软件项目的时间估计我们可以从自底而上和回溯两个方面来看，从而更好的进行估计。 在学习了第十六章IT行业的创新我了解到的是关于创新，有哪些似是而非的断论；WIIFM；创新者的困境；创新的时机，创新路上的鸿沟；先发优势和后发优势；改良式的创新和颠覆式的创新；效能过剩；NPS,CAC,用户留存率。书中提出的迷思一至七是值得我们去深深思索和探寻的，本章中也有结合第八章所提及的四象限方法，可以一起思考消化。 来源： https://www.cnblogs.com/XLX1/p/5487259.html

对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” (Leffingwell 1997) 。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟 ( 期望差异 ) —开发者开发的与用户所想得到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者 (stakeholder)( 这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人 ) 都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员 ( 负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人 ) 、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。软件需求的定义 IEEE 软件工程标准词汇表 (1997 年 )

读软件需求分析首先明确了软件需求包含的三个不同层次，业务需求即组织机构或客户的需求目标，用户需求即用户使用产品必须要完成的任务，功能需求即开发人员需要实现的软件功能。从需求的定义上我们可以知道需求关注的是究竟想开发什么与设计细节实现细节项目规划信息或者测试信息无关 不重视需求过程会给项目带来极大风险，所以在需求过程中我们要注意避免以下几种情况，无足够用户参与，用户需求不断扩展，用户需求不明确或者说模棱两可，不必要的特性即为软件画蛇添足，过于精简的规格说明，忽略了用户分类，不准确的计划，而高质量的需求过程要求产品开发过程中的通力合作同时充分了解其市场，因此要想完成一份优秀的需求就必须具备完整性（功能完整），正确性（准确陈述其功能），可行性，必要性（每项需求都硬把客户真正需要的和最终系统），划分优先级，无二义性（只能有一个明确统一的解释），可验证性等特性。同时需求规格说明也需具备完整性，一致性，可修改性，可跟踪性（即每项软件需求与它的根源和设计元素，源代码，测试用例之间建立起链接链） 再进行软件需求分析时要清楚谁是客户，谁是用户，分清楚业务需求和用户需求。客户有义务说明软件的业务需求，任何其他的说明都应该遵从业务需求的规定，而用户需求则必须从试用产品的用户处收集，业务需求来自风险承担者，用户需求则来自产品的真正使用操作者。对于客户而言客户有权利要求分析人员使用符合客户语言习惯的表达

一、我们应当如何做需求分析？ 通过阅读《我们应当怎么做需求分析》我了解了需求分析需要进行的阶段，以及需要掌握的内容。 需要掌握的内容如下： （ 1 ）需求调研：其中包括如何与客户交流、建立良好的合作关系、通过研讨会与客户交流获得项目的原始需求并对需求进行研讨，并采用迭代的方式进行需求的不断完善。 （ 2 ）需求分析：分析用例、分析业务流程、构建用例说明、其他例如查询功能的分析、子用例及扩展用例的分析、行动图和状态图、业务领域分析、原文分析、非功能需求分析。 （ 3 ）需求确认：列出需求列表得到用户确认、利用快速原型法得到用户的确认、构建需求规格说明书。 一、需求调研 1 、与客户初识： 要树立良好的职业威信。不要在客户面前唯命是从，要适当地提出自己的见解，这样不但会让客户对自己有信心，而且自己也可以规范化客户的需求，不至于客户提出什么我们就按照客户说的做什么。 进行详细的角色分析，对号入座。客户方有很多的角色，每一个角色都有自己独特关注的地方，要合理地进行角色分析，让他们了解他们所希望了解的问题，对于需求的调研分析非常地重要。 从宏观上制定目标。在将角色进行分析后，要对每一个角色进行特定地分析，与各个角色进行详细地业务分析，详细了解业务的流程，对于需求的分析非常重要。 2 、拜访客户 需求分析需要与客户进行交流，与人交流就要处理好与他人的关系

这几天一直在处理各方面收集到的需求，目前整理的进度应该在80%左右，通过整理和分析得到如下一些数据： 需求数目：353 预估的开发量：2536人天 也就是说，如果我一个人来实现这些需求，一年做250天的话，需要做10.14年，如果365天斗来做的话，需要6.95年，目前预估的开发量还没完成，因此需要的时间只会更多。 有了这些真实的数字，很多想法就理性多了，要仔细甄别需求，确定每个需求的商业价值和估算开发量，计算每个需求的性价比。 舍弃低价的需求，选择高性价比的需求，进行详细分析和整合，逐步将这些用户需求转化为真实的产品需求，并根据人员和时间情况，最终确定下阶段要做什么？ 做产品最难的不是怎么做？而是选择做什么？而选择的核心就是需求的价值，如何衡量需求的价值？ 1、实现需求能给用户带来什么价值？ 2、实现需求能给产品带来什么价值？ 3、技术上能否实现？ 4、时间上有什么要求？ 整理需求的过程就是一个思考的过程，在纷杂的用户需求中明确产品需求就是一个扬弃的过程。 形成这个需求列表后，剩下的就需要团队的智慧了，需要大家来讨论了，希望的曙光就在前方。 来源： https://www.cnblogs.com/Duiker/archive/2009/08/11/1543722.html