Analysis beyond UML

In spite of being a de facto standard for analysis and design, UML has some obvious shortcomings: the UML definition is at best semi-formal, the set of result types is far too large and heterogeneous, the tool-support is not satisfactory. If this is true how do people get on with UML? How do they use it in their every day work? At sd&m (a medium size software company in Munich, Germany) we conducted a study of best practices. The study was restricted to analysis; we considered neither requirements specification (gathering requirements) nor design issues. The aim of the study was to answer the following questions: what does a typical analysis documentation contain? Which parts of UML are really used? What kinds of non-UML documentation is used? We identified 17 modules a typical analysis documentation consists of. These are briefly described.