Welcome to the Analysis Stage!
Welcome to your study notes for the Analysis stage of systems development. If you have ever tried to bake a cake without reading the recipe, or built flat-pack furniture without the manual, you know that jumping straight into the action usually leads to a mess. In software and systems development, jumping straight into programming without understanding the problem is a recipe for disaster!
The Analysis stage is all about investigating the existing system, finding out what is wrong (or what can be improved), and figuring out exactly what the new system must do. Don't worry if this seems a bit detailed at first — we will break everything down into bite-sized, easy-to-remember chunks.
1. The Systems Analyst and the Goal of Analysis
The person in charge of this stage is the Systems Analyst. Think of them as a technology detective. They look at clues, interview people, inspect documents, and identify how a business currently works and where the bottlenecks are.
The main goals of the Analysis stage are:
• To fully understand the current system (strengths, weaknesses, and limitations).
• To discover what the users actually need from a new system.
• To establish whether a new system is possible and beneficial.
• To produce a formal User Requirements Specification (also called a System Specification).
Key Takeaway
The Analysis stage is not about writing code. It is about understanding the problem thoroughly so that the developers can build the right solution.
2. Fact-Finding Techniques (Information Gathering)
How does a systems analyst find out what is going on in an organisation? They use Fact-Finding Techniques. There are four main methods you need to know for your exam.
Memory Trick: Remember the acronym I-Q-O-D (Interviews, Questionnaires, Observation, Document Inspection).
A. Interviews
The analyst sits down one-on-one with managers, staff, or clients to ask direct questions about their daily work and system problems.
Advantages:
• In-depth feedback: The analyst can ask follow-up questions if an answer is unclear.
• Non-verbal cues: You can see facial expressions and body language, showing if someone is hesitant or frustrated.
• Complex topics: Great for discussing complicated issues with senior managers.
Disadvantages:
• Time-consuming: Setting up and conducting interviews with lots of people takes a long time.
• Expensive: Pulls staff away from their actual work.
• Bias: Interviewees might give answers they think the boss wants to hear.
B. Questionnaires (Surveys)
A set of pre-written questions (open or closed) sent out to a large group of users either on paper or online.
Advantages:
• Large reach: Can collect data from hundreds of people across different locations very quickly.
• Cost-effective: Cheap to distribute (especially online forms).
• Anonymity: Staff can answer honestly without fear of being judged by managers.
• Easy analysis: Closed questions (e.g., multiple choice) are easy to turn into statistical graphs.
Disadvantages:
• Low response rate: Many people simply ignore or bin questionnaires.
• Inflexible: You cannot ask spontaneous follow-up questions to clarify vague answers.
• Poor design risks: Poorly phrased questions can lead to misleading results.
C. Observation
The analyst watches staff members doing their jobs in real-time to see how data actually moves and where delays occur.
Advantages:
• First-hand evidence: The analyst sees what actually happens, not what staff say happens.
• Identifies hidden steps: Uncovers shortcuts or informal workarounds that staff might forget to mention.
Disadvantages:
• The Hawthorne Effect: People often work faster or differently when they know someone is watching them with a clipboard!
• Disruptive: Can make employees feel nervous or uncomfortable.
• Limited snapshot: The analyst might not observe rare errors or peak seasonal rushes during their visit.
D. Document Inspection (Sampling)
The analyst examines existing paperwork, such as order forms, invoices, receipts, spreadsheets, error logs, and policy manuals.
Advantages:
• Accurate data types: Shows the exact inputs and outputs currently in use (e.g., field names, code structures).
• Zero disruption: Can be done without interrupting daily operations.
Disadvantages:
• Outdated material: Documents may not reflect how people currently work.
• Information overload: Sifting through large volumes of forms can be slow and tedious.
Quick Review: Which Method Should You Pick?
• Need fast opinions from 500 branch employees? Questionnaire
• Need detailed strategic goals from the Managing Director? Interview
• Need to verify if the checkout process really takes 4 minutes? Observation
• Need to know what fields are on the customer invoice? Document Inspection
3. Defining System Requirements
Once the analyst has gathered all the facts, they organise the findings into Requirements. Requirements tell the development team what the system must accomplish.
Functional Requirements
These describe what the system must do — the specific features, functions, and tasks it has to carry out.
Examples of Functional Requirements:
• The system must calculate sales tax at \(20\%\).
• The system must send a confirmation email when an order is placed.
• The system must allow users to search for books by ISBN or Author.
Non-Functional Requirements
These describe how well the system performs — its quality attributes, constraints, and operational criteria.
Examples of Non-Functional Requirements:
• Performance / Speed: Search results must load in under \(1.5\) seconds.
• Security: All customer passwords must be encrypted using 256-bit encryption.
• Availability: The system must be operational \(99.9\%\) of the time.
• Usability: The interface must adhere to accessibility standards for visually impaired users.
Common Mistake to Avoid: Don't mix these up! If it describes an action or task ("System sends an alert"), it is functional. If it describes a quality standard or rule ("Alert must arrive within 2 seconds"), it is non-functional.
4. System Modelling: Data Flow Diagrams (DFDs)
Words can sometimes be misunderstood, so analysts use visual diagrams to model how data moves through a system. The most important diagram at AS Level is the Data Flow Diagram (DFD).
A DFD shows the path data takes, how it changes, and where it is stored. It does not show programming logic (like IF-statements or loops) — it only tracks data.
The Four Core Symbols of a DFD
• External Entity (Source / Sink): Represented by a Rectangle. People or systems outside the boundary of this system that supply data (Source) or receive data (Sink). Example: Customer, Bank.
• Process: Represented by a Rounded Rectangle or Circle. An action that changes or transforms data. Processes must always have a verb in their name. Example: "Calculate Total", "Validate Password".
• Data Store: Represented by an Open-ended Rectangle (or two parallel lines). A place where data is held for later use (like a database table or file). Example: Customer Database, Product Catalog.
• Data Flow: Represented by an Arrow. Shows the direction data travels between entities, processes, and data stores. The arrow must have a label naming the data being moved (e.g., "Order Details").
Levels of DFDs
• Context Diagram (Level 0): A high-level overview. It shows the entire system as just one single central process with data flowing to and from external entities. No data stores are shown at this top level.
• Level 1 DFD: "Zooms in" on that single process, breaking it down into major sub-processes, showing data stores and detailed internal data flows.
Golden Rules for DFDs:
1. Data cannot travel directly from an External Entity to another External Entity (the system wouldn't even know it happened!).
2. Data cannot travel directly from a Data Store to another Data Store without being handled by a process.
3. Every process must have at least one input and at least one output (no "black holes" where data enters and vanishes, and no "miracles" where data is created from nothing!).
5. The Data Dictionary
While a DFD shows the flow of data, a Data Dictionary explains the exact technical details of every single piece of data stored in the system. It is a central catalogue describing data structures.
A typical Data Dictionary entry includes:
• Field Name: A unique, sensible identifier (e.g., CustomerID, DateOfBirth).
• Data Type: The type of data it holds (e.g., Text/String, Integer, Boolean, Date/Time).
• Field Size / Length: The maximum number of characters allowed (e.g., 8 characters for a Postcode).
• Validation Rules: Checks applied to prevent bad data entry (e.g., Range check: \(18 \le \text{Age} \le 65\); Format check: LLNN NLL for UK postcodes).
• Description / Purpose: A brief explanation of what the field is used for.
6. The Deliverable: Requirements Specification
The Analysis stage concludes with a formal document called the User Requirements Specification (URS) or System Specification.
This document acts as an official agreement between the client (the business) and the systems developers. It contains:
• Detailed descriptions of the current system's problems.
• Full lists of Functional and Non-Functional requirements.
• Data models (DFDs, Data Dictionaries).
• Hardware and software constraints.
• Project scope and success criteria.
Why is this document so critical?
Both parties must read and "sign off" (agree) on this specification. It prevents scope creep (where the client keeps demanding extra features later without paying more) and provides a checklist for the Evaluation and Testing stages later in the systems lifecycle.
Chapter Summary Checklist
Before moving on, make sure you can:
• Describe the role of a Systems Analyst.
• Compare the 4 fact-finding techniques (Interviews, Questionnaires, Observation, Document Inspection).
• Distinguish between Functional and Non-Functional requirements.
• Identify and explain the 4 symbols used in Data Flow Diagrams (Process, Data Store, Data Flow, External Entity).
• Explain the purpose of a Context Diagram vs a Level 1 DFD.
• List the standard contents of a Data Dictionary entry.
• Explain why a formal Requirements Specification is signed off at the end of the analysis stage.