Designing a data system for a vintage clothes business Essay Example

requires the following steps:
- The client contacts Luki via email or phone to place an order.
- Luki checks if the requested item is in stock. If not, she informs the client that it is unavailable.
- Payment is made either in cash at the time of purchase or through a check/cash sent to Luki, who then sends the order by post.
- Luki writes down the details of the sale (item sold, cost, customer information) in a notebook.

However, this system presents some issues. There are multiple forms involved, some of which contain repetitive data. Luki has to manually write all this information, which can be time-consuming.

The current data organization is not coherent, making it difficult for Luki to locate specific information. Additionally, if Luki's handwriting becomes unclear or if the buyer's notes are illegible, this poses a significant problem. Incorrect data input is also a concern that can lead to issues later on. Another problem is the absence of a system that accounts for data sold to the same buyer, resulting in repetitive data entry across different forms. In summary, the issues highlighted are:
- Repeated customer data for multiple orders
- Lack of efficient error detection and correction
- Inefficient system requiring two individuals to perform the same task
- Manual calculation of all figures leading to high error potential over time
- Manual calculation of statistics, making it impractical to gather information
- Inability to display data graphically without manual drawing
- Waste of resources in purchasing new notebooks for data recording.
Section appendix2.

Investigation2.1. The current system2.1.1. Data sources and destinationsIn the existing system, there are two primary data sources - the buyer and the

design, but the data is entered into a form. When the buyer wants to place an order, Luki enters their personal data into a form, which is then stored in a folder.There are only two current outputs from this system: a recommendations form that is retained by the practitioner, and an advice and recommendations form that is similar to the practitioner's form, but it is given to the client for their reference.

The current system entails several simple algorithms. One algorithm involves the process of a customer placing an order, where they contact Luki via phone or email and Luki checks stock availability before gathering information and either sending off the order or instructing the customer to collect it. Another algorithm involves the client receiving an order and deciding how much stock to reorder. Luki takes note of which products sold out quickly, fills out an order form via email to the manufacturer (Haines), and requests a specific quantity of products. The third algorithm pertains to updating the website. Luki designs new products, gets the manufacturer to show her what the finished product will look like, and then posts pictures and short descriptions on the website. This process is repeated for multiple products if necessary. Lastly, there is a step involving a new design, where Luki draws a new design, scans it into the computer, makes small edits on Photoshop, and contacts the manufacturer to inform them of the desired quantity of designs for a specific number of products needed.

In regards to input forms, output forms, and report formats, the current system does not have any forms apart from those that Luki has to handwrite herself.

The

proposed system is not mentioned in this text.

The text below provides information about data sources and destinations. It also mentions a hand-drawn data flow diagram that needs to be inserted in this section.

Data sources and destinationsData SourceDestination2. 2.2. Data flow diagramTo be inserted (hand-drawn) here2.2. 3.

The system's data dictionary specifies that it can process and store the details of one order sheet at a time. Each order sheet is saved in a separate folder for potential future reference, with no limit to the number that can be saved. This ensures that the system can handle a lifetime's worth of orders. Additionally, the database has the capacity to store details for an unlimited number of customers.

General objectives:

- Design an easy-to-use interface that can be managed by inexperienced computer users with little training.
- Create a straightforward menu structure with informative prompts.
- Minimize human error by automating processes as much as possible.
- Implement sufficient validation measures to prevent mistakes.
- Ensure a fast system performance for quick data recording after orders to avoid any potential forgetting.

Specific objectives:

- Enable the user to add buyer data.
- Allow the user to update existing buyer data.
- Provide a search function based on specific fields.
- Enable the user to add other products, buyers, and designs.
- Display buyer and order data in a color-coded format.
- Allow data removal capabilities.
- Implement a graphical form for data input.
- Ensure easy navigation through graphical forms and menus using navigation buttons.

Core Objectives • The prices of supplies should be viewable. • The costs of supplies should be calculable. • The profit should be calculable. • The order quantities should be displayable.

Other objectives • Personal and product data

could be encrypted within the database. • The user could be able to back up the data to an external source through the GUI. • The system could be secured with password access. • Other team members could be created who can also add buyer data. • Certain users can be restricted from having full access to the system. • Automated emails can be sent to buyers stating the status and estimated delivery time of their orders.

E-R Diagrams and Descriptions 4.1. E-R diagram 4.2.

The text below provides a consolidated and rephrased version of the original text, while maintaining the and their contents:

Entity Descriptions: The primary DDL defines various entities, such as Customer (CustomerID, Name, AddressLine1, PostCode, Town, EmailAddress, ContactNumber), Product (ProductID, Fabric, Design, QuantityInStock), Order (OrderID, Cost, CustomerID , ProductID), and User (UserID , Name , AddressLine1 , PostCode , Town , EmailAddress , ContactNumber , ProductID , OrderID).

Object Analysis:

• List of Objects: The objects involved include Customer , Product , User (manager/team member) and Order.
• Relationship diagrams: Hand-drawn diagrams that depict the relationships.
• Class definitions: Explanations of the classes written by hand.

Other Abstractions:

• Another Abstraction 6.1

GraphsN/A ATM7. Constraints7.1. HardwareLuki's currently uses an Acer Aspire 7535 laptop for work. For Caroline to use the new system, it must be compatible with this laptop.

Specifications of the Acer Aspire 7535:
• 17.3" Display
• AMD Athlon X2 QL-65 / 2.1 GHz Processor
• 4 GB DDR2 SDRAM
• 500GB HDD
• ATI Mobility Radeon HD 3200 Graphics

The proposed system should have lower system requirements than the hardware it needs to run on, and it should not negatively impact the new system. The laptop's hardware constraints include keyboard size and screen resolution.

Luki's software preferences

are that it is compatible with her version of Windows 7 and does not require an internet connection.

This will not have a significant impact on the project if it is implemented using Python 3.2.7. The only time constraint is the project's implementation deadline, which is January 27, 2013.

The client does not require the system before this time.

User knowledge

The client has limited ICT qualifications and primarily uses a computer for email and word processing. She has minimal technical skills and ICT knowledge, so the system should be designed to cater to her level of expertise. It is important that the system's interface closely resembles Microsoft Word since she is most familiar with this program. The buttons in the system should be properly positioned and labeled. Additionally, it is crucial to provide comprehensive instructions in order to assist users.

Access restrictions: The system should only be accessible by Luki and her team. The rest of the team should have different access restrictions, such as not being able to delete buyer data or add a new design to the system. Since this proposed system contains personal data that can identify a living person, it must comply with the data protection act. This means that measures should be taken to secure this data so that only authorized individuals have access to the necessary data.

8. Limitation

8.1. Areas which will not be included in computerisation: The processing of the buyers personal data (e.g.

D.o.B) will not be included in computerisation, as this process requires buyer’s personal knowledge, which is unnecessary to keep. 8.2. Areas considered for future computerisation: Currently, the company's scale is not large, so the system being created does not

need to handle thousands of products/orders. However, if the company were to grow, additional functions could be developed to accommodate this. 9. Solutions: 9.1.

Alternative solutions9.2. Justification of chosen solution
• Restricting access to the system only to those who have physical access to the hardware on which it is installed is one advantage of having a desktop application.
• Another advantage of using a desktop application is that it reduces the time spent filling in forms before the treatment.
• Unlike using a spreadsheet application, which is generic, a desktop application can be tailored to the client's specific requirements.
• This system uses less paper compared to the current system or a redesigned manual system.
• The storage space required for this system is limited to a hard disk drive, rather than large folders.
• Backing up the system and data is possible.