需求获取属于软件需求工程里的需求开发阶段。
随着系统规模的扩大，需求分析与定义在整个系统开发过程中越来越重要，直接关系到系统的成功与否。需求分析活动不再仅限于系统开发的最初阶段，而是贯穿于系统开发的整个生命周期。于是形成了软件工程的子领域：软件需求工程。
软件需求工程是包括创建和维护软件需求文档所必需的一切活动的过程，可分为需求开发和需求管理两大工作。需求开发包括需求获取、需求分析、需求定义和需求验证4个阶段；而需求管理包括定义需求基线，处理需求变更和需求跟踪等方面的工作。这两大部分相辅相成，其中需求开发是主线，是目标；需求管理是支持，是保障。
本文主要学习需求开发中的需求获取技术。
一、需求概述
1、需求的层次
需求是多层次的，包括业务需求、用户需求和系统需求。这三个不同层次从目标到具体，从整体到局部，从概念到细节。
1）业务需求
业务需求反映企业或客户对系统的高层次目标要求。这些要求通常来自客户高层和管理人员。通过业务需求，可以确定项目的视图和范围，为后面的开发工作奠定基础。
2）用户需求
用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。
3）系统需求
系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。功能需求也称为行为需求，规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。非功能需求是指系统必须具备的属性或品质，又可细分为软件质量属性（例如可维护性，安全性，效率等等）和其他非功能需求。
2、需求的分类
【常规需求】
用户认为系统应该做到的功能或性能，实现越多用户越满意。
【期望需求】
用户想当然认为系统应当具备的功能或性能，但并没有或不能正确地描述自己想要这些功能或性能。如果期望需求没有实现，用户会不满意。
【意外需求】
也称为兴奋需求。是用户要求范围外的功能或性能，实现了用户会更高兴，但不实现也不影响购买决策。意外需求实施与否，控制在开发人员手中。开发人员可以选择实现，以便获得用户的更高忠诚度；也可以从成本角度出发，不予实现。
二、需求获取
1、用户访谈
用户访谈是最基本的一种需求获取手段，形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能事先一一计划清楚。
为了进行有效的用户访谈，需要在三个方面进行组织，分别是准备访谈、主持访谈和访谈的后续工作：
1）准备访谈
（1）确定访谈目的
（2）确定访谈中应该包括哪些用户
（3）为访谈准备一些详细的问题
问题可以分为开放式问题和封闭式问题。开放式问题鼓励用户讨论和说明细节；封闭式问题旨在获得具体的事实。
（4）作出最终访谈安排，并把这些安排通知所有参加者。具体安排应征求客户同意。每个参加者都应该知道访谈目的，可能的话，还可以预览一下访谈的问题和材料。
作为系统分析师，应该在访谈之前加强了解领域相关知识，充分阅读有关材料，以保证自己有较专业的理解和认识，让用户能够信任自己。
2）访谈过程
具体访谈时，猿一定要准时到达，可能的话，早一点到。访谈过程，要做好几项工作：
（1）限制访谈时间
时间控制在90分钟内，如果需要更多时间，应安排下一次。几次比较短的访谈，比一次马拉松式访谈效果要好得多。
（2）寻找异常和错误情况。要找机会问一些类似“如果。。。那会怎样”的问题，有意识地去确定所有特殊的情况，并与用户深入探讨。
（3）深入调查细节
（4）认真做好记录
（5）注意措辞，尊重用户；避免使用IT专业术语；保持谈话轻松气氛。
3）访谈的后续工作
访谈后首要任务是吸收、理解和记录访谈所获得的信息；对于用户回答不上来、或错过的问题，不要丢失或遗忘，准备下一次再问；谈话备忘录要送客户一份。
4）访谈的优缺点
用户访谈具有良好的灵活性，有较宽广的应用范围。但用户时间不好安排；谈话信息量大，不好记录；需要沟通技巧和足够的领域知识、丰富的应对经验等。
2、问卷调查
通过精心设计调查表，下发到相关人员手中，让他们填写答案，可以有效克服用户访谈方法中存在的问题。
一张好的问卷调查表要花费大量的时间来进行设计与制作，包括确定问题及其类型、编写问题、设计问卷调查表的格式三个重要活动。
【问卷调查的优缺点】
与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据；由于问卷调查允许匿名填写，大多数用户可能会提供真实信息；调查结果比较好整理和统计。
最大的缺点是缺乏灵活性；其次还有由于双方未见面，无法从表情等细节获取隐性信息，用户也无法即时澄清含糊或错误的回答；用户可能心理上不够重视，反馈信息不全面；调查表不利于展开回答，不利于了解细节；回答人数可能不及预期，效果打折扣。
较好的做法是用户访谈与问卷调查相结合。先问卷调查，整理分析的基础上，小范围用户访谈。
【提高问卷返还率的方法】
向所有人解释问卷的目的，以及如何使用
说明问卷所有人都要回答
拜托客户领导督促手下回答并返还
尽量参加一次企业全体会议，会上回答大家的问题，并解释这些信息的用处
更改问卷中的问题，尽量减少回答问卷所花费的时间
设置奖励措施
3、采样
采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，系统文档就是采样种群。当开始对一个系统做需求分析的时候，查看现有系统的文档是初步了解系统的最好办法。当文档数量庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。
样本大小 = 启发式因子 * （可信度系数 / 可接受的错误）^2 = 可信度系数由题目给出，可信度越高，可信度系数越大
启发式因子 默认为 0.25；但也可以变。比如，如果已知每10张订单中可能有1张存在问题，则启发式因子 = 0.1 * （1 - 0.1）。
【采样的优缺点】
加快了数据收集的过程，提高了效率，降低了开发成本；采样技术采用了数学统计原理，减少数据收集的偏差。采样技术不仅可以用于收集数据，还可以对人员进行采样。
但采样技术正因为基于统计学原理，样本规模的确定依赖于期望的可信度和已有经验知识，很大程度上取决于系统分析师的主观因素，和个人的经验和能力，对系统分析师要求较高。
4、情节串联板
情节串联板通常就是一系列图片，分析人员通过这些图片来讲故事。一般情况下啊，图片的顺序与活动事件的顺序一致，通过一系列图片来说明会发生什么。图片类型包括流程图、交互图、报表和记录结构等。简而言之，情节串联板技术就是使用工具向用户说明（或演示）系统如何适合企业的需要，并表明系统将如何运转。
【情节串联板的类型】
被动式、主动式和交互式，复杂程度依次递增。
被动式是静态图片，系统分析师充当系统的角色进行讲解和演示；
主动式可以自动播放，描述系统典型场景等；
交互式可以让用户体验系统的行为，可以是抛弃式原型等。
【情节串联板的制作】
情节串联板应该易于创建和修改，不要企图做得太好太精美。情节串联板既不是原型，也不是真实事物的演示。
【情节串联板的优缺点】
优点是直观，生动，用户友好，交互性强，对用户界面起了早期的评审作用。
缺点是花费时间很多，使需求获取的速度大大降低。
5、联合需求计划
什么是JRP?
联合需求计划（Joint Requirement Planning ,JRP）是一个通过高度组织的群体会议来分析企业内的问题，并获取需求的过程。它是联合应用开发（Joint Application Development，JAD）的一部分。
JAD以小组形式定义和建立系统，由企业主管部门经理、会议主持人、用户、协调人员、IT人员、秘书等共同组成的专题讨论组，由这个讨论组来定义并详细说明系统的需求和可选的技术方案。
JRP通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。通常参会人数6 ~ 18人，时间1 ~ 5小时。
JRP的优点：
JRP相对来说成本较高，但是一种十分有效的一种需求获取方法。
1）加快需求获取进度，降低需求获取成本，尤其对有歧义、最不清晰的领域十分有效
2）提升用户参与积极性，提高开发效率
3）采用原型确认系统需求并获取设计审批，具有原型化开发方法的优点
通过这次会议，JRP的这些优点，体会得十分真切。
JRP的原则：
JRP的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP应把握以下主要原则：
1）事先制定议题
2）严格按照约定时间进行
3）对议题逐一进行讨论
4）会议记录
5）避免术语
开发方避免使用专业术语，尽量通俗易懂，利于交流
6）（开发方）应有解决冲突的能力
极力避免与各方，尤其是甲方闹不愉快。就事论事，目的在于解决问题。
7）中场休息
本次会议是一个上午，中午结束，并无中场休息
8）鼓励取得一致意见
9）保证大家遵守会议决议
即会后应有相关跟进，对作出的决议，产生的问题等及时处理。
JRP的一般步骤：
1）让与会者互相认识，力求会议在轻松气氛中进行
2）列举问题，逐一讨论或按照议程，逐一进行
3）鼓励大家对现有系统或现状畅所欲言
4）鼓励大家对新系统畅想，形成清单
5）对清单进行整理，明确优先级，评审，最后形成结论或结议。
当然今天的联合需求计划会议并没有完全按照这样的步骤，但精神是一致的，那就是厘清需求，解决问题，形成结论，为下一步工作做好铺垫。精神贯彻就行，具体做法可以加以裁剪。
三、需求记录技术
由于需求获取人员和需求分析人员可能不是同一个人，或者一个项目有多个系统分析师参与需求获取，因此需要统一需求记录工具，以便统一口径。
常用的需求记录工具有任务卡片、场景说明、用户故事和Volere白卡等。
1、任务卡片
在各种需求记录工具中，任务卡片是一种比较简单的工具，特别适合对业务活动级的信息收集与整理。
增强版任务卡片在基本任务卡片的基础上，增加了问题点描述和解决方案提示。
2、场景说明
场景说明是用户对其工作场景和过程的详细描述。这些描述将在编写测试用例和用户培训手册中再次用到。
3、用户故事
用户故事描述了对用户有价值的功能，包括三个方面的内容：书面描述（用于计划和备忘）、交谈（细化故事）和测试用例（验证故事实现）。
4、Volere白卡
Volere白卡是一种类似于任务卡片的需求记录工具。