Development Specifications Guide¶
Reading Order¶
The nine documents below, covering the whole system, are the base structure. Each specification holds the shared baseline and its per-area chapters, and Booking is one section of the transportation chapter. Where detail grows, it links to the existing per-area source. Per-area collections are secondary navigation, not the whole set of development documents.
| Order | Specification | System-level content |
|---|---|---|
| 1 | SRS — Requirements | Purpose, scope, actors, common and per-area requirements, non-functional requirements, constraints |
| 2 | SAD — Architecture | System boundary, runtime composition, module responsibility, external connections |
| 3 | SDD — Detailed design | Commands and queries, processing, transactions, errors, recovery |
| 4 | Data dictionary and ERD | Entities, fields, relations, writers, source mapping |
| 5 | Interfaces | API, module, file, provider and device contracts |
| 6 | Sequences and state | Normal and exception order, state, transitions, independent flags |
| 7 | Screens and popups | Screen families, fields, buttons, authority, state, navigation |
| 8 | Tests and acceptance | Test layers, per-area cases, expected results, evidence |
| 9 | RTM — Requirements traceability | Requirement → design → implementation → test, evidence, open items |
The nine documents carry the table of contents and the shared baseline for all areas. The fields, APIs, states and test detail of every area are not complete. Each document distinguishes partial from unwritten. Filling these chapters with C1 Legacy, C2 reference and product evidence is the work that follows. Completing the Booking feature, generating test data and achieving real acceptance are not prerequisites for writing the document structure.
How The Supplied Templates Were Applied¶
From the supplied traditional specification HTML, document control, scope and applicability, stable identifiers, per-type detail cards, exceptions and evidence, and review/change control were adopted. Example business values, empty authoring placeholders, and the HTML editing and save scripts were not carried over as product requirements or operational facts.
| Supplied template | Existing document used | Core structure adopted |
|---|---|---|
| SRS | SRS | Business/system scope, actors, functional and non-functional requirements, AC, TBD and change impact |
| SAD | SAD | Architecture by viewpoint, quality scenarios, boundary, placement, risk, ADR |
| SDD | SDD | Component, command, query, processing, transaction, errors and recovery, implementation handoff |
| Data / ERD | Data | Conceptual, logical and physical separation, entity/field/relation, integrity, migration, retention |
| Interface | Interfaces | Provider/consumer, payload, auth, version, timeout/retry/idempotency |
| Sequence Diagram | Sequences and state | Participant/message/state, normal, exception, concurrency, unknown, recovery |
| Screen | Screens | Menu/route, field/action/state, popup, accessibility, viewport, per-Client differences |
| System Verification | Tests and acceptance | Baseline, environment/account/data, case/run/evidence, defect/gate/acceptance |
| RTM | RTM | Bidirectional trace, revision, coverage denominator, orphan, change impact |
The Wiki uses this Markdown as the single source. The display copy provides an English navigation menu and document metadata in the same frame, while the specification body is kept in its original language.
Who It Applies To, And On What Basis¶
| Class | Basis for writing the work and design | Interpretation rule |
|---|---|---|
| Shared | Approved system principles and shared contracts | No separate source package per customer. Application differences in data and policy are explained. |
| Client 1 | Root Legacy code and existing work/schema material | Reconstruct the Legacy work. Do not overwrite C1 requirements with the current New-System behaviour. |
| Client 2 | reference/mkmetal work and forms, and New-System | Reconcile the reference against the current implementation. Where they differ, state the difference and what has to be decided. |
State Of A Statement¶
Confirmed baseline is a principle set by the user or in an approved contract. Source observation is behaviour verified in Legacy/reference. Current implementation is behaviour verified in New-System source. Open is an item where a business decision or real-environment confirmation is still needed. The existence of a source does not by itself mean a business requirement is approved.
Relationship Between Documents And Evidence¶
Each individual document is the single editing source for the body of its specification. The body of another area is not appended to this guide. The HTML and the Wiki display copy are generated results and are not edited separately. Source reconciliation records, implementation contracts beside code, and real test results each link to their own evidence document. When the same fact changes, the relevant evidence and the impact on this specification are reviewed together.
- Detail source reconciliation: docs/processes/OCEAN_BOOKING_SOURCE_RECONCILED.md
- Implementation notes: packages/modules/transportation/README.md
- Per-screen evidence: docs/pages/transportation/booking-workspace/TEST_MATRIX.md
- Execution results and the incomplete range: docs/tasks/NS4-017.md
Client 1 is also in scope for the technical specifications. The C1 user manual authoring and publication hold stays in force. The Wiki reading scope of a technical document is separate from the reading scope of the user manual.
Booking Detail Sources In The Transportation Chapter¶
- Booking Requirements
- Booking Composition And System Boundary
- Booking Processing, State And Recovery Design
- Booking Data Dictionary And Relations
- Booking HTTP Interface
Source:
new-system/docs/requirements/DEVELOPMENT_SPECIFICATIONS.md— ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.