🎓 SEM III Exam Prep Syllabus Portal
🏠 Home
📖 2413MJCT303 • Unit I • 6 Hrs

Unit I - Introduction to development approach SSAD and OOAD

Comprehensive University Exam Preparation Notes, Model Question Answers & Comparison Matrices

🔍
📑 Quick Jump Navigation

📌 Syllabus Topics Covered

6 Hrs Weightage

📖 Comprehensive Theoretical Notes

Exam-Oriented Theory

1.1 SSAD vs OOAD & Roles in SDLC

Structured System Analysis and Design (SSAD): A process-centric paradigm that separates data from functions using Data Flow Diagrams (DFDs), Entity-Relationship (ER) diagrams, and Structure Charts. Functions act upon passive global data stores.

Object-Oriented Analysis and Design (OOAD): Encapsulates data attributes and behavioral operations into unified entities called Objects. Emphasizes real-world mapping, modularity, abstraction, and reusability.

Key Stakeholders and Roles in SDLC:

  • Business Analyst / System Analyst: Elicits user requirements, conducts feasibility studies, authors the Software Requirement Specification (SRS).
  • System Architect & Designer: Creates high-level architectural designs, UML class/component diagrams, and database schemas.
  • Software Developers: Implements code, conducts unit testing, and integrates modules.
  • Quality Assurance (QA) / Testers: Designs test plans, executes black-box/white-box test cases, logs defect reports.
  • Project Manager: Manages project scope, budget, milestones, risk assessment, and resource allocation.
  • End-Users & Clients: Provide business domain requirements and execute User Acceptance Testing (UAT).

1.2 SDLC Models: Waterfall, Spiral, Prototyping, and RAD

Comparison of Core Process Models:

  • Waterfall Model: Linear-sequential lifecycle (Requirements $\rightarrow$ Design $\rightarrow$ Implementation $\rightarrow$ Verification $\rightarrow$ Maintenance). High rigidity; changes in later phases are prohibitively expensive. Ideal for projects with completely stable, well-understood requirements.
  • Spiral Model (Boehm): Risk-driven iterative model structured in 4 quadrants per loop: Planning & Objective Setting, Risk Analysis & Mitigation, Engineering & Development, and Customer Evaluation. Excellent for high-risk, mission-critical systems.
  • Prototyping Model: Develops a quick mock-up/working prototype to clarify ambiguous user requirements. Helps bridge communication gaps between clients and developers.
  • Rapid Application Development (RAD): Focuses on rapid prototyping and component-based construction in short timeboxes (60–90 days) using automated code generators, visual GUI builders, and joint application development (JAD).

1.2 & 1.3 Requirements Engineering, Fact-Finding, Feasibility, and SRS (IEEE 830)

Types of Requirements:

  • Functional Requirements: Describe specific system behaviors, inputs, calculations, and output responses (e.g., 'System shall calculate payroll tax').
  • Non-Functional Requirements: Specify quality attributes and operational constraints (Performance, Scalability, Security, Usability, Availability).

Fact-Finding Techniques: Interviews, Questionnaires, Observation (On-site shadowing), Document Review, and Joint Application Development (JAD) workshops.

Feasibility Study Dimensions: Technical (hardware/tech stack), Economic (Cost-Benefit Analysis, ROI), Operational (user adaptability), Legal (compliance/GDPR), and Schedule feasibility.

SRS (IEEE 830 Standard Structure): 1. Introduction (Purpose, Scope), 2. Overall Description (Product perspective, user classes, constraints), 3. Specific Requirements (Functional & Non-functional requirements, external interface requirements).

🔑 Key Concepts & Examination Keywords

Quick Terminology
SSAD
Structured System Analysis and Design; a process-driven approach separating data flow from functions using DFDs.
OOAD
Object-Oriented Analysis and Design; an approach combining data and methods into cohesive real-world objects.
Spiral Model
A risk-driven iterative software development model incorporating systematic risk analysis in every iteration loop.
IEEE 830
The industry standard guideline for writing structured, unambiguous Software Requirement Specifications (SRS).

🎯 High-Yield Important Examination Questions

8–10 Descriptive Points Each

Q1. Compare and contrast Structured System Analysis and Design (SSAD) and Object-Oriented Analysis and Design (OOAD) in complete detail.

