This document is split up into three main sections.
The first part follows the standard documentation introduction which we use for all of our documentation it aims to give context to the document, it includes:
The second parts aims to give background information on documentation at the EPFL Rocket Team it aims to answer:
The third and final part lists all of the documents types which we aim to prepare along with:
There are four main reasons for which we write documentation: internal knowledge transfer, reviews, standardising engineering processes (design, verification, manufacturing, ...), project overview and trace of work done.
Due to the fact that we are a student association and none of our team members are contractually obligated to stay for the entirety of a project we have high personnel turnover rates compared to companies. Our turnover rates are even higher than previous projects at the EPFL rocket team because our project is 2 years long instead of the normal 1 year and because we want our project to be the foundation for the upcoming rockets which will lead us to our goal of reaching the karman line.
In order to decrease the amount of time it takes somebody new to understand our project and to standardise the information which everybody has about the project, we plan on using technical documentation as a way of transferring knowledge.
In order to try and maximise the amount of useful feedback we can get, we are trying to be as transparent as possible and document most of what we are doing in order to give the reviewer whether that is a stakeholder, team leader or system engineer the most amount of information possible.
Documentation templates allow the project managers and system engineers to set requirements on the engineering process, documentation templates can be seen as a checklist of what needs to be done in order to arrive to the final project. By requiring something to be documented that thing must first be done, for example for Design Justification Files when we asks the engineers to document the method they used make a choice on which design was worth further exploring, it forces each engineer to think about a valid way of picking a design, or in the Software Design Document by asking how the real time constraints are handled, it gives the software engineer a list of constraints to think about and allows the engineer to double check that each constraint has been thought through. Another example, the Design Justification File loosely follows the the early design process we are trying which is start of by doing a state of the art and understanding the key principles of the system you are trying to design, explore the possible designs, establish a way of picking a design, choose a design, find main advantages and disadvantages of a given design iterate to minimise disadvantages.
Documentation allows the project managers and systems engineers to gain insight in to the state of the project, documentation serves as a ways of tracing requirements, filling out the verification control document and checking the technology readiness level of each assembly. Helps project managers to reallocate resources in order to insure proper project completion.
Finally documentation allows the engineers to have a trace of what they have worked on, the documentation can be included in their portfolios which hopefully should help students when trying to get employed.
There are three main target audience types:
All of our documentation is now written and stored on a self-hosted wiki using Wiki.js. Previously, we used Google Docs for writing and stored our documentation on Google Drive. However, starting in 2021, we gradually transitioned to our current setup. The main advantages of our current configuration are:
New types of documents are normally added to the documentation for two different reasons. Either we are working on something and realise that the work we are doing is not included in the scope of one the existing documents or because we realise that something we are doing is not up to our desired standard. Either way we normally look into what the industry standard is by reading ECSS standards and handbooks and find a document which fits our needs, from there we define the document's Documentation Requirements and Definition document, template (and example if need be).
(Although it would have been nice/better to have decided all of the types of documents which should be written during the planning phase of the project. We are learning about project management and system engineering during the project which means we implement new types of documents during the project.)
The process has changed quite a bit since the beginning of the project but at the moment the procedure is:
For the moment all procedure documents are stuctured in the same way:
The manufacturing, assembly and operations procedures templates have been tailored in order to fit the nominal pre-conditions but feel free to add/modify the pre-conditions and post conditions.
One document per mechanical assembly, one document per electronics board and one document per sub-system.
The DDF is a document which establishes the system or product characteristics such as lower level technical specifications, design and interface description, drawings, electrical schematics, specified constraints (e.g. on materials, manufacturing, processes, and logistic).
One document per mechanical assembly, one document per electronics board and one document per sub-system.
The objective of the design justification file (DJF) is to present the rationale for the selection of the design solution.
One document per assembly and one document per sub-system is to be prepared.
The goal of the documentation management plan is to explain how documents are managed, how documentation is prepared, how documentation status is tracked, who is responsible for which tasks in regards to documentation preparation and reviewing.
One document per project.
The design requirement justification document gives all of the information relating to a requirement. The DRJ contains the requirement's: ID, title, description, source, justification, criticality, verification method, trace graph, verification status.
One document per requirement is to be prepared.
The DRL is a list of all of the requirements relating to a particular system or sub-system.
One document per sub-system and one document for the entire system is to be prepared.
The FEA SR is a document which describes simulations performed on a given design using the Finite Element Method. Its goal is to allow others to understand the simulation process and choices in order to validate the simulation results.
One document per analysis which serves as a requirement validation via analysis.
Enumerates all of the interfaces and talks about the the interface management plan.
One document per project is to be prepared.
The Verification Plan contains the overall verification approach, the model philosophy, the product matrix, the verification strategies for the requirements (the interrelation between different methods/levels/stages of verification to be used to demonstrate status of compliance to requirements), the test, inspection, analysis and review-of-design programme with the relevant activity sheets and planning, the verification tools, the verification control methodology, the involved documentation, the verification management and organization.
One document per project.
Our LLIM documents are equivalent to ECSS' Interface Control Documets (ICD)
One document per pare of sub-systems which interface with each other is to be prepared.
For the moment all procedure documents are stuctured in the same way:
The manufacturing, assembly and operations procedures templates have been tailored in order to fit the nominal pre-conditions but feel free to add/modify the pre-conditions and post conditions.
One document per mechanical assembly.
The objective of the mission description document (MDD) is to provide input for the later selection of the best concept meeting the mission statement (MS) in iteration with the preparation of the preliminary design requirements list (DRL)
One document per project is to be prepared.
For the moment all procedure documents are stuctured in the same way:
The manufacturing, assembly and operations procedures templates have been tailored in order to fit the nominal pre-conditions but feel free to add/modify the pre-conditions and post conditions.
One document per sub-system.
The objective of the system engineering plan (SEP) is to define the approach, methods, procedures, resources and organization to co-ordinate and manage all technical activities necessary to specify, design, verify, operate and maintain a system or product in conformance with the customer’s requirements. In particular the SEP is established to fulfil the major technical project objectives, taking into account the defined project phases and milestones.
One document per project is to be prepared.
The software design document provides description of the software architectural design and the software detailed design. Internal interfaces design is also included in this document. It is equivalent to a DDF per for software.
One document per software package.
The software user manual's purpose is to provide instructions for the users of a software.
One document per software which is to be operated.
Solidworks 2D drawing, electrical schematics, etc.
One Technical Drawing per SRAD part.
One document per type of document.
Document which reports what happened during a test and what are the results (filled out during a test).
One document per requirement(s) verification test.
Document which describes which test(s) need to be performed to verify a given requirement and the test by step directions on how to perform the test(s).
One document per requirement(s) verification test.