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.