10 MarksSSAD vs OOADCore Concept
▼
📝 Detailed Examination Answer (10-Point Model):
  1. Core Architectural Philosophy: SSAD is process-centric and function-oriented, focusing on how data flows through transformations; OOAD is object-centric, organizing systems around real-world objects containing state and behavior.
  2. Data and Process Relationship: In SSAD, data and functions are separated (data stored in global structures, manipulated by external subroutines); in OOAD, data attributes and operations are encapsulated together inside classes.
  3. Primary Modeling Notations: SSAD utilizes Data Flow Diagrams (DFD), Structure Charts, and Data Dictionaries; OOAD utilizes Unified Modeling Language (UML) diagrams (Class, Use Case, Sequence).
  4. Modularity and Coupling: SSAD modularity is based on functional decomposition, which often leads to tight coupling with global data; OOAD achieves high cohesion and loose coupling through encapsulation.
  5. Reusability Mechanism: SSAD offers limited reusability via generic subroutine libraries; OOAD provides powerful reusability through inheritance, composition, and polymorphic interfaces.
  6. Maintenance and Impact of Changes: In SSAD, modifying a central data structure requires rewriting multiple dependent functions; in OOAD, changes are localized within class boundaries without rippling across the system.
  7. Real-World Domain Mapping: OOAD maps directly to human mental models and business domain objects (e.g., Customer, Account), whereas SSAD requires translating entities into artificial data flow processes.
  8. Handling Complex Systems: SSAD becomes unwieldy and fragile for massive enterprise systems; OOAD scales effectively through hierarchical abstractions and design patterns.
  9. Development Lifecycle Alignment: SSAD naturally aligns with the linear Waterfall model; OOAD naturally aligns with iterative, incremental, and Agile lifecycles (Unified Process).
  10. Modern Industry Preference: OOAD dominates modern enterprise software engineering, forming the foundation of Java, C#, C++, Python, and microservice architectures.

Q2. Explain the Software Development Life Cycle (SDLC) models: Waterfall, Spiral, Prototyping, and RAD with life-cycle diagrams and suitability criteria.

10 MarksSDLC Models
▼
📝 Detailed Examination Answer (10-Point Model):
  1. Waterfall Model Sequential Phases: Follows rigid linear stages: Requirement Analysis $\rightarrow$ System Design $\rightarrow$ Implementation $\rightarrow$ Testing $\rightarrow$ Deployment $\rightarrow$ Maintenance; each phase must finish before the next begins.
  2. Waterfall Advantages and Limitations: Simple to manage with clear milestone documentation; highly vulnerable to late-stage requirement changes with working software only visible at the very end.
  3. Spiral Model 4-Quadrant Architecture: Structured into cyclical spirals consisting of: 1. Determine Objectives, 2. Identify and Resolve Risks (Risk Analysis), 3. Develop and Test, 4. Plan Next Phase.
  4. Risk-Driven Nature of Spiral Model: Every iteration incorporates explicit risk assessment and prototyping, mitigating catastrophic project failures before major capital investment.
  5. Prototyping Model Mechanism: Involves rapid construction of an interactive mock-up/prototype presented to users for feedback, iteratively refining requirements until fully solidified.
  6. Prototyping Benefits: Eliminates ambiguous requirements, bridges the communication gap between business clients and software developers, and reduces change requests late in development.
  7. Rapid Application Development (RAD) Concept: An adaptive lifecycle emphasizing rapid prototyping and component reusability within tight 60–90 day timeboxes without detailed upfront planning.
  8. RAD Phases and Automation: Comprises Business Modeling, Data Modeling, Process Modeling, Application Generation (via CASE/low-code tools), and Testing/Turnover.
  9. Suitability Criteria for Process Selection: Waterfall: Static, well-understood specs; Spiral: High-risk, mission-critical systems; Prototyping: Ambiguous UI/UX; RAD: Fast delivery with skilled modular teams.
  10. Lifecycle Model Comparison for University Exams: Highlight differences in risk management, flexibility to change, client involvement, and working software delivery speed.

Q3. Describe the Software Requirement Specification (SRS) document according to IEEE 830 standard, detailing Functional vs Non-Functional requirements and Fact-Finding techniques.

