About the system
Objectives, boundaries, users, architecture and protection of the information system that runs online cosmetics sales for a Moldovan retailer.
Objectives
Each goal of the system has a measurable acceptance criterion that is checked during testing before launch.
| # | Goal | Verification criterion |
|---|---|---|
| 1 | Simplify the purchase | A customer finds a product, adds it to the cart and confirms an order without help; the order receives a unique number and a visible status. |
| 2 | Automate order processing | Every confirmed order is saved automatically with contact data, items, total, delivery and payment method; staff process it in the admin panel without re-entering data. |
| 3 | Keep the catalog up to date | Changes to price, stock or visibility made by the Administrator appear in the catalog immediately; ordering more than the available stock is impossible. |
| 4 | Delivery transparency | The customer can see the last confirmed status of an order at any time; each status change is recorded with date and time. |
| 5 | Data protection | All pages work over HTTPS, passwords are stored as secure hashes, card data is never stored on the site and the admin area is available only to authorised roles. |
Scope and boundaries
Business context
Customers increasingly choose skincare, makeup and hair care online, comparing prices and availability before they buy.
A small or medium cosmetics retailer often sells through social media posts, phone calls and messengers. Prices and stock are kept in spreadsheets, orders are copied by hand and customers have to ask whether a product is available or where their parcel is. EDEM BEAUTY turns this into one automated sales channel with clear rules for every step.
| Problem today | Solution in EDEM BEAUTY |
|---|---|
| Prices and stock in spreadsheets and social posts quickly become outdated. | One catalog with prices and live stock maintained from the admin panel. |
| Orders from calls and messengers are re-typed by hand, causing mistakes in items and addresses. | A structured checkout validates the data and saves the order automatically. |
| Products that are already sold out are still accepted in orders. | Stock is checked in the cart and again at checkout; overselling is blocked. |
| Customers repeatedly ask staff “Where is my order?”. | The customer sees the latest confirmed order status online. |
| Payment confirmations are checked manually and card details are shared informally. | Integration with a payment provider stores only the returned payment status, never card data. |
Users and roles
| Role | Type | Responsibility |
|---|---|---|
| Customer (Buyer) | Internal user | Browses and searches products, manages the cart, places an order, pays and tracks the order status. |
| Administrator | Internal user | Manages products, categories, prices, stock, discounts, reviews and staff accounts; views reports. |
| Order Manager | Internal user | Checks and processes orders, prepares shipments and updates order statuses. |
| Payment Provider | External system | Processes the online payment and returns the confirmed result (paid, declined or cancelled). |
| Delivery Service | External system | Receives delivery data, delivers the order and reports the delivery status. |
Technology & infrastructure
The interface, the business logic and the data are separated into three tiers, so each can be secured, tested and scaled independently.
Browser on desktop, tablet or smartphone
Business logic and integrations
Single source of truth
The server sends the amount and order number; the provider processes the card and returns the confirmed result.
The server passes the delivery address and contact data; the service reports delivery status back.
Security & data protection
Personal data is processed only for order fulfilment and in accordance with the personal data protection legislation of the Republic of Moldova. Non-essential cookies and browser storage are used only with the visitor’s consent, which can be changed at any time in the cookie settings.
All pages and forms are served over an encrypted connection.
Passwords are stored only as salted hashes – never in plain text.
Card details are entered on the payment provider’s page; the site keeps only the result.
Customers, administrators and order managers see only their own tools and data.
| Risk | Possible impact | Mitigation |
|---|---|---|
| Data leakage | Loss of customer trust, legal liability | HTTPS, password hashing, role-based access, minimal data collection |
| Payment failure | Unpaid or duplicated orders | Only confirmed provider results mark an order as paid; unique payment and order IDs |
| Data loss | Lost orders and catalog | Regular backups, tested restore, error logging |
| Delivery delays | Dissatisfied customers, extra support calls | Visible status history; the last confirmed status is always shown |
| Load growth | Slow pages during sales and holidays | Three-tier architecture, scalable cloud server, performance monitoring |
Explore all functional modules or follow an order through every business step.