Requirements validation is the process of checking that requirements actually define the system that the customer really wants. It overlaps with analysis as it is concerned with finding problems with the requirements. Requirements validation is important because errors in a requirements document can lead to extensive rework costs when these problems are discovered during development or after the system is in service. The cost of fixing a requirements problem by making a system change is usually much greater than repairing design or coding errors. The reason for this is that a change to the requirements usually means that the system design and implementation must also be changed. Furthermore, the system must then be re-tested.
During the requirements validation process, different types of checks should be carried out on the requirements in the requirements document. These checks include:
- （问题1） : A user may think that a system is needed to perform certain function. However, further thought and analysis may identify additional or different functions that are required. Systems have diverse stakeholders with different needs and any set of requirements is inevitably a compromise across the stakeholder community.
- （问题2） : Requirements in the document should not conflict. That is, there should not be contradictory constraints or different descriptions of the same system function.
- （问题3） : The requirements document should include requirements that define all functions and the constraints intended by the system user.
- Realism checks: Using knowledge of existing technology, the requirements should be checked to ensure that they can actually be implemented. These checks should also take account of the （问题4） for the system development.
- Verifiability: To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable. This means that you should be able to write a set of tests that can demonstrate that the delivered system meets each specified （问题5） .
需求验证是确保需求精准匹配客户真实诉求的关键环节，其核心价值在于大幅降低项目返工成本——需求文档的错误若在开发阶段或系统上线后才发现，修复成本远高于设计、编码阶段的错误，因为需求变更会牵连系统设计、实现及全流程重测。需求验证需开展多维度检查：一是有效性检查，要确认需求真正契合各利益相关方的实际需求，由于系统涉及不同诉求的干系人，需求本质是多方诉求的平衡结果，需避免需求偏离用户真实需要；二是一致性检查，需保障需求文档内无矛盾，同一系统功能的描述、约束不能出现冲突，防止开发方向混乱；三是完整性检查，要确保需求覆盖用户预期的所有功能与约束，无内容遗漏，为开发提供全面指导；四是现实性检查，需结合现有技术能力，同时重点考量项目的预算与时间进度，确保需求在资源限制下具备可落地性；五是可验证性检查，所有需求需具备可验证性，即能通过设计对应测试用例，验证交付系统是否满足需求，这是减少供需方纠纷、保障需求可执行的重要前提。
本题考察的是需求验证（Requirements Validation）的检查方法。
需求验证确保需求文档准确、完整、一致、可实现并且可验证，从而减少后续开发中的返工成本。
问题1：
A选项 Security checks：是关于系统安全性的检查，与确认用户真实需求无关。
B选项 Validity checks：有效性检查用于确认需求是否真正代表了用户的真实需求，符合题干描述，正确。
C选项 Consistency checks：用于发现需求之间是否矛盾，而不是判断用户是否需要，错误。
D选项 Completeness checks：是检查需求是否完整，与题干描述不符。
所以选择 B。
问题2：
A选项 Security checks：关注系统安全性，与需求冲突无关。
B选项 Safety checks：强调系统的安全性要求，不涉及一致性。
C选项 Consistency checks：一致性检查保证需求文档中不出现矛盾和冲突，符合题干描述，正确。
D选项 Usability checks：关注系统的可用性，与一致性无关。
所以选择 C。
问题3：
A选项 Consistency checks：检查需求是否前后一致，不涉及是否遗漏。
B选项 Usability checks：强调可用性，与完整性无关。
C选项 Operational checks：不是常见的需求验证类型。
D选项 Completeness checks：完整性检查确保需求文档中所有功能与约束都被覆盖，符合题干描述，正确。
所以选择 D。
问题4：
A选项 tools：工具与需求现实性无关。
B选项 tests：测试是验证需求的手段，而不是可行性依据。
C选项 models：模型可以帮助分析，但题干强调开发过程的限制。
D选项 budget and schedule：预算与时间表是现实性检查中必须考虑的因素，正确。
所以选择 D。
问题5：
A选项 requirement：需求必须是可验证的，能够通过测试来确认是否满足，符合题干描述，正确。
B选项 model：模型只是分析工具，不是验证对象。
C选项 design：设计是需求实现的方式，而不是测试的目标。
D选项 implementation：实现是代码层面的产物，但验证的对象是需求本身。
所以选择 A。