Computer Science

SAD Master Revision Handbook

12 September 2026

Share this study resource

Help your exam peers & study groups prepare better

📘 SYSTEM ANALYSIS & DESIGN — MASTER REVISION HANDBOOK

Sources merged: BCI Question Bank (308 Qs) + Quiz Sets 1–17 (RSMSSB/Rajasthan Gyan) + Answer-Key Doubt Analysis. Continuously updatable.

🚨 MY EXAM TRAPS & CONFUSIONS (Highest Priority)

DFD Symbols — Confused Rectangle vs Circle repeatedly (6+ mistakes)
Fix: Rectangle/Square = External Entity | Circle = Process | Open Rectangle = Data Store | Arrow = Data Flow
🧠 Trick: "REP-COD-OS-AF" → Rectangle=Entity, Circle=Process, Open-rect=Store, Arrow=Flow

Logical vs Physical DFD — Mixed up "what" vs "how"
Fix: Logical DFD = WHAT (business/process view) | Physical DFD = HOW (real devices/implementation)
🧠 Logical=Logic(brain,WHAT); Physical=Body(real,HOW)

DFD Levels — Thought Level 3 = highest (bigger number = higher)
Fix: Level 0 = HIGHEST/most abstract = Context Diagram. Higher level number = MORE detail (zoom in), not more abstract.

Data Store Rules — Thought Store↔Store or Store↔Entity direct flow allowed
Fix: Data can flow ONLY Store↔Process. Store→Store ❌, Store→Entity ❌ (Store is passive, needs active Process to move data).

Coupling vs Cohesion — Direction of "good/bad" confused
Fix: Cohesion = WITHIN module (higher=better, best=Functional, worst=Coincidental). Coupling = BETWEEN modules (lower=better, best=Data, worst=Content).

SDLC First Step — Book gives 2 different answers in this source
Fix: Classic SAD model → Problem/Opportunity Identification (repeated 5+ times). Pressman-style model (rare Q) → "Communication". For exam, default = Problem/Opportunity Identification.

SDLC Coding Phase — Thought coding = Design phase
Fix: Actual programming/coding happens in Development and Documentation phase, NOT Design (Design = blueprint only).

Maintenance Phase
Fix: Bug fix + Enhancement + Update = Maintenance and Evaluation phase (last/ongoing phase, also called "Operational" in one book variant).

Feasibility Study vs System Analysis timing
Fix: Sequence: Problem ID → Feasibility Study (reviews existing procedure/info flow, Go/No-Go decision) → Final Requirement Spec → Approval → Design.
Feasibility Study = BEFORE final requirement spec. Test Plan/Approval Criteria/Hardware Study = AFTER final spec.

Economic vs Operational vs Technical Feasibility
Fix (table below) — commonly swapped.

Feasibility	Core Concern
Technical	Hardware/software adequacy
Operational	Human, organizational, political — will people USE it?
Economic	Cost vs Benefit comparison
Social	General public acceptance
Legal	Compliance with laws/acts
Management	Management approval + centralized control
Schedule/Time	Will it finish on time

⚠ "Data Feasibility" is NOT a real type (trap distractor).

Decision Table vs Decision Tree
Fix: Table = Tabular (rows/cols), best for MANY complex conditions. Tree = Graphical (nodes/branches), shows decision PATHS sequentially.

Coding Techniques (Serial/Block/Group/Significant/Self-checking) — heavily confused

Code Type	Properties
Serial/Sequential	Concise + Expandable (NOT meaningful)
Block	Meaningful + Expandable
Group Classification	Meaningful + Comprehensive
Significant Digit	Meaningful + Expandable + Comprehensive (NOT concise) — digits represent measurable values
Self-Checking	Used for VALIDATION (check digit, error detection)

Verification vs Validation
Fix: Verification = "Building it RIGHT" → checks against DESIGN/SYSTEM SPECS. Validation = "Building the RIGHT thing" → checks against USER REQUIREMENTS.

Top-Down vs Bottom-Up Design
Fix: Top-Down = Big function → DECOMPOSE into smaller modules. Bottom-Up = small modules → COMBINE into big system. Coding/Testing generally follow Top-Down order.

Stub vs Driver (Integration Testing)
Fix: Top-Down testing uses STUBS (dummy lower modules). Bottom-Up testing uses DRIVERS (dummy higher/calling modules).

Analyst vs Programmer vs DBA
Fix: Analyst = Design/Specify system. Programmer = Build/code (general database building). DBA = Specifically Design+Implement database STRUCTURE. Project Manager = Budget+Staff+Deadlines.

HIPO Full Form
Fix: HIPO = Hierarchy(Hierarchical) + Input + Process + Output. Developed by IBM. Used by programmers to organize/summarize problem analysis; supports top-down decomposition.

