In an earlier post, From MRD to PRD, we talked about the fact that there is design involved in converting from a defined opportunity into a goal for software. In this post we will look at a real world example of doing just that.
The context for our example
In part two of our post on using tags to organize automated tests, we identified several market requirements, and then decided which ones we would transform into software requirements. These then become our goals – and in this post, we will show how we can create product requirements that are designed to address the market requirements.
Recapping the market requirements
In our previous discussion, we identified five market requirements. We also decided that we only wanted to address two of those five problems within the scope of this incremental release of our automated test suite management application. These are the two market requirements we will be addressing.
- Maintaining the suite becomes too expensive. We have a market need to minimize the cost of maintaining the suite.
- Developers will stop using the suite. We need to assure that developers will continue to use the suite.
We believe that it is wrong to stop at this point and expect our implementation team to “take it from here.” Some very bright people disagree – and present good arguments that this is the right (or only) level for capturing requirements. Our approach is to capture these market requirements seperately and build product requirements from them.
We need to talk about ROI
ROI is the primary driver of this project. ROI has two components, the return, and the investment. We can’t determine what the investment will be until we decide the scope of what to do and estimate the cost of doing it. What we can do is define the potential ROI, and from that determine how much we would be willing to spend to achieve it.
If we do not do this project, we estimate that the maintenance of the test suite will take 500 hours of developer time over the course of two years – which translates to roughly 2% of the total development effort on the software being tested. This is an estimate based on previous experience with this type of testing, and the assumption that the software will change with the same frequency that it does today. We are also assuming that the test suite will be actively used throughout the period. With a goal to minimize the maintenance costs, our return will be a number smaller than this estimate.
Measuring the return for our second goal is much harder. There isn’t a quantitative way to predict the likelihood that the developers will stop using the tool. It is reasonable to assume that they would only stop using the tool if an alternative method of managing software quality were available to them. If that tool were available, it would mean that there is no additional benefit to using this tool. And if it were not available, it would mean that the probability of using it would be zero. Therefore, there is no savings associated with implementing features that support this market requirement. We’ve determined that this requirement is not a key driver of our decision making process, and we will not consider it moving forward.
Creating software product requirements
Minimizing maintenance costs is too ambiguous to be actionable. We need to break down which maintenance costs in particular we want to minimize. For this particular project, there are several details that we are glossing over about how this test automation tool works. However, we can list the main maintenance costs of maintaining the tools
- Removing obsolete scripts from the test suite.
- Updating “broken” scripts when changes to the software require that the scripts be modified.
- Maintaining the mappings between inspections and scripts (each “test” is a combination of a script and an inspection).
- Maintaining output result “goldens” that represent successful test runs. Each test run creates an output that is compared with a previously validated, or golden, output. Changes to the software being tested can introduce valid changes to the outputs.
Our current project is only addressing the first three areas of maintenance costs – a seperate project is addressing the fourth area by other means.
Our product requirements should then be written as
- Minimize time spent identifying broken and obsolete scripts.
- Minimize time spent removing obsolete scripts from the suite.
- Minimize the time spent managing the mapping of inspections to scripts.
Our next step is to look at the use cases that describe the underlying activities
One thought on “MRD to PRD Requirements Conversion”