From "How to Write a Technical Paper: Structure and Style of the Epitome of your Research":

Solution

You should begin this section by providing an overview of
your solution. Give a good explanation of its rationale,
concepts and mechanisms. If your solution relies on a
theorem or some other undocumented concept, make sure
that you explain them before you carry on to the detailed
description.
The main part of this section is the thorough description of the solution and its functionality. The description
should not contain arguments on correctness or design decision debates; simply, describe the mechanisms of your
solution and avoid explanations of the "why so" type.
Dedicate a separate paragraph or two on the latter, if
you deem necessary.
Disassemble your solution to its functional components
and explain them separately. For example, if you describe
a distributed algorithm, explain the protocol-specific part
(message format, etc.) separately from the semantics and
decision-making part of the algorithm.
It is both important and useful to provide figures
demonstrating the functionality of your solution. Make
the figures look similar to the system model figure, if applicable, and exploit the similarities and differences to
point out important aspects of your solution.

Analysis

Analysis can be of two types: qualitative and quantitative.
The former means to show some properties (qualities)
of your solution, while the latter means to show some
performance aspects of your solution.
Qualitative analysis is usually proof of correctness,
however it could be proof that the solution possesses some
desired property. For algorithms or protocols, a proof of
correctness is always welcome.
Quantitative analysis is mostly performance analysis.
It is important to explain what performance metric you
use and why you have selected the specific metric. Choosing a metric that has been widely used will make the
comparison to other solutions easier.

Let's include any numbers we can measure: number of test runs, computing hours spent testing, number of states encountered and what percentage of the theoretical state space that is, lines of spec code, lines of implementation code in MongoDB.