System Analyst = Architect analogy
Fix: Analyst role ≈ Architect (plans/designs) — NOT Contractor/Workers (who build).

Structure Chart vs Flowchart vs DFD — shape meaning changes by diagram type!

Diagram	Rectangle means	Circle/Diamond means
DFD	External Entity	Circle=Process
Flowchart	Process	Diamond=Decision, Oval=Start/End
Structure Chart	Module	—

Bubble Chart = another name for DFD (processes look like bubbles/circles).

Data Dictionary
Fix: Developed ALONGSIDE DFD (not database design stage). Contains EVERY data element (not just key/important/numeric) found in Data Flows + Data Stores.

RAD = Rapid Application Development. Advantage: fast, uses 4GL, customer feedback, reusability. Drawback: needs highly skilled/specialized developers (not the advantages!).

Build & Fix Model — suitable ONLY for very small programs (~100–200 LOC), not production software.

Waterfall Model weakness = poor at accommodating CHANGES (rigid, sequential) — NOT poor for small projects.

Regression Testing = Re-testing with PREVIOUS test cases after modification (Maintenance phase) — not Integration/Unit/Acceptance.

Functional vs Non-Functional Requirements 🚨 ANSWER KEY BUG in source book: Book marks "Maintainability" as Functional Requirement — this is WRONG per standard SE. Correct: Reliability, Portability, Maintainability, Efficiency, Usability = NON-Functional (quality attributes / HOW). Functional = WHAT system does (business needs, features).

QFD (Quality Function Deployment) requirement types = Normal, Expected, Exciting (Kano Model) — NOT generic Functional/Non-Functional.

Lehman's Software Evolution — 3 categories: S-type, P-type, E-type. "Continuing Quality" is a FAKE law (real: Continuing Change, Increasing Complexity, Self-Regulation, Continuing Growth, Conservation of Familiarity).

Metadata = "Data ABOUT data" (NOT = Data Dictionary itself; Dictionary is a tool that STORES metadata).

Structured Analysis Tools trio = DFD + Data Dictionary + Decision Table/Tree ("DDD"). "System-text data" / "Plechart" = FAKE distractor terms (not real tools) — appear repeatedly as traps.

Process Description Tools = Structured English + Decision Table + Pseudocode (describe LOGIC). Data Dictionary ≠ process tool (it catalogs DATA, not logic).

KLOC = Kilo Lines Of Code (size metric). Fake distractors: ZLOC, GLOC.

🚨 Other flagged Answer-Key Doubts (book-specific, may differ from standard SE):

