Why English? | Writing a Technical Specification Through Purpose, Scope, Interfaces, Requirements, Constraints, Data, Errors, Quality Attributes, Acceptance and Change Control

ORIENTATION

What this guide covers

Current fact check

Checked on 9 November 2026, NASA’s current systems-engineering references defined a specification as prescribing requirements, design, behaviour or characteristics completely, precisely and verifiably. Appendix C said “shall” denotes a requirement, “will” a fact or declaration of purpose and “should” a goal, and asked whether requirements are active, consistent, traceable, feasible, measurable, interface-aware and testable. These are rigorous requirement-writing practices rather than a mandatory universal template.

What this guide does not cover

This article covers drafting and reviewing a system or component technical specification as a controlled technical agreement. It does not cover business cases, product discovery, procurement law, architecture selection, source code, implementation plans, statements of work, contracts, safety cases, threat modelling, test procedures, acceptance authority or requirements traceability matrices as separate artefacts.

Worked example

Every chapter returns to a fictional school assignment export service that produces an authorised CSV for a teacher while preserving permissions, time-zone meaning, accessibility and audit records. It is fictional, low-stakes and educational; it does not report a real school, clinical decision or guaranteed outcome.

Warm up with eduKate’s guides to explaining scientific evidence and asking better questions in class.

CHAPTER 1 OF 12

1. Name the Purpose and Decision the Specification Supports

Back to contents

Why this move matters

Explain the need, intended users, lifecycle stage and authority of the document.

Define the system boundary and document authority

Explain the need, intended users, lifecycle stage and authority of the document. In The specification supports design and acceptance of a teacher-only assignment export service., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: Purpose does not itself become a testable product requirement.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. Purpose does not itself become a testable product requirement. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “Name the Purpose and Decision the Specification Supports” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

CHAPTER 2 OF 12

2. Draw the System Boundary and Non-Scope

Back to contents

Why this move matters

Identify what the named system contains, what it interacts with and what related work is excluded.

Define the system boundary and document authority

Identify what the named system contains, what it interacts with and what related work is excluded. In Export generation is in scope; changing assignment marks and parent access are out of scope., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: Non-scope cannot exclude a dependency necessary for safe operation.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. Non-scope cannot exclude a dependency necessary for safe operation. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “Draw the System Boundary and Non-Scope” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

CHAPTER 3 OF 12

3. Define Terms, Roles, Assumptions and Governing Sources

Back to contents

Why this move matters

Create a shared glossary and identify confirmed constraints, unresolved assumptions and source requirements.

Define the system boundary and document authority

Create a shared glossary and identify confirmed constraints, unresolved assumptions and source requirements. In Teacher, authorised class, due date and export job receive precise definitions and source links., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: An assumption must not be disguised as an approved fact.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. An assumption must not be disguised as an approved fact. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “Define Terms, Roles, Assumptions and Governing Sources” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

CHAPTER 4 OF 12

4. Give Every Requirement a Stable Identifier

Back to contents

Why this move matters

Number or otherwise identify requirements so design, tests, decisions and changes can reference the exact statement.

Define the system boundary and document authority

Number or otherwise identify requirements so design, tests, decisions and changes can reference the exact statement. In EXP-FUN-004 names the rule that only authorised class records enter an export., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: An identifier does not make a vague requirement valid.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. An identifier does not make a vague requirement valid. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “Give Every Requirement a Stable Identifier” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

CHAPTER 5 OF 12

5. Write Atomic Requirement Statements

Back to contents

Why this move matters

Put one main obligation in each statement with a clear subject, required behaviour and applicable condition.

Define the system boundary and document authority

Put one main obligation in each statement with a clear subject, required behaviour and applicable condition. In “The service shall reject an export request when the requester lacks class access” carries one testable obligation., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: Some closely coupled conditions still need a structured table rather than fragmented prose.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. Some closely coupled conditions still need a structured table rather than fragmented prose. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “Write Atomic Requirement Statements” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

CHAPTER 6 OF 12

6. Replace Vague Qualities With Measures and Conditions

Back to contents

Why this move matters

Define thresholds, units, loads, environments, tolerances and measurement methods for performance or quality claims.

Define the system boundary and document authority

Define thresholds, units, loads, environments, tolerances and measurement methods for performance or quality claims. In Ninety-five per cent of authorised exports of 500 records complete within two seconds in the named test environment., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: A threshold must be feasible and tied to actual user need.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. A threshold must be feasible and tied to actual user need. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “Replace Vague Qualities With Measures and Conditions” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

CHAPTER 7 OF 12

7. Specify Interfaces and Dependencies

Back to contents

Why this move matters

Document actors, systems, protocols, versions, inputs, outputs, timing, ownership and failure boundaries.

Define the system boundary and document authority

Document actors, systems, protocols, versions, inputs, outputs, timing, ownership and failure boundaries. In The export service reads assignment records through a versioned internal interface and writes to approved storage., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: Interface detail must not expose secrets or unsafe internal information.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. Interface detail must not expose secrets or unsafe internal information. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “Specify Interfaces and Dependencies” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

CHAPTER 8 OF 12

8. Define Data Meaning, Validation and Privacy Constraints

Back to contents

Why this move matters

State fields, types, units, permitted values, null meaning, provenance, retention and authorised uses.

Define the system boundary and document authority

