Systems engineering as a documentation-driven learning process

Systems Engineering Documentation

When a scientist is developing a new pharmaceutical, an inventor is creating an alternative to an existing product, and a researcher is determining an easier method to develop a chemical process, they continually take notes or document each of their actions. This significantly reduces the amount of errors when others repeat the work to move ahead in the process and allows for the exact specifications to be copied when successful results are achieved.

Systems engineering follows this same pattern. In fact, documentation is an essential aspect, because of the creation of new designs and end products that meet the identified need of the customer. In Systems Engineering and Analysis, Benjamin Blanchard explains the importance of documentation as a design aid. Throughout the systems design process, which starts on a theoretical plane with an idea and evolves into a more specific set of steps and procedures, engineers often use documentation from other models and end products to build or enhance their own work.

No one wants, or should have, to reinvent the wheel. They would rather take the knowledge gained by others to make improvements or alternative concepts with the additional learning they have acquired. Systems engineers, then, often use previous documentation to decide on a design approach, select the necessary component piece, and decide on the reliability and effectiveness of an item.

Design documentation can be divided into two categories, notes Blanchard. The first, design standards documentation, is when the engineers use manuals that cover preferred component parts and supplier data, mathematical and statistical tables, stress-strength tables, and engineering drawing practices.

Design criteria documentation is applied to cover areas including reliability, maintainability, human factors and safety. In this case, documentation refers to design features such as accessibility, diagnostic and testing provisions, packaging and mounting techniques, interchangeability, controls and panel display methods, human performance capabilities, reliability and safety characteristics.

When systems are developed, there is a great deal of data accumulated and paperwork generated. It is not surprising to have hundreds and even thousands of pages of documentation for a system such as a computer-human interface. Different forms of documentation are helpful to different aspects of systems engineering. For example, designers and developers often use operational-need and operational-concept information to get a thorough understanding of the identified need and what purpose it will serve. It helps clarify why certain decisions are made to limit misunderstandings.

Lists of system requirements clarify the exact goals that designs must meet and are used for the final criteria to be tested and evaluated at the end product. It especially helps to determine why one design is used over another one. At the very least, system documentation helps keep everyone on the same page (pun intended), hopefully minimizing inconsistencies and ambiguities between different people working on the same project.

Once the product is developed, the same documentation can be used by managers to determine if the project can be successfully repeated in the future, by operators who will be implementing the design to build the product and by individuals who are responsible for the safety and maintenance of the product.