2026上半年軟考高級(jí)系統(tǒng)分析師第8章《專業(yè)英語(yǔ)》考試知識(shí)點(diǎn)分值分布及試題如下：

第8章 專業(yè)英語(yǔ)

一、分值分布

二、試題示例

1.專業(yè)英語(yǔ)--5分

試題【2022年上半年系統(tǒng)分析師考試上午真題】

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.

4. 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 （ ） for the system development.

5. 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 （ ） .

選項(xiàng)1：

A：Security checks

B：Validity checks

C：Consistency checks

D：Completeness checks

選項(xiàng)2：

A：Security checks

B：Safety checks

C：Consistency checks

D：Usability checks

選項(xiàng)3：

A：Consistency checks

B：Usability checks

C：Operational checks

D：Completeness checks

選項(xiàng)4：

A：tools

B：tests

C：models

D：budget and schedule

選項(xiàng)5：

A：requirement

B：model

C：design

D：implementation

答案：B、C、D、C、A

解析：需求驗(yàn)證是檢查需求是否實(shí)際定義了客戶真正想要的系統(tǒng)的過(guò)程。它與分析重疊，因?yàn)樗P(guān)注的是發(fā)現(xiàn)需求中的問(wèn)題。需求驗(yàn)證是很重要的，因?yàn)楫?dāng)這些問(wèn)題在開發(fā)過(guò)程中或系統(tǒng)投入使用后被發(fā)現(xiàn)時(shí)，需求文件中的錯(cuò)誤會(huì)導(dǎo)致大量的返工成本。通過(guò)改變系統(tǒng)來(lái)修復(fù)需求問(wèn)題的成本通常比修復(fù)設(shè)計(jì)或編碼錯(cuò)誤要大得多。原因是對(duì)需求的改變通常意味著系統(tǒng)的設(shè)計(jì)和實(shí)施也必須改變。此外，還必須重新測(cè)試系統(tǒng)。

在需求驗(yàn)證過(guò)程中，應(yīng)該對(duì)需求文件中的需求進(jìn)行不同類型的檢查。這些檢查包括：

1.（ ）: 用戶可能認(rèn)為需要一個(gè)系統(tǒng)來(lái)執(zhí)行某些功能。然而，進(jìn)一步的思考和分析可能會(huì)發(fā)現(xiàn)需要額外的或不同的功能。系統(tǒng)有不同的利益相關(guān)者，有不同的需求，任何一套需求都不可避免地是整個(gè)利益相關(guān)者群體的妥協(xié)。

2. （ ）: 文件中的要求不應(yīng)沖突。也就是說(shuō)，不應(yīng)該有相互矛盾的約束或?qū)ν幌到y(tǒng)功能的不同描述。

3.（ ）: 需求文件應(yīng)該包括定義所有功能的需求和系統(tǒng)用戶所期望的約束。

4. 現(xiàn)實(shí)性檢查。利用現(xiàn)有技術(shù)的知識(shí)，應(yīng)該對(duì)需求進(jìn)行檢查，以確保它們能夠真正被實(shí)現(xiàn)。這些檢查也應(yīng)該考慮到系統(tǒng)開發(fā)的（ ）。

5. 可驗(yàn)證性。為了減少客戶和承包商之間潛在的爭(zhēng)議，系統(tǒng)需求的編寫應(yīng)該始終是可驗(yàn)證的。這意味著你應(yīng)該能夠編寫一套測(cè)試，以證明所交付的系統(tǒng)符合每一個(gè)指定的（ ）。

（1）A.安全檢查 B.有效性檢查C.一致性檢查 D.完整性檢查

（2）A.安全檢查 B.安全檢查 C.一致性檢查 D.可用性檢查

（3）A.一致性檢查B.可用性檢查C.操作性檢查 D.完整性檢查

（4）A.工具 B.測(cè)試 C.模型D.預(yù)算和時(shí)間表

（5）A.需求 B.模型 C.設(shè)計(jì)D.實(shí)施