Structured Analysis and Design - CSU1296 - Shoolini U

Structured Analysis and Design

2025, April 04

1. Introduction to Structured Analysis and Design

Structured Analysis and Design is a disciplined approach to understand, analyze, and design systems in a logical, graphical, and modular way. It breaks down complex problems into simpler, visual components to ensure clarity, communication, and maintainability.

1.1 What is Structured Analysis and Design?

Structured Analysis and Design (SAD) is a two-phase method that first analyzes what a system should do (Structured Analysis), and then transforms that understanding into a logical, implementable system design (Structured Design).

It is based on graphical modeling, data flow, modular decomposition, and logical relationships between system elements.

Key tools used:

1.2 Why is Structured Analysis and Design Needed?

Large software systems fail when not structured properly. SAD provides clarity by turning vague requirements into visual, structured, and implementable components. It allows teams to divide responsibility, validate logic early, and make future changes easier.

1.2.1 Real-World Analogy

Think of constructing a hospital. You wouldn’t begin laying bricks without:

Likewise, SAD helps in designing software before coding begins.

1.2.2 Benefits

1.3 When to Use Structured Analysis and Design?

Use SAD when the project:

1.3.1 When NOT to Use

2. Requirement Analysis

Requirement Analysis is the first and most critical step in Structured Analysis. It ensures that the system solves the right problem before solving the problem right. It captures what the system must do, what users expect, and what limitations must be respected.

2.1 Identify Functional and Non-Functional Requirements

2.1.1 Functional Requirements

These define specific actions the system must perform. They are directly tied to user goals.

2.1.2 Non-Functional Requirements

These define how well the system performs. They are the quality attributes.

2.1.3 Real-World Scenario

For an online shopping site:

2.2 Understand User Expectations and System Constraints

2.2.1 User Expectations

Focus on the actual needs of users — not what they say, but what they do.

2.2.2 System Constraints

Limitations due to environment, policy, technology, or budget.

2.2.3 Real-World Analogy

If building a bridge, user expectation is smooth and fast travel. Constraint may be soil quality or budget.

In software, the same principle applies: build for what users need, but within what’s possible.

2.3 Clarify Scope and Boundaries

Define what is included in the system and what is not. This prevents scope creep and ensures clear responsibility.

2.3.1 Scope

Everything the system will support or automate.

2.3.2 Boundaries

Interfaces with external systems or areas not being developed.

2.3.3 Visualize Scope with Context Diagram
graph TB
User((User))
System[Hospital Management System]
Payment[Payment Gateway]
User -->|Books Appointment| System
System -->|Sends Payment Details| Payment

Clarifying scope helps you say “no” to unnecessary features and keeps the project focused.

3. Data Flow Diagrams (DFD)

A Data Flow Diagram (DFD) is a graphical tool used in Structured Analysis to visualize how data moves through a system. It focuses on what the system does with the data, not how it is implemented.

DFD simplifies complexity by showing inputs, processes, outputs, and storage in a system using clear, standardized symbols.

3.1 What is a DFD?

A DFD represents the flow of data between external entities, processes, and data stores in a system. It helps analysts, users, and developers understand the logic of the system at different levels of detail.

3.1.1 Real-World Analogy

Imagine a food delivery system:

DFD maps this flow logically using symbols instead of technical code.

3.2 DFD Levels: 0, 1, 2

3.2.1 Level 0 – Context Diagram

Shows the system as a single process with all external entities. It’s like viewing the entire company from space.

graph TB
User((User))
System[Food Delivery System]
Restaurant((Restaurant))
PaymentGateway((Payment Gateway))
User -->|Order Request| System
System -->|Send Order| Restaurant
System -->|Payment Details| PaymentGateway
3.2.2 Level 1 – Top-Level Diagram

Breaks the system into major sub-processes. Shows how data flows between these sub-processes and external entities.

3.2.3 Level 2 – Detailed Functional Decomposition

Drills down a Level 1 process into more granular sub-processes. This is where each process's internal logic becomes visible.

This hierarchical view allows step-by-step understanding of the system.

3.3 Symbols Used in DFD

Symbol Component Meaning
Rectangle External Entity Outside system boundary (e.g., User, Bank)
Circle or Rounded Box Process Transforms data (e.g., Validate Login)
Open-ended Rectangle (Parallel Lines) Data Store Stored data used by the system (e.g., Database)
Arrow Data Flow Movement of data between components

Each symbol plays a critical role in visualizing how input is processed into output logically.

4. Entity Relationship Diagram (ERD)

An Entity Relationship Diagram (ERD) is a structured visual representation of data objects (entities), their attributes, and how they relate to each other. It is used in Structured Analysis to model the data layer logically before creating the database.

4.1 Purpose of ERD

ERD helps in understanding, organizing, and communicating the data requirements of the system. It ensures the database structure reflects real-world business rules and prevents data redundancy or inconsistency.

4.1.1 Real-World Analogy

In a college system:

ERD acts as a blueprint before building the actual database schema.

4.2 Entities, Attributes, Relationships

