\documentclass[../thesis.tex]{subfiles}
\begin{document}

\chapter{Analysis of Requirements} \label{requirements}

In this chapter we give a brief summary of the intended functionality of the designed energy profiler and we present a list of its formal functional and non-functional requirements. Some of the requirements were inspired by existing works~\cite{FITMT19092,FITBT23847}.

\section{Analysis of Requirements} \label{requirements-analysis}

% Formalization of goals

This work aims to design a novel energy profiler and implement in a suitable way for integration into Perun (see Chapter \ref{perun}), a performance version system. Because Perun is implemented in Python, we want to use Python as the implementation language of the profiler as well. As for profiling, we want to make use of the \emph{eBPF} technology for which the go-to language is C, so the core of the profiler will be implemented as a C shared library.

\paragraph{Energy consumption.} Energy consumption is a difficult metric to measure accurately. Complete coverage of measuring energy consumption would require for voltage monitors to be installed in every part of hardware in a system. That is practically unfeasible in most systems. The \emph{RAPL} (see Chapter \ref{existing-methods-technology-rapl}) interface is currently the best combination of accuracy and practicality for measuring energy consumption of a system. To read the energy readings provided by the \emph{RAPL} interface we will use \emph{perf\_events} which are sampled in an \emph{eBPF} program. 

\paragraph{Runtime context.} Without context, the measured energy consumption data will provide minimal informational value and thus additional \emph{execution context} needs to be provided. For this purpose we chose to use system calls. To keep track of system calls executed by a process we will use two \emph{eBPF} programs tracking the start and end of system calls. Using system calls as a context for energy consumption requires the adoption of a scoring algorithm. In Chapter \ref{existing-methods-technology-syscalls} we discuss a number of methods for utilizing syscalls in the context of energy consumption. As the scope of this work is limited, we chose to implement a much more trivial scoring algorithm.

\paragraph{Visualizations.} Since we are creating a novel energy profiler with complex results, we create will a reporting tool. The tool will be capable of creating text reports with brief summaries of the results accompanied by suitable visualizations providing a visual aid for understanding the results of the energy profiler.

\subsection{Functional Requirements} \label{requirements-functional}

A high-quality profiler needs to, in general, meet certain criteria and an energy profiler has its own set of unique requirements. We compiled a list of criteria that will guide our design process and implementation of the energy profiler.

\begin{itemize}
    \item \textbf{FR\_IU (Independent usability).} The energy profiler is usable even when used as a stand-alone solution.
    \item \textbf{FR\_PI (Perun integration).} The energy profiler is integrated into Perun and
extends its functionality as one of its collectors (see \ref{perun-architecture}).
    \item \textbf{FR\_BPF (eBPF technology).} The energy profiler leverages the \emph{eBPF} technology to implement its profiling capabilities.
    \item \textbf{FR\_RO (Runtime overhead).} The instrumentation overhead introduced by the energy profiler as minimal as possible to obtain results close to the original program performance.
    \item \textbf{FR\_PPT (Post-processing time).} The processing of raw profiled data is fast to keep the user experience as fluent as possible.
    \item \textbf{FR\_IT (Interpretation time).} The interpretation of the profiling results is made easy to allow swift iteration on the findings.
    \item \textbf{FR\_EDS (Energy domain sampling)} The core premise of an energy profiler is that it samples energy consumption.
    \item \textbf{FR\_EDC (Energy domain coverage).} Because energy can be consumed by a large number of components, the energy profiler covers as many of these components to achieve the highest possible accuracy in energy readings.
    \item \textbf{FR\_EDSR (Energy domain sampling rate).} Sampling energy readings at a higher rate can raise the quality of the results.
    \item \textbf{FR\_SCT (System call tracing).} System calls are used as providers of runtime context for the energy readings.
    \item \textbf{FR\_SCS (System call scoring).} System calls need to be put into the energy consumption context using a scoring algorithm.
    \item \textbf{FR\_RR (Result reproducibility).} The energy profiler produces the same, or at least highly similar, results across repeated profiling sessions.
    \item \textbf{FR\_NS (Noise susceptibility).} While energy readings can be affected by a high number of factors, the profiler can leverage the runtime context to minimize the impact of the noise on the precision of the readings.
    \item \textbf{FR\_VIZ (Visualization).} The energy profiler provides a tool for interpreting the generated profile data for further manual analysis.
\end{itemize}

\subsection{Non-functional Requirements}

Aside from the functional requirements, every software has additional non-functional requirements to keep the quality of the software at a reasonable level.

\begin{itemize}
    \item \textbf{NFR\_SS (Storage space).} The resulting profile data require minimal possible amount of storage as smaller files are generally faster to load and process.
    \item \textbf{NFR\_MD (Minimal dependencies).} The energy profiler uses only a bare minimum of mandatory dependencies to lower the entry barrier for new users to use the energy profiler.
    \item \textbf{NFR\_PCP (Profile Comprehensibility).} The energy profiler outputs profile data containing information about both the profiled system and the profiled process.
    \item \textbf{NFR\_RCP (Reporting Comprehensibility).} The reporting tool provides comprehensive outputs with easy-to-understand names, legible formatting and easy-to-read graphs.
    \item \textbf{NFR\_EU (Ease of use).} The energy profiler generates a single file containing all the necessary information for their interpretation. The reporting tool utilizes all this information and does not require anything else. Both tools can be parametrised but they provide sane defaults.
    \item \textbf{NFR\_RP (Results portability).} The reporting tool generates the same results regardless of the runtime environment. All the information it needs are provided by the profile data and no machine-specific info should is used.
\end{itemize}
\end{document}