Skip to content

System Requirements Specification

Jump to bottom
sergio velderrain edited this page Nov 12, 2026 · 10 revisions

System Requirements Specification

Document Control

  • System of interest: VITechnologies/projectbuddy and its governed use of operator-provided execution infrastructure.
  • Version: living system baseline; system-level verification is planned.
  • Owner: Engineering and the operator.
  • Status: requirements baseline, not a claim that every allocated software requirement is implemented or that a release is qualified. The software requirements retain their individual statuses in Requirements-Traceability-Matrix.

System Purpose

Provide a public, project-agnostic engine for provisioning LabVIEW build environments, registering runners, and executing configured SBOM reporting. The system also provides a governed path for qualifying and releasing the engine. A consumer supplies its own configuration and infrastructure; the engine is not a consumer-specific deployment.

System Scope And Boundary

The system includes ProjectBuddy's scripts, workflows, container definitions, qualification and release controls, and the lifecycle of resources created by an authorized invocation, including the planned local-model assistance boundary in SYS-REQ-029. Operators, consumer repositories, provisioner hosts, VirtualBox, guest operating systems, GitHub, LabVIEW, VIPM, Grype, Dependency-Track, and other package or source services are external actors or dependencies. A provisioned VM is a controlled resource, not proof that its host or external services are trustworthy.

In scope are Windows and Ubuntu VM provisioning, runner registration, native Windows and containerized SBOM paths, project registration, fleet observation, operator escalation, documentation governance, and the planned qualification-to-managed-release boundary. Out of scope are consumer-specific credentials and project data, a native Linux SBOM pipeline, licensed activation as an automated LabVIEW phase, direct unmanaged GitHub release writes, and capabilities not listed in the Capability-Matrix-And-Release-Boundary.

Stakeholders And Operational Context

Role Need Priority
Consumer maintainer Supply project configuration and deliberately pin the engine used by the consumer. High
Operator Provision and qualify only authorized resources with visible failures and safe recovery. High
Host administrator Provide supported host tools, capacity, credentials, and a trusted host boundary. High
Engineering Derive software behavior and tests from the system contract without embedding private infrastructure. High
Verifier Bind evidence to the candidate, invocation, VM, runner, dependencies, and cleanup. High
Release operator Prevent an unqualified or ambiguous managed release effect. High

Typical operations are: register a configured project; create and prepare a VM; perform any required human LabVIEW activation; register a runner; run a configured SBOM pipeline; observe fleet state or escalate a blocker; and, once implemented and proven, qualify a candidate through the ordered Docker/VM conveyor before managed release. Each operation has its own authorization and evidence boundary.

Assumptions

  • Operators supply valid identities, configuration, access, licensing, and capacity; those inputs are not precommitted consumer state.
  • Host administrators and root are trusted for the VM boundary. A noncooperating process using the same host identity remains in scope.
  • GitHub, host tools, guest images, and package services are external dependencies whose availability or correctness is not implied by a local test.
  • Existing manual or historical evidence applies only to its recorded candidate and environment. Missing current evidence is not a pass.

Constraints

  • Accepted ADRs remain unchanged; stronger qualification and release rules require a reviewed successor to ADR-0006.
  • Never interrupt a healthy live snapshot; a reserved numbered snapshot is not the committed current snapshot.
  • Credentials, activation values, raw captures, VM disks, saved states, and private known-hosts data are not published as qualification artifacts.
  • A FAIL or UNKNOWN qualification result blocks dependent managed effects. Direct unmanaged publication is outside that guarantee.
  • Windows guest provisioning on a Windows host and Ubuntu runner registration from a Windows host are not claimed by the selected release matrix.

System Requirements

The verification entries below identify the system-level intent. They do not upgrade the status of an allocated software test: system verification remains planned until the applicable end-to-end evidence is independently reviewed.

External Interfaces

Interface Inputs Outputs and boundary
Operator and consumer Explicit configuration, candidate/ref, VM identity values, authorization, and externally managed credentials. Plans, redacted results, escalation, and deliberately pinned consumer changes; secret values stay private.
VirtualBox hosts and guests Verified media, host tools, VM UUID, guest bootstrap and runner inputs. VM lifecycle observations, protected receipts, runner registration, and identity-bound cleanup.
GitHub Repository/workflow identity and authorized API requests. Workflow/job/runner observations and, only through a separately gated managed path, release effects.
LabVIEW, VIPM, Grype, Dependency-Track, source and package services Configured toolchain, project manifest, source checkout, and service endpoints. SBOM, scan, reporting, and run records according to the selected supported path.
Standards assurance Canonical wiki system and software specifications, traceability, architecture, and pinned assurance tool. Separate governed scan inputs and explicit quality/gate results; no silent substitution of one specification for the other.
Local Ollama daemon Explicitly approved model identity, minimized evidence, and bounded inference policy. Advisory structured results with evidence/coverage identity; no remote fallback, source execution, tool authority, or implied native-build proof.

Quality And Life-Cycle Requirements

Safety and security: unknown identities, active snapshots, missing proof, unresolved effects, and failed cleanup block dependent operations. Secrets and raw evidence remain private.

Reliability and supportability: errors are reported explicitly, ambiguous remote effects remain recoverable, and operators receive actionable escalation rather than a success-shaped fallback.

Maintainability and traceability: system requirements allocate to software requirements and verification in Requirements-Traceability-Matrix; Architecture-Packet describes the realization and unresolved choices. The wiki is the canonical authoring surface for both specifications.

Clone this wiki locally