This article is incomplete; it will be constantly in editing mode.
The 'Solution' is very similar to the conventional Requirement Analysis. For their most important goal is to pronounce the purpose and the functionals of the project. Yet, there is a subtle difference between two. I prefer the 'Solution' term to the requirement because the former sounds more focused on the coherent principal that combine the many pieces of the requirements.
The weakness in the term of requirement is that they tend to fragmentized into the incoherent pieces; sometimes one requirement conflicts with another one. Usually customers are known to be incompetent in giving their own requirements to the developers. There's a profession who work as mediator between customers and developers; their sole job is to inspire the customer so that they can come up with better requirements. By the nature of customers, any requirements can be thrown at the project schedule any time.
The 'Solution', in fact, is based on this requirement analysis at any level of completedness. The 'Solution' will start with as many requirements as currently available to the designer at the time. The main goal of 'Solution' is the designers' overall direction toward how they resolve the given problem. Here you don't need patterns or classes; you only need the high level statement that explains your plan for the 'Solution'. Therefore, 'Solution' is the better fit to the Agile; though the 'Solution' is also viewed as the supplemental perspective that helps the requirement analysis.
For example, the company A needs a inventory projection system for their products, and they will provide the formula to forecast the future target inventory based on the historical sales data. Your goal is to implement the system for the comapny A. Now you just proclaim your solution to this business problem, or requirement. The 'Solution' will take the historical sales data of a single product or multiple products, and it processes the data based on the logic that implements the forecast formula that Company A provided with. Finally, the solution will display the forecast to the users of the system.
That is solution at my best in the beginning; someone can put better solution. After this proclamation, you will decompose your statement into multiple chapters as the development goes on. Usually there is an organic ties within the statement of the 'Solution'.
The forms of the organic ties would be the sequential flow of logic or events or the conditional factors that fork several chunks of the sub divisions. From this 'Solution' statement, you can make sub-solutions to cover the details of small problems--the questions raised from interpreting the 'Solution' statement.
We are going to need to veryfy this 'Solution' as we do for classes by Unit Test Tool. That is why we need to talk about the Acceptance Test Tool, Fitnesse.