Once we have a clear understanding of both the underlying nature of the problem and the myriad requirements, we can produce a specification for what should be in the system and what should be excluded – this bounds the scope of the system. The specification also includes what the system should do, and how it should (or could) be used. The design should provide a description of a possible system implementation that should match the specification, and typically includes details about the architecture, data structures and processing steps required.
Our extensive experience with systems designed to solve complex business problems puts us in a good position to either write the specifications and designs, or to help others to do so. This is important as very often the optimisation or scheduling component is the whole system’s reason for existing, even though it may actually represent only a small proportion of the total system. In many cases, these systems are comparatively “information-hungry”, requiring large quantities of good-quality information from a variety of sources to generate the results that are required.