Business Process Design

	Obviously, the first step in system development would be the modelling of its organizational structure via the ORG diagram:
	The next step could be a high level informal description of the business process with the goal of capturing the functionality of the Autoparts Trading Company in general. We consider only one of the business processes going on in the Company, namely, Order Processing
	Further, a more detailed business process model should be developed where events correspond to real documents circulating in the Company. In addition, the role of the Information System under development is also shown in the model: The complicated task Process Order, which is most closely related to the Information System , is refined by a BP diagram of its own. The Business Process Reengineering phase is omitted for this example and we assume that the business process defined herein has already reached final version. Information System Design    Now we are ready to move on to the Information System specification phase. To initiate this, we have to "extract" from the business process all tasks which are to performed by the Information System (as a software system). One of the ways to do this could be to consider the existing business process to be a logical business process. Then we build the corresponding physical business process, describing the same system behaviour, but with tasks performed by software and tasks performed by staff clearly separated. For the sake of simplicity we omit this level and proceed directly to software system design.
	At first, starting from the ORG diagram, we build a CO diagram, in order to specify all information flows between objects contained in the Autoparts Trading Company. Three levels of subordinated CO diagrams happen to be necessary: company environment top level of Autoparts Company Sales Department detailing
	The next step could be data modelling. Data modelling could have been done as part of the initial modelling of the business processes, but was postponed in this case. We can perform this modelling by means of GRADE DD Datatype and ER diagrams. Note the use of subtype entities in the ER model.
	Now it's time to specify the software, the general behaviour of which was already described in the business process. In GRADE this specification is performed via PD diagrams The previous diagram actually specifies a small part of the software - the fragment of the Order Processing application related to supporting the Salesman in finding out what is to be done in order to full the order. This application is assumed to be a typical client application based on a Windows GUI and using the company data base (Sales_Data) on a server. The PD diagram can be considered as a graphical equivalent of structured English (or pseudocode). The actions associated to the menu items of the simplified main window of the application and interaction necessary to find the appropriate partially entered order are shown. The procedure of selecting the required product via listboxes corresponding to Products in Stock and Assembled Products is also presented. The lengthy interaction necessary to complete the Assembling Specifications from the Order is assumed to be done in the procedure Prepare Assembling Specifications which could be designed in the same style. The selected level of abstraction permits one,e.g., to perform a thorough validation of the design. The next phase is the Implementation phase-which can be considerably shortened and simplified by providing a GRADE specification that is accurate and with the appropriate level of detail.