B01SYAD310/BIT309 Systems Analysis And Design For ABC Car Sale System Assignment Answer

Answer :

Introduction

This report will contain the system details, problem summary, functional and non-functional requirements and various modelling diagrams. ABC car sale system is a web-based system and the Customers do not need to visit the ABC car sales company. They can view, book or buy cars online. After booking or buying a car online they can also make all the payments online and get the payment receipt. If any customer does not want to book or buy a car online, the customer can also send a request for an appointment to view the cars. They can also send cars for service and repair. Staff can add all the details related to any customer, suppliers, cars, sales, service or repair and payment. Manager can access different type of reports according to various conditions. An accountant can only access financial records. The admin is the only one person, that has access to add staff information and give the required access privileges to staff and customers. 

Problem summary

There is a current manual system to handle the ABC Car Sales System. The customers must visit the car sales company for booking, purchasing, repairing or servicing the cars. All the data is maintained using books and there is no computers or web-system involved. Now, in this era of technology, the customers can’t always visit the company to even view the cars or to make the purchase. Also, maintaining the records manually is a very cumbersome task.

Functional and non-Functional requirements· System Requirements 

• Customers: The customers can register on the ABC car sale system site and after logging in, they can view all the car’s details. They are also able to do an enquiry on any of the available cars and send a request to ABC car sale company for the appointment.  They can also book or buy the cars online and then pay the advance payment for their booking. After the payment process, they will get the payment receipt at the same time. They can also send their cars for service and repair. If they are not interested to visit the site, they can also visit the car sale company and all these tasks will be performed by the staff.
• Staff: The staff can add new customers, car’s suppliers, car, sales, service, repair and payments details into the system. When any customer requests for the appointment, and staff can check all these requests and book the appointment for the customer.
• Manager: The manager has access to view different types of reports and prints them. These reports can be related to sales, services, repair, car purchases, employees, customers etc.
• Admin: Only an admin can add new staff details and provide the required access privileges to the staff and the customers. 
• Wed based system: The most important requirement is, this is a web-based system. The Customer is not required to visit the ABC car sale company. They can view all the car details online and book or buy any of the cars. They are also able to make the payment online and download the payment receipt after the payment. They can also send their car for service and repair by making the requests online

· Use Case diagram

We know that the use case diagram specifies the expected behaviour of the system. This use case diagram contains actors, use cases and the relationship between them. There are mainly three actors, and these are the following: -

1. Customer: 
2. Customers can register on the ABC car sale site.
3. Customers can log in on the system and after logging in, they can perform other tasks.
4. After logging in, they can view car details, book or buy cars.
5. They can make the payment online and get the receipt.
6. If they want to visit the company, they can request for an appointment.
7. They can also send their car for service or repair.
8. Staff:
9. Staff can add new customers, suppliers, cars, sales, repair or services, detail.
10. They can approve the customer’s appointment request.
11. They can access the different reports related to customers, cars, sales, service, repair, payment etc.
12. They can also access financial records.
13. Admin: 
14. Admin can add the staff details.
15. An admin can give access privileges to staff and customers. 

· Context Diagram:

This diagram represents the boundary of our software system. This diagram contains various external entities, one process and relationship between the external entities and the process. There are mainly three external entities which are customer, staff and admin and one process which is the ABC Car Sale system

· DFD 0 level diagram:

This diagram is also like a context diagram. But the main difference is that we have divided the main process into five sub-processes. These processes are the following: -

• Appointment
• Car
• Sales
• Service repair
• Payment

(Visual-paradigm.com, 2020)

· Entity-relationship Diagram (ERD):

The entity-relationship diagram represents the database design. This diagram represents all the entities, entity attributes, primary and foreign keys and the relationship between these entities. We have created the following entities: -

1. User
2. Staff
3. Customer
4. Supplier
5. Car
6. Carsale
7. Servicerepair
8. Payment
9. SRPayment
10. carsalePayment
11. appointment

· Relationship between entities:

