The Analysis Phase

 

 

Table 2.1: The Analysis Phase: What does the system do?

Phase	Deliverable
Analysis	$\bullet$ Requirements Document
	$\bullet$ Domain Ontology
	- Things
	- Actions
	- States
	$\bullet$ Typical Scenarios
	$\bullet$ Atypical Scenarios

 

The analysis phase   defines the requirements of the system, independent of how these requirements will be accomplished. This phase defines the problem that the customer is trying to solve. The deliverable result at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is to be built. This analysis represents the ``what'' phase. The requirement document tries to capture the requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details. The analysis phase   is summarized in Table 2.1 on page .

The requirement document may be expressed in a formal language based on mathematical logic. Traditionally, the requirement document is written in English or another written language.

The requirement document does not specify the architectural or implementation details, but specifies information at the higher level of description. The problem statement, the customer'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 the requirement document. This is the exception and should not be the rule. These exceptions occur for many reasons including maintaining the consistency with other established systems, availability of particular options, customer's demands, and to establish, at the requirement level, a particular architecture vision. 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 the usage of some accepted computer industry standard, or a constraint on the image size of the application.

There is a fundamental conflict between high levels and low levels of detail. The requirement document states what the system should accomplish, independent of many of the details. The discovery process used in establishing the requirements during the analysis phase is best described as a refinement process than as a levels-of-detail process [#!Clements85!#].

Top-down and bottom-up approaches force a greater distinction between high levels and low levels of detail. Interactive approaches lead to the refinement of those details.

Traditionally, the requirement document describes the things in the system and the actions that can be done on these things. Things might be expressed as objects in an object-based technology where data and algorithms are hidden behind hierarchical-polymorphic methods. ^2.1 Alternatively, things might be expressed as services accessing databases in a functional approach where data is a fundamentally different concept than functions. In general, the description of things in the system can be 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 defining the application specific protocol.

The requirement descriptions of the things in the system and their actions does not imply an architecture design rather a description of the artifacts of the system and how they behave, from the customer's perspective. Later, in the design phase, these requirement descriptions are mapped into computer science based primitives, such as lists, stacks, trees, graphs, algorithms, and data structures.

The description of the abstraction of the noun phrases and the verb phrases are not bound to the use of a written human language. Most written human languages are too vague to capture the precision necessary to build a system. Alternative descriptive mechanisms based on mathematical logic are sometimes more suitable but much more difficult to accomplish. Mathematical logic provides a scientific foundation for precisely expressing information. However, frequently in the real world, a precise description is not attainable.

Again the requirement document should state in a clear and precise fashion what is to be built. The definitive mechanism to author such a document, either formally or informally, has yet to be developed, although reasonable success has been achieved with existing methods including CASE tools and tools based on mathematical logic. See [#!ZCoom91!#], [#!Brown94!#], and [#!Rader93!#].

Later, in the design phase, the very important decomposition of the problem leads to the development of data structures and algorithms. A functional decomposition for a distributed environment leads to a natural split of the data structures and algorithms. Examples include distributed client-server systems, where a database holds the data in a server while the algorithms manipulating the data reside on the client. An object-based decomposition leads to a natural joining of data structures and algorithms forming objects with methods. The requirement documents should be independent of the decomposition technique.

The analysis team develops the requirement document, which talks about things and actions on things. This document should also include states, events,   typical scenarios   of usage, and atypical scenarios of usage. The definitions of things, actions, states, typical scenarios, and atypical scenarios follow this section. More detailed examples of a requirement document can be found later in this thesis. See Appendix E on page for an example requirement document.