Semantic Elicitation - Where to Look

Semantic Elicitation—Where to Look

Where do semantics come from? We've found the quest for meaning in business systems to be one part archaeology and two parts anthropology. In other words, we've found that some of the sources of semantics can be found in documentation and existing data, but a great deal of the meaning in systems comes from direct interaction with users and analysts. This chapter outlines practices and approaches that we have found useful from over a decade of structured observations.

Elicit

To bring or draw out (something latent); educe. To arrive at (a truth, for example) by logic.

The primary sources of clues as to the current and potential semantics of a given can be found in the following:

• Users

• Requirements documents

• Existing systems

• Existing electronic data

• Existing paper data

• Industry literature and trade associations

• Regulations

Users

Assuming there are users of a current system that is going to be replaced or upgraded, these users are good sources for information about the meaning of things in and related to the system. Within the community of users are often stakeholders and sponsors, and this process of elicitation also introduces them to the new system.

Humans are great at interpreting meaning. They can make distinctions interactively, and they can deal with the large parts of the system that are either not dealt with by the existing system or are dealt with in a nonsemantic way (e.g., in comment fields).

Requirements Documents

Most projects have requirements documents. There may still be one around from when the existing system was implemented. Generally, two or three are prepared for various approvals and false starts of the project. These documents are rich with semantics. Often they were written by the end users or their business analysts, and as such express their needs in their own language. Often they are imprecise, unrealistic, or not of much help to someone trying to design the system. You will probably be expected to summarize much of what you find into a requirements document, but that process is not part of the discovery process.

Existing Systems

The existing system is a validated expression of the semantics as currently understood, often called the "operational semantic" of the system. It isn't perfect, or there wouldn't be a project to replace it, but we have to keep in mind that the existing system can prove or disprove many assertions we might make about the semantics of the system. For example, we may wonder if a product can be in more than one category. Conduct an experiment using the current system. If it is not allowed, you may ask if this is a problem for users. If it is allowed, you might check to see if it is ever done.

Keep in mind that people have organized what they know about the domain of the business system structurally and terminologically from what they know of the current system.

Existing Electronic Data

The data in databases is a great clue to how people are really using the system. We will discuss data profiling, as a tool for finding meaning in existing databases, later in this chapter. For now, consider it a great source for clues about meaning.

Existing Paper Data

The "paperless office" is about as rare as the "paperless toilet." Despite, or perhaps because of, the great explosion of systems, we have more paper than ever. Two things are of interest to us:

• What paper is retained—The mere fact that people hang on to certain pieces of paper and throw away others is significant in itself. Check filing systems, as well as "piling" systems.

• What annotations are made on the paper—One of the main reasons people hang onto paper is because of the notes and marks they have made on it. Some of this is the data that is currently "outside" the system, and some of it places importance on the data that is in the system.

Industry Literature

Each company shares far more than they would like to admit with the characteristics of the industry they belong to. Any information you can glean from the industry trade association provides a good backdrop and potential challenge to the limited information from the company itself.

One source is literature on industry packages. The package developer has attempted to abstract as much of the differences between companies out of the package, while at the same time including as much industry-standard semantics (this is typically where software readers win points in the checkliststyle evaluations). Other sources include white papers on issues in the industry or for the application area.

Perhaps the most fertile source is the ever-growing body of industry consortia standards for extensible markup language (XML). This effort involves numerous industry representatives coming together to agree on what terms mean precisely. Two good sources for XML standards are the Cover Pages^[50] and O'Reilly's XML site.^[51]

Regulations

Some systems more than others are driven by the need to comply with regulation (payroll and financial systems, material safety, workplace safety, etc.). Getting these regulations and extracting the semantics from them (a sometimes daunting but valuable exercise) can yield another great source of information.

The reason for doing this is due to the fact that features of a system often are justified based on some regulation. But on close study we find that the regulation prescribes a particular requirement, which has been historically implemented such that the regulation becomes synonymous with the requirement.

^[50]See http://www.oasis-open.org/cover/sgml-xml.html for further information.

^[51]See http://www.xml.com/ for further information.