How often do You Encounter so called "Frame Problem" while Describing an App. Domain?

Question

Have you experienced such stress in a real-world task and how did you get rid of it?

I hope that my question is OK, otherwise feel free to close it.

Answer 1

My understanding of the "Frame Problem" is that it relates to the removing the need to state implicit assumptions about the way the world works. In the example given here Moving an object doesn't change its colour, painting an object doesn't move it. "Obvious" to those familiar with the real world, but tedious to write down such assumptions. [And then we move an object into the paintpot, and lo! Its colour changed.]

I would say that the problem of agreeing what is "obvious" is endemic to every requirements gathering exercise. The Business person does not tell of a special case, because it is obvious that ... they are not even aware of it being a special case.

Hence our job as producers of software is to get into that Frame of Reference, to really understand the problem domain. And it's tough. I would say that improperly understood requirements are a very serious problem for a high proportion of projects. Great analysts are very good at teasing out the detail.

Answer 2

My thinking about the App. domain is "framed" by the term "data modeling".

Data modeling encourages viewing the problem domain from a data centered frame. I'm a big fan of looking at things data centrically, but it's important to understand the limitations of such an approach.

The problem domain consists not only of data, but also of actions on that data. Put another way, it consists of both state and behavior. In classical database design projects, data and actions get split at the requirements gathering level.

The data analysis results in a conceptual model of the data (often expressed in the form of an ER diagram and/or model). The actions analysis results in a functional spec for the App. or collection of Apps. that are going to use the data.

Logical design of the apps and the data often proceed separately. The logical design of the apps. often uses object oriented design, which frames things in a certain way. The logical design of the database often uses the relational model of data, which frames things in a very different way.

Later, when it comes time to implement, the programmers are faced with the "object-relational impedance mismatch". Much has been written about this. One way to look at this mismatch is that two different frames have been applied to the requirements as a whole.

The above just scratches the surface of your question, but it's a start.