Cost-Benefit Analysis defined narrowly as "estimate H/W+S/W cost" in book — standard = compare cost vs benefit.
"System does not perform a process" marked TRUE in one Q — technically FALSE (systems DO transform input→output). Likely a mis-keyed FALSE/TRUE question.
Significant Code definition circularly answered "are significant" — correct concept = "represent measurable VALUES".
UML symbol '%' in one Q — NOT standard (real UML visibility symbols: + public, − private, # protected, ~ package).
Tangible vs Intangible: book marks "Sales increase" & "Bad debt reduction" as Intangible — standard theory calls these Tangible (measurable in ₹). Follow book key for this exam only.
Computer purchase cost marked "All of these" (Fixed+Variable+Intangible) — standard = Fixed/Tangible only.

🎯 HIGH PRIORITY WEAK AREAS

Topic	Priority	Frequency (approx)
DFD (symbols, rules, levels, logical/physical, data dictionary)	🔴 Very Weak	25+
SDLC/PDLC (phases, sequence, documents per phase)	🔴 Very Weak	22+
Feasibility Study (types, sequence, cost-benefit)	🔴 Very Weak	20+
Systems Analyst (roles, skills, vs PM/DBA/Programmer)	🟠 Weak	18+
Structured Design (Structure Chart, Cohesion, Coupling)	🟠 Weak	15+
Decision Table/Tree, Structured English, Data Dictionary	🟠 Weak	12+
Coding Systems (Serial/Block/Group/Significant/Self-check)	🟡 Moderate	8+
HIPO, UML, Software Models (RAD/Waterfall/Spiral)	🟡 Moderate	10+
Testing (Verification/Validation, Regression, Stub/Driver)	🟡 Moderate	8+
Requirement Engineering (Gathering vs Engineering, QFD, CORE)	🟢 Strong-ish	7+

⭐ HIGH-YIELD EXAM FACTS (One-Line Revision)

SDLC = System Development Life Cycle ⭐⭐
PDLC = Program Development Life Cycle
SDLC first step = Problem/Opportunity Identification ⭐⭐
SDLC 2nd step = System Analysis (after Initial Investigation)
Coding happens in Development & Documentation phase ⭐⭐
Maintenance = Bug fix + Enhancement + Update ⭐⭐
Documentation prepared at EVERY stage of SDLC ⭐⭐
DFD = Data Flow Diagram; another name = Bubble Chart
Rectangle=Entity, Circle=Process, Open Rect=Store, Arrow=Flow ⭐⭐
Context Diagram = Level-0 DFD (highest/most abstract) ⭐⭐
Logical DFD = WHAT (business); Physical DFD = HOW (implementation) ⭐⭐
Data cannot flow Store↔Store or Store↔Entity directly
External Entity = source OR destination (either role)
Feasibility Study reviews existing procedures/info flow ⭐⭐
Feasibility Study done BEFORE final requirement specs
Economic Feasibility = Cost vs Benefit comparison ⭐⭐
Operational Feasibility = Human/org/political acceptance
Technical Feasibility = Hardware/software adequacy
Social Feasibility = general public acceptance
System = interrelated components + common goal + I-P-O transformation ⭐⭐
Open System = interacts with environment; Closed = doesn't
Conceptual→Logical→Physical = idea→design→implementation
Structure Chart = hierarchical module decomposition (Design phase output)
Structure Chart = primary tool of Structured Design
Cohesion: best=Functional, worst=Coincidental (7 types total) ⭐⭐
Coupling: best=Data, worst=Content
Common Coupling = modules share common/global data structure
Decision Table = tabular; Decision Tree = graphical (nodes/branches)
Structured English = precise description of DFD process logic (not code)
Data Dictionary = catalogs every data element in Data Flows+Stores; built with DFD
Metadata = data about data
HIPO = Hierarchy+Input+Process+Output; developed by IBM ⭐
Bug = coding error; Debugging = finding+fixing it
Algorithm = logic steps; Coding = translate to programming language
Audit Trail = tracing process back to original source
Gantt Chart = project schedule; developed by Henry Gantt
Pie chart = shows percentage; Bar/Line = comparison
System Analyst role ≈ Architect (plans, not builds)
Project Manager = budget+staff+deadlines; Analyst = requirements+design
DBA = designs/implements database structures
Candidate System = system currently being developed
Parallel Operation = old+new system run together to compare
Verification = design-spec check; Validation = user-requirement check ⭐⭐
Top-down testing → Stubs; Bottom-up testing → Drivers
Regression Testing = retest with old test cases after change
Acceptance Testing = actual user, live data (book: "all of above")
RAD = Rapid Application Development; uses 4GL; drawback = needs skilled devs
Waterfall weak at accommodating changes
Build & Fix Model = only for ~100-200 LOC programs
Requirement Engineering = Gather+Analyze+Document (SRS output)
QFD requirement types = Normal, Expected, Exciting
CORE methodology drawback = analyst role is passive
Lehman: 3 software categories (S/P/E-type); Continuing Change law
KLOC = size metric (Kilo Lines of Code)
EDP = Electronic Data Processing
UML = Unified Modeling Language (modeling, NOT programming language)
UML diagram types: Activity, Sequence, Class (+others)
Package = UML mechanism to group model elements
File conversion = Implementation phase activity
Test plan/Hardware study/Approval criteria specified AFTER final specs
Feasibility Study report = "Cost Benefit Report"
System evaluation = after reasonable operational time; improves system
System modification driven by CHANGING USER REQUIREMENTS (not new tech)
Good system design = Practical, Effective, Secure, Reliable, Flexible, Economical (PESRFE)
Interactive Input = input given when computer prompts mid-entry
CASE tool = supports structured analysis & design (checks DFD, maintains dictionary)

📊 DIFFERENCE TABLES (Frequently Confused)

DFD Symbol Table

Symbol	Meaning
Rectangle/Square	External Entity
Circle	Process
Open-ended Rectangle	Data Store
Arrow/Line	Data Flow

Flowchart Symbol Table (DIFFERENT from DFD!)

Symbol	Meaning
Rectangle	Process
Diamond	Decision
Oval	Start/End
Circle	Connector

SDLC Sequence (Standard)

Problem/Opportunity ID → System Analysis → Feasibility Study → Requirement Spec (Initial→Final) → Design → Development/Coding & Documentation → Testing → Implementation → Maintenance & Evaluation

Cohesion vs Coupling

	Cohesion	Coupling
Scope	Within a module	Between modules
Desired	High (strong)	Low (weak)
Best type	Functional	Data
Worst type	Coincidental	Content
Total types	7	~6 (Data,Stamp,Control,External,Common,Content)

Verification vs Validation

	Verification	Validation
Question	Building it right?	Building the right thing?
Checks against	Design/System specs	User requirements

Stub vs Driver

Testing Type	Dummy Used	Simulates
Top-Down	Stub	Missing LOWER modules
Bottom-Up	Driver	Missing HIGHER/calling modules

Coding Techniques

Code	Concise	Meaningful	Expandable	Comprehensive
Serial	✔	✘	✔	✘
Block	✘	✔	✔	✘
Group Classification	✘	✔	✘	✔
Significant Digit	✘	✔	✔	✔

Documents produced per SDLC phase (book-specific naming — memorize exactly)

Phase	Document
Analysis	Program Specification
Design	Design Specification
Study Phase	System Specification
Development	System Specification (per this book)

🧠 MEMORY TRICKS & MNEMONICS

DFD symbols: "R-C-O-A" = Rectangle-Circle-Open box-Arrow = Entity-Process-Store-Flow
Feasibility types: TELOS = Technical, Economic, Legal, Operational, Schedule (+Social, Management as extras)
Good code (Serial): "Short & Extendable but Blind" (no meaning)
Cohesion/Coupling: "Cohesion = Close family inside; Coupling = Cousins outside" — want close family(high cohesion), distant cousins(low coupling)
Verification = "Right way" (spec); Validation = "Right thing" (user)
Stub(top) vs Driver(bottom): "S before D" alphabetically, "Top before Bottom" — Stub=Top, Driver=Bottom
HIPO = "Hi, I Process Output" (Hierarchy-Input-Process-Output)
PESRFE (good design): Practical Effective Secure Reliable Flexible Economical
Requirement Elicitation problems = USV (Understanding, Scope, Volatility)
Lehman software categories = SPE (S-type, P-type, E-type)

⭐ PYQ FAVOURITES (Highly Repeated ⭐⭐)

⭐⭐ DFD Rectangle = External Entity (asked 6+ times across sets)
⭐⭐ Logical DFD = process/data flow focus (asked 5+ times)
⭐⭐ Economic Feasibility = profit vs cost comparison (asked 4+ times)
⭐⭐ Documentation prepared at every stage (asked 3+ times)
⭐⭐ SDLC first step = Problem/Opportunity Identification (asked 3+ times)
⭐⭐ Circle in DFD = Process (asked 3+ times)
⭐⭐ System = components+interaction+goal (definition asked 4+ times)
⭐⭐ System Modification driven by changing user requirements (asked 3 times)
⭐ HIPO full form + IBM origin
⭐ Feasibility Study = "Cost Benefit Report"
⭐ Structure Chart = primary structured design tool (asked 4 times)

🎯 LAST-MINUTE RAPID REVISION

Q Trigger Word	Answer
"external entity symbol"	Rectangle
"process symbol in DFD"	Circle
"process symbol in Flowchart"	Rectangle
"decision symbol"	Diamond
"data store symbol"	Open rectangle
"highest level DFD"	Level 0 / Context Diagram
"cost vs benefit"	Economic Feasibility
"hardware adequacy"	Technical Feasibility
"people will use it?"	Operational Feasibility
"public acceptance"	Social Feasibility
"laws & regulations"	Legal Feasibility
"actual coding done in"	Development & Documentation phase
"bug fix/enhancement phase"	Maintenance & Evaluation
"building it right"	Verification
"building right thing"	Validation
"stub used in"	Top-down testing
"driver used in"	Bottom-up testing
"best cohesion"	Functional
"worst coupling"	Content
"tabular decision logic"	Decision Table
"graphical decision logic"	Decision Tree
"data about data"	Metadata
"IBM tool with hierarchy+IPO"	HIPO
"analyst role compared to"	Architect
"system under development"	Candidate System
"old+new system run together"	Parallel Operation
"size metric"	KLOC
"3 categories of software (Lehman)"	S-type, P-type, E-type
"small program only ~100-200 LOC"	Build & Fix Model
"RAD drawback"	Needs skilled developers
"waterfall weakness"	Can't accommodate changes
"retest with old test cases"	Regression Testing

📌 EXPECTED SIMILAR FUTURE QUESTIONS

DFD level numbering (which is most detailed — Level 3, not Level 0)
Match feasibility type to its concern (matching-type Qs repeat often)
Cohesion/Coupling ranking order (best to worst sequence)
Data Dictionary vs Decision Table vs Decision Tree — "which tool NOT used for X"
SDLC step numbering — "which activity belongs to phase N" (book-specific numbering trap)
Verification vs Validation — true/false statement type questions
HIPO full form exact wording (Hierarchical vs Hierarchy, Process vs Provide traps)
Functional vs Non-functional requirement classification (verify against standard SE, book may err)

Rajasthan Exam Twister

Comprehensive Preparation for Rajasthan Exams

Review detailed blog breakdowns, previous year papers, and topical revision handbooks.

Browse Blogs