Here’s an interesting little challenge I’ve been presented with:
- Imagine someone has found they have two computer systems which do very similar things (how they got into that situation is too long a story to relate here)
- They would like to rationalise this into one system (for the obvious economic reasons)
- Let’s say they assume that they want to keep “System B”, because it seems to have more function
- However they want to understand what they might lose (or have to redevelop) by moving from “System A” to “System B”.
- Neither “System A” nor “System B” have formally documented requirements, but both have long lists of Features (should that be “Feechurs”?)
- Of course, because the systems were created independently, the terminology they use is different.
- And of course the assessment has to be done quickly!
The outline of the method I’ve come up with is:
- Develop a simple model that can be used to describe both systems
- Use the components of the model the classify the high-level features of “System A” (the system we expect to remove)
- Ask the question “why do we have this feature?” this gives us a “Reason or Purpose” (which becomes a proxy Requirement). System1-Feature –> Reason-or-Purpose
- For the Reason-or-Purpose, ask the question “what feature in System 2 addresses this need?”
- This should identify the equivalent features, and any gaps (efficiently?), providing the list of Features is reasonably complete
- Which will then identify whether the move is a good idea and what changes are needed.
It’s still going to be an interesting problem.