Systems analysis Study Guide

📖 Core Concepts System analysis – breaking a system into parts to see how they work together and to design procedures that meet the system’s goals efficiently. Feasibility study – first phase that checks economic, social, technological, and organizational viability before any design work. Fact‑finding – gathering end‑user requirements via interviews, questionnaires, observation. Five‑phase structured approach – Scope definition – set clear objectives & stakeholder requirements. Problem analysis – understand needs & formulate possible solutions. Requirements analysis – list conditions the system must satisfy. Logical design – map logical relationships among system objects. Decision analysis – choose the preferred solution. Use case – a modeling tool that describes a business scenario/event and the system’s required response; captures functional requirements. Development models – Waterfall (linear) vs. Spiral (iterative risk‑driven). Policy analysis – applies system‑analysis techniques to evaluate and improve public policies. Related fields – systems thinking, systems theory, cybernetics, systems/software/enterprise architecture. 📌 Must Remember System analysis = analysis (break down) plus synthesis (re‑assemble into improved system). Feasibility study precedes all other phases; if it fails, the project stops. Fact‑finding methods: interviews, questionnaires, observation. Waterfall order: feasibility → fact‑finding → design → implementation → testing. Spiral model loops: risk assessment → requirements refinement → prototype → evaluation. Use cases = who (actor) + what (goal) + system response. Decision analysis = final selection after logical design is complete. 🔄 Key Processes Conduct Feasibility Study Evaluate four dimensions → accept/reject project. Fact‑Finding Choose method(s) → collect user needs → document. Five‑Phase Structured Approach Scope → Problem → Requirements → Logical Design → Decision. Develop Use Cases Identify actors → define scenarios → write “system must …” statements. Select Development Model If requirements are stable → Waterfall; if high risk/uncertain → Spiral. 🔍 Key Comparisons Waterfall vs. Spiral – Linear, fixed phases vs. iterative cycles with continuous risk assessment. Fact‑finding vs. Requirements analysis – Fact‑finding gathers raw user input; requirements analysis refines that input into formal system conditions. System analysis vs. Requirements analysis – System analysis looks at whole system structure; requirements analysis focuses only on what the system must do. ⚠️ Common Misunderstandings “System analysis is only about drawing diagrams.” – It also involves feasibility, decision making, and stakeholder negotiation. “Waterfall means no changes ever.” – Minor refinements can occur, but major scope changes are costly. “Use cases are the same as user stories.” – Use cases are more formal, include full system response; user stories are brief, informal. 🧠 Mental Models / Intuition “Zoom‑out → zoom‑in” – First view the entire system (scope/feasibility), then drill down to components (problem, requirements, design). Risk‑driven loop – In the Spiral model, think of each loop as “ask: what could go wrong? then redesign.” 🚩 Exceptions & Edge Cases When regulatory constraints dominate, feasibility may be non‑economic (e.g., legal feasibility overrides cost). In highly agile environments, a hybrid “mini‑Waterfall” (short cycles) may be used instead of pure Spiral. 📍 When to Use Which Waterfall – stable, well‑understood requirements; regulated industries needing documentation. Spiral – high uncertainty, high risk, or need for frequent stakeholder feedback. Use cases – whenever functional requirements must be clearly communicated to developers and testers. Decision analysis – after logical design when multiple viable solutions exist; use scoring matrices or cost‑benefit analysis. 👀 Patterns to Recognize Feasibility → Fact‑finding → Requirements pattern at the start of any system‑analysis project. Iterative risk → prototype → evaluate pattern signals a Spiral approach. Actor + Goal + System response phrasing indicates a use‑case description. 🗂️ Exam Traps Choosing “Spiral” because it sounds modern – If the question states requirements are stable, the correct answer is Waterfall. Confusing “requirements analysis” with “problem analysis.” – Remember problem analysis is why the system is needed; requirements analysis is what it must do. Selecting “use case” for non‑functional requirements – Use cases capture functional behavior; non‑functional specs need separate documentation. Assuming feasibility is only financial. – The exam may test knowledge of economic, social, technological, organizational dimensions.