• There are two types of user’s staff and customer. So, the user entity is the super-entity and staff and customers are the sub-entities.
• 0: 1 relationship between the user and the staff. The user plays the role of zero or one staff and each staff is related to one and only one user.
• 0: 1 relationship between user and customer. A user can play the role of zero or one customer and each customer is related to one and only one user.
• 0: M relationship between staff and customer. Staff can add zero or many customers and each customer is added by one and only one staff.
• 0: M relationship between staff and supplier. Staff can add zero or many suppliers and each supplier is added by one and only one staff.
• 0: M relationship between staff and carsales. Staff can handle zero or many carsales and each carsale is related to one and only one staff.
• 0: M relationship between staff and servicerepair. Staff can handle zero or many servicerepair and each servicerepair is related to one and only one staff.
• 0: M relationship between staff and the appointment. Staff can set zero or many appointments and each appointment is related to one and only one staff.
• 0: M relationship between customer and appointment. A customer can request zero or many appointments and each appointment is related to one and only one customer.
• 0: M relationship between customer and carsale. A customer can be included in zero or many carsale and each carsale is related to one and only one customer.
• 0: M relationship between customer and servicerepair. A customer can send a car zero or many times for servicerepir and each servicerepair is related to one and only one customer.
• 0: M relationship between customer and payment. A customer pays zero or many payments and each payment is related to one and only one customer.
• 0: M relationship between supplier and car. A supplier supplies zero or many cars and each car can be supplied by one and only one supplier.
• 0: M relationship car and carsales. A car can be included in zero or one carsale and each carsale is related to one and only one car.
• 0: M relationship between car and servicerepair. A car can be included in zero or one servicerepair and each servicerepair is related to one and only one car.
• 0: M relationship between carsale and carsalePayment. A carsale can be included in zero or many carsalePayment and each carsalePayment is related to one and only one carsale.
• 0: M relationship between servicerepair and SRPayment. A servicerepair can be included in zero or many SRPayment and each SRPayment is related to one and only one servicerepair.

Team building

It is a formal process to collect system requirements and preferences. In this process, the developer needs to collect the details about the current system and the proposed future system. Many fact-finding methods are used to collect the system requirements and some of these are the following: -

1. Examining documentation: - In this process, we go throw the case study provided in this requirements file. We can collect the main information from the given case study and understand the workflow of the system. After analysing the workflow, we can find that which type of information they want us to store in the ABC Car sale system. 

Pros: 

• Understand the workflow of the ABC car sale system.
• Collect which kind of information is required to be collected in the car sale database.

Cons:

• Some information is missing. For example, supplier, staff, sales. We need to make some assumptions about the requirements.

1. Observing the enterprise in action: We can follow this method and observe all the staff members in a car sales company. We can also observe the different departments of the company like sales department, payment department, service and repair department etc. By observing, we can understand the workflow and understand all the system requirements.

 Pros: 

• We can easily understand the workflow of the system.
• We can observe exactly how complex tasks are being performed in the system.

Cons:

• Sometimes people perform in a different way when someone is observing them.
• Sometimes the same task can be handled in various ways as each person has his way of performing any task.

1. Research:  Research is the best method that is used to collect information related to any application or any problem. We have used the internet and the provided case study for analysing the system requirements. Huge quantity of information is available on the internet and a lot of information can be utilized to design the car sales system. We can study different system problems that are currently faced by various companies and their current solutions.

Pros:

• We can collect a huge quantity of information related to the system.
• We can design our system with the best quality. 

Cons:

• it is a very time-consuming process. 

Development approach

· System development tools:

1. Back end development (MYSQL): We will use MYSQL to design the database. In this database, we will store information related to the customers, staff, supplier, purchase a car, car sales, repair, service payment and appointment information. We will also generate the reports so that the manager can easily print the required reports related to the ABC car sale system. In this system, only the admin has permission to give all the access privileges to staff and customers.
2. Front end development (Visual Studio): Visual Studio is an integrated development platform which is developed by Microsoft. It is commonly used to develop computer programs as well as websites. It uses Microsoft software development platforms and it can produce both native code and managed code. It can support various languages like C, C++, C#, .Net etc. We will make the use of this IDE for creating the backend of our application. We can write the code and the User interface in any language and then this backend will interact with the MYSQL database.

· System development methods:

1. The top-down approach to analyse the system: For the system analysis part, we have used the top-down approach. Firstly, we studied the given case study and used some fact-finding methods to collect information related to the ABC car sales system. Then we divided this system into smaller parts for example sales, payments, appointment and service and repair. Then we observed that we need some users to handle this system. For example, customer, staff etc. So, finally, we created some diagrams to represent the workflow of the system and to represent how the data is being stored by using the database in our system.
2. Modelling: in this method, we have created four diagrams, and these are the following: -
3. Use case diagram:  In this diagram, we represent what kind of things or work will be performed by the users.
4. Context diagram: This diagram represents how the user will interact with the system.
5. DFD 0 level diagram: This diagram is also like the context diagram. But in this diagram, we have divided the single process into other smaller processes or subprocesses.
6. Entity-relationship diagram: This diagram represents the database design and shows how the database is stored in the database system.

Conclusion

I have learnt many things while doing this assignment. We have created various design models like use cases, context diagram, DFD 0 level and entity-relationship diagram. We have also learnt to gather and analyse all the requirements from the provided case study. Apart from these things, we have also learnt about some fact-finding methods, some tools and various system development methods.