Add test protocol

content/analysis.tex

@@ -43,7 +43,11 @@ The steps that are introduced by \ridm are covered in more detail.
         In the initial design step, the "what has to be solved", is expanded with a solution on "how it is solved".
         To find the best solution it is important to explore the different solutions and design space.
         Often, there are many possible alternatives but they must be narrowed down to the solutions that fit within the schedule and available resources.
-        This step results in one initial design that is used in the next phase of the design.
+        The best alternative is materialized in a design document together with the system requirements.
+        To verify that the system works in line with the system requirements, a test protocol is written for the system.
+        This protocol explains how the tests are preformed and what the pass conditions are.
+        This design document is used in the next phase of the design.
+
 
 \section{Rapid Iterative Design Method}
     From this point, the design plan is based on the \ridm and not anymore on the waterfall model.
@@ -63,13 +67,18 @@ The steps that are introduced by \ridm are covered in more detail.
 \subsection{Feature Definition}
     \label{sec:featuredefinition}
     During the feature definition, the system is split into features as preparation for the rapid development cycle and the variable-detail approach.
-    The aim of the \ridm is to have short implementation cycles to have early testing feedback.
-    To achieve this, the features are as small as possible, but can still be implemented and tested individually.
+    The goal of the \ridm is to get feedback of the design as early as possible by performing short implementation cycles.
+    To achieve these short cycles, the features that are implemented in these cycles, are as small as possible. 
+    However, the features must still be implemented and tested individually during the implementation and can thus not be split indefinitely.
     Together with the definition of the features, the requirements are divided along the features as well.
+    During the initial design, a test protocol is made to evaluate the system-wide specifications.
+    For the feature requirements, tests are added to the test protocol as well.
+    These tests only require the corresponding feature to be implemented and must all pass to finish the implementation of the feature.
     The optimal strategy on splitting features and specifications is strongly dependent on the type of system.
     Therefore, the best engineering judgement of the developer the best tool available.
 
-    Sometimes features are dependent on each other, the implementation of one feature influences another.
+    In some cases it is not possible to define a feature that can be implemented and tested independently.
+    This occurs when the feature is dependent on the implementation of other features.
     This dependency can occur in specifications, where strength of one feature dictates the maximum mass of another feature.
     Such a dependency can work both ways and can be resolved by strengthening the one feature, or reduce the weight of the other feature.
     Another type of dependency is when the implementation influences other features.
@@ -77,8 +86,16 @@ The steps that are introduced by \ridm are covered in more detail.
     An example of this is a robot arm, where the type of actuation strongly influences the end-effector.
     When the robot arm approaches an item horizontally, it requires a different end-effector than approaching the item vertically.
 
+    There are two important responsibilities for the developer when the design encounters feature dependency.
+    The first one is during the definition, where the developer has to decide on how to split the system and how the dependency is stacked.
+    For the specification and the implementation dependency the developer must evaluate the optimal order of dependency.
+    The developer must arrange the dependency of the features such that the influence on the dependent feature is as small as possible.
+    In other words, if feature A can be easily adapted to the implementation of feature B, but not the other way around, the developer must go for A dependent on B.
+    The second responsibility is organizing the feature requirements.
     Due to these dependencies it is possible that the division of requirements changes, because the result of the implemented feature was not as expected.
-    This is not directly a problem, but a good administration of the requirements makes an update of the requirements easier.
+    This is not directly a problem, but a good administration of the requirements makes an update of these requirements easier. 
+
+
 
 \subsection{Feature Selection}
     \label{sec:feature_selection}
@@ -111,8 +128,9 @@ The steps that are introduced by \ridm are covered in more detail.
 
     To determine the order of implementation of features, a dependency graph and a comparison table is made.
     The dependency graph and the comparison table for a theoretic system is shown in \autoref{fig:feature_dependency} and \autoref{tab:feature_selection} respectively.
-    The comparison table has dependees column, that describe the number of features that are depending on that specific feature, and are derived from the dependency graph.
+    The comparison table has dependees column, that describes the number of features that are depending on that specific feature, and are derived from the dependency graph.
     The tests column describes the number of tests that are covered by implementing this feature.
+    These tests are defined during the initial design and the feature definition, the number represents the amount of tests that pass after implementation of the feature.
     The risk per time score for third rule is calculated by dividing the risk score with the time score.
     The goal of this score is to eliminate as much risk as possible in the least amount of time.
     It seems logic to always implement the highest risk feature first, but it is possible to finish multiple features with a lower risk in the same time period.

content/background.tex

@@ -54,10 +54,12 @@ The variable detail approach is finished when all the tests are passed and all t
 Although the \ridm does not specify the complete steps for the preparation, it does state some requirements.
 The rapid development cycle requires a list of features that can be implemented one by one.
 These features are gained by splitting the system into individual subsystems, where each subsystem can be implemented and tested individually.
+For each feature it is required to specify the feature requirements and the corresponding test protocol.
+The feature requirements are based on the system requirements and the tests are used to validate that the feature meets its requirements.
 About the order of implementation, the \ridm states that critical features should be implemented first, as these features have an increased chance of invalidating the complete design.
 Would such a feature fail, the investment loss is limited, because the development is still in an early stage.
 
-\subsection{Combination}
+\section{Combination}
 \begin{marginfigure}
     \centering
     \includegraphics[width=6cm]{graphics/design_flow.pdf}