下载掌阅APP，畅读海量书库
立即打开
需求获取也称需求捕获，是需求开发中的第一个活动。需求捕获的过程是人与人打交道的过程，其成功与否与需求分析人员的沟通能力关系极大。需求获取的目标是主动与干系人（Stakeholder，对项目有话语权和决策影响的人）协同工作，找出他们的需求，识别潜在的冲突，磋商解决矛盾，定义系统范围与边界。其实质是了解待解决的问题及其所属领域，关键是确保该问题的解决是有商业价值的。
如图3.3所示，需求的来源可以是主题世界、应用世界、开发世界和系统世界。其中，主题世界是系统关注的主题内容；应用世界是系统未来的操作环境，关注人和企业的流程；系统世界是操作环境下的所有内部操作；开发世界关注软件系统的开发过程、项目团队、人员、进度、安全、性能等质量要求。有了四世界模型，我们可以很好地对问题的本质以及关注的对象进行分别处理。
图3.3 需求获取的四世界模型
确定客户需要什么是一件非常困难的事情，因为客户可能没有意识到自己的公司在做什么以及真正需要的是什么。比如某公司要开发一个速度更快的软件产品，但没意识到自己当前的数据库设计很差，当务之急是重新组织和加强数据存储；又如另一个公司要开发一个商用管理信息系统，但其不赚钱的根本原因是盗窃和内盗，真正需要的是首先构建一个库存控制系统。Steve McConnell说过：“需求获取过程中，最困难的不是记录用户需求，而是与用户探讨磋商，发现真正要解决的问题，确定适用的方案。”
询问在需求获取时通常不太起作用。没有专业的软件开发小组的协助，客户很难了解需要开发什么的相关信息；除非需求获取人员与客户进行面对面的交流，否则很难弄清楚客户真正需要什么。
获取需求的一般流程是：首先需要理解应用域，即目标产品应用的特定环境，可以是银行、空间探索、汽车制造或遥感勘测，需要综合技术文档、现有应用、客户调研、专家意见、当前/未来需求等各方面信息；其次是构建业务模型，用来确定客户的初始需求，通过需求启发等方法来发现客户（潜在）的需求；再次是应用迭代法不断分析、推敲和扩充需求，直到开发小组对需求真正满意为止。
需求获取的策略多种多样，需求分析人员需要加以灵活运用，主要有以下几种：
●主动：发挥主动性、把握主动权。
●聚焦：针对问题步步深入，一次集中一个问题。
●破解需求的冰上模型：尝试理解业务场景、善于利用技术为用户创造全新体验。
●破解阻碍：客户可能有言过其实、非正事、抗拒、推卸责任等不同程度的阻碍。
●不忽视变更可能：事实上，需求一直处于变动中。
●需求协商：探讨解决方案后面的问题，共赢性谈判。
需求获取的方法也有很多，包括：用户访谈，涉及技术团队中的高层、中层、操作层等；用户调查，通常使用问卷方式，一般先访谈后调查，更加有的放矢；文档研究，针对对方提供的带有真实数据的样本；情节串联板，也称原型法，考虑具体的使用场景、用户交互情况等；现场观摩，实地考察，体会细节和难点；联合开发，能够突破盲点，通常采用直接头脑风暴等方式。下面列举几种常见做法。
1.焦点小组
焦点小组（Focus Group）即找到一群目标用户的代表以及项目的利益相关者，讨论用户想要什么、用户对软件的评价等。
该方法可能会有以下缺点：因为一群人在一起，大家会出于讨好其他人的心理来发表意见，尽量避免不一致的意见或冲突，这反而不利于获取真实的需求；参与讨论的人在表达能力上也会有差异，有可能会出现一些善于表达的人控制讨论议程的倾向；讨论者对于他们不熟悉的事物（例如全新的市场、颠覆式的创新）不能表达有价值的想法；讨论者还容易受到主持人有意或无意的影响，主持人可能会从不同意见中挑选最符合自己利益的那些条目，然后对外号称是大家的共识。
这些特点要求会议的组织者要有很强的组织能力，能让不同角色都充分表达自己的意见，并如实地总结这些意见。这种形式也叫作推进会议（Facilitated Meeting）。
2.用户问卷调查
用户问卷调查（Survey）是目前常用的用户需求获取方式，需要预先定义问题，面对广泛受众的时候使用，即具备大基数的被访者，并在需要得到关于良好定义的特定问题答案时、需要验证有限次面谈得出的结论时或需要一个特定的结果时使用，通过统计分析得到的结果看起来更加科学。
问卷调查的优点是可以快速获得大量反馈，可以远程在线执行，可以搜集关于态度、信念及特性的信息，但也有一些缺点，比如简单的分类会导致对上下文的考虑较少，留给用户自由表达其需求的空间较小等。问卷调查的注意事项有：选择样本时可能会存在偏见、自愿的问卷回答者可能存在偏见；样本规模太小；自由发挥的问题难于分析；对答案有诱导性的提问；问题的妥当性；含糊的问题等。另外要注意，问卷调查也需要原型化和测试。
因而用户问卷的设计至关重要，用户问卷中常见的毛病有：定义不明确，使用含糊的形容词，让人难以琢磨；让用户花费额外的努力来回答问题，这可能导致用户半途而废；带有引导性的问题，使结果有所偏颇；过于开放式的问题，用户常常无从下手；选择过于狭窄的问题，可能导致以偏概全的结果。
3.人类学调查
人类学调查（Ethnographic Study）需要需求获取人员感同身受，通过“同吃同住同劳动”的方式，放下自己的观点，用心观察并如实记录。
4.深入面谈
深入面谈（In-depth Interview）可以深入了解用户，开展用户体验研究，即实地参观用户使用新版本的软件，让用户完成一些任务。如果选择的面谈对象比较合适，那该方法的效果应该还可以，但实际上面谈对象可能没有讲实话。
另外，还有卡片分类（Card Sorting，收集自由表达的、不同角度的需求和抱怨，通过讨论来明晰定义，再归类并排优先级）、快速原型调研（Quick Prototype Studies）、日志调研（Diary Studies，对记录的日志信息进行分析、处理和挖掘）、A/B测试（在真实的环境中实验新的功能，同时跟踪数据，考察不同设计的效果）等其他需求获取方法。其中原型、仿真是用户偏爱的方式之一，其目标是明确含糊、不确定的需求，简化需求文档并确认需求，尽早获得最终用户和客户的反馈，其指导方针是用于需求确认、提供需求评估的数据基础，尤其适合评估不同的用户界面方案，帮助用户可视化关键的功能，是直观、有效的沟通工具。
需求的获取是否都按照用户的要求来？答案是既要听其言，又要观其行。
很多时候，用户并不知道自己确切的需求或者不愿意表达完整的需求，需要软件团队设身处地替用户着想，引导出用户的需求，此即需求捕捉。
有些需求在实现之前，用户并没有明确表达过（例如没有用户说“我希望有一个偷菜的软件，我可以偷别人家的菜”），但是成功的团队还是可以从“用户需要和朋友之间玩游戏，用户有证明自己能力的需求”这些角度出发，挖掘出需求。另外，软件团队也需要分析技术的发展趋势及产业的变化、社会发展的大趋势，以此推测用户会产生哪些新的需求。例如，看到全球定位系统（GPS）技术的成熟、地理信息系统的发展、私家车的普及和智能手机性能的不断提高，可以推测出“利用手机给汽车导航”将是一个普遍的需求。
还可以进一步获取和引导需求，需求既可以来自管理机构，又可以来自企业内部。比如有些需求来自监管部门，一些互联网服务需要对不同年龄用户的内容加以管理——屏蔽敏感词、快速删除网上内容等。又如，软件企业=软件+商业模式，即企业所采用的商业模式会对软件提出需求，一个免费的互联网服务到达一定规模后，企业就会考虑如何让这个服务带来收入。例如，一个免费的互联网电子邮件服务会考虑对用户收费，支持几种不同等级的用户、在邮件中附带广告或者在页面显示广告等。这些需求并非来自用户，因为事实上绝大部分用户都反感这样的需求，但是企业需要一个能维持生存和发展的商业模式，尽管这种模式下的种种需求未必都是对用户有利的。
需求还可以来自技术团队本身，包括代码的迁移、架构的演化、平台的变化或者引入新的技术、编程语言等。例如，为了提高开发效率，一个手机软件团队决定引入跨平台的语言和框架；或者需要支持新的HTTPS协议；原来后台的数据服务使用了专用的数据库和专门的小型机，现在改为基于开源技术的软件和硬件；软件前端代码需要支持某种自动测试工具，以便更有效地进行自动测试等。除此以外，还需要更好地了解用户的行为和需求。例如，我们要在软件的各个功能点加上收集信息的代码，并在后台实现数据收集、整理、报告和数据挖掘（Data Mining）工作，此类技术在一些公司叫作遥测技术。
我们还可以进一步对需求进行分类，如对产品功能的需求、对产品开发过程的需求、服务质量需求和综合需求，具体说明如下。
●对产品功能的需求：要求产品必须实现某些功能。例如，学校的选课软件只允许有学生身份的用户浏览并选择课程，同时要求学生选择某一门课时必须满足“选修课”的要求等。
●对产品开发过程的需求：要求软件的开发流程必须满足某些约束条件。例如，开发过程必须产生某种类型的文档，必须在某个时间点达到某个状态，必须对源代码施以某种约束（安全性核查、代码版权核查、代码规范和支持文档的核查）。
●非功能性需求：也叫服务质量需求（Quality of Service Requirement）。例如，股票交易系统必须在一定时间内返回用户查询结果（对时间的要求比科技文献检索网站要高），火车票购票系统、大学选课软件必须能支持一定数量的用户同时访问等。
●综合需求：有些需求并不是单单一个软件模块就能满足的。例如，“购物网站必须在24小时内把货物发送到用户手中”，这个需求涉及软件系统、货物派送系统、送货部门、监控系统等不同部门的功能和执行能力。
所有利益相关者（干系人）都有需求，请体会他们不同的需求：最终用户、顾客（决定购买的客户）、市场分析者、监管机构、软件工程师。
其中，用户也会有多种。很多人假设评价软件的人就是购买软件的人或使用软件的人，但实际上未必如此。比如你要开发一个中学生学习英语的软件，你找谁去做用户调研？是作为最终用户的中学生还是家长（家长是要掏钱的人，他们不会每天都使用该软件，有些人也不太会英语）？还是学校老师（他们是有巨大影响力的人，可能已经规定使用某款软件）？再如，要开发一个企业管理软件，你要找谁去做用户调研？
以上各种需求获取方法有不同的适用场景，比如在设计界面时，原型、情景与建模的需求获取方法比较合适；而在考虑业务逻辑时，参与观察、亲身实践、面谈和情景法比较有效；在获取信息时，面谈法和现有系统分析更为适用。
总之，在需求获取中，建立完整精确的模型很难，建立完整的原型也不现实，以上需求获取方法，要根据需要和客观条件灵活加以运用。
在了解需求获取的若干方法后，我们介绍一个NABCD模型，该模型也称为竞争性需求分析框架，说明应该按照什么步骤做出真正有用的软件产品。
N 是指需求（ N eed），即现在市场上未被满足但又急需满足的用户需求是什么、你的创意解决了用户的哪些需求，用户对已有软件或服务有不满意的地方，但是用户往往也不知道如何进行颠覆性的创新。
A 是指方法（ A pproach），即要满足这种需求，你的独特做法是什么、有什么招数特别是独特的招数可以用来解决用户的痛点。例如在技术上，不能只是说“我会C++，所以我一定可以写好这个软件”，要有独特的办法，例如具有人脸识别技术、会做超大规模的数据处理等，另外，方法也可以是在商业模式上的（第一个做众包的服务）、地域的（对本市的公交线路很熟）、人脉的（认识很多大学生）、行业的（有地图测绘行业的资质）或者是成本上的（能找到更便宜的资源来维护网站）独特优势。
B 是指好处（ B enefit），即该方法给顾客提供的便利是什么，要考虑产品/功能给最终用户、客户、公司带来什么好处，要花费多少时间、金钱才能得到这些好处。
C 是指竞争（ C ompetitors），即要调研目前行业中有多少竞争者，他们的优势/劣势是什么，我们有什么先发优势/后发优势，对于竞争对手和其他可选择的方案，这种单位成本收益的优势在哪里。知己知彼，才能百战百胜。
D 是指交付（ D elivery），即产品研究完成后的交付与推广方案，考虑如何把产品交到用户手中。假如你有一个比现有产品更好的产品，怎么交到千百个用户手中？例如你开发了一个手机的应用，如何把产品交到千万个用户手中？可以把它提交到应用商店。但在中国有多少个手机应用商店？应用提交之后，在相应的产品类别中会名列第几？有多少人会看到？因此，为了让新用户知道我们的产品，可以做广告、做公关活动、鼓励有影响力的用户或市场认识这个产品、做出高质量的功能让用户口口相传。我们也可以设计产品功能，让更多的非用户自然地成为用户。一种方式是让产品把用户拉进来，把用户生活中的好友拉到产品中（例如把用户拉到微信群中讨论）；另一种方式是在交流中自然地宣传产品（例如免费邮件产品在邮件正文后面加上一句宣传的话）。了解产品怎样能有效地在用户中推广，能让我们把相关的功能设计做好。
下面给出分别针对新产品和改进产品的电梯演说模板，大家可以体会NABCD模型的实际作用。
●电梯演说模板——新产品
我们的＜新产品＞是为了解决＜目标用户＞的痛苦，他们需要＜ N eed＞，但是现有的方案并没有很好地解决这些需求，我们有独特的办法＜ A pproach＞，它能给用户带来好处＜ B enefit＞，远远超过竞争对手＜ C ompetitor＞。同时，我们有高效率的＜ D elivery＞方法，能很快地让大部分用户知道我们的产品，并进一步传播。
●电梯演说模板——改进产品
我们的＜功能改进＞是为了解决＜目标用户＞的痛苦，他们需要＜ N eed＞，但是现有的方案并没有很好地解决这些需求，我们有独特的办法＜ A pproach＞，它能给用户带来好处＜ B enefit＞，远远超过竞争对手＜ C ompetitor＞，包括我们以前的版本。我们有数据＜ Data ＞（用户调查）支持这个结论。我们相信新的改进能给我们带来＜ D ata＞的业绩改善（用户量、使用时间、评价、收入）。
另外，竞争环境中有三个不同的选择策略：差异化、同质化、优化。在核心价值、关键点和挑战这三个方面的具体比较情况如表3.1所示。如果你有新的产品想法，请选择合适的策略。特别是在资源有限的情况下，你要考虑减少/停止哪些项目才能支持新的项目。
表3.1 竞争环境中的三种选择策略
影响项目成功与否的因素有很多，下面大致列举几个。大家可以边实践边思考。
一是产品的因素，包括：希望产品达到什么样的可靠性标准，能接受平均每天重启一次还是需要一年99%的时间内都能运行；产品的数据量有多大，比如图书馆管理系统中有多少本书，每天有多少事务发生；产品的复杂程度，是做一个单页面展现信息的网站，还是一个需要实时处理交易的网站；对模块重用的要求，是所有模块都可以重新写还是必须要重用原来系统的某些老的模块；文档的需求，是需要完备的文档还是“有什么事就问我”；如果是涉及硬件、供应链、软件、社区、运营的复杂产品，应该如何管理各种依赖关系。
二是平台的因素，包括：执行时间的约束，所开发的是否是一个实时系统；存储的约束，数据如何保存；恢复的策略是怎样的；平台变动的约束，编程语言和工具每半年是否会发生大的变化。
三是人员的因素，包括：分析师和程序员的能力；做此类应用的经验，即其使用开发平台、编程语言和工具的经验；人员流动性，如项目做到一半有人突然离职。