1、需求调研方法论文件版本： 文件编号：编制人： 编制日期：审核人： 审核日期：批准人： 批准日期：修改记录版本号 修订人 修订日期 修订描述目 录1 需求概述 .41.1 软件需求 .41.1.1 需求定义 .41.1.2 需求层次 .41.1.3 需求来源 .41.2 需求调研定义 .51.3 需求调研目的 .61.4 需求调研必要性 .61.5 需求调研是否可裁剪 .101.6 需求调研启动时机 .102 需求调研过程 .112.1 调研实施前活动 .112.1.1 识别调研范围 .112.1.2 组建调研团队 .112.1.3 确定调研方案 .122.1.4 调研准备 .162.1.5 前
2、期沟通 .182.2 调研实施 .182.2.1 调研实施 .182.2.2 调研注意事项 .223 编写用户需求规格说明书 .231 需求概述1.1 软件需求1.1.1 需求定义需求是用户一种期望，是用户期望改善现状，解决某些问题或达到某种目标的需要。需求实现的过程，就是通过软件产品的功能达成用户目标，使之与用户期望目标相符的过程。1.1.2 需求层次软件需求的三个层次 1业务需求：反映了组织机构或用户对系统、产品高层次的目标要求。 2用户需求：描述了用户使用产品必须要完成的任务。 3功能需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。 4非功能性的需求：
3、不直接完成用户完成某项工作，但是在用户在操作系统过程中伴随产生的需要，描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。1.1.3 需求来源软件需求可以来自方方面面，这取决于所开发产品的性质和开发环境。下面是几个软件需求的典型来源。1. 访谈、调查用户或潜在用户 为找出新软件产品的用户需求，最直截了当的方法是询问他们。通过直接与最终用户的访谈或调查，了解用户目前管理或应用过程中存在的问题、思想或想法、业务未来发展趋势，经过整理分析，形成软件需求。2. 研究竞争对手同类产品 当用户在实际工作中产生出新的需求后，总会有对需求感觉灵敏的
4、厂商嗅到商机，把用户的需求转换为产品。在我们没有更好条件深入到客户中进行调研的情况下，可以对竞争对手同类产品进行研究，发掘产品中的优点和存在不足，研究产品功能的目的和意义，倒推出软件需求。3.需求分析人员的经验 需求分析人员要时刻保持对所在领域知识的敏感，勤于思考，结合积累的丰富的所在领域知识，加上自己的分析和判断，形成基于用户实际工作中需求的假设，形成软件需求。 4.市场支持活动 软件产品发布推广后，用户在实际工作中对软件产品进行检验。在市场售后的支持人员在对用户进行培训和提供技术支持工作的同时，他们收集了用户在使用系统过程中所遇到的问题，还接受了用户关于系统改进的想法。因此，可以通过收集市
5、场支持人员接受的系统改进想法，并把它们转换为软件需求。 5. 政策制度和法律法规 公司所在的国家、行业的政策制度和法律法规是企业经营活动过程中必须遵循的规则，对公司活动有强制约束力。研究目标企业所在国家、行业的政策、法规和制度，发现其中信息化相关的要求，经过整理和分析形成软件需求。尤其是当企业所使用的法律法规、政策制度发生变动时，是软件产品更新换代的一个重大契机。1.2需求调研定义通常情况下，用户无法独立直接提出完整、准确的需求，这就需要通过项目组的介入，借助需求调研把用户已经表述的需求弄清楚，挖掘用户尚未说明的需求。 需求调研指通过和用户进行沟通和交流而获取用户的需求的一系列活动，是为编写需
6、求说明书而做的前期工作。 换言之，需求调研就是假设用户已经掌握需求，通过某些手段或方法将需求准确、完整的描述出来，以便软件开发的后续活动顺利进行。1.3需求调研目的需求调研就是了解参与实际工作的人们真正需要什么样程序的过程，获取准确、清晰、完整的用户需求信息，编写需求说明书，为后续工作提供依据。 需求调研有三个主要目的：1、获取准确、清晰、完整的需求，包括功能需求和非功能需求； 2、确定需求的分级，划分需求优先级，指导后续工作； 3、收集调研对象业务资料，预测需求的发展趋势，为软件产品发展方向提供依据。1.4需求调研必要性1、需求调研是减小用户“期望差异”的关键一步 软件产品作为一种特殊的商品
7、，是软件公司通过有限的技术手段、资源为了满足用户的需要而开发出来的。由于需求“效用”的不可计量，再加上软件产品不能直接创造价值的特殊性，用户就有可能会对最终产品产生“期望差异” ，这种“期望差异”会影响用户对软件产品的满意度，影响软件产品的销售。需求调研就是要了解到用户的期望，以期在软件研发过程中减小这种差异，提高用户的满意度。软件需求也可以说是用户在一定的条件下为了改善管理条件、追逐更大利润的“欲望” 。当欲望得到满足，人们会感到快乐和幸福，这就是“效用” 。处于软件产品两端的用户和开发商由于受到客观条件的限制，双发不能传递准确的需求信息，在一开始无法在信息系统的需求上达成一致意见。由于技术
8、能力的局限，用户很难准确地把系统需求传达给开发商；由于业务局限，开发商也很难准确获取用户真实的应用需求。需求信息的不对称和需求描述的错位，容易引起系统设计的缺陷，最终导致系统应用不理想甚至系统失败。作为客观世界的存在，用户所处环境、思想等的不同，不同用户对同一领域的需求是存在差异的。软件产品是在有限的资源、有限的时间、有限的技术手段和条件下研发出来的，不可能获取所有潜在用户的需求，也不可能满足所有潜在用户的需要，这就需要软件产品确立目标用户，重点关注目标用户的需求。能够获取目标用户的满意，赢得目标用户的认同，促进目标市场的销售，就是一款成功的产品。作为一家商业的软件公司，其追求的目标是利益最大
9、化，利益的重要来源就是向市场推出更多令人满意的软件产品，获得市场的成功。如何令用户对我们推出的产品满意，是作为软件研发、销售人员时刻警惕和思考的主题。在我看来，让用户满意就是在用户看到、使用我们软件的时候满足其“期望”甚至超出他的“期望” ，这就会引起用户的购买欲，从而带来销售机会。而获取、了解用户的期望值，是软件产品能够满足用户期望的先决条件，只有了解了用户的期望，通过产品研发最大限度的实现用户期望，提升用户的满足感， 研发出的软件产品才能更好贴近用户的期望，提升用户期望的满足度。结论： 1） 软件产品一定要有目标客户，目标客户的需求才是需要重点关注的； 2） 需求调研很重要，是软件产品能够
10、赢得市场的先决条件，是任何软件公司、软件研发人员必须重视的一个环节。 3） 需求调研和分析是信息化建设的第一步，牵一发而动全身，做好需求调研是软件产品成功的关键一步。2、需求变动大，可能是因为需求不完整、不清晰。 参与过软件研发的很多人都有这样的抱怨“用户需求又变了，截至今天已经变了 3 次，很多工作得重新返工，真不知道下次还会不会变了。 ”，尽管无奈，又不得不对改变的需求重新评估、设计、开发、测试，这些变更不只是加大了软件研发的成本，对研发人员的积极性也是一种挫伤，降低了研发人员的成就感。 尽管需求发生变化时，对软件研发影响很大，但往往需求变更又是不可控的，需求变化是客观存在的， 是作为软件
11、研发人员必须正视和面对的问题随着目标用户的变化，目标用户认知的提高、用户内部环境的变化、外部境的变化、技术的进步等，需求也总是在不断改变的，往往是在前期需求得到满足后，会产生出更高层次的需求。 诚然，为保证软件研发的顺利进行，保证软件产品的按时交付，我们要对需求加强管理，控制需求变更，但是面对变更，我们更应该考虑如何减少变更发生的机会，让我们更多掌握研发的主动权。更何况控制需求变更，不可避免的要牺牲用户的满意度，在软件产品还没有交付到用户手中时，已经产生了“期望差异” ，势必对产品的销售造成影响。 换个角度看这个问题，用户的需求总是发生变化，很有可能是我们原本就没有完全获取用户的需求，或者没有
12、挖掘出用户隐含的需求，研发所依据的需求是不完整、不清晰的。通过需求调研，是获取完整、清晰用户需求的很好途径，有了完整、清晰需求作为研发依据，可以很好降低需求发生变化的几率。结论： 1） 需求变化是客观存在的，作为软件研发人员必须保持良好心态处理好需求变更； 2） 需求在一定的时间范围、一定的环境下（经济环境、组织结构、发展期间、IT 应用水平） 、一定的用户群体范围内是确定的，或者说是相对确定的。 3） 加强需求管理，进行需求调研，尽快、尽早获取完整、清晰需求是比控制需求变更更好的办法；3、错误越早修复成本越低 需求阶段是软件研发中的一个重要阶段，其成果是研发后续各阶段工作的重要依据，对研发有
13、着重大影响，需求质量的高低往往决定着一个项目的成败。做好需求调研是获取完整、准确、清晰需求的前提，准确的需求是项目成功的关键。 据权威机构对软件各阶段发现错误修复成本的统计，如下图：从上图可以看出，在软件研发过程中，越到后面阶段修复错误的成本越高，而且往往是需求阶段成本的成百上千倍。进行需求调研，可以尽早使不清晰的需求更加明确，可以对不准确的需求进行修订，补充完善需求，尽早发现错误，尽快修复，减少研发过程中后续阶段的潜在错误数，缩短研发周期，降低研发成本。 结论： 需求调研可以有效减少研发过程中潜在的需求错误数量，降低研发成本。1.5需求调研是否可裁剪在实际的研发过程中，由于外部环境或内部环境
14、的压力，软件研发往往面临着时间紧、任务重的局面，为了能够保证按时交付软件产品，项目管理者往往会选择裁剪或压缩需求调研，而给软件编码和测试预留充足时间，结果往往是项目结束时按期交付了产品，质量如何就不好说了。 在我看来，这样的过程是很危险的，很可能是花费了大量的时间成本和人力成本，得到一个并不被市场认可的产品，公司浪费了人力财力，参与其中的研发人员也不能从中获取成就感。即使软件研发团队面临着工作量大、人员不足、时间紧张的局面，研发团队也不能在不了解需求的情况下直接编码，凭自我感觉做事。 需求不清晰、不完整、不稳定是项目最大的风险，可能导致项目的返工，导致项目延期，最终导致项目的终止。一个有生命力的软件产品，必然要以真实用户的需求为依据，严谨的研发过程为保证，从用户中来，回到用户中去。 需求调研的过程是否可以裁减，我认为是可以的，只要需求是清晰、完整、准确的，并且研发团队与用户对需求的认知是一致的，在这样的条件下，需求调研过程是可以裁减的，但是建议项目团队出具需求文档，便于项目的传承交接。在其他情况下，需求调研过程应该都是不可以裁减的，但可以根据条件选择适合的调研方式。
