Lesson 6: Systems Design

Once requirements are clear, the next question is: How should the system be built? That is the job of design.

System design translates analysis outputs into implementable decisions. It covers architecture, data storage, interface design, controls, validation, module structure, and integration.

A sound design should be:

• correct with respect to requirements
• simple enough to understand and maintain
• modular so parts can change without breaking everything
• secure enough for the risk level
• usable for the target users
• scalable enough for expected growth

Architectural choices

At the classroom level, you usually compare broad architectures:

A practical design answer should justify architecture using context. For example:

• A barangay office with multiple service windows may prefer a web-based local network system.
• A student appointment system may prefer a web-based platform with mobile-friendly screens.
• A small office with one workstation may still use a standalone desktop system if the scope is limited.

Do not choose architecture only because it sounds modern. Choose it because it fits the project's users, environment, and constraints.

Design also decides how information will be stored and how modules will be separated.

Database design

This usually comes from the ERD and normalization work done earlier. At design stage, you now think about tables and keys, constraints, indexes, transaction integrity, and archival/backup needs. A weak database design can cause duplicate records, slow queries, broken reports, and inconsistent updates.

File and record considerations

Some systems still export or import files such as CSV, PDF reports, spreadsheet uploads, and official printable forms. A complete design states which outputs are on-screen only, printable, downloadable, or sent through email/SMS integration.

Component or module design

A system is rarely one giant block. It is usually divided into modules — for example: user management, transaction processing, reporting, notification, inventory, audit log. Name components by major responsibilities. Example for a clinic system: Appointment Module, Patient Record Module, Medicine Inventory Module, Reporting Module, Access Control Module. The design should also decide which modules interact and what data they exchange.

Input and output design

Input design focuses on correct, efficient data entry: ask only for needed data, use clear labels, group related fields, reduce repetitive encoding, validate early, use appropriate controls (dropdowns, date pickers, checkboxes). Good examples: restricting dates to valid ranges, requiring a reference number format, auto-filling known details, confirming destructive actions.

Output design includes receipts, reports, dashboards, notifications, approval slips, history logs. Managers usually want summarized reports; front-line staff often need transaction-level detail.

A useful interface is consistent, readable, efficient, forgiving of mistakes, and accessible to beginners. In many BSIT courses, UI design connects closely with HCI — consider learnability, feedback, and error prevention, not only appearance.