10 MarksSRS & Requirements Engineering
▼
📝 Detailed Examination Answer (10-Point Model):
  1. Definition and Importance of SRS: An SRS is a formal legal contract between clients and developers specifying exactly what the software system will accomplish without dictating internal implementation details.
  2. IEEE 830 Standard Section 1: Introduction: Contains Purpose, Document Scope, Definitions/Acronyms, References, and Overview of the document.
  3. IEEE 830 Section 2: Overall Description: Covers Product Perspective, Product Functions, User Characteristics/Personas, General Constraints (hardware/OS limits), and Assumptions/Dependencies.
  4. IEEE 830 Section 3: Specific Requirements: The core section detailing functional requirements, external interface requirements (UI, hardware, software, communications), and non-functional quality attributes.
  5. Functional Requirements Definition: Specifies fundamental system services, mathematical algorithms, data processing inputs, outputs, and validation rules (e.g., 'System must calculate EMI').
  6. Non-Functional Requirements (FURPS+ Model): Specifies operational quality constraints: Performance (response time < 2s), Security (AES-256 encryption), Reliability (99.9% uptime), Usability, and Scalability.
  7. Fact-Finding: Interviews & Questionnaires: Interviews gather deep qualitative domain insights from key stakeholders; questionnaires collect broad quantitative feedback across large user bases.
  8. Fact-Finding: Observation & Document Review: On-site job shadowing observes actual operational workflows; document reviews inspect existing forms, reports, and legacy code to extract business rules.
  9. Fact-Finding: Joint Application Development (JAD): Intensive structured collaborative workshops bringing together users, managers, and system analysts to resolve requirement ambiguities in real time.
  10. Characteristics of a High-Quality SRS: An ideal SRS must be: Correct, Unambiguous, Complete, Consistent, Ranked for importance/stability, Verifiable/Testable, Modifiable, and Traceable.

⚖️ Comprehensive Comparison & Difference Tables

8+ Comparison Criteria

📊 Waterfall Model vs Spiral Model vs RAD Model

Comparison ParameterWaterfall ModelSpiral ModelRAD (Rapid Application Development)
Lifecycle ParadigmStrict linear-sequential progression.Risk-driven cyclical iterative progression.Timeboxed iterative & prototyping development.
Risk ManagementNo formal built-in risk assessment.Comprehensive risk analysis in every spiral quadrant.Moderate risk management focused on timebox constraints.
Requirement FlexibilityExtremely rigid; change requests are difficult to accommodate.Highly flexible; new requirements accommodated in next spiral loop.Highly flexible; adapts continuously via user prototyping.
Customer InvolvementOnly at the beginning (requirements) and end (acceptance).Continuous involvement at the end of each spiral evaluation phase.Intense, continuous involvement throughout all prototyping stages.
Delivery of Working CodeWorking software delivered only at the final deployment stage.Early working prototypes produced during early spiral loops.Rapid working increments delivered within 60–90 days.
Cost and ManagementLow management complexity; fixed cost and schedule.High cost; requires expert risk assessment specialists.Moderate cost; requires highly skilled developers and CASE tools.
SuitabilitySmall projects with frozen, well-understood requirements.Large, complex, mission-critical enterprise systems.Projects with modular architecture needing rapid time-to-market.
Documentation EmphasisHeavy formal documentation at each sequential phase gate.Extensive risk analysis and milestone documentation.Lightweight documentation; prioritizes working software artifacts.

📊 Functional Requirements vs Non-Functional Requirements

Comparison ParameterFunctional RequirementsNon-Functional Requirements
Core DefinitionSpecifies WHAT the system should do (features and operations).Specifies HOW the system should perform (quality constraints).
Focus AreaUser business tasks, data calculations, workflows, inputs/outputs.System properties: performance, security, reliability, availability, usability.
Measurement & TestingDirectly tested with boolean pass/fail test cases.Quantified using quantitative metrics (latency ms, throughput TPS, MTBF).
Origin of RequirementDefined directly by end-users and business domain experts.Defined by software architects, security engineers, and DevOps teams.
Architectural ImpactDictates the business logic classes and module implementations.Dictates global system architecture, hardware sizing, and caching strategy.
Example'User can transfer money between bank accounts via OTP.''Transaction response time must be under 500ms under 10,000 concurrent users.'
Standard ModelUse Cases, User Stories, Functional Process Lists.FURPS+ model (Functionality, Usability, Reliability, Performance, Supportability).
Failure ConsequenceSystem fails to provide required business features.System may function correctly but crashes under load or is insecure.

⚡ Quick Pre-Exam Revision Summary

5-Minute Recap
💡 Core Takeaways & High-Yield Summary
  • SSAD separates functions from data using DFDs; OOAD encapsulates data and behavior into cohesive objects.
  • Waterfall is linear-sequential; Spiral is risk-driven iterative; RAD uses 60-90 day timeboxed prototyping.
  • Fact-finding techniques: Interviews, Questionnaires, Observation, Document Review, and JAD workshops.
  • Feasibility dimensions: Technical, Economic (ROI), Operational, Legal, and Schedule.
  • SRS (IEEE 830) specifies Functional (behavioral) and Non-Functional (performance/security) requirements.
  • A good SRS must be Correct, Unambiguous, Complete, Consistent, Verifiable, and Traceable.
← Back to Object Oriented Software Engineering
Next: Unit II →