plemented?" This is normally the stage when the team grows and individual 25.2.1 Requirements capture and analysis groups are assigned subsystems to complete without necessarily having a complete knowledge of the systems as a whole. This stage identifies the requirements for the final software in terms Depending on the design method adopted, this stage may be split of the user's needs. It answers the question "what does the user into two: really want?" It may take the form of a user writing a document which is then analysed and clarified by the software team, or a set 1. High Level Design which specifies the architecture of the of recorded interviews, or a special team consisting of a customer system in terms of which facilities are in hardware and which representative and a software expert may generate the list of re- are in software; what software programs will be provided and 25/4 Software systems in telecommunications the interfaces between them; which programs will run on which 25.2.6 System testing processor; and so on. Detailed Design which provides the detailed architecture of This is the final set of tests on the complete system to be run by the each program in terms of the functions how and when they are software team. The tests should be set up to be repeatable, and as called, the implementation data model, and the detailed beha- automated as possible. The tests defined should be against the initial viour of the system. requirements specification and should aim to show that all require- ments have been satisfied. If the user has provided acceptance tests Depending on the quality of the work in this phase, the resulting then these should be run during this stage as part of system testing system will be resilient to change with many reusable components. to ensure that: If this stage is not completed properly the resultant software will tend to contain a large number of bugs often arising from unnecess- There are no remaining misunderstandings between the user ary cross dependencies in the software; in th