Designing a data system for a vintage clothes business
My client is Imogen Summer-Rooney, but she likes to be called Luki. She has some knowledge about computers. Luki’s main uses for a computer are email, internet and word processing. At the moment Luki uses an Acer Aspire 7535 laptop to which is running a 32 bit version of Windows 7.
She is a self-employed designer, specialising in re-working vintage clothes to something that can be worn by the youth’s image of today. Luki currently offers these designs off her Facebook, Tumblr, twitter and website page. Luki runs a team consisting of a photographer, two male models and two female models who all are her closest friends. She’s named this group ‘The House of Sharps’ and has plans to expand in the near future. Luki works alone doing the designing, printing and general creation of her products but she sells the clothes through her friends.
Luki would like a new system, as her current system is unorganised and is recorded simply through writing. Her business is not very big so she would like a system for when she expands she can stay organised. With the current system there is a difficulty in trying to record all data when there is a bigger order. Luki would like to be able to have an ordering system along with a database system to which data can be stored in a secured manner.
1.2. Define the current system
The current system to manage all the data is a manual system of which involves writing the buyer and design data on multiple forms, and storing the forms in folders which contain all the other data – this includes the price of the products. The data that is collected from the buyer and the design is output to a form, of which is stored in her folder system.
Currently, for one buyer that buys some clothing, Luki writes down who, when, how much, etc of the product shes sold and to whom.
With each different product, there is a different form of paper filled in, with the same data being input. This means if one buyer were to buy another product, then two pieces of paper would be filled out.
So summarising, the current system does:
Client emails/calls Luki to make order
Luki checks stock for order. If not in stock she tells client its unavailable.
Luki takes payment by cash then hands over item OR Luki gets sent cheque/cash and sends order off in post
Luki then writes down what she has sold, how much it cost, who the person was who order it. This is all done in a notebook.
1.3. Describe the problems
The current system has a lot of forms, some containing the same data or information. These have to be hand written by Luki which can take a long time to complete fully. The data is not split into logical sections and headings – which mean specific data, may be difficult to find if Luki were to look for the specified data.
If Luki’s handwriting became unclear/ or the buyer wrote down something and was not able to be read, then this would be a significant problem. Data may also be input incorrectly which may also cause problems later.
There is currently no system which takes into account data that is sold to the same buyer which may lead to large amounts of re-written data to different forms.
So summarising, the problems are:
• Data repetition – the customers data is repeated if makes numerous orders.
• Very little error detection and error correction is near impossible if the error is not noticed straight away.
• System is inefficient as two people are required to perform the same task to reduce errors.
• All figures are calculated by humans, which introduces a very high possibility of errors over the course of time.
• Any statistics have to be calculated manually and are not a practical format to gather information from.
• Data cannot be displayed in a graphical format, unless drawn by hand.
• Resources are wasted purchasing new notebooks to record data.
1.4. Section appendix
2.1. The current system
2.1.1. Data sources and destinations
In this current system there are two main data sources – the buyer and the design, however the data is passed into a form. When the buyer would like to order a product, Luki passes their personal data into a form and from there it is stored into a folder.
The only current outputs from this system are a recommendations form that is kept by the practitioner, and an advice and recommendations form of which is similar to the recommendations form that is kept by the practitioner, however – this form is given to the client so that they have this information.
Phone Call of Order
Email of Order
Certain amount of T-Shirts from Manufacturer
At the moment in the current system there are some simple algorithms used. One is the customer making order:
Customer phone calls or emails Luki to ask for product
Luki checks stock
Luki gather information and stock
Luki sends off or asks customer to come and receive order
Second there is, the client receiving order and deciding how much stock to order:
Luki takes note of which stock sold out quicker
She then fills out an order form via email to Haines(manufacturer)
She asks for X amount of products
Thirdly, updating website:
Luki designs new product
Gets manufacturer to show her what finish product will look like
Luki then posts picture and short description about product
She does this for many products if need be
Lastly a New Design:
Luki draws new design
Scans drawing to computer
Makes small edits on Photoshop
Then contacts manufacturer to let them know X amount of designs for X amount of products needed
2.1.3. Data flow diagram
2.1.4. Input Forms, Output Forms, Report Formats
In the current system there are no forms other than the forms which Luki has to hand write herself.
2.2. The proposed system
2.2.1. Data sources and destinations
2.2.2. Data flow diagram
To be inserted (hand-drawn) here
2.2.3. Data dictionary
Array of Integer
The system will be required to process one order sheet at a time and add the details to the database. The order sheet will then be saved separately in a folder for possible future reference. There are unlimited order sheets that will be required to be saved at any one time, which will be enough for a life time’s worth of orders! The database must also be able to hold details for unlimited customers.
3.1. General Objectives
• Easy to use interface so that inexperienced computer users can manage with little training.
• Straightforward menu structure with useful and informative prompts.
• Reduce human error as much as possible by having most processes undertaken by computer.
• Sufficient validation to prevent as many mistakes as possible.
• System must be fast to use so that data can be recorded quickly after order before forgotten.
3.2. Specific Objectives
• The user should be able to add buyer data.
• The user should be able to update current buyer data.
• The user should be able to search through specific data, given a field to search.
• The user should be able to add other products, buyers and designs.
• The user should be able to view the buyer and order data in a colour-coded form.
• The user should be able to remove data.
• The user should be able to input data via a graphical form
• The user should be able to navigate through the graphical forms and menus easily via navigation buttons.
3.3. Core Objectives
• Must be able to view prices of supplies.
• Must be able to calculate costs of supplies.
• Must be able to calculate profit.
• Must be able to show order quantities.
3.4. Other objectives
• Personal and product data could be encrypted within the database.
• The user could be able to backup the data to an external source through the GUI.
• The system could be secured – password access.
• The ability to create other team members that can also add buyer data.
• User restrictions – stop certain users from having full access to the system.
• The ability to automatically send emails to buyers stating where order is, when they shall receive it.
4. E-R Diagrams and Descriptions
4.1. E-R diagram
4.2. Entity Descriptions
The following is a list of my proposed entities defined in basic DDL:
Customer (CustomerID, Name, AddressLine1, PostCode, Town, EmailAddress, ContactNumber)
Product (ProductID, Fabric, Design, QuanityInStock)
Order (OrderID, Cost, CustomerID, ProductID)
User (UserID, Name, AddressLine1, PostCode, Town, EmailAddress, ContactNumber, ProductID, OrderID)
5. Object Analysis
5.1. Object Listing
• User (manager/team member)
5.2. Relationship diagrams
5.3. Class definitions
6. Other Abstractions
At the moment, Luki’s uses a laptop (Acer Aspire 7535) to work from. The new system must be able to run on this laptop for Caroline to be able to use it. 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 not negatively impact the new system – the system requirements should be significantly less than the hardware it needs to run on. The hardware constraints to this are the keyboard size and screen resolution for the laptop that it will be designed to work on.
Luki’s only preferences are that it is compatible with her version of Windows 7 and the new system does not require an internet connection. This should not affect the project greatly if it’s implemented with Python 3.2.
The only restriction for time is the implementation deadline for this project, of which is the 27th of January 2013. The client does not need the system before this period.
7.4. User knowledge
The client does not have any ICT related qualifications, and her main use for a computer is day-to-day emailing and word processing. She does not possess an advanced technical ICT ability or vocabulary – so this should be taken into consideration for the system. The system should be as basic as possible – perhaps visually similar to Microsoft Word – as this is most commonly used program. The buttons in the system should be well placed, and relevantly named.
There should be detailed instructions with the system, to assist the users.
7.5. Access restrictions
The system should only be accessible by Luki and her team. The rest of the team should have different access restrictions – for example not being able to delete buyer data, or add a new design to the system.
Because this proposed system contains data of which can identify a living person, it should comply with the data protection act. This means that measures should be taken to secure this data so that only the correct people have access to the necessary data.
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 – this will be unnecessary to keep.
8.2. Areas considered for future computerisation
At the moment the scale of the company is not huge. Taking this into account I’m not creating a system that needs to take into account thousands of products/orders. So if this company did ever pick up, it would be possible to create more functions for this to happen.
9.1. Alternative solutions
9.2. Justification of chosen solution
• Having a desktop application means access to the system is restricted to those who have physical access to the hardware the system is installed on.
• Using a desktop application will reduce the time taken filling in forms before the treatment.
• The application will be specific to the client’s requirements, unlike if a spreadsheet application were to be used.
• This system uses less paper than the current system, or a re-designed manual system.
• The storage space for this system is only on a hard disk drive – rather than in large folders.
• Backups of the system and data can be made.
Get access to
Guarantee No Hidden