Software Requirements Specification (SRS)¶
0. Document Control And Scope¶
| Item | Baseline |
|---|---|
| Document ID / type | SPEC-SRS / Software Requirements Specification |
| Baseline state | a structure and shared baseline draft with some area detail written |
| Scope | the whole system and the SYS-F01 to 11 areas; Booking is the detail of SYS-F08 |
| Basis priority | C1 Legacy, C2 reference and New-System, and the shared Product contract |
| Notation of a value | a confirmed fact, an interpretation, an assumption, TBD or unwritten, and NOT_APPLICABLE are distinguished |
| Approval and acceptance | the document update date is not the requirement approval date or the work acceptance date |
A requirement is written with a stable ID and a verifiable SHALL meaning, and on a change the effect on the design, data, screen, test, and RTM is checked together. An example and a blank in the supplied template are not a real requirement, and only the content whose basis is confirmed is filled in here.
1. Purpose And System Scope¶
The Logistics Workspace is a multi-tenant logistics system that connects master data, the trade contract, inbound and outbound, field work, weighing, inventory, transport, equipment, documents, billing, and settlement. Booking is the ocean reservation function of the transport area and is not the boundary of this whole specification.
This document defines what the system must guarantee. The design method is covered in SAD and SDD, the fields and messages in Data and Interfaces, and the verdict method in Tests and RTM. The basis of the product scope is PRODUCT, and the basis of the responsibility is the Module Registry. The requirements below are a system-level draft organised from that basis, not a list of the implementation, approval, and acceptance completion of every feature.
2. Users And The Applied Basis¶
The work actors are distinguished as the administration owner, the office work owner, the field worker, the weighing owner, the inventory and warehouse owner, the transport owner, and the billing and settlement owner. These are analytical actors and not a definition that grants a new real role ID or authority. They are compared with the current role and authority in each area.
| Target | The basis for authoring a requirement | The difference that must be left |
|---|---|---|
| Client 1 | the external Legacy code, screen, work, and data material | the Legacy requirement and the product correspondence, and the undetermined items |
| Client 2 | the external reference and mkmetal, and the product internal implementation and contract | the mismatch between the reference and the current implementation, and the approval status |
| shared | the approved Product and module contract | the difference between the target contract and the real implementation and verification |
A new user manual targets only C2. Authoring a C1 technical specification and holding the C1 manual are not confused.
3. System Common Requirements¶
| ID | Requirement | What to confirm on acceptance |
|---|---|---|
| SYS-C01 | a work request is processed according to the authenticated tenant and authority and the membership of the target record | the result and the no change of a command with another tenant identifier or without authority |
| SYS-C02 | the public identifier is a UUID, and a numeric compatibility is kept inside the DB adapter | the request, response, and relationship reference, and the compatibility boundary |
| SYS-C03 | the commercial intent, execution plan, physical evidence, inventory, document, and settlement state are distinguished | the save of one record is not mistaken for a completion of another area |
| SYS-C04 | an unconfirmed change result, a duplicate request, and a concurrent edit follow the recovery contract of that command | a duplicate side effect, a conflict, the re-query, and the retry result |
| SYS-C05 | a Client difference is explained by a policy, setting, and representation of the common owner | a separate writer per customer is not created, and the source difference is preserved |
4. Per-Area Functional Requirement Contents¶
Each row is an area of this SRS. When the detail becomes large it is linked to a document of the same kind, and the whole of another specification is not put into this section. The detail is unwritten does not mean the work does not exist, but that it is not yet organised into a traditional specification.
| ID and area | The feature and the work result to define | The current detail |
|---|---|---|
| SYS-F01 administration, access and settings | the user, role, menu, and tenant settings and the valid authority | §4.2 the 3 system requirements are written; the per-role acceptance condition is unwritten |
| SYS-F02 master data | the reference management of the company, counterparty, item, unit, and place | §4.3 the 3 system requirements are written; the field and lifecycle detail is unwritten |
| SYS-F03 trade | the intent and the fulfilment link of the contract, order, item, and price | §4.4 the 2 system requirements are written; the state transition detail is unwritten |
| SYS-F04 inbound and outbound | the execution order, item, and source link, distinguished from the execution result | §4.4 the 2 system requirements are written; the per-area quantity policy is unwritten |
| SYS-F05 field work and Transload | the plan, assignment, the field and office execution, and the correction | §4.5 the system requirement and acceptance boundary detail is written; the real role and DB acceptance is NOT_RUN |
| SYS-F06 weighing | the weighing evidence, ticket, correction, and cancellation, and the link to the consuming area | §4.5 the requirement and acceptance boundary detail is written; the device, role, and DB acceptance is NOT_RUN |
| SYS-F07 inventory and warehouse | the lot, ledger, location, and allocation, and the correction and reversal | §4.6 is written; the real role and DB acceptance is NOT_RUN |
| SYS-F08 transport and Booking | the ocean reservation, schedule, Shipment, Transport Leg, and the transport waybill | §4.1, §4.7, and the Booking requirements is written; the shared transport state is unwritten |
| SYS-F09 equipment and yard | the container and chassis assignment, availability, Yard, return, and photo relationship | §4.7 the 2 system requirements are written; the equipment transition detail is unwritten |
| SYS-F10 documents and output | the source projection, form, preview, and output, distinguishing the dispatch effect | §4.8 the 2 system requirements are written; the per-document issuance contract is unwritten |
| SYS-F11 billing and settlement | the service billing, the AP and AR evidence, the cost and margin, and the source link | §4.8 the 2 system requirements are written; the accounting posting and margin policy is unwritten |
4.1 The Booking Section Of The Transportation Area¶
Booking manages the carrier booking number, the schedule, the equipment plan, the related companies, and the document information. Storing a reservation does not complete an inbound, a loading, a billing, or a dispatch. The existing BKG-R identifier and the requirement body are kept in the Booking detail. SYS-F08 is the upper scope of this work group and does not change the existing BKG-R number.
4.2 Administration, Access, And Settings Requirements¶
| ID | Requirement | The current basis and the difference |
|---|---|---|
| SYS-F01-R01 | after authentication the tenant, the module and settings, the menu, page, and API, the action authority, and the record membership and state are judged in order | the current access contract confirms that this judgement is currently distributed |
| SYS-F01-R02 | in an administrator delegation the real actor and the applied subject are distinguished, and the validity of both is confirmed | |
| SYS-F01-R03 | a settings change distinguishes the current value, the proposed value, the applied value, the revision, and the read-back |
An action authority is not confirmed by a menu exposure or a numeric role ID alone. CLIENT_ID is a compatibility identifier and not a target public contract.
4.3 Master Data Requirements¶
| ID | Requirement | The current basis and the difference |
|---|---|---|
| SYS-F02-R01 | a company or Party, an item, a UOM, a place, and an equipment reference are managed per semantic owner | |
| SYS-F02-R02 | a snapshot such as the name, the unit price, and the unit at the time of a trade is not retroactively changed by a master data change | |
| SYS-F02-R03 | a Port, a Terminal, a Warehouse, a Yard Location, and a Dock are not arbitrarily merged into one place lifecycle |
the master data source comparisonconfirms T_COMPANY, T_COMPANY_EMAIL, T_COMMODITY, T_MASTER, and the distributed place and UOM boundaries. A UOM conversion and a rounding are not inferred until an approved rule exists.
4.4 Trade And Inbound And Outbound Requirements¶
| ID | Requirement | The current basis and the difference |
|---|---|---|
| SYS-F03-R01 | the quantity, UOM, unit price, currency, and counterparty of a Purchase or Sales Agreement and its line are recorded as a commercial intent | |
| SYS-F03-R02 | when an execution exists the agreement type and line change and the deletion are restricted, and the exact source is preserved | |
| SYS-F04-R01 | a Fulfillment execution order explicitly references a source such as an Agreement, a Service, or a Booking, and a save alone does not create a Receipt or an Allocation | |
| SYS-F04-R02 | the plan, the actual result, the correction, and the follow-up inventory and transport effect of an inbound or outbound execution are distinguished |
What Booking.SALES_ORDER_ID points to is the outbound SALES execution T_LOAD and not a Commercial Agreement. The term distinction of the commercial and service source comparison is kept.
4.5 Field Work And Weighing Requirements¶
| ID | Requirement | The current basis and the difference |
|---|---|---|
| SYS-F05-R01 | the Transload plan, work assignment, field start and completion, Office confirmation, and the correction and Undo are recorded as different facts from each other | |
| SYS-F05-R02 | a work record commit and the follow-up effect of a message, a file, and a provider are judged and recovered separately | |
| SYS-F05-R03 | an Appointment, a Loading Plan, and an Assignment each preserve their own save result and applied target, and saving a plan is not interpreted as an assignment acceptance or a work start | |
| SYS-F05-R04 | Check-in, Staging, Dock-in, Cancel Dock-in, Dock-in After Clear, and No Show are handled as separate commands that verify the current state and the Yard and Warehouse occupancy | |
| SYS-F05-R05 | a work start claims the equipment and the location that match the Transload or Unload type, updates the planner and the work time evidence, and returns the authoritative Transload | |
| SYS-F05-R06 | a work completion verifies the required evidence per type and finalises the result, the equipment and location, the planner, and the work time as the same work result, while judging the inventory and provider results independently | |
| SYS-F05-R07 | an Undo performs only the reversal allowed at the current step, and compensates only the named items among the already created equipment load, warehouse placement, Yard occupancy, planner, and time evidence | |
| SYS-F05-R08 | Spare, Leftover, Domestic Pickup, Scale Ticket, and Document Submitted are handled as their own commands and results, not as a general Transload update | |
| SYS-F05-R09 | when a mutation response is lost or a follow-up effect fails, the Transload, planner, equipment and load, location, time, and file and effect authority is re-queried, and only the unconfirmed unit is resumed | |
| SYS-F05-R10 | C1 is described on the basis of the Legacy Loader-centred flow, and C2 compares the Office and common path of the reference and New-System, but a physical Transload is not forced on a non-physical area | |
| SYS-F06-R01 | a Scale preserves the gross, tare, and net, the per-axle reading, the UOM and precision, the device and manual provenance, and the operator, the time, and the place | |
| SYS-F06-R02 | a weighing completion, correction, or void does not automatically complete or reverse a Receipt, the Inventory, the Delivery, or the Settlement | |
| SYS-F06-R03 | a Scale Ticket creation verifies the Fulfillment Order UUID, the direction, and the commodity of the tenant, and stores the first GROSS or TARE stage and a unique ticket identity | |
| SYS-F06-R04 | each stage preserves the steering, drive, rear, fourth, and fifth axle reading and the measured time, and a repeat request of the same value is handled idempotently | |
| SYS-F06-R05 | a Ticket where both stages are recorded provides an accepted weight evidence only when the finite and non-negative, gross>tare, and positive net conditions are satisfied | |
| SYS-F06-R06 | a change to the same stage before completion requires a reason, a reweigh after completion is not allowed as a normal stage record, and an explicit correction path with a before and after lineage is used | |
| SYS-F06-R07 | the discard of a FIRST_STAGE Ticket is a Void, and the discard of a COMPLETE Ticket is a Reversal, and the expected lifecycle, the reason, and the current snapshot are verified | |
| SYS-F06-R08 | when a downstream Transload, a finalized Inventory Lot and Ledger, and an Equipment and Delivery execution exist, the Ticket reversal is blocked | |
| SYS-F06-R09 | on a lost response or a conflict, the exact Ticket and the correction or reversal event are re-queried first, and a consuming area is judged in a separate authority | |
| SYS-F06-R10 | the conditional and core Scale flow of C1, and the Office-centred conditional Receipt and Outbound flow of C2, are distinguished by a policy in the same owner |
The acceptance boundary of SYS-F05 is as follows. The plan save, the assignment, the start, the field completion, the Office confirmation, the inventory reflection, and the provider delivery must each be observed. A Transloading completion needs the final equipment, 5 TRANSLOAD photos, a valid bale result, the seal, and the quantity, and an Unloading completion needs an active warehouse location and the purchase lot and placement follow-up result. An Undo and a No Show must confirm the allowed scope per current state and the owner read-back.
The acceptance of SYS-F06 observes the ticket identity, the first and second stage, the axle readings and the total and net, the correction lineage, the void and reversal, and the downstream no change separately. Storing a Scale Ticket or readyForReceipt is not a Receipt finalisation. The detail basis is in Operations and Scale. The precision and rounding and the UOM conversion, the device, manual, and offline authority, and the whole role policy are unresolved.
4.6 Inventory And Warehouse Requirements¶
| ID | Requirement | The current basis and the difference |
|---|---|---|
| SYS-F07-R01 | a Receipt uses an approved source, a quantity or weight, and weighing evidence to make a Lot, a ledger and provenance, and a read-back | |
| SYS-F07-R02 | a lot identity, the current remaining quantity, the Placement, the Allocation, and the Cost Layer are managed as independent facts | |
| SYS-F07-R03 | an Allocation records the relationship with the target execution line and the source lot, blocks an over-allocation, and allows a partial allocation | |
| SYS-F07-R04 | a correction, a reversal, and an unknown result re-query the exact Lot, Placement, Ledger, and Allocation, and resume only a missing owner command | |
| SYS-F07-R05 | a Receipt is finalised only by an explicit command that verifies an approved source Order and item, the remaining quantity, the Scale and no-scale policy, and the warehouse condition | |
| SYS-F07-R06 | a Receipt and Lot and Ledger commit is distinguished from a Placement result, and when a Placement fails only the missing step is resumed with the same Receipt and Lot identity | |
| SYS-F07-R07 | a lot identity, REMAIN_QUANTITY, REMAIN_NET_WEIGHT, the status, the ownership and custody, the location, and the rate snapshot are preserved as separate meanings |
|
| SYS-F07-R08 | an Allocation verifies an existing target execution line and an active source lot, records the target item and relation, and conditionally deducts the remaining balance | |
| SYS-F07-R09 | an Allocation and Receipt reversal verifies each UUID, the follow-up execution, the ledger, and the Container result, and recovers a repeat of the same intent with an exact read-back | |
| SYS-F07-R10 | the C1 custody and owner-party flow, and the C2 tenant-owned stock flow, are distinguished by the source and policy of a shared Inventory owner |
Receipt, Lot, and Placement and the Allocationpreserves the current differences of
The acceptance of SYS-F07 must read the Receipt, the lot identity, the Ledger, the Placement, the balance, the Allocation relation, the target item, and the follow-up Container separately. On a partial completion or a lost response, an already committed identity is reused, and an inventory reversal is not interpreted as an automatic cancellation of a Packing, Invoice, Billing, or Settlement.
4.7 Transport, Equipment, And Yard Requirements¶
| ID | Requirement | The current basis and the difference |
|---|---|---|
| SYS-F08-R01 | an Ocean Booking, an outbound execution order, a Delivery, a Yard move, an Equipment state, a Container return, and a provider notification are tracked independently | |
| SYS-F08-R02 | the internal transport distinguishes a dispatch, a Driver and Vehicle, an arrival, and a completion evidence, and the external transport distinguishes a carrier reference, a milestone, and a proof | |
| SYS-F09-R01 | a Yard queue plan, claim, and completion is distinguished from the real Yard occupancy, and the real spot read-back is preserved | |
| SYS-F09-R02 | a Container and Chassis assignment, a Yard state, a loading, a departure, and a Port return are tracked as independent lifecycles |
the transport, Yard, and equipment source comparisonkeeps the current C1 and C2 differences and the partial-result risk.
4.8 Documents, Billing, And Settlement Requirements¶
| ID | Requirement | The current basis and the difference |
|---|---|---|
| SYS-F10-R01 | a BOL, Packing, Booking, Weight Ticket, and Invoice are previewed and rendered with an approved source revision and template | |
| SYS-F10-R02 | the file metadata, the object store and deletion, the document issuance, and the provider transmission result are recorded and recovered separately | |
| SYS-F11-R01 | a Service Charge, a Purchase and Sales Settlement, a Landed Cost, and a Trade Margin are distinguished, and the calculation source is traced | |
| SYS-F11-R02 | the amount, currency, precision, rounding, finalisation snapshot, and the correction and cancellation are specified |
A document preview amount is not interpreted as a settlement finalisation or an accounting posting. An external dispatch and a payment are also separate effects.
5. Applying The Per-Client Work Basis¶
| Area | The Client 1 technical specification basis | The Client 2 technical specification basis |
|---|---|---|
| Administration and master data | the Legacy user, menu, company, item, and place structure and the real work use | the reference material and the tenant, role, and master contract of the New-System |
| Trade and inbound and outbound | the Legacy service job, load, and delivery relationship is preserved as the original means | the separation of the reference Purchase and Sales and the New-System Agreement and Fulfillment |
| Field work, weighing, and inventory | the Legacy Transload, Scale, inbound, Lot, location, and allocation flow | the warehouse and trade flow of the reference and each semantic owner of the New-System |
| Transport, equipment, and yard | the Legacy internal dispatch, driver and vehicle, and yard and equipment flow | the Booking and external carrier flow of the reference and the Booking and Delivery owner of the New-System |
| Documents and settlement | the Legacy service document and billing basis and the real output | the trade document and AP and AR basis of the reference and the preview and source difference of the New-System |
Even when the terms of the two Clients are the same, they are not assumed to be the same state or data owner. A common requirement is promoted to an approved Product contract only after the two bases are compared.
6. Non-Functional Requirements And Constraints¶
Security covers the tenant isolation, the authority, and the protection of sensitive information, reliability covers an unconfirmed result recovery and a source tracing, maintainability covers a single owner and a change impact tracking, and usability covers a consistent input, error, recovery, and accessibility. The numbers of a performance goal such as p95 and throughput, an availability, a retention period, and RPO and RTO are not fixed in this draft. A number is not put in without a basis, and the relevant environment and the measurement and work decision are recorded in a later section.
7. Area Authoring Items And The Change Linkage¶
Each functional requirement has an ID, a purpose, an actor, a precondition, an input, a normal result, an exception and forbidden condition, a per-Client basis, an acceptance criterion, and an open item. When one area is added, the needed design, data, interface, state, screen, and test are linked in RTM. Authoring a specification is not an instruction that automatically starts a feature fix or a real data test.
8. Requirement Detail Card And Change Review¶
| Field | Authoring criteria |
|---|---|
| ID, title, state, and priority | a functional, a non-functional, and a work rule are distinguished, and the baseline state is stated |
| the actor, the purpose, and the scope | the role, the tenant, the start condition, and the included and excluded result |
| the input and the normal result | the type, unit, and source, and an observable screen, API, or data result |
| the alternate, error, and forbidden result | the authority, the boundary value, a conflict, a duplicate, a partial success, and a recovery |
| the acceptance criterion | a Given/When/Then or an equivalent verdict condition, and the related test case |
| the basis and the traceability | the C1 and C2 source, and the design, field, interface, screen, test, and evidence links |
| An open item and a change impact | a TBD, a TBR, or an assumption, the owner and decision condition, and the affected ID |
The review checks the atomicity, the verifiability, an ambiguous number or term, a hidden external effect, and a mixed Client basis. The change history leaves the related ID, the reason, the impact, and the re-verification state, and does not express an unapproved value as a fixed requirement.¶
Source:
new-system/docs/specifications/SRS.md— ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged. A user instruction quoted inside the text is kept in its original language.