Professional English and Technical Writing
Domain 9 covers reading technical English under time pressure and producing documentation that meets Chinese and international standards. The morning paper tests comprehension of a short passage; the essay paper rewards precise, standard-conformant documents.
Reading technical English
- Typical items ask for the main idea, an inference, the meaning of a term in context, or the author's attitude. Locate the sentence carrying the claim before reading the options.
- Discourse markers decide answers: however and whereas signal contrast, therefore and hence signal conclusion, for example signals an illustration rather than the claim itself.
- Learn the requirement vocabulary: requirement, specification, verification, validation, traceability, baseline, deliverable, stakeholder, constraint. Distinguish effectiveness (doing the right thing) from efficiency (doing it with less resource), and reliability (failure rate) from availability (uptime share).
- RFC 2119 keywords matter: shall is mandatory, should is recommended, may is optional. Translating shall as should reverses an obligation.
Documentation standards
- GB/T 8567-2006 defines the software documentation set, including feasibility study report, project development plan, software requirements specification, outline design description, detailed design description, test plan, test report, user manual and project development summary.
- An SRS follows a fixed skeleton: purpose and scope, definitions, references, overall description, specific requirements, appendices and index. Each requirement carries an identifier so it can be traced to design and tests.
- A design description documents architecture, module decomposition, interfaces, data structures, error handling and traceability to the SRS.
- Style rules: one requirement per sentence, active voice, defined terms used consistently, no vague qualifiers such as etc., and/or, as appropriate, user-friendly, or fast.
Worked example
A sentence reads: The system shall be user-friendly and process data quickly where appropriate. Three failures: user-friendly is unverifiable, quickly has no threshold, and where appropriate removes the obligation. Rewrite: The system shall display the search results screen within 2 seconds for 95% of queries returning fewer than 1,000 records. The rewrite names an actor, a measurable response and the condition under which it holds.
Traps
- Answering comprehension items from background knowledge rather than the passage.
- Rendering shall as should, or may as must.
- Using the same actor under three names (client, user, customer), which breaks traceability.
- Writing documentation that omits the identifier scheme and traceability matrix.