State fields, types, units, permitted values, null meaning, provenance, retention and authorised uses. In Due time is stored in UTC and exported with an explicit Singapore time-zone label., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: A data field’s availability does not authorise its use.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. A data field’s availability does not authorise its use. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “Define Data Meaning, Validation and Privacy Constraints” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

CHAPTER 9 OF 12

9. Describe Errors, Recovery and Observability

Back to contents

Why this move matters

Specify failure conditions, safe responses, retry or rollback behaviour and evidence needed for support.

Define the system boundary and document authority

Specify failure conditions, safe responses, retry or rollback behaviour and evidence needed for support. In An expired export link returns a defined error without revealing whether another class exists., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: Verbose diagnostics may belong in protected logs rather than user messages.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. Verbose diagnostics may belong in protected logs rather than user messages. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “Describe Errors, Recovery and Observability” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

CHAPTER 10 OF 12

10. State Security, Accessibility, Reliability and Maintainability

Back to contents

Why this move matters

Express relevant quality attributes as bounded, verifiable requirements and connect them to policy or risk.

Define the system boundary and document authority

Express relevant quality attributes as bounded, verifiable requirements and connect them to policy or risk. In Keyboard operation, audit retention and service recovery each have defined criteria and evidence., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: A specification cannot certify compliance before implementation and verification.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. A specification cannot certify compliance before implementation and verification. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “State Security, Accessibility, Reliability and Maintainability” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

CHAPTER 11 OF 12

11. Define Verification and Acceptance Evidence

Back to contents

Why this move matters

Assign a verification method, success criterion, environment and responsible review route to each requirement.

Define the system boundary and document authority

Assign a verification method, success criterion, environment and responsible review route to each requirement. In EXP-FUN-004 is verified by an automated permission test and an authorised acceptance review., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: Passing a component test may not satisfy system acceptance.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. Passing a component test may not satisfy system acceptance. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “Define Verification and Acceptance Evidence” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

CHAPTER 12 OF 12

12. Baseline the Document and Control Change

Back to contents

Why this move matters

Record version, approvals, open decisions and the process for impact assessment, revision, notification and re-verification.

Define the system boundary and document authority

Record version, approvals, open decisions and the process for impact assessment, revision, notification and re-verification. In A changed time-zone rule updates the specification, data dictionary, tests and release plan after approval., name the product, users, interfaces, assumptions, constraints and governing sources before writing requirements.

Turn needs into atomic and verifiable statements

Give each requirement a unique identifier, consistent subject, measurable condition and acceptance method. Preserve this limit: Editing the document does not approve the change.

Connect interfaces, data, errors and quality attributes

Describe inputs, outputs, states, performance, security, accessibility, reliability and recovery without hiding contradictions across sections.

Baseline, trace, verify and control change

Route review to authorised owners, record decisions and update dependent tests and documents after approval. Editing the document does not approve the change. A precise specification supports engineering; it cannot prove feasibility or safety by wording alone.

Student, parent and career transfer

Practise “Baseline the Document and Control Change” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to engineering projects, school design tasks, software development, data systems, procurement support, quality assurance, cybersecurity coordination, operations and technical writing without guaranteeing grades, approval, publication, system safety, research validity, employment or future outcomes.

PRACTICE LAB

Build a technical specification decision trail

Student route

1. Choose one real example or official document inside this guide’s scope.
2. Copy its objective and underline actor, action, context, evidence and intended decision.
3. Draw the specific reasoning chain used in this article.
4. Mark each step reported, inferred, contested or unknown.
5. Rewrite the conclusion so it preserves the narrowest important limitation.

Parent or teacher route

Ask the learner to explain turn a technical need into a precise, traceable and verifiable agreement about what a system must do, where its boundaries sit and how people will know the result meets the specification twice: once to a classmate and once to a method specialist. Praise a precise correction and a well-stated unknown; both show disciplined attention to evidence.

Early-career route

Create a one-page technical specification audit with source link, date checked, scope, method logic, decisive wording, contrary evidence, limit and next action. A colleague should be able to continue without guessing.

Continue with eduKate’s guides to reading course and career information and giving useful feedback in group projects.

USEFUL NEXT READING

Connect this narrow owner to its neighbour

Read the product-requirements document guide for a related but different reader job. Return here when the question is specifically how to turn a technical need into a precise, traceable and verifiable agreement about what a system must do, where its boundaries sit and how people will know the result meets the specification. Use each guide for the reader task named in its heading.

For English practice across research, school and career communication, visit the Singapore English Tuition Centre learning site.

FREQUENTLY ASKED QUESTIONS

Questions students and parents often ask

Is a technical specification the same as a requirements document?

They may overlap, but local governance defines the artefacts. This guide focuses on a precise controlled specification of system behaviour and characteristics.

Must every requirement use “shall”?

NASA uses shall for requirements, but follow the controlling standard and project style consistently.

Should a specification say how to implement the system?

Include design constraints only when genuinely required and authorised; otherwise state the needed outcome and interface rather than an accidental solution.

How detailed should interfaces be?

Detailed enough for compatible implementation and verification, while protecting secrets and avoiding unsupported internals.

Can one person approve the specification?

Only the project’s governance determines reviewers and approvers. Writing clarity does not create authority.

Does a complete specification guarantee project success?

No. Feasibility, design, implementation, testing, operations and change management remain separate work.