Domain Requirements

~ ~ In order to keep the domain manageable, it had to meet several requirements. It had to be intuitive, meaning that the objects to be designed, the rules the experts would follow, and the actions needed to design the objects all had to be something most people could envision in their heads and not expect to need books of tables and parts lists. This was so that the system could be used by managers, executives, and engineers with equal ease.

The domain had to lend itself to a common design paradigm. In our case we chose the specification of a design from abstract to concrete as the paradigm. Using this system, design decisions would refine a structure from its most abstract form to a concrete collection of objects with specified parameters. Other paradigms include modification of alternative designs.

The user must be able to make most of the design decisions. Design decisions might include material selection, size of objects, placement, etc. As many of these as possible should be left in the hands of the user to keep the user in charge of the design.

The system should help make the choices, limiting the number of actions among which the user has to choose. The system should handle anything which would be too repetitive or difficult for the user. Anything that might require the user to use a calculator or book should be controlled by the system, so that the design can remain intuitive.

Finally, the domain should make itself available for commentary from many aspects and also from many different types of agents. The types of agents are defined in chapter . This is necessary to show the power of concurrent engineering even applied to a simple domain such as this, and to complete the main task, which is to show how a simple design decision affects multiple aspects in different ways.