Week 1: Introduction to Systems Analysis & Design
Week 1 — Introduction to Systems Analysis & Design
What you will learn this week
- What an information system is and why organizations build them
- What systems analysis and systems design actually mean
- The role of the systems analyst as a bridge between business and technology
- The major types of information systems in a typical organization
- Why careful analysis and design saves time and money
1. What is an information system?
An information system (IS) is an organized combination of people, processes, data, and technology that collects, stores, processes, and distributes information to support an organization. Notice that technology is only one part — an information system is not just software. A point-of-sale terminal in a store, the staff who use it, the rules for processing a sale, and the customer data it records together form one information system.
Running case — ShopEase. Throughout this course we follow ShopEase, a growing online retailer. ShopEase currently takes orders through a basic website and tracks stock in spreadsheets. They want a proper e-commerce platform. We will analyze and design that system together, week by week.
2. Analysis vs. design
These two words are used constantly in this course, and beginners mix them up. Keep this distinction clear:
| Term | Question it answers | Example for ShopEase |
|---|---|---|
| Systems analysis | What does the business need the system to do? | ShopEase needs customers to browse products, add them to a cart, and pay securely. |
| Systems design | How will the system be built to do it? | A product catalogue page backed by a database, a cart stored per session, and an integrated payment gateway. |
Analysis comes first and focuses on understanding the problem. Design comes second and focuses on shaping the solution. A common beginner mistake is to jump straight to design ("let's build a React app with a payment API") before understanding what the business actually needs.
3. The systems analyst
The systems analyst is the person who studies a business problem and specifies how an information system can solve it. The analyst is a translator: they speak "business" with managers and "technical" with developers. Core responsibilities include:
- Investigating the current situation and identifying problems or opportunities
- Gathering requirements from stakeholders
- Modelling the system using diagrams and specifications
- Communicating the design to developers and verifying it meets the need
Tip. The most valuable skill of an analyst is not coding — it is asking good questions and listening carefully. A system that is built perfectly but solves the wrong problem is a failure.
4. Types of information systems
Organizations run several categories of system, each serving a different level of decision-making:
| Type | Purpose | Typical users |
|---|---|---|
| Transaction Processing System (TPS) | Records day-to-day operations (sales, payments, stock changes) | Front-line staff |
| Management Information System (MIS) | Summarizes operational data into routine reports | Middle managers |
| Decision Support System (DSS) | Helps analyze data for non-routine decisions | Analysts, managers |
| Executive Information System (EIS) | High-level dashboards and trends | Senior executives |
For ShopEase, the order-taking platform is mainly a TPS, but the weekly sales report it produces is an MIS function.
5. Why analysis and design matter
Research on software projects consistently shows that the cost of fixing a mistake grows dramatically the later it is found. A requirement misunderstanding caught during analysis costs a conversation to fix. The same mistake caught after the system is live can cost a rebuild. Investing in early analysis and design is one of the cheapest forms of insurance in software.
Key terms to remember
- Information system, systems analysis, systems design, systems analyst
- TPS, MIS, DSS, EIS
- Analysis = what; Design = how
Common mistakes
- Treating "the system" as just the software, forgetting the people and processes around it.
- Starting design before the problem is understood.
- Confusing analysis (what) with design (how).