Visualising System Requirements
The Importance of Visualising System Requirements
We need ways to visually convey the requirement because of:
- Clarity: Visuals simplify complex processes, making them easier to understand.
- Communication: They provide a common language for stakeholders, developers, and users.
- Error Reduction: Early visualisation helps identify potential issues before implementation.
Visualizing system requirements is a critical step in the design process, bridging the gap between abstract ideas and concrete implementations.
Types of Requirements Visualisation
System Flowcharts
System Flowcharts provide a high-level view of a system, illustrating how data flows through various components, including hardware, software, and manual processes.
Key Features of System Flowcharts include:
- Data Flow: Arrows indicate the direction of data movement.
- Processes: Rectangles represent operations or tasks.
- Decision Points: Diamonds show where decisions are made.
- Input/Output: Parallelograms depict data entry or retrieval.
- Storage: Cylinders represent databases or files.
When creating a system flowchart, focus on the overall process rather than the details of individual programs.
Imagine taking a book in the library:
- Data Entry: The user scans their library card and the book barcode using a scanner.
- Validation: The system checks if the library card is valid. If not, an error message is shown on the monitor.
- Availability Check: The system verifies if the scanned book is available for checkout. If not, a message is displayed.
- Processing: If both validations pass, the system records the transaction and updates the database
- Output: A receipt with the due date is printed, confirming the checkout.
Use system flowcharts for high-level overviews that include hardware and software interactions.
Data Flow Diagrams (DFDs)
Data Flow Diagrams (DFDs) focus on how data logically moves through a system, highlighting links between parts of the system.
Key Components of DFDs include:
- Processes: Circles or ovals represent operations that transform data.
- Data Flows: Arrows indicate the direction of data movement.
- Data Stores: Open-ended rectangles show where data is stored.
- External Entities: Squares represent sources or destinations of data outside the system.
System Flowchart vs Data Flow Diagram
| Feature | System Flowchart | Data Flow Diagram (DFD) |
|---|---|---|
| Purpose | Shows how data moves through hardware and software systems | Shows how data flows within a system's processes |
| Focus | Emphasizes physical components (e.g., input/output devices, files, programs) | Emphasizes logical flow of data between processes |
| Symbols Used | Includes symbols for input/output, storage, processing, decisions | Uses processes, data stores, data flows, external entities |
| Level of Detail | More technical and specific (e.g., describes files, devices) | More abstract and conceptual (e.g., describes functions) |
| Used By | System designers, developers | Analysts, designers |
| Example Use | Flow of data from a barcode scanner to a database to print receipt | Flow of customer info through an order processing system |
| Represents Decisions? | Yes, by using decision symbols (diamonds) | No, DFDs do not show control flow or decisions |
Do not mix them up!
Imagine again the scenario of the library:
Structure Charts
Structure Charts break down a system into modules, illustrating the hierarchical relationships between functions and sub-functions.
Key Features of Structure Charts include:
- Modularity: Each module performs a specific function.
- Hierarchy: The chart shows how modules are organised, from high-level tasks to detailed sub-tasks.
- Data Flow: Arrows indicate data passed between modules.
Think of a structure chart as a blueprint for a building, where each room (module) serves a specific purpose, and all rooms together form the complete structure.
Imagine splitting a scholarship application system into several modules:
- Application Submission: Students submit forms online.
- Verification: The system checks grades with an external consultant.
- Decision: The application is approved or declined based on the verification.
Structure charts are the best for organising system functions and modular design.
- Always consider the audience when choosing a visualisation.
- Stakeholders may prefer flowcharts for clarity, while developers might need detailed DFDs or structure charts.
When visualising the requirements:
- Keep It Simple: Avoid unnecessary details that can clutter the diagram.
- Use Standard Symbols: Ensure consistency and clarity.
- Validate with Stakeholders: Regularly review diagrams with stakeholders to ensure accuracy and alignment with requirements.
- Can you identify the key components of a system flowchart, DFD, and structure chart?
- How would you choose the appropriate visualisation for a given scenario?
- Why is it important to involve stakeholders in the visualisation process?
- How do visualisations enhance communication between technical and non-technical stakeholders?
- What are the potential consequences of failing to visualise system requirements accurately?
How might these visualisation techniques apply to other areas of problem-solving beyond computer science?