4.2.1 Entities

An Entity is a real-world object with identifiable properties. It becomes a table in a database.

4.2.2 Attributes

Properties that describe an entity.

4.2.3 Relationships

Defines how entities are related.

erDiagram
    STUDENT ||--o{ ENROLLMENT : enrolls
    COURSE ||--o{ ENROLLMENT : includes
    STUDENT {
      string roll_no PK
      string name
      date dob
    }
    COURSE {
      string course_id PK
      string title
    }
    ENROLLMENT {
      date enrolled_on
    }

4.3 Normalization Concepts

Normalization is the process of organizing data to minimize redundancy and ensure data integrity.

4.3.1 Goals of Normalization
4.3.2 Common Normal Forms
Normal Form Condition
1NF Atomic values (no repeating groups or arrays)
2NF 1NF + No partial dependency on composite key
3NF 2NF + No transitive dependencies (non-key depending on non-key)
4.3.3 Real-World Example

Without normalization:


Student(RollNo, Name, Course1, Course2)

After 1NF and 2NF:


Student(RollNo, Name)
Enrollment(RollNo, Course)

This separation makes querying, updating, and scaling much easier and consistent.

5. Data Dictionary

A Data Dictionary is a centralized repository that defines and describes every data element used in the system. It acts like a glossary of all variables, fields, and data flows, ensuring clarity, consistency, and control in data usage across the system.

5.1 What is it?

It is a reference document that lists all data items—what they mean, how they're used, and how they are related. It is essential for both developers and analysts to speak the same language when designing or implementing a system.

5.1.1 Real-World Analogy

Just like a medical dictionary helps doctors use consistent terms for symptoms and diagnoses, a data dictionary ensures that everyone in a software team interprets "customer_id" or "status_code" the same way.

5.2 Usage of Data Dictionary

It is used to:

5.2.1 Integration with DFD & ERD

Every element in a DFD (e.g., data flows, stores, processes) and ERD (e.g., attributes, keys) must be documented in the data dictionary for traceability.

5.3 Includes in Data Dictionary

The following are commonly defined for each data item:

Element Description
Name Unique name of the data element
Alias Alternate name(s) used elsewhere
Description What the data element represents
Type Data type (e.g., Integer, String, Date)
Length Maximum size (e.g., 50 characters)
Format Expected format (e.g., YYYY-MM-DD)
Valid Values Allowed values (e.g., status: Active, Inactive)
Default Value Assigned if user doesn't provide one
Source Where the data originates from
5.3.1 Sample Entry

{
  "name": "customer_id",
  "alias": ["cust_id", "cid"],
  "description": "Unique identifier for a customer",
  "type": "String",
  "length": 10,
  "format": "CUST#####",
  "valid_values": null,
  "default_value": "CUST00000",
  "source": "User Registration Form"
}

6. Process Specifications (PSPEC)

Process Specification (PSPEC) defines the internal logic of each process in a Data Flow Diagram (DFD). It bridges the gap between what a system should do (functional model) and how each part will do it (logic model).

PSPEC ensures that processes are precisely defined, unambiguous, and ready for implementation or testing.

6.1 Structured English

Structured English is a limited form of natural language with clearly defined keywords to express logic. It combines the familiarity of English with the precision of programming.

6.1.1 Key Elements
6.1.2 Example

IF cart is not empty THEN
   CALCULATE total cost
   IF total cost > 1000 THEN
      APPLY 10% discount
   ELSE
      NO discount
ENDIF
6.1.3 When to Use

Best for describing simple logic in a human-readable but structured format.

6.2 Decision Tables

A decision table is a tabular method to represent complex conditional logic, especially when there are multiple rules or combinations of inputs.

6.2.1 Structure
Conditions Rule 1 Rule 2 Rule 3
Amount > 1000 Yes No No
Customer is Premium No Yes No
Action 10% Discount 5% Discount No Discount
6.2.2 When to Use

Use decision tables when:

6.3 Flowcharts

Flowcharts are graphical representations of the logic inside a process. They use standardized symbols to describe the flow of control.

6.3.1 Symbols
6.3.2 Example
flowchart TD
  Start([Start])
  CheckCart{Cart is Empty?}
  Calc[Calculate Total]
  Discount{Total > 1000?}
  Apply10[Apply 10% Discount]
  NoDisc[No Discount]
  End([End])

  Start --> CheckCart
  CheckCart -- No --> Calc
  CheckCart -- Yes --> End
  Calc --> Discount
  Discount -- Yes --> Apply10 --> End
  Discount -- No --> NoDisc --> End
6.3.3 When to Use

Best for illustrating logic that involves multiple steps, conditions, and loops — especially helpful for visual learners or stakeholders during reviews.

7. Structured Design Principles

Structured Design transforms the "what" from Structured Analysis into "how" — creating a well-organized architecture ready for coding. It follows proven principles to ensure the system is logical, efficient, maintainable, and scalable.

7.1 High Cohesion & Low Coupling

7.1.1 High Cohesion

Cohesion measures how strongly related and focused the functions within a single module are. High cohesion means a module does one thing well.

7.1.2 Low Coupling

Coupling measures how much one module depends on another. Low coupling means modules can work independently.

7.1.3 Real-World Analogy

In a car: Engine, brakes, and music system are cohesive modules. If you replace the music system, the brakes shouldn't stop working — that's low coupling.

7.2 Modularization

Modularization is the process of dividing the system into independent, logical units (modules) such that each module handles a specific responsibility.

7.2.1 Benefits
7.2.2 Example

Online Store Modules: Authentication, Product Catalog, Shopping Cart, Payment, Notification

graph TD
  A[Main System]
  A --> B[Authentication]
  A --> C[Catalog]
  A --> D[Cart]
  A --> E[Payment]
  A --> F[Notifications]

7.3 Maintainability & Reusability

7.3.1 Maintainability

Structured design ensures the system is easy to fix, update, and improve. This is achieved by using clear documentation, separation of concerns, and consistent naming conventions.

7.3.2 Reusability

Design modules in a way that they can be reused in other systems with minimal modification.

7.3.3 Practices That Support Reusability

8. Structure Chart

A Structure Chart is a hierarchical diagram used in Structured Design to represent the organization of modules and their relationships. It shows which modules call which other modules, how data flows between them, and how control is transferred.

8.1 What is it?

It depicts the breakdown of a system into functional modules. Unlike flowcharts (which focus on logic), a structure chart shows program structure and interactions between procedures, making it essential for top-down design.

8.1.1 Real-World Analogy

Think of an office:

A structure chart represents this exact command-and-control hierarchy in software.

8.2 Symbols & Arrows

Symbol Meaning
Rectangle Module or subprogram (e.g., calculateTax)
Vertical Line Hierarchy: control flow from parent to child module
Arrow (downward) Control passing (invoking a sub-module)
Arrow (horizontal with label) Data passed between modules (parameters)
Double horizontal line Library/Reusable Module
8.2.1 Example Structure Chart
graph TD
  A[Main Program]
  A --> B[Input Module]
  A --> C[Process Order]
  A --> D[Generate Invoice]
  C --> E[Check Inventory]
  C --> F[Calculate Total]
  D --> G[Send Email Confirmation]

8.3 Helps in

8.3.1 Use Case Example

In a Payroll System:

This logical hierarchy enables smooth delegation, testing, and integration.

9. Interface, Database & Control Design

These three components form the core of how the user interacts with the system (Interface), how the system stores and manages data (Database), and how the logic flows inside the system (Control). A well-designed system ensures all three are aligned, efficient, and user-friendly.

9.1 Interface Design

Interface Design defines how users interact with the system through screens, forms, buttons, inputs, and feedback. It emphasizes usability, clarity, and consistency.

9.1.1 Key Elements
9.1.2 Best Practices
9.1.3 Real-World Example

ATM Screen Interface: Simple buttons for Withdraw, Deposit, Check Balance — no training needed.

9.2 Database Design

Database Design involves organizing the structure of data storage to ensure efficient retrieval, integrity, and minimal redundancy. It is based on the ERD and refined using normalization.

9.2.1 Steps in Database Design
9.2.2 Best Practices
9.2.3 Sample Table Structure

CREATE TABLE Student (
  roll_no VARCHAR(10) PRIMARY KEY,
  name VARCHAR(50),
  dob DATE
);

CREATE TABLE Enrollment (
  roll_no VARCHAR(10),
  course_id VARCHAR(10),
  enrolled_on DATE,
  PRIMARY KEY (roll_no, course_id),
  FOREIGN KEY (roll_no) REFERENCES Student(roll_no)
);

9.3 Control Flow Design

Control Flow Design determines how decisions, processes, and sequences are managed inside the system. It ensures the system reacts properly to user inputs, errors, and process conditions.

9.3.1 Includes
9.3.2 Flowchart Example
flowchart TD
  A[Start]
  B{Is user logged in?}
  C[Redirect to Login Page]
  D[Show Dashboard]
  A --> B
  B -- No --> C
  B -- Yes --> D
9.3.3 Best Practices
9.3.4 Real-World Analogy

In a restaurant kitchen: Orders are taken, queued, processed, errors are managed (e.g., out of stock), and responses are sent. That's a real-time control flow.

10. Evaluation

Evaluating Structured Analysis and Design involves weighing its strengths and weaknesses in real-world scenarios. While it provides structure and clarity for complex systems, it may not fit all environments, especially those needing rapid iterations.

10.1 Advantages of Structured Analysis and Design

10.2 Disadvantages of Structured Analysis and Design

10.3 A Project to Practice Structured Analysis and Design

10.3.1 Project: Student Attendance Management System

Build a system to manage attendance for a college or school. It should support:

10.3.2 Apply SAD Techniques
10.3.3 Tools Suggested

10.4 Conclusion

Structured Analysis and Design is a powerful methodology for building complex systems. By following its principles, you can ensure that your system is well-structured, maintainable, and scalable. However, be mindful of its limitations in fast-paced environments.