Welcome to Systems Analysis!

Imagine setting out to build a dream house without asking the future owner how many bedrooms they need, whether they prefer a garage or a garden, or what their budget is. The project would almost certainly end in disaster! In software and systems development, jumping straight into building without a clear plan leads to what experts call the software crisis — systems that are delivered late, cost too much, or completely fail to do what users actually need.

The Analysis stage of the Systems Development Life Cycle (SDLC) is all about investigating the current system, understanding what the business and its users truly require, and planning the foundation for the new system. In this chapter, you will master the five main fact-finding techniques, learn how to draw and validate Data Flow Diagrams (DFDs), and discover the key documentation produced during this phase. Let's break it down step-by-step!

1. Purpose and Role of the Analysis Stage

Systems Analysis is the investigation of an existing system (whether it is manual, paper-based, or an older digital system) to understand its strengths and weaknesses, define user and business requirements, and formulate clear functional and non-functional specifications for the proposed replacement.

Why is Analysis so vital?

  • Bridges the Communication Gap: Business clients often talk in everyday business language (e.g., "We need faster invoicing"), while developers think in code, databases, and network architecture. The systems analyst acts as a translator between user expectations and technical design.
  • Prevents System Failure: By thoroughly defining requirements before writing any code, organisations avoid wasted development time, costly redesigns, and user dissatisfaction.

Quick Key Takeaway: Analysis ensures developers build the right system the first time, directly preventing the software crisis by aligning user needs with technical goals.

2. Fact-Finding Techniques (Information Gathering)

How does a systems analyst find out what is actually going on inside an organisation? They use five standard fact-finding techniques. Each method has distinct strengths and limitations, and a good analyst usually combines several methods to get a complete picture.

Memory Trick: Remember the acronym I-Q-F-O-D ("I Question Facts On Demand") for Interviews, Questionnaires, Focus groups, Observation, and Document sampling.

1. Questionnaires / Surveys

Written sets of questions distributed on paper or online to collect structured feedback from respondents.

  • Strengths:
    • Inexpensive and cost-effective.
    • Can reach geographically dispersed users simultaneously.
    • Provides anonymity, which encourages honest, candid feedback.
    • Easy to collate into quantitative (numerical/statistical) data.
  • Limitations:
    • Often suffers from low response rates.
    • Inflexible — if a question is ambiguous, respondents cannot ask for clarification.
    • Closed questions lack qualitative depth and nuance.

2. Interviews

One-on-one, direct conversations between the systems analyst and key stakeholders (such as managers or end-users).

  • Strengths:
    • Provides rich, detailed qualitative data.
    • The interviewer can read non-verbal cues and body language.
    • Highly adaptable — the analyst can ask probing follow-up questions to explore unexpected issues.
  • Limitations:
    • Very time-consuming to prepare, conduct, and transcribe.
    • Costly in terms of staff hours.
    • Susceptible to interviewer bias.
    • Interviewees may give the "perceived correct" answer rather than their genuine view.

3. Observation

The analyst watches staff perform their day-to-day tasks within the working environment.

  • Strengths:
    • Provides direct, first-hand evidence of the actual workflow rather than relying on user memory.
    • Excellent for identifying bottlenecks, physical workspace inefficiencies, and delays.
  • Limitations:
    • The Hawthorne Effect: Staff often change their behaviour, work faster, or follow rules more rigidly simply because they know they are being watched.
    • An atypical day (e.g., quiet periods or sudden system outages) may give a distorted, unrepresentative picture of regular operations.

4. Document Sampling / Inspection

Collecting and reviewing existing paper trails, order forms, invoices, receipts, error logs, and user manuals used in the current system.

  • Strengths:
    • Identifies exact data structures, required input fields, and transaction volumes.
    • Gives an objective, factual record of system inputs and outputs.
  • Limitations:
    • Documentation may be outdated or rarely updated.
    • Misses unofficial "workarounds" that staff have developed to bypass official paper forms.

5. Focus Groups / Workshops

Facilitated group sessions bringing together stakeholders from different departments to discuss system requirements collaboratively.

  • Strengths:
    • Encourages collaborative brainstorming and creative problem-solving.
    • Quickly uncovers cross-departmental requirements and conflicting priorities.
  • Limitations:
    • Dominant personalities can take over the discussion and suppress quieter voices.
    • Can be difficult to schedule and coordinate when many key staff are involved.

Quick Key Takeaway: No single fact-finding method is perfect. Analysts combine quantitative methods (like questionnaires) with qualitative methods (like interviews and focus groups) and objective reviews (like observation and document sampling) to understand requirements fully.

3. System Modelling: Data Flow Diagrams (DFDs)

Once the analyst gathers all the facts, they model the movement of data through the system using Data Flow Diagrams (DFDs). A DFD shows where data comes from, how it is processed, where it is stored, and where it goes.

