Structured Analysis Methodology
Structured Analysis (SA) is a systematic software engineering approach for requirements analysis and system modeling. It employs graphical and textual artifacts to represent system functionality, data flows, and structural relationships, enabling development teams and stakeholders to understand both business and technical requirements. This methodology emphasizes detailed examination of system logic and data organization, commonly applied in waterfall development models.
Core Structured Analysis Artifacts
Data Flow Diagram (DFD)
DFDs visually represent system data movement and processing activities through hierarchical decomposition:
- Context Diagram (Level 0): Defines system boundaries, external entities, and primary data flows
- Detailed DFDs (Level 1+): Decomposes processes into finer-grained components
Notation elements include:
- External Agent: System boundary interfaces
- Process: Transformation activities
- Data Repository: Persistent storage locations
- Data Pathway: Information movement routes
+----------------+ +----------------+ +----------------+
| Inventory Clerk|---->| Order Processing|---->| Customer Records|
+----------------+ +----------------+ +----------------+
Data Dictionary
Provides precise definitions for all data elements referenced in DFDs:
Data Element:
- ProductCode (type: string, length: 12, format: XXX-999999)
- UnitPrice (type: decimal, precision: 2, range: 0.01-9999.99)
Composite Structure:
- PurchaseRecord
- ProductCode
- Quantity
- OrderDate
Data Pathway:
- NewPurchase
- Origin: OrderProcessing
- Destination: BillingSystem
- Composition: PurchaseRecord
Data Repository:
- CustomerProfileDB
- Contents: CustomerID, Name, ContactDetails
- Access: Read/Write
Process Logic:
- CalculateInvoice
- Input: PurchaseRecord
- Output: InvoiceDocument
- Rules: Apply pricing rules and tax calculations
Entity-Relationship Diagram (ERD)
Models data structures and relationships between system entities:
+--------------+ +-------------+ +-----------+
| Professor | | Course | | Student |
+--------------+ +-------------+ +-----------+
| - FacultyID | | - CourseID | | - StudentID |
| - Name | | - Title | | - Name |
| - Department | | - Credits | | - Major |
+--------------+ +-------------+ +-----------+
| | |
| 1 teaches M | M enrolled by N |
|_______________________|______________________|
State Transition Diagram
Illustrates behavioral state changes in response to events:
+--------------+ +-------------+ +--------------+
| Application |-----> | UnderReview|-----> | Approved |
| Received | | | | |
+--------------+ +-------------+ +--------------+
^ | |
|_________Rejected______|___________Revoked_____|
Decision Matrix
Tabular representation of complex business rules:
Structured Specification Language
Pseudocode-like notation for process logic:
IF paymentMethod = 'CreditCard' AND verificationPassed THEN
CONFIRM transaction
ELSE IF paymentMethod = 'Invoice' AND creditApproved THEN
GENERATE receipt
ELSE
REJECT transaction
Structured Analysis Process
- Requirements Elicitation
- Stakeholder interviews and workshops
- Existing system documentation review
- Requirements Analysis
- Functional capaiblity identification
- Performance criteria specification
- Security constraints definition
- System Modeling
- DFD development
- Data dictionary population
- ERD construction
- Requirements Validation
- Prototype demonstration
- Scenario-based user testing
- Documentasion
- Formal specification compilation
- Structured review sessions
Methodology Evaluation
Advantages:
- Visual clarity through diagrammatic representations
- Comprehensive requirement traceability
- Structured decomposition approach
Limitations:
- Limited support for dynamic behavior modeling
- Scalability challenges in complex systems
- Reduced adaptability to iterative development