TABLE OF CONTENTS The aim of the analysis discipline is to analyze the requirements identified in the use case analysis (the requirements discipline) and to structure them in terms of the internals of the system. That is, the requirements are converted from the external users view into "what the system needs to do to support the user's requirements". This does not mean how the system will do it, merely what it must do. For example, users may be unaware that they have an internal profile which specifies what they can and cannot do; however, an internal requirement on the system might be to check the user's actions against the user's profile.
The intention is that this will provide a better understanding and a more maintainable form for the (internal effects of) the requirements. The issue here is that the requirements (as described in the use case model) are in the language of the customer, not the language of the developer. The analysis discipline therefore attempts to move the requirements into the language of the developer and to identify what the key elements/concepts/entities of the system will need to be in order to support the user's requirements. In particular, the analysis discipline aims to identify the important entities in the system. These entities are likely to form important aspects in the architecture. They may become classes, collections of classes, or even subsystems within the final design.
The analysis model is thus expressed in terms of analysis classes, packages and collaborations.
