Lesson 1: Foundations of Systems Analysis and Design

Systems Analysis and Design is the study of how organizations understand problems, define requirements, and build information systems that solve those problems well. In BSIT, this subject sits between technical development and real organizational needs. It teaches you how to move from "May problema ang office" to "Here is a clear, justified, testable system solution."

An information system is more than software. It includes:

• People who use, manage, and support it
• Processes that define how work is done
• Data that the organization stores and uses
• Technology such as hardware, software, and networks
• Policies and controls that keep work accurate, secure, and compliant

A common mistake is to think that a system project starts with coding. In practice, coding starts much later. Good projects begin with questions like:

• What is the real business problem?
• Who is affected by it?
• What does the current process look like?
• What data is needed?
• What constraints exist?
• How will we know the new system is successful?

If these questions are skipped, the team may build a system that works technically but fails operationally. A fast, well-coded program is still a poor solution if it does not match the users' work, legal requirements, budget, or timeline.

A useful way to think about this subject is:

In Philippine contexts, Systems Analysis and Design is often applied to cases such as:

• student enrollment and clearance systems
• barangay service request and document tracking
• clinic appointment and medicine inventory systems
• payroll and HR systems for SMEs
• e-commerce order processing for local sellers
• logistics and delivery tracking for cooperatives

The subject trains you to think like a professional who can connect users, managers, developers, testers, and decision-makers into one coherent project effort.

A systems analyst is the bridge between the organization and the technical team. The analyst does not only gather requests. The analyst studies operations, clarifies problems, identifies requirements, models processes and data, evaluates options, and helps the team produce a workable solution.

A good systems analyst usually performs these responsibilities:

• studies the current system or workflow
• identifies business problems, causes, and effects
• gathers requirements from users and stakeholders
• models processes, data, and interactions
• checks whether requirements are complete and consistent
• works with designers and developers during solution design
• helps prepare test cases and implementation plans
• communicates with both technical and non-technical audiences

The analyst must talk to different stakeholders. These often include:

A strong analyst needs both technical awareness and soft skills. For example:

• Communication for interviews, presentations, and documentation
• Critical thinking for separating symptoms from root causes
• Modeling skill for diagrams and structured descriptions
• Empathy for understanding the user's real work
• Professional ethics for handling sensitive data responsibly

A simple example: if a registrar complains, "The enrollment process is slow," the analyst should not immediately conclude, "We need a new website." The analyst must ask:

• Which part is slow?
• Is the issue data entry, approval, payment posting, or scheduling?
• Is the current delay caused by policy, staffing, network limits, or software?
• Who experiences the delay most?
• What evidence exists?

That is what makes the analyst different from someone who only receives feature requests.

Most systems follow some form of life cycle, meaning a sequence of work from idea to operation. The classic model is the Systems Development Life Cycle or SDLC.

A common SDLC flow looks like this:

1. Planning
2. Analysis
3. Design
4. Implementation
5. Testing
6. Deployment
7. Maintenance and review

In real projects, these stages may overlap, but the logic remains useful: understand first, design next, build after, then evaluate.

Several development approaches are commonly discussed in this subject.

Waterfall

Waterfall moves mostly in sequence. One stage is completed before the next begins. It works best when requirements are stable and heavily documented.

Strengths: easy to track by stage; strong documentation; useful in formal environments. Weaknesses: changes are costly later; user feedback may arrive too late.

Prototyping

A prototype is an early model of the system or interface. It is used to gather feedback and clarify requirements.

Best for: unclear user needs; interface-heavy systems; projects where users must react to something visible.

Agile

Agile develops the system in short cycles or iterations. It values user feedback, incremental delivery, and adaptability.

Best for: changing requirements; fast-moving digital products; teams that can collaborate frequently.

RAD and iterative approaches

Rapid Application Development and other iterative methods emphasize faster delivery, repeated refinement, and continuous user input.

For exam purposes, remember this principle:

The best development approach depends on the project's level of uncertainty, stakeholder availability, risk, and need for structure.

Core Outputs to keep in mind: problem statement, objectives, scope and limitations, feasibility study, requirements list, use cases/user stories, DFD/ERD/UML diagrams, interface sketches, data design and controls, test plan, implementation plan. Analysis asks what and why; design asks how.

Review Questions

1. What is the difference between system analysis and system design?
2. Why is it risky to begin coding before requirements are clarified?
3. Give three responsibilities of a systems analyst.
4. Differentiate an end user from a system sponsor.
5. Name four common stages of the SDLC.
6. When is prototyping more suitable than a strict waterfall approach?
7. Why is documentation important in systems projects?
8. How does this subject support a BSIT capstone project?

Worked Exam-Style Problems

Problem 1: Classify the project concerns. A private college wants to improve its student clearance process. Classify each concern as primarily a problem of people, process, data, or technology: approvals take too long; signatories cannot track pending requests; inconsistent cashier and registrar records; students must visit several offices physically.

Step-by-step solution — Look for the dominant cause.

• "Approvals take too long" → Process (workflow speed)
• "Cannot track pending requests" → Technology (missing system functionality)
• "Inconsistent records" → Data (facts not matching across offices)
• "Must visit several offices" → Process (fragmented workflow)

Problem 2: Choose the development approach. A city health office wants a vaccine inventory and clinic appointment system. Staff can review screens weekly, and some requirements may change once nurses see drafts. Waterfall or prototyping/iterative?

Step-by-step solution — Clues: users review weekly; requirements may change; seeing drafts affects decisions. Waterfall fits stable requirements; prototyping/iterative fits changing requirements + frequent review. Answer: Prototyping or iterative development, because requirements are not yet stable and users can give regular feedback.

Problem 3: Distinguish analysis from design. Label each as Analysis or Design:

• Identify what reports the manager needs → Analysis
• Decide the database tables to store transaction history → Design
• Interview users about current delays → Analysis
• Define the validation rules for a mobile registration form → Design
• Write the system objective "reduce average processing time by 40%" → Analysis

Hands-On Practice — Barangay Service Request Tracker. A barangay office receives complaints through paper forms, Facebook messages, and walk-ins; records are duplicated and statuses inconsistent.

1. Write a 3-sentence problem statement.
2. List five stakeholders.
3. Propose two measurable objectives.
4. Choose one development approach and justify it in 3-5 sentences.

Guide: a good problem statement names the difficulty, who is affected, and why improvement matters; good stakeholders include residents, barangay staff, secretary, captain, IT support; objectives should be time/accuracy/tracking-based; prototyping fits if the barangay wants to review sample screens early.

How to Pass This Topic

• Memorize the difference between analysis and design — it appears often.
• To justify a method, use the words requirements stability, user feedback, risk, documentation.
• In essays, always mention people, process, data, and technology.
• Do not confuse stakeholders with project deliverables.
• Be specific. "To improve the system" is weak; "To reduce duplicate records and shorten approval time" is better.