|
|
@@ -0,0 +1,46 @@ |
|
|
|
|
|
# Feature selection procedure |
|
|
|
|
|
|
|
|
|
|
|
## Introduction |
|
|
|
|
|
The goal of this document is to record the decisions during the feature development. |
|
|
|
|
|
To make this document more readable the following section will explain the selection procedure. |
|
|
|
|
|
|
|
|
|
|
|
## Selection procedure |
|
|
|
|
|
There are three criteria that are applied in the selection procedure. |
|
|
|
|
|
These are: dependency, test coverage and risk/time analysis. |
|
|
|
|
|
Each criterion is a hard selection. We will only select on dependencies first. |
|
|
|
|
|
If any of the features have an equal amount of dependencies then we will look which one completes more tests. |
|
|
|
|
|
And the last is a risk/time analysis. |
|
|
|
|
|
|
|
|
|
|
|
### Dependency |
|
|
|
|
|
With the dependency criteria we count the number of other features each feature depends on. |
|
|
|
|
|
The feature with the highest number of dependencies will be implemented first. |
|
|
|
|
|
|
|
|
|
|
|
This is often a design dependency. For example, the engine in a car must be able to pull the weight of the car. |
|
|
|
|
|
Therefore, we need to know the weight of the car before we can design the engine. |
|
|
|
|
|
This can be a dependency, however we rather solve this by setting the specifications correctly. |
|
|
|
|
|
That the car itself has a maximum mass of something. Therefore, the engine has to be able to pull that maximum mass. |
|
|
|
|
|
Now we solved the dependency. |
|
|
|
|
|
|
|
|
|
|
|
However, at some point, we might have to test something before we can specify the mass of the complete car. |
|
|
|
|
|
In that case, a feature that can help us define the mass of the car better should get priority as other features depend on it. |
|
|
|
|
|
|
|
|
|
|
|
### Test coverage |
|
|
|
|
|
To see how the different systems work together we have designed multiple tests. |
|
|
|
|
|
Each test that can be resolved by implementing the feature gives us more information about the system. |
|
|
|
|
|
And if tests fail early, we can change the design earlier in the design. |
|
|
|
|
|
|
|
|
|
|
|
### Risk/Time procedure |
|
|
|
|
|
If we still have multiple features that have a draw in dependency and in test coverage we can assess the risk/time factor. |
|
|
|
|
|
We want to clear the most amount of risk per time period. |
|
|
|
|
|
In practice we will clear all the high risk features which have a short implementation time. |
|
|
|
|
|
And eventually we end up with low risk long implementation time. |
|
|
|
|
|
By moving al this risk forward we can clear more risk in an early stage of the development. |
|
|
|
|
|
|
|
|
|
|
|
The time and risk factor will be given _high_, _medium_, or _low_ as factor. |
|
|
|
|
|
Where _high_ = 3, _medium_ = 2, and _low_ = 1 point. |
|
|
|
|
|
We divide the risk points by the time points and note down the factor. |
|
|
|
|
|
The feature with the highest score will be implemented first. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|