semantic – In Search Of

Semantic Collision

Posted on December 27, 2012Leave a comment

Sometimes when you talk about application software, you find that the technicians and the customer are agreeing but don’t realize it. This happens when each party says something that is essentially the same semantically, but they don’t derive the same meaning from it. I have been in that situation many times, because of misunderstandings of the domain semantics or ambiguities in domain semantics.

Other times you have the opposite effect, where the technicians and the customer appear to be in agreement, but have different understandings of the problem or solution, so while all are smiling and nodding – there will be some time when, subsequently, they all realize that they missed something.

One of the reasons that these kinds of miscommunication happen is when the same term has meaning in multiple domains, and different people assume that they know which domain is in play without qualifying or clarifying it. These collisions, where a term has meaning in multiple distinct domains that are relevant in a conversation are sometimes very hard to detect. It feels like a wormhole opened in the conversation and we jumped from one domain to another without realizing it.Continue Reading

Semantic Overloading

Posted on December 21, 2012Leave a comment

I spend a lot of time with software developers. Most of the time I spend is clarifying semantics between business domain and technical domain. Semantics have to do with the meanings of words or terms. In the business domain, when semantics are ambiguous it is often context that allows us to clarify. I work hard to clarify terms that users posit to describe the entities and operations we are modeling in the software we use.

When words are “overloaded” it is hard to avoid being confused because we use the same word to describe multiple distinct entities or operations or operational states. Much of the overloading occurs because “qualifiers” are embedded in business context, so to the business staff, the qualifiers are unnecessary.

Sometimes, though business people actually use the same word differently in the same context and you end up with a buffalo.Continue Reading

Inaugural Curation Post…

Posted on September 30, 2011Leave a comment

This week I am making good on my intent to post some of what I’ve been reading and found valuable.

agile42 | Feature Injection Applied to Service Delivery

I spent a bit of time reading about Feature Injection as a different way (than other agile processes) at dealing with requirements. I really am intrigued, and will try to adjust my requirements practice to include these concepts.

Do You Suffer From Decision Fatigue?

This also was interesting – as it clearly reflects what we all experience – decisions take mental energy, and making decisions when mentally tired is sub-optimal. One could infer from this how to re-arrange one’s schedule to make better decisions, or to be less mentally tired when decisions are needful.

Time to ditch “The Backlog” « The IT Risk Manager

This also was provocative – not because having a backlog is a bad thing, but because how we name things allows others to infer things from the connotative meaning in that naming.

Calamity howlers & positively selecting with surprise « Freckle Time Tracking

A “calamity howler” (CH) is a persistently negative individual who predicts rack & ruin, frequently and at the top of his voice. It’s a great term that was especially popular in political writings back in the mid-to-late 1800′s but has since fell out of disuse. — who is the CH on your current project or in your current team.

Semantic Clarity

Posted on March 19, 2011Leave a comment

One of the most difficult aspects of gathering and documenting software requirements is to get all of your stakeholders and project team participants to agree on terminology, especially words commonly used in the business domain. Common usage is never very precise, and often business problems arise from ambiguities in common usage. In developing a conceptual model of the business domain, it is necessary to define key metaphors very precisely, to remove these ambiguities, and allow software to implement logic that is correct.

There are two key types of metaphor ambiguities: semantic diversity and multiple identity.

Semantic Diversity – when a key metaphor has different properties in different contexts. This presents itself as a word that means different things in different aspects of the domain.

Multiple identity – when multiple metaphors actually share the same meaning or identity. This presents as different words that are used in different aspects of the domain to mean the exact same thing.

There is one other pattern that we see, which is called contextual revelation. Contextual revelation is when a metaphor presents different attributes in different aspects of the domain. In this case, it is the same metaphor, but different information is relevant to different parts of the business process. This often presents itself as if we have different metaphors, that have a mandatory one to one relationship with each other.

In some business domains, certain aspects appear optional, in that not all aspects are in play for every situation. In this case, the contextual revelation pattern may present as the metaphor having behavioral variants. In this case, one way of disambiguation is to derive the Behavior Taxonomy. Simply put, this can be accomplished by determining the simple list of behavioral variants that are needed to support the business process, and mapping the driver attribute(s) used in determining which behavior is selected.