I am an advocate of the Sandwich method since, of course, I am its inventor (btw, a possible name for this method could be Ruben's Sandwich.) I have used this method in several occasions and taught it to several organizations. The following three experiences provide a flavor of what you can expect from doing domain analysis using this method.
My first experience in applying this method was for the domain of command and control systems. My employer at the time was interested in reducing development costs and improving quality by reusing parts from their legacy systems. I was assigned to work with a veteran expert with 17 plus years of experience in developing C2 systems. We decided to focus on three operational systems that were well documented. Requirements documents were made available to us, however, we did not have access to source code. C2 systems are highly classified.
We began bottom-up by inspecting selected samples from the massive requirements specifications. We did a preliminary vocabulary analysis and were able to separate mechanized from manual activities. This separation helped us to properly scope the domain and draw a domain boundary. Human driven activities such as decision making, information review, comparing courses of action, etc. were considered outside the domain. We also found a high incidence of activities related to message processing. This finding gave us a clue to pay close attention to the role of message processing in C2 systems.
Next, we attempted a top-down analysis. We began by comparing the architectures of the three systems and could not find any similarity; each architecture looked completely different. One of the reasons, as explained by the expert, was that the designs of these systems were hardware-driven, that is, the equipment was selected first and the requirements drafted to accommodate the hardware. Software was, in most cases, considered the glue that makes systems work. We stepped back from this approach and reviewed basic principles and theory of C2 systems. We then went back to the architectures and were able to recognize common patterns.
After several iterations and consultations with other experts, we were able to propose a high-level generic architecture, common not only to all three systems, but, to future systems as well. We went back to our bottom-up analysis and did a vocabulary analysis on the data manipulated by C2 systems. We discovered that all data that flows through the system could be formatted in a small set of standard templates. We went back to the architecture postulated during initial top-down and refined it to accommodate for standard (i.e., template) processing of messages. Here we were fully engaged in a sandwich process.
The new re-structuring of the architecture allowed us to discover yet another interesting characteristic of our architecture- almost every subsystem of a C2 system can be represented as a specialized message processor. We then proposed a generic architecture for message processors and demonstrated that a C2 system could be build by assembling different instantiations of message processors. Needless to say, our work was initially received with skepticism, however, as the idea of being able to build C2 systems out of leggo-like parts sank in, the engineers bought into it completely.
This effort took us six months working half time, a total of 3 MM. The following two cases are short experiments on trying to teach domain analysis hands-on. Since domain analysis is a difficult and complex technique, and since it has not evolved into a mature process or method yet, I decided to teach it by example on domains familiar to the participants. I designed a three-day course. The first day for presenting concepts and the method and the last two for starting a domain analysis on a domain selected by the class (i.e., the customer.)
The organization in the first case wanted to use the course to analyze the domain of flight simulators. After an initial scoping, the class realized the domain of flight simulators was broad and complex. I proposed two alternatives: to do a high level, general analysis of the domain, or to look for a subdomain suitable for a more detailed analysis. The class selected the latter. After looking at several components and activities of flight simulators, we found that the design and validation of empirical equations that characterize aircraft behavior was an extremely time consuming endeavor.
Typically, designers work with a virtual aircraft, one that exists on a drawing board and in mathematical models. In order to achieve realistic simulation, the coefficients of several complex equations have to be found. The process is by trial and error. The designer, literally, plays with the coefficients until the expected behavior is observed. To be able to do this, an engineer has to create an interactive environment for plotting the equation and for manipulating the coefficients. Unfortunately, each environment is different because equations are different. As a result engineers spend most of their time creating and tuning the environments and only a fraction of their time playing with the coefficients.
We did a preliminary vocabulary analysis of the concepts in this activity and produced a taxonomy of classes of equations, behaviors, and environments. We then designed generic scripts (i.e., templates) in their high level graphical language for instantiating different kinds of environments. Since this was a two day effort only, we were limited to planning the next steps: to implement several scripts and to make them available in a catalog to design engineers. A few months later I learned that design engineers were reusing predefined templates that they could quickly customize for playing with their equations.
The domain of avionics displays was the topic of the next experience. Again, the class recognized that the domain was broad and complex, but in this case they decided to take a stab at the whole domain. We started bottom-up with a vocabulary analysis of all concepts, keywords, nouns, and verbs used in avionics displays. The concept of ``tapes'' appear to recur in most kinds of displays. Tapes are display elements with graduation marks used to measure variable parameters. Temperature, airspeed, attitude, pressure, etc., all are displayed in some kind of a tape form. Since each parameter was considered unique, engineers were designing their own tapes. The course helped them to realize that designing a generic tape package or a family of tape classes would make their job easier, promote reuse, and help them to agree on some standards. Although a generic architecture of avionics displays was not derived during the seminar, the concept of standard tapes more than paid off for the unmet expectations.
I hope that these experiences demonstrate the value of domain analysis and show, at the same time, the relative immature state of domain analysis. There is significant research efforts aimed at improving domain analysis and at integrating domain analysis as part of software development. I also hope that these brief descriptions have proven useful and provide some reusable experiences.