下载掌阅APP，畅读海量书库
立即打开
苏格拉底早在2400年前就提倡并描述了对事务的认知和推理，直到今天，哲学家、科学家和心理学家都还在继续研究证据和推理，这是科学实践的基础。研究认识论的人有科学家、教育家、哲学家，当然还有精英级的软件测试员。学习认识论的学生研究科学、哲学和心理学，目标是了解怎样才能改进我们的思维，以便能够更多地利用批评性思维的最新成果，将认识论运用于软件测试。实际上我们对软件需求审核（review）的过程，也就是一个对软件需求推理和认知的过程。
2.1 PRD分类
小白 PRD对于测试工程师来说一定是非常重要的吧。
大鸟 没错，PRD来自于需求分析阶段的开始，是测试执行的源头，是测试生命的源泉，只有源泉干净清晰，才能保证身体的健康。同样，只有PRD业务描述清晰、完整、正确才能保证整个测试流程的“生命”，否则整个流程都会紊乱。所以在PRD出来后做审核工作是非常有必要的，每个测试人员都应该负责地去审核需求人员编写的每1个字、每1张图，哪怕是每1个标点。但是这种审核不是做文字查错，更多的应该是去关注业务、流程、逻辑和查漏补缺。
小白 我最早还以为PRD仅是PM和市场人员的事呢？
大鸟 的确，现在很多公司或者组织在需求分析和架构阶段，仅有PM和架构师参与，而 DEV（研发工程师）和 QA 在一开始并不被“卷入”。这样操作将会导致两方面的负面结果，一是很容易导致DEV和QA因为不清楚或者误解原始需求和设计背景，而在实现的过程中出现或大或小的功能或者性能的偏差；二是上游的设计没有完全挖掘出一些隐性的风险和漏洞（具体实现层面的细节），而这些隐性的不可实现便会导致研发的不可进行或者延迟交付。因此项目架构应该由架构师牵头，整个开发团队各抒己见，共同完成。
小白 我知道了，那么，PRD包括哪些方面的内容呢？
大鸟 PRD主要包括软件产品定位、软件产品需求以及范围约束这3大项。每一个大项，又分为若干小项，如下表所示。
2.2 软件产品定位
小白 产品背景及定位是指什么呢？
大鸟 产品背景及定位描述了软件需求规格说明中所定义的产品的背景和起源。说明了该产品是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个新型的、自主型产品。如果PRD定义了大系统的一个组成部分，那么就要说明这部分软件是怎样与整个系统相关联的，并且要定义出两者之间的接口。
背景分析包括市场状况及该产品的用途、未来增长趋势、市场的竞争能力、需求规模、发展前景。比如说，要开发一款基于HPC（High Performance Compute高性能计算）的系统管理软件，就要先讲一下HPC行业背景分析。
案例 HPC2.0产品背景/定位
HPC2.0是在HPC1.0基础上的改进版本。
传统的HPC应用程序通常内置了MPI（并行计算），它的常见市场用途包括：现代地质、建筑结构、计算流体力学、天气建模、其他科学模型仿真。
此外，潜在的市场用途还包括在同一个应用程序中同时运行大量的独立作业，例如电子模拟、蒙特卡罗模拟、基因组测序和业务分析，以及基于使用Hadoop基础设施的大数据分析，如内存分析等。
最后，HPC 应用程序还包括业务分析及企业级应用。如利用多个服务器应用程序以增加容量和吞吐量，进一步提高了集群性能和可靠性。
小白 讲完了产品背景及定位，下面就该讲目标潜在客户群了。所谓的目标客户，就是我们打算把产品卖给谁是吧？
大鸟 对的，所谓目标客户，是指企业的产品或者服务的所针对对象，是产品能满足需求的客户群。一般来说，目标客户具备以下几个特征。
（1） 购买能力 ：具备一定数量及支付能力，特别是具备发展的潜力。
（2） 购买需求 ：对你所销售的产品的某一个或多个功能有迫切需求，而这一需求是目前市场上其他种类产品所不能完美提供的。
小白 目标客户是潜在客户吗？
大鸟 目标客户包括潜在客户和价值客户。用户产生购买行为后，就从潜在客户变成了价值客户。然后，我们要做的是继续深挖用户的需求，保持产品的先进性，从而使价值客户成为忠实客户。
案例 HPC产品目标潜在客户群
HPC管理软件针对的一些客户类型如下：
（1）使用集群软件管理商业领域向外扩展应用程序的客户，集群是由系统管理员作为单一操作系统进行统一管理的。
例如，波音公司、埃克森美孚公司、英国网络公司等。
（2）需要工具来部署和管理集群操作系统和软件堆栈应用开发的客户。
例如，富士通公司等。
（3）进行超级计算和研究并寻找可扩展的集群管理解决方案的客户。
例如，红牛公司、德意志银行等。
（4）组织并利用超级计算机的能力租赁给内部或外部客户的客户。
例如，日本北海道超级计算中心等。
小白 下面是关于用户问题的内容。我有一个问题，为什么不直接获得用户需求，而是还要费力搞清楚用户问题、用户的麻烦是什么？
大鸟 用户遇到的麻烦、痛点、顾虑到底是什么？面临的问题是什么？这是我们获取用户需求的基础。如果不知道为什么（Why）就直接问用户要什么（What），那么有可能把事情做偏。下面的例子是高性能计算领域用户常见的问题。
案例 组织部署和管理基础设施时经常面临的问题
● 昂贵的IT成本（包括硬件管理、不同操作系统的配置、不相容的预警系统等）；
● 故障排除时间太久；
● 终端用户使用效率太低；
● 从采购到生产环节成本高，部署时间长；
● 没有简单的方法可以快速部署和有效地管理多个集群；
● 技术的可扩展性限制：现有的企业管理解决方案无法向外扩展；
企业云解决方案如 VMware、OpenStack 等目前不支持物理服务器环境中的高性能计算应用程序。
小白 是啊，的确如此。那怎样才是一个好的问题定义呢？
大鸟 “问题定义”只定义了“问题是什么”，而不涉及任何可能的解决方案。它是一个很简单的陈述，并且听起来应该像一个问题。像“机器宕机了，以至于客户不能运行相关的Job了”这样的句子是一个很好的问题定义，而“我们需要HA系统，使得在机器宕机的情况下还能运行用户的 Job”这种句子就是糟糕的问题定义，因为它听起来不像是问题，倒像是解决方案。
小白 只搜集问题而先不做猜想？
大鸟 对，先不做猜想。福尔摩斯说过：猜想是很不好的习惯，它有害于做逻辑推理。没有掌握全部问题之前，先做出假设来，这是很大的错误，那样就会使判断产生误差。
小白 如何获得问题的来源？
大鸟 问题的来源是指要考虑“这是谁的问题？”，其目的可能是：
（1）确定谁是顾客，就是说，谁必须被取悦？
（2）搜集一些有用的线索，以找到合适的解决方案。
小白 举个例子，就说刚才“机器宕机了”这个问题。我们怎么来寻找是谁的问题？
大鸟 如果“机器宕机了”这个问题只是来自于一个小型 PC 机用户，那么从影响面上考虑，问题不那么大。我们可以采取如下解决方案。
（1）远程电话协助。
（2）派专业人员上门服务，探查是否存在任何软件问题（如病毒、木马系统崩溃等）或者硬件问题。
（3）让用户自己过来报修。
小白 毕竟是小型客户，影响范围小，优先级和严重性也就小。
大鸟 但是大型用户就不一样了。2013年7 月，有大量用户反映微信发生全面故障，故障包括微信信息无法发出、无法刷新朋友圈、无法登录公众账号平台、无法连接微信网页版、页面显示为“服务器暂时不可用”。这可就是一个非常严重的问题了。
小白 对，当问题来自于大型客户，解决方案就迥然不同了。
大鸟 如果我们把工商银行或者腾讯公司当作我们服务器的顾客，我们可能会得到一个迥然不同的列表，比如说：
（1）服务器是否需要事务级的管理。
（2）是否要求电源备机控制系统。
（3）是否需要高易用性的远程分布服务系统。
（4）技术支持人员是否需要常驻现场。
这两个客户列表，尽管不一定完全排斥，但是我们确实能够看出一些倾向上的差别。为了避免因为这些倾向而做出草率的决定，我们要在提出解决方案之前仔细考虑，并把问题想得尽量全面些：考虑一类问题而不仅是一个问题。
小白 怎么去寻找一个问题的解决方案？
大鸟 四句话：把自己当成别人；把别人当成自己；把别人当成别人；把自己当成自己。
（1）在动手去解决问题之前，好好想想问题的来源。
（2）站在各个角度来看待面临的问题，以便能够了解其真正所在。
（3）不要把解决方法误认为是问题的定义，哪怕是你自己常用的解决方法。
小白 产品的特点和特性是指什么呢？
大鸟 简单点说，就是阐述将要开发的这款软件的特性和有必要去开发的理由：创新点是哪些？优越性是哪些？有没有什么独特的价值？研发出来后对相关领域有多大影响？再和市场已经存在的那些软件做个对比，自己产品的优点、改进点是哪些？
小白 是啊，如果没有的话，公司为什么要投资进行研发呢。
大鸟 下面以ETT公司开发的HPC（高性能计算）系列软件产品做为一个例子。
案例 ETT公司的HPC产品特性
ETT公司的HPC软件是一个商业产品，用于管理大规模硬件和软件。此外，它还是一个可以管理多集群和多租户的计算基础架构的软件产品。
ETT公司HPC软件相对市场其他产品的 独特价值 是：
（1）综合管理和监控硬件组件、操作系统和中间件。
（2）支持多个操作系统和软件配置。
（3）支持多集群、多租户管理。
（4）高可扩展性——最多可以扩展到50000个节点。
（5）能够提供各种规模的集群环境，如高性能计算、Hadoop和OpenStack的等。
（6）ETT的HPC软件不仅能在有OEM（Original Equipment Manufacturer，贴牌代工厂商）合作伙伴的硬件（如 Dell、HP 等）上运行，而且支持在非 OEM 合作伙伴的硬件上运行。
小白 产品的结构图指什么呢？
大鸟 产品的结构图指产品的架构和组成方式。这里，以HPC产品为例简单解释一下。
（1）在这个图中，最下层是Scope（范围）支持，是指这个产品在哪个硬件范围、操作系统范围以及浏览器范围获得支持。
（2）上面一层是产品的架构、内核、数据库。
（3）再上面一层是HPC产品的基本功能（安装、部署、管理、监控、扩展性、高易用性）和高级功能（多集群、服务管理、策略管理）。
（4）最上面一层是应用层，指应用上支持哪些服务（大数据、GPFS等）。
2.3 软件产品需求
小白 软件产品的需求包括什么呢？
大鸟 包括如下几个方面。
（1）功能性需求。
（2）非功能性需求。
（3）文档需求。
（4）项目需求优先级定义。
小白 功能性需求是指什么？
大鸟 功能性需求包括如下几个方面。
（1）特性需求。
（2）安全性需求。
（3）互操作性需求。
特性需求是根据系统特性即产品所提供的主要服务来提交给用户使用的软件功能，使用户可以通过使用产品所提供的特性来执行任务，达到自己的期望。
安全性需求指系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。
互操作性需求包括硬件接口互操作、软件接口互操作，以及通信接口互操作。
硬件接口描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。软件接口描述该产品与其他外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具、库和集成的商业组件。通信接口描述与产品所使用的通信功能相关的需求，包括电子邮件、Web浏览器、网络通信标准或协议及电子表格等，定义了相关的消息格式，规定了通信安全或加密问题、数据传输速率和同步通信机制。
以ETT公司的HPC产品为例，我们可以看一下一个大型软件的功能性需求都包括什么。
案例 ETT公司的HPC产品功能性需求
软件安装/卸载/升级/更新需求：
● 交互式安装
● 静默安装
● 工厂安装
● 重新安装（P2）
● 卸载（P2）
● 安装中断后继续安装（P3）
● 升级
● 打补丁
节点/网络/模块管理包括：
● 添加
● 删除
● 修改
● 替换
● 重新部署
● 导入
● 导出
● 显示
● 锁定
● 激活
● 查询
● 生成报表
● 预警
● 配置
● 同步
● 过滤
● 状态监控
应用层模板管理：
● 模板实例化
● 发布
● 拷贝
用户安全管理：
● License控制
● 用户认证安全
● 系统网络安全性
● 数据库安全性
全球化支持：
● 中文支持
● 德文支持
● 日文支持
其他需求：
……
小白 非功能性需求是指什么？
大鸟 非功能性需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括系统的性能、易用性、可靠性、可维护性、可支持性、可扩充性、可移植性以及对技术和对业务的适应性等。例如：
● 性能（Performance）——响应时间、吞吐量、准确性、有效性、资源利用率（如要求系统能满足 100 个人同时使用，页面反应时间不能超过 6秒）；
● 易用性（Usability）——人性化因素、帮助、文档；
● 可靠性（Reliability）——故障频率（如系统能7×24小时连续运行，年非计划宕机时间不能高于8小时）、可恢复性（系统出现故障时，能够快速切换到备用机）、可预测性；
● 可支持性（Supportability）——适应性、可维护性、国际化、可配置性。
● 可移植性（Portability）——是否有对原来产品进行软件硬件迁移的支持？迁移过程中是否有兼容性的要求？
以ETT公司的HPC产品为例，我们可以看一个软件的非功能性需求包括什么。
案例 ETT公司的HPC产品非功能性需求
● 可靠性测试（P1）
我们的目标是支持自动化高可用性计算（High Availability）。
● 可扩展性需求（P1）
我们的目标是支持集群节点从目前的2000个扩展到5000个。
集群的报表、预警系统的图表系统必须能够支持扩展到5000个节点。
● 性能需求
同时部署500个节点的时间＜4个小时。
同时部署2000个节点的时间＜8个小时。
同时更新2000个节点的时间＜8个小时。
小白 大鸟，文档需求是指什么？
大鸟 文档需求列举出将与软件一同发行的用户文档部分，例如用户手册、在线帮助和教程，并明确所有已知的用户文档的交付格式或标准。
案例 ETT公司的HPC产品非功能性需求
（1）Online Help（在线帮助）。
（2）Man Page（功能帮助以及参数帮助）。
小白 对于一个项目优先级的定义是什么样的呢？
大鸟 一般来说，项目定义为3个优先级，分别是P1、P2、P3。
● P1——是强制性的一定要完成的模块，如果出现问题，将会影响项目发布。
● P2——对项目发布非常重要，但是如果出现问题也不会影响项目发布（具体由项目经理决定）。
● P3——重要，但不是强制性的或预期的一定要发布。
2.4 审核软件产品需求
小白 大鸟，上面我们已经介绍了功能性需求和非功能性需求。那么从QA角度来讲，我们怎么来审核 PRD，以确保它是个好的需求文档呢？
大鸟 一般来说，用户需求存在如下两个特点。
（1）零散：用户会提出不同角度、不同层面、不同粒度的需求，所以是零散的。
（2）存在矛盾：由于用户处在企业/组织的不同层面，因此难免会出现盲人摸象的现象，从而导致需求的片面性甚至自相矛盾。
一个合理的需求文档有如下特性：
（1）完整性。
（2）正确性。
（3）一致性。
小白 你总说审核软件需求。先问一个问题，审核到底是什么意思？
大鸟 “审核”在很多人的脑海中就是得出一个通过与否的结论。其实不是那么简单。顾名思义，审核（review）实际意思就是再（re）看（view）一遍的意思，其本质含义是通过再次的审读，尽早地暴露出错误。QA 通过审核需求文档，消除歧义、错误、不完整性，以确保沟通没有失真。搞清楚用户想要什么？用户要这干什么？他为什么这么想？他会不会漏了什么？
小白 那你也说了，正是因为需求文档存在歧义、错误、不完整性，所以我们需要不断地审核。
大鸟 是的。
小白 软件需求的完整性是指什么呢？
大鸟 完整性是指：不应该遗漏要求和必需的信息。不完整性是指：完整性涉及的东西可能根本不存在，或者只说了一部分，没说完整，有遗漏。
小白 别漏了。可是如何保证不漏呢？
大鸟 我们一般用如下这几种方法。
（1）演绎法。
（2）比较法。
（3）分解法。
（4）打标签。
小白 演绎法如何解决需求的不完整性？
大鸟 我们知道用户的需求可能是零散的，我们将这些零散、孤立的需求认为是一个个需求孤岛，需要把这些需求孤岛连接起来，最终形成闭环。
小白 需求孤岛？
大鸟 咱们看下面几个例子。
例1 业务需求——研发一个飞机，这个飞机可以起飞，可以空中平行飞行。
例2 用户需求——HPC软件可以正常地安装。
例3 功能需求——普通用户可以对管理节点进行增加、删除的操作。
你觉得上面这些需求缺点什么吗？
小白 第一个例子，貌似没有提降落的事啊。又不是恐怖分子，怎么会研发这种只能起飞和飞行的飞机呢？应该是漏掉了吧。
大鸟 这种遗漏可能是一个大大的缺陷。用户所要求的飞行服务需求应该是一个体系，而不是割裂、孤立的需求。例2也有这样的问题：HPC管理软件里面有安装的需求，但是没有提及卸载、升级、打补丁、重新安装的需求。例3亦然，普通用户对管理节点有增加、删除的需求但是没有提及修改、查看的需求，另外只是普通用户有这个需求吗？管理员、根（root）用户又会怎样呢？进行了增加、删除操作后，成功了如何？失败了又怎样？这些都是需求的不完整性。
小白 如何避免呢？
大鸟 把它放到体系里。还是刚才那个例子，用户有安装的需求：安装的需求放在软件测试里，是属于“可安装性测试”里面的，这里包括安装、卸载、升级、降级、不完全安装等多方面的需求。而“可安装性测试”又属于“可移植性测试”这个体系的一部分。我们把一个孤点需求放在软件需求的整个体系中，通过零散的需求拼图碎片补全整个需求拼图。
小白 有点像达芬奇密码里的拼图。
大鸟 准确点说是用演绎法。
小白 演绎法是什么呢？
大鸟 演绎法是指从普遍性结论或一般性事理推导出个别性结论的论证方法。在演绎论证中，普遍性结论是依据，而个别性结论是论点。演绎推理与归纳推理相反，它反映了论据与论点之间由一般到个别的逻辑关系。
比如说：“天下乌鸦一般黑，西安也有乌鸦，所以西安的乌鸦也是黑的”。这段话中就包含着一个完整的演绎论证。“天下乌鸦一般黑”，是普遍性原理，是论据，是“大前提”；“西安也有乌鸦”，是已知的判断，是“小前提”；而“西安的乌鸦也是黑的”则是结论，也是论点。
同理，大多数软件都有“安装、卸载、升级、降级、不完全安装”需求，大多数用户管理都有“增、删、读、改、导入、导出”等需求。所以，如果开发一个新的软件，那它的需求至少要和体系里面的软件需求保持一致，至少不能丢。
小白 嗯，但是会不会有这样的情况，我们研发了一个产品，就是只有安装，不能卸载。
大鸟 有可能，但是不需要做的东西，你要把它放在 Scope 外面去，并且从 QA的角度来说，至少你要想到这些，否则你怎么审核呢。在本书第2部分的测试分类中，我们会详细讲述测试分类的体系来验证这些需求。
小白 除了演绎法之外。你说还有比较法？
大鸟 是的，比较法包括纵向比较、横向比较。
小白 纵向比较是啥？
大鸟 现在的版本和以前的版本相比少不少东西，这是纵向的比较。
例 HPC4.2版本的产品，与HPC4.1版本产品相比，管理节点不能修改IP。
HPC4.1版本的产品是可以修改管理节点IP的，但是HPC4.2版本反而不能这样做了。是用户真的没有这样的需求吗？如果用户没有这样的需求，为什么？
如果用户有这样的需求，而仅仅是实现的局限性造成的，那就要问清楚，下一个版本还要实现吗？并把它明确加入到Scope里面去。
此外，上一版本的关键遗留问题（没做的）和上一版本没做好现在要加强（Enhance）的地方，是否已包含在内？这也是检查项之一。
小白 横向比较是啥？
大鸟 新引入一个东西，和类似产品相比少不少东西，这是横向的比较。
例 HPC产品中，系统可以监控GPFS，监控包括Alert（预警）。
GPFS是一个新引入的东西，系统以前监控的是NFS，而且监控包括Alert、Report两种。那么GPFS的监控为什么不包括Report呢？既然是一个体系，应该包括完整的监控。
小白 分解法是分解什么呢？
大鸟 分解关键字。文字表述中，往往关键字过于庞大，需要分解。像下面这个例子。
例 用户不能访问系统管理员级别的数据库里面的数据。
这个就是一个非常模糊的用户需求。它有如下的问题：
● 如果关键字是“用户”，用户是普通用户还是 root 用户，系统管理员级别的用户可以吗？
● 如果关键字是“不能”，那我想知道，验证成功如何？验证失败又该如何？
● 如果关键字是“访问”，访问的方式很多，增、删、读、改、导入、导出都包括吗？
● 如果关键字是“系统管理员级别的”，那么系统管理员级别是指什么？能否继续分解？情况如何？
● 如果关键字是“数据库”，那是什么样的数据库？是Sql database还是报表？
● 如果关键字是“数据”，数据包括什么？是数字、图表？
小白 哇哦，一句话居然扯出来那么多东西。
大鸟 正因为关键字不同，一个含混的需求可以分解成若干个清晰的子需求。
小白 那该咋办？
大鸟 限定、分解、细化。所谓限定，是指在范围约束里就把范围都定义清楚了，这里就不至于那么乱了。比如说：我们在范围约束中就指明数据库仅指Oracle 10数据库，那这里的数据库概念就清晰了。
所谓分解就是把主谓宾状都分解：根据什么样的人（Who）在什么样的条件下（Condition）做了什么样的事情（What），结果如何（成功如何？失败如何？）。必要的时候还可以画流程图把它分解成一个细粒度的需求，分解的方法我会在用户故事里面细讲。
小白 需要分解，需要细化。
大鸟 没错，下面的就是一个分解后的软件需求。
例 当请求者输入账户号码时，系统将根据在线用户列表来验证所输入的账号。如果在此列表中查不到该账号，则系统将显示一个出错信息并拒绝订货；否则，进入订货流程。
小白 还有一个问题哦，假如说QA确实知道某些需求不完整，缺乏一些信息，但这个东西用户、PM暂时也不确定，该咋办呢？
大鸟 没有问题，如果知道缺少某项信息，那么用TBD（To be done，待确定）作为标准标识来标明这项缺漏，这样将有助于你避免不完整性。在开始开发之前，必须解决需求中所有的TBD项。
小白 完整性说完了，接着我们说一下正确性。软件需求的正确性是指什么呢？
大鸟 正确性是指：没有歧义，逻辑一致，表达清晰。
小白 可是如何保证软件需求的正确性？
大鸟 有下面两种方法。
（1）明确用户动机。
（2）正确的表达方式。
小白 既然我们已知道用户要什么，干嘛一定还要追究用户为什么要这么做呢？
大鸟 在福尔摩斯探案集里，每次锁定了犯罪嫌疑人后，除了拿出证据之外，读者更期待知道罪犯的动机是什么。同理，在需求阶段，用户想要什么只是表相。用户的痛点、难点、困难、处境、顾虑、背景等，这才是他们要这样干的原因。许多需求团队在进行需求捕获活动时，经常预期用户能够直接告诉他们要做什么（What），而不太关心用户提出需求的真正动机（Why）。这样就会经常引起下面这样的局面发生：
“你要绳子，我给你了；你要木板，我也给你了；你为什么说这不是你想要的呢？”。我想程序员也有类似的问题想问自己的客户：“你要文本框，我提供了；你要一个表单，我也有了；你为什么说这个功能不是你想要的呢？”
小白 所以要透过现象看本质。
大鸟 是的。因为对于一个特定的问题来说，可能的解决方案会有很多，因此用户可能在使用软件的过程中会不断发现其他可选的、更合适的替代方案，从而导致了不必要的需求变更。而缓解这一现象的关键就在于，在需求捕获的过程中要多问“为什么”。还有一种情况是多个原因导致一个结果。
小白 不过虽然很多书籍里都强调需求是讲做什么（What）而不是怎么做（How）。但是实际上我感觉：只写 What 会导致开发结果不可控，所以某些项目管理人员在需求里面写了好多How。
大鸟 其实，当我们发现How没说清楚的时候，一定要反思Why说清楚了没有，因为需求人员并不是最佳决策者，他们也缺乏解决方案的知识，经验缺乏的结果会造成后期变更。如果程序员不知道Why就去做，很可能做拧了，结果就像欧亨利小说中的老板娘一样。
欧亨利小说节选
很久很久以前，一个男人天天都到一家小面包店里买两个隔夜的陈面包，新鲜面包是五分钱一个，陈面包五分钱却可以买两个。除了陈面包以外，他从来没有买过别的东西。时间一长，小店女主人开始注意这个男人，从开始的同情、怜悯，到后来对他的坚强和坚持产生好感。后来她得知他是一个艺术家，她想：他眼镜后面的目光是多么温柔和善啊！——但却靠陈面包过活！不过天才在成名之前，往往要经过一番奋斗。
又过了很长时间，男人又来买面包，店主鼓起勇气，乘男人不注意，快速地在面包里面塞了一块黄油，然后男人拿走了。女店主开始不安，猜想男人发现后会怎样，会感动？会接受？还是自尊被打击，再也不来了。
第二天，男人一早就出现在小店，发疯似地向女店主狂吼：“谁让你在面包里面加黄油的？一年了，我每天都加班到半夜，这幅设计图本来今天就可以完工了，谁让你在面包里面加黄油的！”
原来，橡皮能擦掉铅笔字是 1770 年英国科学家普里斯特首先发现的。在这之前，人们是用陈面包来擦铅笔的。
小白 好心办坏事。
大鸟 女主人知道用户的需求（需要陈面包），但是却搞不知道用户为什么要这样做（擦画）；她以为是用来吃的（没搞清楚用户动机），想要把需求变更一下（夹了块黄油），结果好心做了坏事。同理只有切实知道用户的理由，你才能提供正确的实现方法。
小白 为啥这么做，先给我一个理由。
大鸟 下面是一个我工作中的案例。
案例 曾经有一次我们Team做一个节点部署的软件。当时用户提出这样的一个需求：当节点部署完了之后，可以自动跑一个用户自定义的脚本（What）。我们当时部署节点的方式是通过 OS 模板（Template）方式来作。比如说你想安装一个操作系统为Rhel6.4的节点，那么你就得指定一个Rhel6.4的模板，然后方能部署。所以我们当时的解决方式是把用户自定义的脚本（Script）绑在了模板上，这样用户部署节点的时候，就可以自动执行这个脚本了（How）。从当时来看，这个解决方案确实解决了用户的问题。可是到了项目快结束的时候，用户却并不买账。我们又仔细调查了用户需求：原来用户想跑Script的目标节点是同时给多个组使用，不同的组有不同的模板，有的时候还要随时新建模板，并且期待在不同模板间的频繁切换（Why）。这样，把脚本直接耦合在模板上就不合适了（谁知道那个组用哪个模板呢）。所以，用户实际的需求是要解决在不同模板切换的情况下依旧保持脚本可以顺利运行。因此，目标节点应该和脚本直接耦合。搞清楚了Why才能弄明白用户是怎么玩的，你的How才不会是无的放矢。
小白 怎么才能弄清楚用户动机呢？
大鸟 如果你能够直接问用户或者项目负责人，那是最好的。如果没有这样条件，QA可以做一些推理，大胆假设，小心求证。其实，当你感觉这个地方动机不明、模糊的时候，这些都是QA的机会，别放过它。负责任的警探不会因为动机没搞清楚就匆匆结案，同理，负责任的QA也不会因为没搞清楚用户动机就匆忙测试。
小白 正确性的第二条是正确的表达方式。需要什么表达方式吗？说出来不就完了，写出来不就得了。
大鸟 表达是一种沟通方式的问题。我们做软件一般是通过文档沟通，所有的文档都是书面语言。语言是一种非常无力的东西，心里想的是什么，一张口可能说的是另一个意思。
场景：解说员的故事
解说员韩某某：
“守门员将球回传给门将”；
“各位观众，中秋节刚过，我给大家拜个晚年”；
“可能有的观众刚刚打开电梯，我们再把比分……”；
“球被守门员的后腿挡了一下！！！”；
“梅西又习惯性地舔舔自己的舌头”。
韩老师心里明明是这样想的，但表达出来后就是另一种意思了。这是语言描述的局限性。有些东西靠说是讲不清楚的，描述的过程中会造成信息扭曲。
可是文档的表述还不如口语呢，文档没有声音，没有图像，更没有语气。
小白 所以表达方式很重要。
大鸟 是的，所以我们要用正确的表达方式，具体包括如下几条。
（1）直接沟通。
（2）简洁描述。
（3）减少定性描述。
（4）词语的准确性。
小白 您的意思是尽量做一些直接沟通。
大鸟 我们说PRD是很重要的，这没错，但是它再重要也就是一个文档。文档是死的而人是活的，所以不要局限在这个文档上。文档只是我们过河的一条船，我们的目的是过河。如果可以的话，和写文档的人多做一些互动、交互不是更好吗？获取需求的最好办法就是直接和客户面对面沟通，尽量不打电话；如果可以打电话，尽量不要用Skype；如果能用Skype，尽量不要发邮件。越直接，效果越好。找到项目相关的人，最好找到项目的接口人进行面谈，或者直接去用户那里，看看使用环境。
小白 下一条是简洁描述。
大鸟 软件需求说明书，不是记叙文，而是应用文。应该概括段落大意，给出关键点。尽量用应用文的方式、短句的方式，不要长篇大论。
小白 所谓定性描述是什么呢？
大鸟 定性的词语也就意味着不确定。比如“系统对报警提供了有效的支持”、“两个报表间存在有效依赖关系”这两句话，你看其中的两个词“有效”、“依赖”。什么叫有效呢？表现在什么方面呢？依赖是什么呢？是数据依赖？还是流程依赖？这些都是定性的词语，如果审核时候发现了这样词语，QA 就要问个为什么了，为什么不能用更加定量的方式来表述。
小白 怎样更加定量呢？
大鸟 用一个指标性或者经验值之类的东西来描述。比如写可靠性时，不写“高可靠性”，而是写“7×24 小时不间断的服务”；写易用性时，不写“达到高易用性”，而是写“没有接触过本软件的初级用户能够不在帮忙的情况下30分钟理解所有功能点”。
场景漫画：开封菜的故事
甲：“对对对，我想起来了，这个地方有个挺好吃的，叫什么开封菜还不错。你到那里等我哦。”
乙：“开封菜？”
甲：“就是一白头发老头做的广告，叫什么KFC（KaiFengCai），再见！”
小白 词语的准确性是指什么？
大鸟 有时候需求文档中同一个词有多种含义，对于含混的表达，文档的作者必须基于这样一个理论：即文档的读者必须有一定的认知水平和认知标准。如果认知标准不同，必须加上清晰的注释。比如IB这个词是个缩写，在软件领域可以理解为IN BOUND CALL也可以认为是Infini Band，这种缩写一定要在需求文档中定义清楚。
小白 需求的一致性是指什么呢？
大鸟 一致性是指与其他软件需求或高层（系统、业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实一致。
案例 系统管理员可以具备访问一切数据内容的权限。PCM 用户的数据库仅允许自己访问。
如果系统管理员可以访问一切数据库的内容，那也就可以访问PCM用户的数据库，可是PCM数据库仅允许自己访问。这就是不一致。
2.5 范围约束
小白 范围约束是指什么呢？
大鸟 范围约束限制了开发人员设计和构建系统时的选择范围。范围约束一般有如下三种。
（1）用户的期盼超出了实现的能力。
（2）非技术因素决定的技术选型。
（3）预期的使用环境限制。
场景：玩具飞机的故事
一个稚气未消的三岁小孩，将一个玩具飞机举过头顶，看着爸爸说：“爸爸，你帮我把这个玩具飞机送到太空上去吧，我要把月球上的嫦娥姐姐接下来玩”。爸爸：“-_-|||”！ 小白 什么叫用户的期盼超出了实现的能力？
大鸟 这句话的本质就是实现的局限性。
小白 所谓的“属下无能，听凭教主发落”。
大鸟 用户提出了大量的需求，有些是技术上根本无法实现的，比如说一百年前如果有用户提出移动电话的需求，那么当时是实现不了的。
小白 后来技术突破了，就解决了。
大鸟 对，有些是费用预算内无法实现的。就像孩子不知道航天飞机上月球要多少钱一样，用户也不知道自己提出的需求要多大的成本。
小白 用户想掏买馒头的钱吃鲍鱼，显然不可能。
大鸟 还有一种情况是，我能实现，但是在这个时间期限内根本做不完。做不完怎么办？加人或者砍 Scope，做不完的就砍掉了，也就是放在范围以外了。或者是这个版本我不支持，下个版本再支持。
小白 非技术因素决定的技术选型是指什么？
大鸟 对于软件开发而言，有些技术选型并非由技术团队决定，而会受到企业/组织实际情况的影响，例如 HPC 软件产品原来采用的是 Oracle 数据库系统，但是现在由于一些实际的原因（法律或者其他非技术因素），采用了 PostgreSQL 数据库。
小白 预期的使用环境是指什么？
大鸟 用户的使用环境（使用场合、软硬件环境等）也会对软件的开发产生很大的影响，如果忽略了这方面的因素会给项目带来一些不必要的麻烦。一般使用环境包括如下几个方面。
（1）硬件平台范围：产品支持哪些机器？内存大于多少？硬盘多少。
比如：
● 机器类型——ETT/Dell系列/苹果系列等。
● 内存——不小于4G。
● 硬盘——至少500G。
注意：每类机器有不同的型号，如ETT3750，DellR510。
（2）OS（操作系统）范围，支持哪些操作系统？
比如：
● DOS.
● Windows.
● Linux(Rhel/Sles/Ubuntu).
● UNIX(Solaris/AIX/HP-UX).
注意：OS还有小版本，如Red Hat 5.8，Windows 7等。
案例 原来假设用户的环境是Sles11.2，没想到用户实际环境只有Sles10，从而导致很多基于Sles11.2开发的客户端程序不支持。
（3）浏览器支持范围，支持哪种浏览器？这里要注意一点，浏览器支持往往与软件或硬件相关。
浏览器包括：Firefox，IE，Chrome，Safari，Opera等。
注意以下几点：
● 浏览器往往支持多个操作系统，但其针对不同的操作系统有不同的版本。比如Firefox，要弄清楚是哪个操作系统上的Firefox。
● 有些浏览器的版本变化很快，要搞清是支持哪个版本。
● 有些浏览器是支持移动设备的，比如Android上的UC浏览器。
（4）预期的使用依赖。
有些软件预期的使用前提是有.NET平台支持，或者有其他第三方软件，忽略这样的情况，会造成实际使用时的尴尬。如果实在没办法解决，那么至少在对软件需求规格的说明中列举出影响需求陈述的假设因素。
小白 对于QA而言，在审核Scope时要做什么呢？
大鸟 要注意以下三点。
（1）要搞清楚范围和超出范围的界定。如果确定不做的，就要将其写入范围之外（out-of-scope），不要不了了之。
（2）要把超出范围而不去做的原因搞清楚。在此期间，QA 可能要做一些调查，而不要完全听从PM和DEV的“忽悠”。搞清楚是Can’t（不能）还是Won’t （不愿）？
（3）搞清楚完成此模块开发的假定事项或者依赖事项是否已表述清楚。
小白 PM和DEV还会“忽悠”QA？
大鸟 多了去了，人都有惰性。明明可以把事情做好，但不愿做的事情也蛮多的。从QA角度，你要搞清楚哪个是不能做的，哪个是不愿做的。