TABLE OF CONTENTS We have identified and modeled the requirements to the system in the previous steps in Sections 2.2 through 2.5. That's the area we generally call "analysis." We now dedicate ourselves to the design of the system. This means that we describe structures and behaviors that realize the requirements we identified and determined in the analysis. [17]
We now have to deal with the issue of how the results from the analysis should be transferred into the design in a structured and reproducible way. That's the only way to ensure that all results from the analysis will be taken into account, and that changes to the requirements will be made in the right places, or changes to the design will be harmonized with the requirements.
We are only looking at the abstract solution in this book, i.e., structure and behavior descriptions, excluding concrete implementations. This means that we do not take the technical aspects, such as concrete hardware, software technologies, and so on, into account. We will add these technical aspects later on when we'll be ready to take technological decisions on the basis of the abstract solution.
The most important thing about a system is the services it offers to its environment. A system is useless without them. I've emphasized this fact over and over again in the previous sections. Accordingly, we will now have a closer look primarily at the use cases as the representatives of services, and we will realize them systematically in our...
