软件需求分析产生软件操作特征的规格说明，指明软件和其他系统元素的接口，建立软件必须满足的约束。下面对于软件需求分析的描述，不正确的是（） 分析员研究系统规约和软件项目计划，并在系统语境内理解软件和复审，从而生成计划软件范围的估算。 需求分析使得系统工程师能够刻画出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束。 经过仔细的需求分析活动，分析员能够得到详细的系统规约。 需求分析能够为软件设计者提供可被翻译成数据、架构、界面和过程设计的模型。
缺陷排除效率（DRE）是对软件质量保证及控制活动过滤能力的一个测量。假设某个软件在交付给最终用户之前发生的错误数量为45，软件交付之后发现的缺陷数为15，那么对应的DRE值为（） 0.75。 1.3。 0.5。 0.25。
条件测试是检查程序模块中所包含逻辑条件的测试用例设计方法，注重于测试程序中的条件。BRO（Branchand Relational Operator）测试保证能发现布尔变量和关系操作符只出现一次且没有公共变量的条件中的分支和条件操作符错误。考虑条件C1：（E1>E2）&（E3”和“=”是关系运算符，则C1的条件约束至少为（）时，就可以检查C1中的关系操作符错误。 {（>，=），（>，>），（>，<），（<，<），（=，<））。 {（<，<），（<，=），（<，>），（=，<），（=，=），（=，>），（>，<），（>，=），（>，>）}。 {（>，<），（=，<），（>，=）}。 {（>，<），（=，<），（>，=），（<，<）}。
在软件开发的V模型中，应该在（）阶段制定单元测试计划。 需求分析。 概要设计。 详细设计。 代码编写。
面向功能的软件度量使用软件所提供功能的测量作为规范化值。下面关于面向功能的软件度量方法的描述，不正确的是（） 面向功能度量是由Albrecht首先提出来的，他建议采用基于功能点的测量。 功能点是基于软件信息领域的可计算的（直接的）测量及软件复杂性的评估而导出的。 “功能”不能直接测量，所以必须通过其他直接的测量来导出。 “用户输入数”和“用户输出数”不属于面向功能的软件度量需要考虑的因素。
敏捷软件过程强调：让客户满意和软件应尽早增量发布；小而高度自主的项目团队；非正式的方法；最小化软件工程工作产品以及整体精简开发。（）不是采用这种软件开发过程的原因。