CCEA Standard DFD Notation & Symbols

Make sure you use the official CCEA shapes and naming rules:

  • External Entity (Rectangle / Box): A person, organisation, or external system outside the system boundary that sends data into the system (a source) or receives data from it (a sink).
    Example: Customer or Bank.
  • Process (Rounded Rectangle or Circle): An operation or transformation applied to incoming data. It MUST be named using an active verb-noun phrase.
    Correct: Validate Customer Order or Process Payment.
    Incorrect: "Customer Order" or "Payment Data" (these are nouns, not actions!).
  • Data Store (Open Rectangle / Two Parallel Lines): A repository where data is held for later use (e.g., a database table or paper file). It is labelled with a plural noun.
    Example: Customer Records or Product Details.
  • Data Flow (Directed Arrowhead Line): Shows the movement of data between components. The arrow shows the direction of flow and MUST be labelled with a specific noun/data item.
    Example: Order Details or Payment Status.

Levels of DFDs

  1. Level 0 (Context Diagram):

    Provides a high-level overview of the entire system. The entire system is drawn as a single process in the centre, connected only to external entities by boundary data flows. It contains no data stores and no internal sub-processes.

  2. Level 1 DFD:

    Decomposes (breaks down) the single system process from Level 0 into its major internal sub-processes, adds data stores, and maps out internal data flows while remaining strictly consistent with the external entities from Level 0.

Core DFD Validation Rules (Avoid These Traps!)

Examiners frequently test whether you can spot modelling errors. Watch out for these three vital rules:

  • Black Hole Error: A process that has inputs coming in, but produces no outputs. Data goes in and vanishes!
  • Miracle Error: A process that produces outputs without receiving any inputs. Data appears magically from nowhere!
  • Direct Connection Violations: In a valid DFD, data cannot flow directly between:
    • Entity to Entity (outside the system scope).
    • Data Store to Data Store (data cannot move itself without being processed).
    • External Entity to Data Store (an external user cannot write straight into a database without an intervening system process).
    Golden Rule: Every data flow must connect to at least one Process!

Quick Key Takeaway: Processes need active verb-noun labels, data flows need arrows and noun labels, and data can never jump straight from an entity to a store without passing through a process.

4. Key Deliverables of the Analysis Phase

The Analysis phase concludes with formal documentation that serves as the blueprint for the subsequent Design phase:

  1. User Requirements Specification (URS):

    Written in clear, accessible business language from the customer's and end-user's viewpoint. It outlines what the user expects the system to achieve.

  2. System / Functional Requirements Specification (SRS / FRS):

    A comprehensive technical document detailing the exact inner workings of the proposed solution. It defines:

    • Input data and user interface requirements.
    • System outputs, reports, and alerts.
    • Calculations and processing logic.
    • Data validation rules.
    • Security constraints and performance parameters (e.g., response times, user access levels).
  3. Data Dictionary:

    A centralised, structured catalog that defines every piece of data used in the system. It records field names, data types (e.g., Text, Integer, Date), field lengths, descriptions, and specific validation rules for all system data entities and attributes.

Quick Key Takeaway: The URS records what the user wants; the SRS/FRS records the detailed technical functions developers must build; and the Data Dictionary defines every individual data field.

5. Common Pitfalls & How to Avoid Them

  • Informal / Vague Language: Do not write informal phrases like "cost" or "how easy it is". Use proper terminology such as economic feasibility, budgetary constraints, and operational feasibility / usability.
  • Static DFD Process Names: Always use active verb-noun phrases (e.g., Validate Customer Order, not Customer Order).
  • Missing Arrows & Labels: Every flow line on a DFD must have an arrowhead indicating direction and a noun describing the data moving along it.
  • Bypassing Processes: Never draw an arrow directly connecting an External Entity to a Data Store. Always place a Process in between.
  • Ignoring the Exam Scenario: In extended-response and Quality of Written Communication (QWC) questions, always relate fact-finding methods directly to the business scenario given in the question rather than just giving generic definitions.

Summary Checklist for Revision

  • [ ] Can you define Systems Analysis and explain its role in preventing the software crisis?
  • [ ] Can you evaluate all five fact-finding techniques (Questionnaires, Interviews, Observation, Document Sampling, Focus Groups) including their strengths and limitations?
  • [ ] Can you explain the Hawthorne Effect in the context of observation?
  • [ ] Do you know the four standard CCEA DFD symbols and their naming conventions?
  • [ ] Can you distinguish between a Level 0 Context Diagram and a Level 1 DFD?
  • [ ] Can you identify Black Hole, Miracle, and Direct Connection errors on a DFD?
  • [ ] Can you describe the three main deliverables: URS, SRS/FRS, and the Data Dictionary?