Skip to Content
chalvien 1.0 is released
DocumentationSRS DocumentationSRS ProjectDomain

Conceptual domain model

SRS as a living system.

1. Core domain concept

An SRS Workspace contains structured knowledge objects with traceability and versioning. Everything hangs off that idea.

2. High-level domains (bounded contexts)

You can mentally split the system into 6 domains:

  • Workspace & Collaboration
  • SRS Structure
  • Requirements
  • Diagrams & Models
  • Traceability & Change
  • Export & Publishing

We’ll zoom into each.

3. Core entities & relationships

3.1 Workspace

Workspace
- id
- name
- description
- standard (ISO/IEC/IEEE 29148:2018)
- createdAt

Relations:

  • has many Members
  • has many SRSVersion

One workspace = one product/system.

3.2 Member & Role

Member
- id
- userId
- role (Author | Reviewer | Viewer)

Relations:

  • belongs to Workspace
  • participates in Review

Keep roles simple at first.

4. SRS Structure (this replaces “a big document”)

4.1 SRSVersion

SRSVersion
- id
- versionTag (v1.0, v1.1)
- status (Draft | Released | Archived)
- createdAt

Relations:

  • belongs to Workspace
  • has many Sections
  • snapshots many Requirements
  • snapshots many Diagrams

Versioning is explicit and meaningful, not Git magic.

4.2 Section

Section
- id
- code (1, 1.1, 3.2.4)
- title
- description
- order

Relations:

  • belongs to SRSVersion
  • contains many Requirements
  • references many Diagrams

This maps cleanly to ISO 29148 structure.

5. Requirements domain (the heart)

5.1 Requirement

Requirement
- id
- identifier (REQ-001)
- type (Functional | NonFunctional | Constraint)
- priority (Must | Should | Could | Won't)
- status (Draft | Approved | Deprecated)
- statement
- rationale

Relations:

  • belongs to Section
  • has many AcceptanceCriteria
  • has many Links
  • has many RequirementVersion

This is an entity, not text.

5.2 AcceptanceCriterion

AcceptanceCriterion
- id
- format (Given/When/Then | Plain)
- content

Relations:

  • belongs to Requirement

5.3 RequirementVersion (important)

RequirementVersion
- id
- changeType (Created | Modified | Deprecated)
- changeNote
- createdAt

Relations:

  • belongs to Requirement
  • belongs to SRSVersion

This enables:

  • change tracking
  • impact analysis
  • clean exports per version

6. Diagrams & models

6.1 Diagram

Diagram
- id
- type (ERD | Sequence | Context)
- source (Mermaid | ImportedSchema)
- content

Relations:

  • belongs to Workspace
  • referenced by many Sections
  • linked to many Requirements

6.2 DataModel (ERD specialization)

DataModel
- id
- sourceType (Prisma | SQL | Manual)
- schemaText

Relations:

  • generates one or more Diagrams
  • contains many Entities
  • linked to many Requirements

6.3 Entity (ERD Entity)

Entity
- id
- name

Relations:

  • belongs to DataModel
  • linked to many Requirements

This is where schema → requirement traceability shines.

7. Traceability (cross-cutting, very important)

TraceLink
- id
- fromType (Requirement | Entity | Diagram)
- toType (Requirement | Entity | Diagram)
- relation (Satisfies | Impacts | DependsOn)

Relations:

  • generic polymorphic links

This lets you build traceability matrices and graphs without hard-coding relations.

8. Review & collaboration

8.1 Review

Review
- id
- status (Open | Approved | Rejected)

Relations:

  • belongs to SRSVersion
  • has many ReviewComments
  • has many Approvals

8.2 ReviewComment

ReviewComment
- id
- content
- targetType (Requirement | Section | Diagram)

8.3 Approval

Approval
- id
- decision (Approve | Reject)
- decidedAt

Relations:

  • belongs to Review
  • belongs to Member

9. Export & publishing

9.1 ExportProfile

ExportProfile
- id
- name (Academic | Client | Internal)
- format (Markdown | PDF)
- config (included sections, verbosity)

Relations:

  • belongs to Workspace

9.2 ExportArtifact

ExportArtifact
- id
- format
- generatedAt
- versionTag

Relations:

  • belongs to SRSVersion
  • uses ExportProfile

10. Visual summary (mental ERD)

Workspace
 └── SRSVersion
      ├── Section
      │    └── Requirement
      │         ├── AcceptanceCriterion
      │         └── RequirementVersion
      ├── Diagram
      ├── Review
      └── ExportArtifact

With TraceLink floating across everything.

11. Why this model works well for juniors

  • Clear ownership of concepts
  • Explicit versioning
  • No “magic document”
  • Teaches:
    • traceability
    • impact analysis
    • requirements discipline

And it maps beautifully to:

  • Prisma models
  • Postgres JSONB
  • React block-based UI
Starting PointWorkspace