Version 1.0
Prepared by Aerodos12
Tridentu Group
Monday January 26th, 2026
| Name | Date | Reason For Changes | Version |
|---|---|---|---|
➥ Briefly summarize the SRS’s purpose, product scope, intended audience, and how the document is organized. Do not include details here; reference the relevant sections instead.
This document is meant for detailing and explaining the style and requirements for building a proper Tridentu 2 ISO-based system. The TRLIS standard will cover both the installed system and the ISO version as well. This document is ALWAYS meant for anyone (developers, engineers and end-users) to read and eventually understand.
The TRidentu Live ISO Specification (or TRLIS) is a set of rules (a.k.a style guide, like PEP 8) that details how the Tridentu ISO is to be built as well as how its contents are to be installed/managed. This specification/style guide is meant for engineers/developers (for Contributions) and end-users (to understand their system at a deeper level).
Tridentu 2 (via TRLIS) uses a “release-code” system that defines 3 MAJOR components:
Tridentu 2 is mainly a Linux distro with influences from other systems (such as BSD) considered. The CT version is ALWAYS the baseline, so most of those critical standards found in that will be listed here. anything with K or G as the first letter (except in GT) are usually desktop environments. Anything after that defines capabilities by purpose (i.e. KG would support gaming and come with WINE pre-installed). The goal of all this is to standardize and streamline a new ISO production pipeline that allows for flexible upgrades/releases.
💡 Tips:
| Term | Definition |
|---|---|
| API | Application Programming Interface - A set of definitions and protocols for building and integrating application software |
| BTRFS | B-TRee FS - A filesystem that a modern, copy-on-write (CoW) filesystem for Linux designed for advanced storage, high capacity, and data integrity. |
| CT | Console Terminal - A variant of Tridentu 2 (1.5+) that only uses the Linux console. It is also the smallest variant to be commissioned for creation/official use. |
| DE | Desktop Environment - A complete graphical interface (GUI) that provides a user-friendly way to interact with an operating system. |
| SRS | Software Requirements Specification - A document that describes the intended purpose, requirements, and nature of a software |
| TR2RC | TRidentu 2 Release Code - a 3-part set of letters and numbers that define the UI environment, purpose and/or version of the distro |
| TRLIS | TRidentu 2 Live ISO Specification - A set of rules and standards that keep Tridentu 2’s development from stalling |
| UI | User Interface - The visual part of computer application through which a user interacts with a software |
| WINE | WINE - A Windows Emulation layer that only comes on Gaming-based variants of Tridentu 2. |
➥ Cite standards, contracts, policies, interface specs, UX style guides, use-case docs, architectural decisions, or a vision/scope document. For each reference, include title, author/owner, version, date, and location/URL. Indicate whether each reference is normative (binding) or informative (guidance).
Most References will be listed below from this document. The reason for that is due to the fact that the standards come directly from here. Anything else will have a page linked to it.
The following references are normative:
Tridentu 2 was created mainly to learn about how Linux systems such as Fedora, Arch, Debian and Gentoo are built/created. as a result, this system follows most if not all instructions to the letter in Linux From Scratch.
Tridentu 2 as a Linux distribution provides the following:
Each constraint is coded by C followed by a number. It is also prefixed with “TRLIS”. All constraints below (unless otherwise stated) are BOTH INTERNAL AND EXTERNAL.
/usr/lib64, /usr/libx32 and /opt/lib MUST be included in every Tridentu 2 variant/derivative. This is (for compatibility reasons) MANDATORY .💬 Defines the user groups and the attributes that affect requirements.
There are mainly 3 types of Tridentu 2 users that are intended.
This user cares about two main things:
Accuracy implies that the College Student wants to turn in assignments properly, with integiry AND on time. The main reason why Chrony is used instead of systemd-timesyncd is to prevent issues where timezone differences may interfere (cush as submitting an assignment to a professor).
Productivity is obvious - the College student wants to be able to use Tridentu 2 (or ANY distro following the Tridentu 2 Philosophy) in a way that can help them learn and succeed in school.
This user cares about development of programs. They want to ensure that they can plan and even jump into coding almost immediately. To cater to this specific user, the Tridentu 2 distro comes with various development tools and languages builtin to the system when installed. One of those is GCC.
💬 External assumed factors or conditions, as opposed to known facts, that the project relies on.
➥ List assumptions about environment, hardware, usage patterns, third-party components/services, and organizational support. List dependencies on external systems, libraries, or teams. For each, indicate potential impact if proven false.
💡 Tips:
💬 Allocation of requirements across components or increments.
➥ Map major requirements to subsystems, services, or releases/iterations. Use a cross-reference table to show allocation and to clearly identify deferred requirements.
💡 Tips:
💬 This section specifies verifiable requirements of the software product to enable design and testing.
➥ State requirements to a level of detail sufficient for design and verification. Use unique identifiers, consistent keywords (shall/should/may), and clear conditions. Describe inputs, processing in response, and outputs where applicable. Reference the relevant 2.3 Product Constraints that the requirement addresses.
📃 Template (applies to all requirements):
- ID: REQ-FUNC-001
- Title: Short title, representative of the requirement...
- Statement: The system shall...
- Rationale: ...
- Acceptance Criteria: ...
- Verification Method: Test | Analysis | Inspection | Demonstration | Other
- More Information: Additional context. Links to related artifacts.
| Verification Method: Inspection | Demonstration |
| Verification Method: Inspection | Demonstration |
Requirement ID schema and traceability:
💡 Tips:
💬 Specifies all external inputs and outputs, covering both required and provided interfaces.
➥ Provide interface definitions sufficient for implementation and test.
💡 Tips:
💬 Describes how users interact with the system at a logical level.
➥ Define UI elements, flows, and standards to be followed (style guides, accessibility guidelines). Include layout constraints, common controls (e.g., help, search), keyboard shortcuts, error/empty-state behavior, and localization. Keep visual designs in a separate UI specification and reference them.
💡 Tips:
💬 Details interactions with physical devices and platforms.
➥ Specify (un)supported device types, data/control signals, electrical or mechanical characteristics if relevant, and communication protocols. Include timing, throughput, and reliability expectations.
💡 Tips:
💬 Defines integrations with other software components and services.
➥ List connected systems (name and version), required or provided services/APIs, data items/messages exchanged, communication styles/protocols, and limit/error/timeout semantics. Identify shared data and ownership.
💡 Tips:
💬 Specifies the externally observable behaviors and functions the software shall provide.
➥ Organize functional requirements by feature, use case, or service. For each, describe triggers/inputs, processing/logic (at a black-box level), outputs, and error conditions. For AI behaviors, define determinism bounds (e.g., temperature), refusal criteria, safety rules, and human review points.
💡 Tips:
💬 Quality attributes that constrain or qualify functional behavior.
➥ Use specific metrics, ranges, and conditions.
💡 Tips:
💬 Response time, throughput, and resource usage expectations.
➥ Specify timing relationships, peak/steady-state loads, and performance targets under expected conditions. Include measurement methods, environments, and acceptance thresholds. Note any real-time constraints.
💡 Tips:
💬 Defines the protection of data, identities, and operations.
➥ Define authentication, authorization, data protection (in transit/at rest), auditing, and privacy requirements. Address abuse/misuse and external attacks (e.g., injection, data exfiltration, or service compromise), and include secure defaults and incident response requirements.
💡 Tips:
📝 Note: Place generic security controls here (3.3.2), and cross-reference from supported controls as necessary:
💬 Ability to consistently perform as specified.
➥ Specify reliability metrics and techniques (e.g., MTBF, error budgets, retry/backoff, idempotency, redundancy). Define conditions under which reliability is assessed and any failover behaviors. Define graceful degradation (e.g., fallback components, cached results, AI/ML deterministic heuristics), timeout/abstain policies, and rollback to previous versions.
💬 System uptime and readiness to deliver service.
➥ Define availability targets, maintenance windows, and mechanisms like checkpointing, recovery, and restart. Include geographical/zone redundancy if applicable.
💡 Tips:
💬 Ability to understand system state and behavior in production through telemetry.
➥ Define requirements for logs, metrics, traces, and profiling: events/fields, cardinality limits, sampling, retention, and privacy/PII handling in telemetry. Specify standard labels (e.g., service, version, tenant), correlation/trace IDs propagation, and redaction policies. State SLO-aligned alert rules, dashboards, and ownership.
💡 Tips:
💬 Requirements derived to satisfy external standards, regulations, or contracts.
➥ Specify mandated formats, naming conventions, accounting procedures, provider/user rights and agreements, licensing agreements, audit tracing, records retention, and reporting. For each compliance item, reference 2.3 Product Constraints if applicable, or cite the authoritative source directly.
💬 Constraints or mandates affecting how the solution is designed, deployed, and maintained.
💬 Ensures the software runs smoothly in its target environments.
➥ Define (un)supported platforms/environments, prerequisites, installation methods, environment configuration (e.g., env vars, secrets), and rollback/uninstall procedures.
💡 Tips:
💬 Defines the controls for building, packaging, and delivering software artifacts to ensure integrity, traceability, and reproducibility.
➥ Define how source code is transformed into deployable artifacts and moved through environments. Describe expectations for build reproducibility, dependency management, licensing, configuration management, artifact verification, and release promotion.
💡 Tips:
💬 Addresses geographically or organizationally distributed deployments, data, and devices.
➥ Specify deployment topologies, component and data distribution/replication approaches and scale-out runbooks, and constraints imposed by organizational or network structure.
💬 Attributes that make the software easier to modify, fix, and evolve.
➥ Define expectations for modularity, code complexity, interfaces, coding standards, developer oriented observability, documentation, software delivery performance, and technical debt management.
💬 Encourages leveraging components across products or contexts when appropriate.
➥ Identify components intended for reuse and any constraints on their dependencies or technology choices. Specify modularization, API stability, packaging, and documentation to enable reuse.
💬 Ability to run on multiple platforms or environments with minimal changes.
➥ Specify (un)supported operating systems, hardware architectures, cloud providers, or container runtimes. Define abstraction layers, configuration policies, and externalization of environment-specific settings.
💬 Financial considerations or cost targets.
➥ State budgetary limits, cost-per-transaction targets, licensing constraints, or cloud spend envelopes that influence design decisions.
💡 Tips:
💬 Schedule expectations that affect scope and prioritization.
➥ Specify key milestones, delivery dates, or phases/increments. Indicate dependencies between milestones and required readiness criteria.
💡 Tips:
💬 Validates feasibility and de-risks critical assumptions before full-scale delivery.
➥ Define the objectives, scope, success criteria, and timebox for any POCs. Describe what will be validated (technical, usability, performance) and how results will influence requirements or design.
💡 Tips:
💬 Controls how changes are introduced and communicated.
➥ Define change categories (breaking, additive, bugfix), approval workflow, and required artifacts (changelogs, evaluation summaries, migration guides, release notes). Specify backward/forward compatibility guarantees, client communication plans, deprecation timelines, and rollout/rollback procedures.
💬 Describes how each requirement will be verified to provide objective evidence of compliance.
➥ Outline verification methods (test, canary metrics, analysis, inspection, demonstration) and test evidence preferably in a matrix paralleling Section 3. Consider adding environment details, tools, and test data requirements.
| Requirement ID | Verification Method | Test/Artifact Link | Status | Evidence |
|---|---|---|---|---|
| REQ-FUNC-001 | test | tests/UC01.md | Passed | reports/tuc01.html |
| REQ-SEC-003 | analysis | threat-model.md | WIP |
💡 Tips:
💬 Optional supporting material that aids understanding without being normative.
➥ Include glossaries, data dictionaries, models/diagrams, sample datasets, or change-impact analyses that support the main sections. Reference rather than duplicate content when possible.
💡 Tips: