English Reading and Technical Documentation (英语阅读与技术文档)
Domain 9 checks that you can read English specifications and produce documentation Chinese teams actually use: requirements specs, design documents, API references, test reports and user manuals. Questions combine a short English passage with a comprehension item, or ask which document should contain a given piece of information.
Vocabulary that decides answers
latency, throughput, uptime, SLA, scalability, escrow, fulfilment, chargeback, reconciliation, procurement, tender/RFP, compliance, audit trail, deprecate, idempotent, mandatory/optional. Note that escrow is 资金托管, not a fee; fulfilment is 履约发货, not payment; reconciliation is 对账.
Reading rules for specs
- RFC 2119 keywords carry obligation: shall/must = required, should = recommended, may = optional. A question turns on this distinction.
- Read numbers with their qualifier: "99.9% monthly uptime" is a commitment, "best effort" is not.
- Tables and error-code lists are usually where the answer lives; read the parameter's type, whether it is required, and its range.
Document set and structure
需求规格说明书 (SRS): scope, actors, functional and non-functional requirements, acceptance criteria, traceability. 概要设计: architecture, modules, interfaces, data model. 详细设计: algorithms, tables, screen logic. API document: endpoint, method, parameters, response, error codes, examples. Test report: environment, cases, defects, conclusion. Every document needs a version number, revision history and traceability to requirements.
Worked example
A vendor SLA reads: "The Platform shall maintain 99.9% monthly availability, measured as the percentage of minutes in the calendar month during which the checkout API returns a valid response." Reasoning: 30-day month = 30 × 24 × 60 = 43,200 minutes; the allowed unavailability is 0.1% × 43,200 = 43.2 minutes. "Shall" makes it binding; the measurement object is the checkout API, not the whole site. If the clause said "best effort", no credit would be due however long the outage. Writing the calculation out is what earns the mark.
Traps that cost marks
- Translating terms word-for-word and changing their technical meaning.
- Ignoring shall/must/should/may when judging obligations.
- Computing uptime on a 31-day month without adjusting the minute base.
- Documents without version, revision history or traceability to requirements.
- Putting security and performance requirements only in the design document, never in the SRS.