TABLE OF CONTENTS Why have an architecture? This is a very valid and important question, not least because the Unified Process, on which this book is based, is said (among other things) to be architecture-centric. Let us consider what role requirements (and in this case use cases) have. They help to identify what the system should do; that is, its functionality. They do not state anything about how that functionality should be provided. In some cases non-functional requirements may also be identified which may impose restrictions on the realization of the system, but even these say very little about how the system should be structured or designed.
However, many people have taken the requirements of a system (i.e. its required functionality) and used them as their sole starting point in producing a design and implementation of a software system. In some cases this has been successful, and in many others it has not been so successful. Indeed, in software engineering this is exactly the series of steps that are advocated in many development methods. That is, find out what the system should do and then implement it. This may well be acceptable if this is the nth time that you have produced such a system; however, if this is the first time you have produced a system to these requirements (and the system is large) it is likely to be fraught with danger.
Consider the equivalent case within the domain...
