The analysis phase
is summarized in
Table 
on page .
[IMAGE ]
Table: Summary of Analysis Phase
The analysis phase deals with the requirements of the system, independent of how these requirements will be accomplished. This phase defines the problem that the end user is trying to solve. The deliverable at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is being built. This analysis represents the ``what'' phase. The requirement document tries to capture the requirements from the end user prospective by defining goals and interactions at a level removed from the implementation details.
The requirement document may be expressed in a formal language based on mathematical logic. Traditionally, the requirement document is written in English or another spoken human language.
The requirement document does not specify the architectural nor implementation details but specifies information at the higher level of description. The problem statement, the end user's expectations, and the criteria for success are examples of high level descriptions. There is a fuzzy line between high level descriptions and low level details. Sometimes, if an exact engineering detail needs to be specified, this detail will also appear in this document. This is the exception and not the rule. An example of a low level detail that might appear in the requirement document is the usage of a particular vendor's product line or a constraint on the RAM image size of the application.
There is a fundamental conflict between high and low levels of details. The requirement document states what the system should accomplish independent of levels of details. Refinement of the specification might be a better analogy then levels of details [PCW85].
Top-down and bottom-up approaches force more of the distinction of high and low levels details. Interactive approaches lead to refinement of details.
Traditionally the requirement document describes the things in the system and the actions that can be done on these things. A thing might be an object but is much more general and not confined to a particular technology. In a more general sense, this document describes the ontology, that is the noun phrases and the verb phrases that will become the guidelines for the defining application specific protocol.
The description of the abstraction of the noun phrases and the verb phrases are not bound to using a spoken human language. Most spoken human languages are two vague to capture the precision necessary. Alternative descriptive mechanism based on mathematical logic are sometimes more suited.
Recall that the requirement document states in a clear and precise fashion what is being built. The definitive mechanism to author such a document, either formal or informal, has yet to be developed though reasonable success has been accomplished with existing methods including CASE tools, tools based on mathematical logic, and tools based on writing using a spoken human language.
The decomposition of the problem is very important leading to the development of data structures and algorithms. Some decompositions in some environments lead to a natural split of the data structures and algorithms. Examples include the distributed client-server systems where a database holds the data at a server while the algorithms to manipulate the data reside on the client. In some decompositions in some environments a natural joining of data structures and algorithms occur forming objects with methods. In either case the requirement documents should be similar.
The analysis team delivers the requirement document which talks about things and action on things. This document should also include states and changes to states, typical scenarios of usage, as well as atypical scenarios. More detailed examples of a requirement document can be found later in this thesis.
![[IMAGE ]](img3.gif){kind=link}