The HVT Analysis Approach
In my career it took me some time to understand and be convinced of the importance of doing analysis. I still remember my first job experience, I just wanted to quickly write some code and refactor it n-times to get better results. Did not you?
Things are different today and I am writing this post to share with you my personal approach to analysis. It is not something new, it is just my tailored method based on experience and well known methodologies.
In general you get as input a problem domain (the observed system with all the entities and rules involved) and must produce as output a solution domain (the designed system that solve the original analysis problem). So a good start is to:
- Get a clear view of the problematic to solve,
- Reduce the problem domain to a minimum knowledge space
If I should quickly define Analysis I would say that it is about finding details, categorizing knowledge and solving problems. The HVT approach is made of three steps:
- Horizontal Analysis (Layers)
- Vertical Analysis (Integration)
- Transverse Analysis (Influences)
To briefly describe the method I will use examples; those will be based on a quite common case study, that is building an house. In this case study our goal is to identify all the necessary requirements that are needed by an architect to design the building.
Phase 1: The Horizontal Analysis
Horizontally we search for common aspects, grouping them in named Layers with minimal coupling between them (and ideally no cyclic dependencies). The scope is to detect all the functional requirements and have a good vision of their functional context and boundaries. In our example we could define the following layers:
- Geography: The ground has to be solid; It must be far from floods; Must be close to green areas; Must be close to schools; …
- Infrastructure: Has to be connected to electricity and water provider; Has to be connected to city sewers; Must have a very fast internet connection; …
- Technology: Most devices must be remotely controllable; Doors have to open with a human recognition technology; Must produce solar electricity; …
- Security & Ergonomics: A modern alarm system has to be installed; Interior design has to be safe for babies; It must be accessible for old people; …
Phase 2: The Vertical Analysis
Vertically we study Integration. Integration means putting things to work together; If things are intrinsically interoperable then integration efforts will be minimized. And this is our scope.
For this step we choose profiles and we do analysis by formulating integration questions. In our example:
- Adult: Will an adult have easily access to all the necessary devices? Does furniture fits well for him? Is the kitchen comfortable?…
- Baby: Are stairs well protected? Will he have enough space to play? Is the chosen floor easy to clean?…
- Apartment: Does the apartment easily access infrastructure services? Does it has an homogeneous design? Does it has enough light? …
A negative answer probably means a loop back in previous phase to make some adaptations to increase interoperability.
Phase 3: The Transverse Analysis
The last step is the more complicated, and not always needed. Its purpose is to study the indirect influences of different layers spanning between different profiles.
As for phase 2 we do it by analyzing the ongoing model and formulating questions. In our example some questions could be:
- Will the WI-FI required by an adult be dangerous for a baby? Maybe it will be better to have less signal power in his sleeping room.
- Will be an adult able to sleep when his child is playing an electric guitar? Maybe the child room should be acoustically isolated.
This process is sometime difficult to solve, because it will surely bring you to find conflicts between profiles that sometime do not want to (or simply cannot) renounce to their needs.
Conclusion
Even if the study case was very simple I hope you get an idea of what it means to move it to more complex domains. For example in Software Architecture clients are stakeholders, needs are functional and non functional requirements, profiles are applications or components, and an indirect influence can be a compatibility matrix of the used technologies. It is not easy to explain this approach in few lines, there are thousand of words I missed so if you have questions or any advice do not hesitate to leave your comment and share it.
Reference: | The HVT Analysis Approach from our JCG partner Marco Di Stefano at the Refactoring Ideas blog. |