ervices a telecom system offers to it users. Software control opened up for the enormous functional complexity of the telecom systems of today, where just the service control functionality comprises many millions of lines of source code. Five years after my friend's remark, I had another encounter with the AXE system, which turned his challenge into my almost passionate determination to do some- thing about the problem. I am sharing the result of this determination with you through this book. At that time I received an assignment to specify and find a way to implement a new service feature in the existing AXE system. Since I had almost no knowledge about the system, I had to start from the top, learning everything I needed to solve the problem through the system documentation. This, on the other hand, seemed feasible in a reasonably short time, since AXE was at that time documented by an impressive number of documents, very systematically structured into sets of bind- ers (in the range of 500) that described the overall system, its subsystems, its blocks and the implementation units (software source code, hardware schematics, etc.). In the next few weeks my mood turned from impressed to frustrated. To make a long story short, I give you my findings in summary: Top level system documentation was too abstract to help me in understanding how to find a solution. By comparing this documentation with documents on the block level and below, it was also obvious that no one had bothered to update the Preface documents in some years. Thus, they were unreliable and, at the most, of some value to very initial training of AXE engineers. Block descriptions were supposed to constitute the specifications of software and hardware units. It did not take long to reveal that they were flow-chart descriptions of (mainly) software units, produced after implementation. Thus, they did not tell me what a block did, but how the block was constructed. Since block descriptions were also not always up-to-date, the only way to find out how to