.: Methodology

.: Problem Domain

Definition of the problem domain is a key early step in the development process. As in every other part of the development process there is ample opportunity for unwarranted assumptions, inconsistent interpretations of terms and concepts, and insufficient detail in descriptions of business entities.

It is especially easy to miss the boat here, because most stakeholders are likely to assume they have a good understanding of the problem domain and feel that developers are strangely thick-headed as they insist on detailed and precise definitions of domain terminology and concepts.

Anyone who has been through this process knows, however, that human communication and manual practices successfully and almost invisibly tolerate inconsistencies and all sorts of “special” circumstances. These subtleties in the problem domain must be seen and understood before one attempts to create software in support of these business practices.

The following elements of the description of the problem domain are maintained throughout the development process. It is especially important, however, to take them as far as possible at the very beginning of a project.

Domain vocabulary. This is essentially a glossary of all terms and concepts relevant to the project. All definitions should be precise and complete. They should include a reference to the source(s) of the information and the date on which they information was obtained. Modifications, clarifications, questions and answers should also be separately noted, along with source and date information.
This document serves a number of purposes.

First, the very act of creating precise, agreed-upon definitions brings into the open many subtleties of the problem domain, leading stakeholders and team members to a deeper understanding of both the requirements and the opportunities inherent in the project.

Second, it creates stability and reliability in project communication. A business vocabulary consists of many interrelated, dependent terms. A common understanding of the nuances of one concept usually has implications for related concepts. Without clear, time-referenced documentation of each term, a dependable understanding of the problem domain will not exist. It’s worth mentioning that stakeholders and team members are often not aware that a common understanding has not been achieved.

Finally, the domain vocabulary serves as a kind of intellectual contract between stakeholders and developers throughout the entire project. As database entities, the object model, and outputs of the system become more distinct, the domain vocabulary remains a point of reference by which the validity of each system element can be judged.
Object model. A side effect of creating the problem domain vocabulary is the ease with which an initial set of business objects can be identified. Our documentation of the object model initially describes these objects at a fairly high level, indicating their purpose and a preliminary list of services which each object will perform. It also shows the relationship of these objects in terms of usage and hierarchy. Later, during the design phase, this document is supplemented with a more detailed description of object properties, behaviors and relationships.
Database definition. Closely related to the domain vocabulary and object model is the specification of the database. This document, too, begins at a fairly high level, simply identifying database entities, and their relationship to domain concepts and business objects. As the project unfolds, especially during the external and functional design phases, the database definition becomes extremely precise, with exact definitions for each data element, specification of data types, permitted values and ranges and other constraints, entity relationships, and initial recommendations regarding indexing.

Discovery / Requirements