There can be many reasons for making an Ampersand model. Just a few examples are:
You want to study the conceptual structure of something, to gain a better understanding or to acquire the jargon of a topic. Business analysts do it when starting on a new assignment. In a new environment with new people, unknown habits and a lot of catching up to do, they pick some documentation, courseware, legislature or other jargon-laden documentation and make an Ampersand model. Making sense of piles of new material goes much faster if you try to make an Ampersand model on the side.
You want to design persistent store (a database) for use in an application. You make a model of the data, the rules and make one interface for every service your store provides.
You want to detect flaws in an architecture. Make an ampersand model of that architecture, and model every rule you want checked. Populate your model with data from the real architecture, and you can measure every flaw as it occurs.
Your build-team wants clear working instructions, but there is no time to make a functional specification. You make your Ampersand model and derive the work instructions from the functional specification and the prototype that you have made.
You need correct software. Develop your software in Ampersand and use the rules to establish correctness.
Your assignment is to cleanse a polluted database. Try to find the rules that define what clean data is, and run your data through Ampersand.
There are most certainly other reasons for making an Ampersand model, because a good conceptual analysis precedes practically every problem that is worth solving.
An information system is modeled by designing every subsystem separately.
To specify an information system, take the following steps: 1. Agreement on the domain language; 2. Agreement on rules; 3. Validate rules; 4. Define interfaces.
An ampersand model describes the rules, relations and concepts that define a business system. Using this specification, a software system can be built that can hold structured information as a set of facts. Based on the rules, the set of facts can be checked automatically to detect violations of rules.
In an Ampersand model, interfaces can be defined too, enabling the definition of changes to the set of facts.