| EDUCE Overview | Copyright 2009 Nikolas S. Boyd. All rights reserved. |
Capture business elements, facts, relationships, policies, and procedures in a comprehensive domain vocabulary.
Creating useful and usable software solutions requires effective communication among solution stakeholders. So, creating a shared understanding of business policies, problems, and practices is the primary challenge facing a software development team. The degree to which all the various stakeholders share their (sometimes diverse) understandings, viewpoints, and needs affects their conceptual commonality.
The various stakeholders need to express and share many kinds of ideas, including vision, mission, values, viewpoints, interests, wants, needs, goals, conditions, situations, alternatives, options, requirements, roles, relationships, responsibilities, collaborations, events, qualities, quantities, and measures.
Without a common vocabulary and shared conceptual models of a business opportunity and its attendant problem(s), the effectiveness of a software development team and the likelihood that the developed solution will achieve its intended ends are substantially reduced (if not utterly doomed).
So, how can we ensure that business policies, problems, and practices are not merely understandable, but actually understood by all stakeholders? Discussing, capturing, crunching, and reviewing business and technical knowledge manufactures commonality between the members of a software development team and the solution stakeholders.
Use a domain vocabulary when
A comprehensive, published domain vocabulary serves as a natural repository for business domain and solution requirements knowledge. A domain vocabulary focuses on business domain elements and their relationships. Thus, a domain vocabulary will naturally focus on topical subjects and the predicates that surround those subjects, especially those predicates describing the relationships between subjects, and the associated business practices and policies.
Maintaining a domain vocabulary in an on-line repository provides an effective mechanism for sharing domain and requirements knowledge thoughout an (often distributed) organization and development team. A Wiki (with hypertext links between related topics) provides one of the more convenient and effective ways to host a domain vocabulary in an on-line repository.
While other narrative and structured descriptions will often be generated to serve solution development, the essential form of a domain vocabulary will include a list of domain elements (as nouns or noun phrases) and their attendant predicates (as verb phrases). The verb phrases are assembled from the nuclear sentences extracted from policy statements, problem descriptions, and solution usage descriptions. Consider the following list excerpted from a sample problem domain:
- drum
- contains a hazardous chemical
- has a volume capacity (quantity + unit of measure)
- drum contents
- is a hazardous chemical
- has a category (hazard type)
- has a volume (quantity + unit of measure)
- has a weight (quantity + unit of measure)
- drum identifier
- identifies a drum in the system
- drum identification label
- identifies a drum within the depot premises
- indicates the drum identifier
- indicates the drum contents, measurement(s) and hazard type
A domain vocabulary can be used to integrate viewpoints from multiple stakeholders. Stakeholders may offer complementary views of interactions with domain elements or relationships between domain elements. These complementary views help complete and stabilize the conception of those domain elements.
A domain vocabulary may highlight differences in stakeholder viewpoints and biases. It may help resolve what might otherwise become conflicts through differences of opinion (esp. those based on differences in viewpoint). Some of these apparent differences of viewpoint may indicate that there are bounded contexts within which a given concept will be construed differently.
Fortunately, software solutions are soft. Thus, such differences can often be accommodated simply by offering different solution users different views of the same underlying domain model.