需求分析是（）。A、软件开发工作的基础B、软件生存周期的开始C、由系统分析员单独完成的D、由用户自己单独完成的

软件需求分析主要目的是分析并抽象描述各种需求信息，为目标系统建立一个概念模型，是在计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。是要解决目标系统"做什么"的问题。由此可见选项A正确。选项B需求分析可分为需求提出、需求描述及需求评审三个阶段。需求提出：主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。开发人员和用户确定一个问题领域，并定义一个描述该问题的系统，这样的定义称作系统规格说明，并且它在用户和开发人员之间充当合同。需求描述：在问题分析阶段分析人员的主要任务是：对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。需求评审：在需求评审阶段，分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰、具体，并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。因此B不正确。选项C正确，根据项目的复杂程度，需求分析的工作可以由不同人员来完成。选项D正确，需求分为三个层次：业务需求、用户需求、功能需求与非功能需求。业务需求（Business Requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。用户需求（User Requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件一一响应都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（Behaviour Requirement）。功能需求描述是开发人员需要实现什么。非功能需求：产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性等。

设①的需求分析为活动R1，②的需求分析为活动R2，③的需求分析为活动R3，④的需求分析为活动R4；①的软件设计为活动D1，②的软件设计为活动D2，③的软件设计为活动D3，④的软件设计为活动D4。根据题意，可画出历时最短（能并行的活动尽量并行）的带时标的双代号网络图如下图。可识别出关键路径为R2—R3—R1—D1—D4，①的需求分析、①的软件设计、③的需求分析均在关键路径上，而③的软件设计D3不在关键路径上。故单独压缩③的软件设计时间对进一步加快进度没有帮助。

进度压缩指在不改变项目范围、进度制约条件、强加日期或其他进度目标的前提下缩短项目的进度时间。进度压缩的技术有以下几种：

① 赶进度（也称作赶工）。对费用和进度进行权衡，确定如何在尽量少增加费用的前提下最大限度地缩短项目所需时间。赶进度并非总能产生可行的方案，反而常常增加费用。

② 快速跟进。这种进度压缩技术通常同时进行有先后顺序的阶段或活动，即并行。例如，建筑物在所有建筑设计图纸完成之前就开始基础施工。快速跟进往往造成返工，并通常会增加风险，这种方法可能要求在取得完整、详细的信息之前就开始进行，如工程设计图纸。其结果是以增加费用为代价换取时间，并因缩短项目进度时间而增加风险。

根据上述概念，“压缩需求分析工作周期”、“使用最好的工程师，加班加点尽快完成需求分析说明书编制工作”属于在尽量少增加费用的前提下最大限度地缩短项目所需时间的做法，即赶工。“设计图纸全部完成前就开始现场施工准备工作”属于并行展开相关活动，即属于快速跟进。而对于“与其他项目协调好关系以减少行政管理的摩擦”这一选项，间接防止进度的拖延，而非实质性推进工程进度，故不属于赶工，也不属于快速跟进。因此应选择B。