Functional Specification Document Definition and Template

Introduction

A functional Specification details the functional requirements of a machine, or module. Within OSE, a machine is recognized as a collection of modules. This document will keep track of a synopsis of the core functional requirements of the base project, and any replications. This is intended as a living document to be updated during the project process.

The goal of a functional specification is to have a base place that defines and organizes a project throughout its life-cycle. In the example of the 3D printer project, this document would detail the core Requirements of the final 3D printer project. If requirements do evolve, they should be versioned. This happens in R&D projects naturally as the team finds though research what is feasiable and unfeasiable. Any replication or branch should show what Version of FS requirements it is addressing. then, though replications, one can see how the R&D process reflects evolving sub-projects to address that need in various ways.

So, you would see the base requirements followed by the initial scrutiny of the Prusa printers. You'd have DS docuemnt branches with those printers and all those modules. The, you would eventually see a breach with a Machine DS that uses the Universal Axis DS

Functional requirements

Functional requirements are a translation of OSE Specifications - which apply to all machines - into a more specific and focused requirement.

Such as:

• "All modules of this machine are OSE derived products and can be produced in the ecology"
• "Prints a variety of materials (list materials)"
• "Can print at X rate"

There is No Uniform Compiler

It should be noted that any build can be considered a fork - unless ALL of the build is ABSOLUTELY IDENTICAL. This is by direct analogy to software. When a software is run, it is compiled to the same product in all cases. In hardware, there is no uniform compiler. The 'compiler' includes tools, skills, supply chain, and other aspects of the production process. An identical supply chain is not guaranteed - parts may be different. All in all - it is very unlikely that 2 builds will be identical - unless they are produced in a specific production run at a specific production facility under tight quality control.

Applied to the AI Apocalypse, this means that it will be extremely difficult for AI to seize all of the hardware productive capacity of the planet - in a controllable, energy-efficient, maintainable way. Meaning that the human stewards of AI will gravitate away from AI Apocalypse towards a more collaborative (between humans and machines) solution.

Branches and Replications History

--This section should read like a history of each replication and branch from the core FS

[Branch Name] [Quick header describing how different i.e. 12" PVC D3D]

Reason for Branching

Why was the project taken in this direction? how does this branch address an R&D need detailed in the FS requirements?

Design Synopsis

Here, you should see a list of parts of a module or what modules are going into a machine in the machine case.

[Branch Name2] [Quick header describing how different i.e. 12" PVC D3D]

Reason for Branching 2

Why was the project taken in this direction? how does this branch address an R&D need detailed in the FS requirements?

Design Synopsis

Here, you should see a list of parts of a module or what modules are going into a machine in the machine case.

Links to builds of this DS (FORKS)

And so on...