You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
16 lines
2.4 KiB
16 lines
2.4 KiB
\section{Methodology}
|
|
\par While system engineering requires a model picking process, where it is used to give understanding of a system. According to \cite{sebokwiki_typesofsystems}, there are many type of models such as formal versus informal models, descriptive models, analytical Models, domain driven model, and simulation versus model. These types of models are made via a classification process based on system type. This project would be implementing \textbf{Descriptive Model} where the information can be shared and distributed among stakeholders. As mentioned in \cite{sebokwiki_typesofsystems}, "Descriptive Models: A descriptive model describes logical relationships, such as the system's whole-part relationship that defines its parts tree, the interconnection between its parts, the functions that its components perform, or the test cases that are used to verify the system requirements. Typical descriptive models may include those that describe the functional or physical architecture of a system, or the three-dimensional geometric representation of a system." The initial step is to transform the requirement set to functions. In general, functions should be described in verb form, giving it the potential to accept input and produce output. However, it meant to satisfy the requirements. Refer to Figure \ref{fig:traditional-approach} where it captures what phases needs to be completed along with System Engineering artifacts for the project.
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=0.9\linewidth]{methodlogy.png}
|
|
\caption{Traditional Approach}
|
|
\label{fig:traditional-approach}
|
|
\end{figure}
|
|
|
|
\begin{itemize}
|
|
\item Decompose: Achieved via Function Hierarchy and Functional Flow Block Diagram (FFBD).
|
|
\item Transforming: Change requirements to verb form (function). Give them capability of accepting input and producing output.
|
|
\item Allocate: Using Function-Component matrix to check if components have been fully allocated
|
|
\item Verify: With specified requirements, we use House of Quality (HoQ) to communicate with stakeholders, giving them sufficient information for system capability. Noted that requirements have to be specified and can be used for mission parameters.
|
|
\item Translate: After defining the need for stakeholders, trying to quatify the requirement as much as possible since this would be used as mission parameters.
|
|
\end{itemize}
|