• No results found

USER REQUIREMENTS DEFINITION

In document SIMULATION MODELLING OF AN (Page 83-86)

CHAPTER 8: INFORMATION SYSTEM DESIGN AND IMPLEMENTATION

8.3 USER REQUIREMENTS DEFINITION

In the development of any system or product, user requirements are of the utmost importance to ensure a usable and feasible end product. No matter how practical and technologically advanced a product might be, if the user does not want it – it is ultimately useless. The user requirements phase starts at a high level investigation into the needs and requirements of OPF and the users involved in the information system. A high-level context diagram translate main requirements into system functions whereas the Functional Operating Area analysis digs deeper into the per activity requirements of the users. To conclude, the phase describes each of the user requirements as a requirements document.

CONCEPT OF OPERATIONS

The context diagram denotes the high-level interactions of the user with the system. The information system is essentially divided into four main categories that describe the main functions the database will provide. Essentially OPF wants to input information for vehicles and tyres. These categories are further broken down into vehicle maintenance and tyre purchases. The concept of operations looks at the core of the information system and the purpose for its development.

FIGURE 27: INFORMATION SYSTEM DESIGN CONTEXT DIAGRAM

FUNCTIONAL OPERATING AREAS

According to The House of Representatives (1999) the core business processes can be divided into major groupings called Functional Operating Areas (FOA). The processes within each of these FOA’s are candidates for becoming the system functional requirements. By identifying the functional requirements, one can begin to identify the related technology areas early in the development process.

To determine and evaluate the FOA’s and functional requirements, a Use Case diagram was developed to provide the main activities performed by the external system users. OPF has the following FOA categories:

a. Vehicle Operations b. Tyre Operations c. Maintenance Operations d. Purchasing e. Ordering f. Deliveries g. Procurement Model

Three main actors to the system were also identified: a. Vehicle Management

b. Tyre Procurement Management c. Finances

The Use Case diagram depicts the activities each of the system actors want to perform as well as high-level feedback expected from the system. Each of the FOA categories can now be translated into a list of activities outlined in the user requirements document.

USER REQUIREMENTS

Requirement Description

User login User logs in as a specific database user with appropriate parameters.

Add to inventory The user inserts information for a new tyre purchased. Each tyre is identifiable with an identification number.

Delete inventory The user needs to be able to remove any information of product not in inventory anymore.

View inventory The user needs to be able to view the entire inventory available.

Add vehicle The user needs to be able to insert information regarding a new vehicle in the department.

View vehicle information The user needs to be able to view all the necessary information regarding a single vehicle in the system.

Delete vehicle Information When a vehicle is sold or not in use, the user must be able to delete the relevant information and records.

View vehicle market value It is necessary for the user to view information regarding the value of a vehicle in the system.

View tyre cost centre purchases The user needs to be able to view and interpret purchase information allocated to each of the cost centres in the system.

Create new order A new order can be created by a user.

View and edit orders The user needs to be able to view and change information for all or a single order.

Add tyres to orders The user needs to be able to insert information on the product that needs to be ordered. An order must be capable to take information for more than one product type.

Add tyre fit to vehicle It must be possible for a user to link the information of a specific tyre to a specific vehicle when a tyre of a vehicle is changed.

View vehicle fits The user must be able to view all the tyres in inventory that are fitted to a specific vehicle.

View tyre usage The user must be able to view the period a tyre was fitted to a vehicle. Add new purchase A new purchase can be entered by the user.

Close an order It must be possible for a user to close an order that has been fulfilled.

View purchases The user needs to be able to view all purchase information for a certain period of time.

information purchase.

View demand trend A user must be able to view and interpret a trend in tyre demand data. View price trend A user must be able to view and interpret a trend in tyre price data. Add delivery A new delivery can be added by a user.

View delivery history It must be possible for a user to view previous delivery information. Add vehicle maintenance A user must be able to add new information regarding vehicle maintenance. Update vehicle status The status of a vehicle must be updateable by the user.

View tyre use availability The user must be able to determine how much product is available for use. Edit and close vehicle maintenance The user must be able to edit and close maintenance records for certain

vehicles.

View Inventory Inventory information must be viewable by users.

Run procurement model The user needs to be able to activate the mathematical procurement model from within the information system.

View procurement model results The user needs to be able to view and interpret the results of the procurement model.

Edit or add procurement model parameters

It is necessary for the user to be able to edit of add parameters relating to the procurement model and related tyres.

TABLE 37: INFORMATION SYSTEM DESIGN USER REQUIREMENTS

In document SIMULATION MODELLING OF AN (Page 83-86)

Related documents