\section{Conclusion and Future-work}
\par This thesis has achieved several key goals: identifying the problem, establishing system requirements, modeling system behavior and structure, and designing a component-level mock-up. Based on the requirements provided above, if the Based Station System is in acquisition phase, farmers should be able to monitor their 1000 sqrt farming area without the need of public utilities such as internet and cloud services. Farmers have this build to last for 10 years lifespan to support their irrigation activity. Although this approach can drive the system toward implementation, it is still limited by the scope of stakeholder-defined requirements. If the number of requirements exceeds 30 items, the document-based method may become insufficient to maintain full traceability.

It is also important to recognize that diagrams are inherently limited—they primarily represent behavioral and structural aspects. When components are swapped or modified, the relationships or flows between functions may be disrupted. In other words, physical part changes often require updates to the model to reflect new interactions or data paths.

There is a need for a Model-Based Systems Engineering (MBSE) approach, which provides a standardized framework for defining structure and relationships if  the number of component in Physical Architecture increase. MBSE also supports function decomposition and component allocation, just as traditional document-driven methods do. It offers additional benefits in terms of model reusability and traceability, especially when the number of stakeholders or requirements grows. In such cases, adopting SysML may be advantageous, as it encourages careful parameter definition in the early stages (black-box) model building for supporting long-term traceability and system evolution. With Back-box model, It exposes the features of the system that are visible from an external observer and hides the internal details of the design (\cite{sebokwiki_typesofsystems}).  A white-box model of a system, on the other hand, shows the internal structure and displays the behavior of the system. Utilizing the black and white box module can enhance function decomposition  since external environment is accounted and addressed how system perform in different environment.


% non AI readproof check
Although the overall framework leans toward a Waterfall-like progression, the integration of verification planning and traceability enhances the rigor and alignment with V-Model principles. However, it is important to note that actual testing and validation procedures are outside the scope of this current phase. These steps—such as test case execution, performance validation, and operational scenario walkthrough—must be carried out in the system deployment phase to confirm that the system satisfies stakeholder needs and performs reliably under field conditions. The transition to V model as extension of Waterfall development life cycle requires  extending the interaction phase between stakeholders and requirements forming as mentioned in figure \ref{fig:sikorsky-vmodel}. While the requirements are verifiable, they also have to be considered in the well defined test cases which have constraints along with it. The extension can be described in figure \ref{fig:sikorsky-vmodel}bellowed. 

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{requirement-testcase.png}
    \caption{Sikorsky’s development and verification workflow adapted from Nick Kefalas, Sikorsky Aircraft / Lockheed Martin, presented at the EASA Rotorcraft \& VTOL Symposium 2019 \cite{easa2019kefalas}.}
    \label{fig:sikorsky-vmodel}
\end{figure}

\begin{figure}
    \centering
    \includegraphics[width=0.75\linewidth]{vee-model.png}
    \caption{Left Side of the Sequential Vee Model (INCOSE 2015, adapted from Forsberg, Mooz, and Cotterman 2005, Reprinted with permission of John Wiley \& Sons Inc. All other rights are reserved by the copyright owner.}
    \label{fig:v-model}
\end{figure}

Roles and responsibilities were defined: the system engineer (the author) conducted system modeling, design, and traceability; the users—primarily farmers and homesteaders—are intended to handle installation, maintenance, and usage; and the open-source community plays an ongoing role in system support, particularly in software updates and extension modules.

Key development milestones were guided by a Systems Engineering Management Plan (SEMP). The requirements analysis phase established the functional and non-functional needs. The conceptual design phase produced FFBDs, N-Diagrams, and function allocation tables. The component architecture phase defined the physical structure and cost estimates. The verification planning phase focused on mapping requirements for future testing. However, the deployment preparation which needs to be updated, factors such as strategies and configuration management not yet considered. In addition, the actual testing, validation, and iterative refinement phases (right side of V model figure \ref{fig:v-model})are essential next steps that must be addressed in future work or a follow-up implementation project.

\begin{table}[H]
\centering
\caption{SEMP - Current Development Milestones}
\renewcommand{\arraystretch}{1.2}
\begin{tabular}{|p{0.3\textwidth}|p{0.6\textwidth}|}
\hline
\textbf{Phase} & \textbf{Deliverables} \\
\hline
Requirements Analysis & Functional and Non-Functional Requirements Documented \\
\hline
Conceptual Design & FFBDs, N-Diagrams, and Function Allocation Tables \\
\hline
Component Architecture & Component Hierarchy, Physical Flow Diagrams, and Cost Model \\
\hline
Verification Planning & Requirement Traceability Matrix and Test Preparation \\
\hline
Deployment Preparation & Configuration Table, Maintenance and Update Strategy (future work) \\
\hline
\end{tabular}
\end{table}