System Analysis & Design
Practice Questions by Chapter
A comprehensive chapter-wise practice bank based on the BIT 123 syllabus, covering structured analysis, process modeling, UML design, requirements analysis, feasibility studies, cohesion, and coupling.
Overview of System Analysis and Design
BIT 123 - System Analysis & Design - Chapter 1
Section A - Very Short Answer
2 Marks EachHint & Explanation: The process of studying a business situation or system to identify its components, understand its operations, and determine its requirements for improvement.
Study Tip: Describe it as the 'understanding' phase before building begins.
Hint & Explanation: The process of planning, sketching, and configuring a new system or component to replace or complement an old system, based on requirements analyzed.
Study Tip: Contrast it with analysis: design is about 'blueprinting' the solution.
Hint & Explanation: An organized set of hardware, software, data, people, and procedures that work together to collect, process, store, and distribute information.
Study Tip: Mention the core components: hardware, software, data, and people.
Hint & Explanation: 1. Transaction Processing Systems (TPS). 2. Management Information Systems (MIS) and Decision Support Systems (DSS).
Study Tip: TPS and MIS are the most common foundation types.
Hint & Explanation: Any individuals or groups who have a direct interest, influence, or involvement in a system's development, operation, or outcome (e.g., users, managers, developers).
Study Tip: Broad category: anyone affected by the system.
Hint & Explanation: System Development Life Cycle. A structured, multi-phase methodology used to plan, analyze, design, implement, and maintain information systems.
Study Tip: It serves as the standard development framework.
Hint & Explanation: It is a linear, sequential development model where each phase must be fully completed before the next phase begins, with no overlapping.
Study Tip: Think of it as a rigid, step-by-step waterfall.
Hint & Explanation: The final phase of the SDLC where a deployed system is monitored, debugged, updated, and enhanced to keep it operational and aligned with business changes.
Study Tip: It represents the longest phase of the system lifecycle.
Section B - Short Answer
7 Marks EachHint & Explanation: A System Analyst bridges the gap between business users and technical programmers. Key skills include: analytical problem-solving, strong communication, business domain knowledge, and technical coding/database awareness.
Study Tip: Focus on their role as the 'translator' between business and technology.
Hint & Explanation: TPS: operational staff (records daily transactions). MIS: middle managers (generates structured summary reports). DSS: analysts/managers (supports semi-structured decisions). ESS: senior executives (highly aggregated strategic views).
Study Tip: Draw or describe a pyramid showing operational at the base and executive at the top.
Hint & Explanation: Phases: 1. Planning/Investigation (defines scope). 2. Analysis (details requirements). 3. Design (blueprints interfaces/DB). 4. Development/Coding. 5. Testing & Implementation (installs system). 6. Maintenance (updates).
Study Tip: List the phases in chronological order with a brief 1-sentence purpose for each.
Hint & Explanation: Waterfall: rigid, linear, requirements set early, low customer interaction during coding. Prototyping: iterative, builds working mockups quickly, high customer feedback, requirements evolve dynamically.
Study Tip: Evaluate them based on flexibility, customer feedback, and suitability for vague requirements.
Hint & Explanation: Stakeholders: 1. Business Owners (expect ROI, strategic fit). 2. System Users (expect ease of use, speed). 3. System Designers (expect clean architecture). 4. System Builders (expect clear documentation).
Study Tip: Group stakeholders into: Sponsors, Users, and Developers.
Hint & Explanation: A system inputs data, processes it, and outputs results. Feedback loops monitor the outputs against standards, and control mechanisms adjust inputs or processing rules to correct errors.
Study Tip: Use the example of a thermostat checking temperature (feedback) to turn on AC (control).
Hint & Explanation: Challenges: traditional SDLC requires document-heavy planning, does not adapt well to weekly requirement changes, delays software delivery until the final stage, and carries high cost for late-stage design alterations.
Study Tip: Explain that agile models were created to address these specific rigidities.
Section C - Long Answer
15 Marks EachHint & Explanation: 1. Deliverables: Planning (feasibility report), Analysis (System Requirements Specification - SRS), Design (design specifications), Development (source code), Implementation (installed database, user logs), Maintenance (patch logs). 2. Impact of skipping: skipping analysis leads to building the wrong system; skipping design leads to spaghetti code; skipping testing causes operational failures.
Study Tip: Create a structured table matching each SDLC phase to its primary deliverable and the risk of omission.
Hint & Explanation: 1. Waterfall: linear, best for projects with clear, fixed requirements. 2. Spiral: risk-focused, iterative loops, best for high-risk, expensive large-scale systems. 3. Agile Scrum: sprint-based, collaborative, best for projects with evolving requirements and quick release needs.
Study Tip: Compare them using criteria like: Requirement Flexibility, Risk Handling, Customer Involvement, and Project Cost Profile.
Hint & Explanation: 1. Change Agent: overcoming employee resistance to new systems, redesigning workflows. 2. Requirement Detailer: eliciting tacit knowledge from users, resolving conflicting demands. 3. Communicator: translating complex business needs into coding blueprints for developers. 4. Skillset breakdown.
Study Tip: Argue that interpersonal communication and business understanding are more critical than coding skills for analysts.
Hint & Explanation: 1. TPS: transaction clearing, high volume, low latency, raw data. 2. MIS: management summaries, monthly performance tables, internal focus. 3. DSS: interactive analytical tools, scenario forecasting (what-if analysis). 4. EIS: high-level external metrics, dashboards. 5. Integration: how data cascades upwards from TPS to EIS databases.
Study Tip: Explain that lower levels are structured/operational, while higher levels are unstructured/strategic.
Hint & Explanation: 1. Systems theory: an organization is a set of interrelated parts forming a whole. 2. Boundary: defines what is inside the system vs what is in the external environment. 3. Environments: competitors, markets, laws. 4. Sub-systems: departments (sales, HR, finance) interacting. 5. Coupling: keeping sub-systems loosely coupled so one failure doesn't crash the company.
Study Tip: Connect systems theory directly to software architecture concepts like modularity.
Process and Conceptual Modeling
BIT 123 - System Analysis & Design - Chapter 2
Section A - Very Short Answer
2 Marks EachHint & Explanation: A graphical model that represents the flow of data through an information system, detailing inputs, outputs, processes, and storage.
Study Tip: It is a process modeling tool that does not show control logic or timing.
Hint & Explanation: 1. Entity (External agent). 2. Process. 3. Data Store. 4. Data Flow (directed arrow).
Study Tip: State both Yourdon & Coad and Gane & Sarson naming styles if possible.
Hint & Explanation: The highest-level DFD that represents the entire system as a single process, showing only external entities and boundary data flows.
Study Tip: Crucially, a context diagram contains zero data stores.
Hint & Explanation: A conceptual database model that represents the data entities, their attributes, and the logical relationships between them.
Study Tip: It is used for database design to establish relational structures.
Hint & Explanation: A person, place, object, event, or concept in the user environment about which the organization wishes to maintain data.
Study Tip: Represented by a rectangle in Crow's Foot or Chen's notation.
Hint & Explanation: The numerical relationship (one-to-one, one-to-many, many-to-many) between occurrences of one entity and occurrences of a related entity.
Study Tip: For instance, one department can have many employees.
Hint & Explanation: The requirement that input and output data flows in a parent DFD process must match the net inputs and outputs of its child decomposed DFD.
Study Tip: Balancing prevents data leakage during DFD detailing.
Hint & Explanation: An entity in an ERD that resolves a many-to-many relationship by converting it into two one-to-many relationships, containing attributes of its own.
Study Tip: Commonly used in relational database tables (intersection tables).
Section B - Short Answer
7 Marks EachHint & Explanation: Process: rounded rectangle (Gane/Sarson) vs circle (Yourdon). External Entity: double square vs single rectangle. Data Store: open-ended rectangle vs double line. Data Flow: directed lines in both.
Study Tip: Mention that both sets represent the same logical concepts, only the shapes differ.
Hint & Explanation: Context: single system process, external entities. Level 1: breaks the system into main functional sub-processes, showing local data stores. Level 2: decomposes a single Level 1 process to detail its specific sub-steps and flows.
Study Tip: Decomposition adds detail to processes, like zooming in on a map.
Hint & Explanation: If process 3.0 has input 'A' and output 'B' at Level 1, then the decomposed Level 2 DFD (processes 3.1, 3.2) must collectively receive only 'A' and output only 'B'. Any new internal flows are local to Level 2.
Study Tip: State that inputs and outputs must remain constant across parent/child boundaries.
Hint & Explanation: Cardinality: maximum number of relationship instances (one or many). Modality (participation): minimum number of instances (zero for optional, one for mandatory).
Study Tip: Use examples like: Employee must have one Department (mandatory one).
Hint & Explanation: The analyst interviews users, translates business rules into entities/relationships, creates the ERD, normalizes tables, and hands the blueprint to DBAs for SQL creation.
Study Tip: Describe the ERD as the logical database design phase before the SQL physical database is built.
Hint & Explanation: Process: changes/moves data. Data Flow: data in motion. Data Store: data at rest. External Entity: source/destination of data outside system boundaries.
Study Tip: A noun represents stores/entities/flows, while a verb represents processes.
Hint & Explanation: 1. Black Hole: process with inputs but no outputs. 2. Miracle: process with outputs but no inputs. 3. Grey Hole: inputs cannot produce the outputs (inconsistent logic). 4. Direct flows between entities or between stores.
Study Tip: Every data flow must touch at least one process symbol.
Section C - Long Answer
15 Marks EachHint & Explanation: 1. Logic: modeling systems as processing pipelines. 2. Symbols: Gane & Sarson design elements. 3. Decomposition levels: Context (system boundary), Level 1 (core processes), Level 2 (functional sub-processes). 4. Validation: checking balancing, eliminating black/grey holes, ensuring entities do not connect directly to stores.
Study Tip: Structure your response into: DFD Core Purpose, Symbol definitions, Decomposition levels, and Common Drawing Errors.
Hint & Explanation: 1. Design: identifying candidate entities. 2. Attributes: key, composite, multivalued. 3. Relationships: recursive, binary, ternary. 4. Cardinality: crow's foot notations. 5. Normalization connection: resolving many-to-many relationships using associative entities to achieve 3rd Normal Form.
Study Tip: Describe how normalization cleans up database redundancy, beginning with a clean logical ERD.
Hint & Explanation: 1. Context: System process in center. Entities: Student, Librarian. Flows: book request, return confirmation. 2. Level 1 Processes: 1.0 Validate Student, 2.0 Check Book Catalog, 3.0 Issue Book, 4.0 Process Returns. 3. Data Stores: D1 Student DB, D2 Books Inventory, D3 Transaction logs. 4. Detail the flows between them.
Study Tip: Write your answer in a descriptive step-by-step format mapping out entities, processes, and store connections.
Hint & Explanation: 1. Business Rules extraction: interviews, document scans. 2. Translation: rules ('one customer can place multiple orders') determine cardinality (one-to-many). 3. Modality checking: ('order must have customer' = mandatory). 4. Validation: walking stakeholders through the ERD to confirm business logic matches data rules.
Study Tip: Use Crow's Foot notations (||, |o, <|,
Hint & Explanation: 1. DFD (Process focus): shows data in motion, functional transitions, inputs/outputs. 2. ERD (Data focus): shows data-at-rest structure, static relationships. 3. Complementary role: DFD data stores correspond to ERD entities; DFD data flows correspond to attributes in ERD tables; both are required to blueprint a complete system.
Study Tip: Summarize: DFD is about what the system DOES; ERD is about what the system IS.
Data and Process Modeling
BIT 123 - System Analysis & Design - Chapter 3
Section A - Very Short Answer
2 Marks EachHint & Explanation: A centralized database containing metadata (data about data) that describes the database structure, data elements, sources, and access rights.
Study Tip: Think of it as the reference manual of data structures.
Hint & Explanation: Computer-Aided Software Engineering. The use of software tools to automate system analysis, design, code generation, and project management.
Study Tip: CASE tools support the analyst's design work.
Hint & Explanation: CASE tools designed to assist in the early phases of the SDLC, such as planning, requirements elicitation, analysis, and database design.
Study Tip: Focuses on modeling and planning tools.
Hint & Explanation: CASE tools designed to assist in the later phases of the SDLC, such as code generation, compiling, testing, and system maintenance.
Study Tip: Focuses on code development and deployment.
Hint & Explanation: Data that describes other data (e.g., field type, maximum length, description, validation rules).
Study Tip: Metadata defines the properties of database fields.
Hint & Explanation: A central database folder that stores all project diagrams, data definitions, screen designs, and documentation generated by CASE tools.
Study Tip: It ensures team consistency by centralizing project assets.
Hint & Explanation: Automatically verifying ERD cardinialities and generating physical database schemas (SQL scripts) from logical models.
Study Tip: Automates the transition from ERD to SQL code.
Hint & Explanation: A document that describes the internal processing logic of a low-level (primitive) DFD process using structured tools.
Study Tip: Also called mini-specs, written for base-level processes.
Section B - Short Answer
7 Marks EachHint & Explanation: A Data Dictionary ensures consistency by providing a single source of truth for data definitions. It prevents duplicate fields, helps developers understand data types, and assists in database audits.
Study Tip: Focus on consistency, data integrity, and avoiding duplicate field names.
Hint & Explanation: CASE tools automate development. Categories: 1. Upper CASE (diagramming, analysis). 2. Lower CASE (code generators, testing). 3. Integrated CASE (I-CASE) covering the entire SDLC.
Study Tip: Highlight early stage (Upper) vs late stage (Lower) design focuses.
Hint & Explanation: The repository stores all metadata, entity lists, process specs, and screens. It enables team collaboration, tracks change logs, and runs consistency checks to make sure diagrams balance.
Study Tip: Describe it as the centralized database holding all project design elements.
Hint & Explanation: Contents: 1. Name/Aliases. 2. Data Type (integer, text). 3. Length. 4. Input/Output formats. 5. Validation rules (ranges). 6. Description. 7. List of files/DFD flows using the element.
Study Tip: Use the example of defining a 'Student ID' field (format, range, type) to illustrate.
Hint & Explanation: CASE tools allow analysts to draw ERDs. They automatically validate relationships, check key assignments, run normalization checks, and compile logical models into physical SQL tables for databases.
Study Tip: Explain that they bridge the gap between logical drawing and physical database compilation.
Hint & Explanation: Process modeling tools (DFDs, CASE drawing suites) are used during the analysis and design phases to document current system bottlenecks ('As-Is' model) and design the new workflows ('To-Be' model).
Study Tip: Link process modeling to business process re-engineering and SDLC mapping.
Hint & Explanation: Advantages: faster design, high-quality models, automatic schema generation, team collaboration. Limitations: expensive licenses, steep learning curve, tool lock-in, and rigid design formats.
Study Tip: Evaluate tool cost and training overhead vs automated speed benefits.
Section C - Long Answer
15 Marks EachHint & Explanation: 1. Structure: cataloging data flows, data stores, structures, and primitive elements. 2. Entry Formats: detailed XML or database table representations of fields. 3. Data Integrity: how dictionaries prevent duplicate field names (synonyms/homonyms), enforce global validation checks (e.g., date ranges), and ensure consistent field formats across all tables.
Study Tip: Explain the risk of homonyms (same name for different fields) and synonyms (different names for same field) in database design.
Hint & Explanation: 1. Architecture: central repository, design workspaces, diagram editors, code generators, validation modules. 2. Upper CASE: mockups, DFDs, ERDs. 3. Lower CASE: compiler links, automated unit testing, template code generation. 4. Integrated CASE: syncing logical design models directly with IDE code files.
Study Tip: Detail how modern Agile modeling tools (like Visual Paradigm or Enterprise Architect) represent Integrated CASE.
Hint & Explanation: Provide dictionary entries for: 1. Data Flow: CustomerOrder (comprising Cust_ID, Order_Date, Item_List). 2. Data Structure: Item_List (comprising Item_ID, Qty, Unit_Price). 3. Data Element: Cust_ID (type: string, length: 8, format: AAA99999, validation: non-null). 4. Data Store: Orders (comprising Order_ID, Cust_ID, Total_Amt).
Study Tip: Write out the structured algebraic data definitions (e.g., Order = Customer_ID + Date + {Items}) to demonstrate.
Hint & Explanation: 1. Collaborative features: check-in/check-out of diagrams, locking segments of models to prevent conflicts. 2. Version Control: tracking database schema changes, maintaining old iterations, rollback capabilities. 3. Consistency checks: automated balancing checks running across different team members' DFD levels.
Study Tip: Focus on how the repository handles concurrent access and database migration scripts.
Hint & Explanation: 1. Requirement: primitive DFD processes (lowest level processes that are not decomposed further) need detailed specs. 2. Connection: process 3.1.2 in a DFD points to process spec 'Mini-spec 3.1.2'. 3. Formats: Structured English, Decision Tables, Decision Trees. 4. Purpose: clarify rules for developers.
Study Tip: Explain that process specs act as the final logic guides, bridging the visual DFD to actual programming code.
Logic Modeling
BIT 123 - System Analysis & Design - Chapter 4
Section A - Very Short Answer
2 Marks EachHint & Explanation: The process of documenting and representing the internal rules, decisions, and logic that govern system processes.
Study Tip: It details 'how' a process works rather than just the data movement.
Hint & Explanation: A matrix representation of logic that maps combinations of conditions to their corresponding actions in a tabular format.
Study Tip: Ideal for complex rules involving multiple conditions.
Hint & Explanation: A graphical branching model representing conditions and actions sequentially, showing all possible paths of decision logic.
Study Tip: Read from left (root) to right (leaves/actions).
Hint & Explanation: A modified form of English that uses programming design structures (IF-THEN-ELSE, DO-WHILE) to express process logic clearly without formal code syntax.
Study Tip: It serves as a middle-ground between human talk and programming code.
Hint & Explanation: The upper-left quadrant of a decision table that lists all the criteria or conditions that must be checked.
Study Tip: Condition stubs define the questions that need answering.
Hint & Explanation: The lower-left quadrant of a decision table that lists all the possible steps or outcomes that the system can perform.
Study Tip: Action stubs define the results based on condition paths.
Hint & Explanation: It is easily understood by business clients and system users while maintaining a logical flow for developers.
Study Tip: Avoids technical code terms but retains programming logic.
Hint & Explanation: When decisions must be made in a sequential, step-by-step order, making branching paths easier to follow visually.
Study Tip: Trees excel at depicting sequential decision chains.
Section B - Short Answer
7 Marks EachHint & Explanation: Structure: 1. Condition Stub (lists factors). 2. Condition Entry (Y/N rules). 3. Action Stub (lists outcomes). 4. Action Entry (X markings for execution). Rules represent columns.
Study Tip: Describe the table quadrants: upper-left, upper-right, lower-left, lower-right.
Hint & Explanation: Steps: 1. Identify conditions. 2. Draw root node. 3. Draw branches for condition options (e.g., age ranges). 4. Add child nodes for secondary conditions. 5. Terminate leaves with execution actions.
Study Tip: Branch nodes represent conditions, while leaf nodes represent actions.
Hint & Explanation: Control structures: 1. Sequence (top-to-bottom steps). 2. Selection (IF-THEN-ELSE decisions). 3. Iteration (DO-WHILE or REPEAT-UNTIL loops). Uses indentation for block clarity.
Study Tip: Write a simple pseudo-code snippet to demonstrate indentation and keywords.
Hint & Explanation: Tables: best for complex, multi-condition rules. Trees: best for sequential decisions. Structured English: best for process-heavy algorithms involving loops.
Study Tip: Focus on rule complexity, sequential flow, and readability by non-programmers.
Hint & Explanation: Look for rules with identical action markings. If condition 'A' is Y in one rule and N in the other, but all other conditions are identical, they can be merged into a single rule with a dash '-' (indifferent).
Study Tip: Explain that removing redundant rules keeps tables concise and easy to parse.
Hint & Explanation: A DFD process represents a function. If the process is a primitive node, the analyst creates a logic model (e.g., Structured English block) to explain the internal calculations of that specific process.
Study Tip: Explain that logic models expand primitive DFD nodes into algorithmic detail.
Hint & Explanation: Changes require updating condition/action stubs. A table needs rule column updates; a tree needs branch redraws. Structured English requires rewriting block logic. Tables are usually the easiest to audit and update.
Study Tip: Highlight that decision tables make logical gaps or missing rules obvious.
Section C - Long Answer
15 Marks EachHint & Explanation: 1. Detailed comparison based on: complexity of rules, sequential decision paths, customer readability, developer conversion, and audit compliance. 2. Structured English: best for procedural algorithms. 3. Tables: best for large rule matrix. 4. Trees: best for sequential workflows. 5. Include examples of when each fails.
Study Tip: Use a structured comparison matrix table evaluating these three formats across at least 5 criteria.
Hint & Explanation: Business Rules: Customer type (VIP gets free shipping; Regular has fees). Order size (Over $100 regular gets free; Under $100 has fees). Location (Domestic vs International). 1. Identify conditions: 1. VIP Customer? 2. Order > $100? 3. Domestic? 2. Calculate rules (2^3 = 8 columns). 3. Map actions (Free Shipping, $5 Domestic Fee, $15 International Fee). 4. Simplify table by merging rules.
Study Tip: Explain the 2^n rule for calculating columns, where n is the number of binary conditions.
Hint & Explanation: Tree architecture: 1. Root: Customer Type (VIP / Regular). 2. VIP branch points to action: Free Shipping. 3. Regular branch splits to Order size (> $100 / <= $100). 4. Regular > $100 points to action: Free Shipping. 5. Regular <= $100 splits to Location (Domestic / International). 6. Domestic points to $5 Fee; International points to $15 Fee.
Study Tip: Describe the nodes and branching decisions clearly in text format representing a tree structure.
Hint & Explanation: Structured English code: IF Customer is VIP THEN Apply Free Shipping ELSE (Regular Customer) IF Order Size > $100 THEN Apply Free Shipping ELSE IF Location is Domestic THEN Apply $5 Shipping Fee ELSE Apply $15 Shipping Fee ENDIF ENDIF ENDIF
Study Tip: Ensure you use capitalization for key logical terms (IF, ELSE, THEN, ENDIF) and indent the blocks correctly.
Hint & Explanation: 1. Contradictions: when a single combination of conditions points to two conflicting actions (conflict). 2. Completeness check: calculating the total theoretical columns (2^n). If the table has fewer columns and no indifferent symbols (-), it is incomplete. 3. Redundancy: identical rules that should be merged. 4. Role of CASE tools in checking logic.
Study Tip: Explain that a table is complete only when all possible combinations of conditions have designated actions.
Object Modeling
BIT 123 - System Analysis & Design - Chapter 5
Section A - Very Short Answer
2 Marks EachHint & Explanation: An analysis approach that models a system as a collection of interacting objects, rather than separating data and processes.
Study Tip: Data and processes are bundled together into 'objects'.
Hint & Explanation: Unified Modeling Language. A standardized modeling language used to visualize, specify, construct, and document software systems.
Study Tip: UML is the standard language for object modeling.
Hint & Explanation: A static structure diagram in UML that shows the system's classes, their attributes, operations, and relationships.
Study Tip: Shows the static blueprint of system classes.
Hint & Explanation: A behavioral UML diagram that represents a user's interaction with the system, showing the boundary, actors, and use cases.
Study Tip: Focuses on user goals and system boundaries.
Hint & Explanation: An interaction diagram that details how operations are carried out, showing the chronological sequence of messages sent between objects.
Study Tip: Focuses on the timeline of messages between objects.
Hint & Explanation: A UML diagram that shows the life cycle of a single object, detailing the states it can enter and the events that trigger transitions.
Study Tip: Documents the lifecycle states of an object (e.g., Order: Pending -> Paid).
Hint & Explanation: A relationship where a subclass inherits all attributes and methods of a parent class (superclass), allowing code reuse.
Study Tip: Think of an 'IS-A' relationship (e.g., CheckingAccount is a BankAccount).
Hint & Explanation: Any entity external to the system that interacts with it, such as a user role, device, or external database.
Study Tip: Actors are drawn as stick figures outside the system boundary.
Section B - Short Answer
7 Marks EachHint & Explanation: Class: a template defining attributes and methods. Object: an instance of a class. Attributes: data properties of the class. Operations (methods): actions the class can perform.
Study Tip: Use the analogy: Class is a blueprint; Object is the house built from it.
Hint & Explanation: Actor: external entities (stick figures). Use Case: system functions (ovals). System Boundary: box enclosing use cases, excluding actors. Relationships: include, extend, association.
Study Tip: Explain that the boundary box separates the system from external users.
Hint & Explanation: Notations: 1. Association (basic link). 2. Generalization (inheritance/triangle arrow). 3. Aggregation (weak part-whole/empty diamond). 4. Composition (strong part-whole/filled diamond).
Study Tip: Use composition when child object cannot exist without parent (e.g., Room in House).
Hint & Explanation: Lifelines: vertical dashed lines representing object existence. Messages: horizontal arrows showing communication. Activation boxes: rectangles on lifelines showing when execution runs.
Study Tip: Explain that time flows vertically from top to bottom.
Hint & Explanation: State: a condition during an object's life. Event: trigger causing change. Transition: arrow from one state to another. Guard: condition that must be true for transition.
Study Tip: Use the transition of an 'Invoice' class (Unpaid -> Paid upon PaymentReceived event) as an example.
Hint & Explanation: Structured: separates data (ERD) and process (DFD). Object-Oriented: encapsulates data and processes together inside objects (Class Diagrams), using message passing.
Study Tip: Explain that OOA matches software engineering models (Java, C++) much better.
Hint & Explanation: Include: base use case always runs the included case (e.g., 'Withdraw Cash' includes 'Authenticate User'). Extend: conditionally runs extended case (e.g., 'Order Book' extends 'Request Gift Wrap' only if customer wants it).
Study Tip: Include is mandatory; extend is optional/conditional.
Section C - Long Answer
15 Marks EachHint & Explanation: 1. OOA Core philosophy: encapsulation, polymorphism, inheritance. 2. Class Diagrams: attributes, visibility (+,-,#), methods, relationships. 3. Use Case: boundary, actor interactions. 4. Sequence: message-passing timelines. 5. State: object life cycles. Discuss how these diagrams model different views of the system.
Study Tip: Describe Class as static structure, Use Case as requirements, Sequence as dynamic interaction, and State as object behavior.
Hint & Explanation: Identify Classes: Customer, Account, Order, ShoppingCart, Product, Payment. 1. Attributes: Customer (name, email), Order (orderNumber, status). 2. Methods: ShoppingCart (addItem(), checkout()). 3. Relationships: Customer has one Account (1-to-1); Account places multiple Orders (1-to-many); Order contains multiple Products (many-to-many via OrderItem composition); Payment pays for Order.
Study Tip: Describe classes with their attributes and methods, showing how they link via association and composition.
Hint & Explanation: Objects involved: User, ATM Interface, Controller, BankAccount. Steps: 1. User inserts card. 2. ATM asks for PIN. 3. User types PIN (ATM sends verifyPIN message to Controller). 4. Controller checks account. 5. User requests cash amount (ATM sends debitAccount to BankAccount). 6. Account verifies balance, approves, deducts. 7. Controller instructs dispenser to dispense cash. 8. Card returned.
Study Tip: Detail the message flows in a chronological, step-by-step format from user input to cash delivery.
Hint & Explanation: 1. Actor-to-Use Case: Association (solid line). 2. Actor-to-Actor: Generalization (e.g., Manager is a Customer). 3. Use Case-to-Use Case: include (dependency pointing to sub-task) and extend (dependency pointing to base task). 4. Detail a corporate sales system showing these relationships in action.
Study Tip: Include should point FROM base case TO target case; extend should point FROM target case TO base case.
Hint & Explanation: 1. Class mapping: UML classes map directly to Java/C# class files, attributes become fields, methods become functions. 2. Visibility mapping: + to public, - to private, # to protected. 3. Generalization: maps to inheritance (extends keyword). 4. Composition: maps to instantiating nested class structures. 5. Database mapping: ORM (Object-Relational Mapping).
Study Tip: Show how a simple 3-box Class Diagram translates directly into actual Java class code.
System Analysis
BIT 123 - System Analysis & Design - Chapter 6
Section A - Very Short Answer
2 Marks EachHint & Explanation: The phase in system analysis where user requirements are studied, verified, and documented to define what the system must achieve.
Study Tip: Documents what the system must do, not how it will look.
Hint & Explanation: Functional: defines what the system must do (e.g., generate invoice). Non-functional: defines how the system performs (e.g., page loads in under 2 seconds).
Study Tip: Functional is behaviour; non-functional is performance/quality.
Hint & Explanation: 1. Interviews. 2. Questionnaires and JAD (Joint Application Design) sessions.
Study Tip: Interviews (qualitative) and Questionnaires (quantitative) are standard methods.
Hint & Explanation: An evaluation and analysis of the potential of a proposed project, checking whether it is technically, economically, and operationally viable.
Study Tip: It serves as the 'go/no-go' checkpoint before full investment.
Hint & Explanation: An evaluation that checks whether the financial benefits of the system exceed the development and operational costs.
Study Tip: Addresses the question: Is the project worth the money?
Hint & Explanation: Tangible: measurable in cash (e.g., $10,000 saved in paper costs). Intangible: non-measurable (e.g., improved customer goodwill).
Study Tip: Tangible is concrete; intangible is qualitative.
Hint & Explanation: The length of time required for an investment's cumulative cash inflows to equal the initial cost of the development.
Study Tip: Shorter payback periods indicate lower financial risk.
Hint & Explanation: The process of organizing project tasks, allocating resources, and setting milestones on a timeline (using Gantt or PERT charts).
Study Tip: It manages the time constraints of system analysis.
Section B - Short Answer
7 Marks EachHint & Explanation: Steps: 1. Form project team. 2. Perform initial investigation. 3. Define scope. 4. Analyze feasibility categories (technical, economic, operational). 5. Evaluate alternatives. 6. Write and submit Feasibility Report.
Study Tip: Describe this as an structured investigation leading to a recommendation.
Hint & Explanation: Technical: do we have the technology? Economic: is there financial ROI? Operational: will users accept it? Legal: does it violate laws? Schedule: can we build it on time?
Study Tip: Use the acronym TELOS to memorize the main feasibility categories.
Hint & Explanation: Interviews: deep details, slow, high labor cost. Questionnaires: fast, mass reach, lacks depth. Observation: sees actual workflows, avoids bias. Document Review: reviews historical forms, records rules.
Study Tip: Choose the method based on audience size, time, and depth of details needed.
Hint & Explanation: CBA compares system costs with benefits. Direct costs: easily allocated to project (hardware purchases, coder salaries). Indirect costs: shared overheads (office electricity, general support staff time).
Study Tip: Direct is specific to the project; indirect is shared utility overhead.
Hint & Explanation: Gantt chart: bar chart showing tasks, durations, and overlaps on a calendar timeline. PERT/CPM: network diagram showing task dependencies and the Critical Path (longest path of dependent tasks).
Study Tip: Gantt is best for timelines; PERT is best for finding task dependencies.
Hint & Explanation: Initial cost: $30,000. Annual cash savings: $10,000. Payback Period = Initial Cost / Annual Inflows = $30,000 / $10,000 = 3 Years. If cash flows vary, accumulate savings year-by-year until cost is recovered.
Study Tip: Detail the formula: Payback Period = Initial Investment / Net Annual Cash Flow.
Hint & Explanation: Challenges: 1. Scope Creep: project boundary expands endlessly. 2. User mindsets: users don't know what they want or change their minds during development. 3. Lack of sponsor interest. 4. Poor communication.
Study Tip: Explain how prototyping and agile standups prevent scope creep.
Section C - Long Answer
15 Marks EachHint & Explanation: 1. Investigation: starting project requests. 2. Requirements Elicitation: interviews, workshops (JAD), creating System Requirements Specifications (SRS). 3. Eliciting requirements: functional (what it does) and non-functional (performance, security). 4. Validation: feasibility verification (TELOS framework) to get formal project approval.
Study Tip: Show how requirements elicitation feeds directly into writing the SRS document.
Hint & Explanation: 1. Financial metrics: ROI (Net Benefit / Cost * 100), Payback Period (cost recovery time), Net Present Value (NPV discounting future cash flows to today's value). 2. Cost classifications: capital expenses (CAPEX) vs operational expenses (OPEX). 3. Benefit classifications: tangible (paper/labor savings) vs intangible (user convenience).
Study Tip: Explain that NPV is the most accurate metric because it factors in the time value of money.
Hint & Explanation: 1. Stakeholder identification: Students, Faculty, Registrars, IT admins. 2. Methods: Questionnaires for students (large scale), Interviews for registrars (deep process info), JAD session to align IT and managers. 3. Target requirements: Class registration, grade check (functional); response time under 1 sec, SSL encrypt (non-functional).
Study Tip: Structure your response into: Stakeholder Matrix, Selected Elicitation Methods, and Sample SRS criteria.
Hint & Explanation: 1. Task dependencies: finish-to-start relationships. 2. PERT: network nodes showing Earliest/Latest Start/Finish. 3. Critical Path Method (CPM): path with zero slack time; any delay on this path delays the entire project. 4. Gantt: tracking progress visually. 5. Show how analysts manage project buffers.
Study Tip: Define the Critical Path as the longest sequence of dependent tasks that determines the shortest possible project time.
Hint & Explanation: Evaluate a hospital clinic booking system project: 1. Technical: integrating with legacy doctor databases. 2. Economic: development costs vs doctor time saved. 3. Operational: medical staff computer literacy levels. 4. Legal: protecting patient data privacy (HIPAA compliance). 5. Schedule: launching before peak flu season.
Study Tip: Evaluate all five TELOS parameters in separate paragraphs to ensure comprehensive coverage.
Systems Design
BIT 123 - System Analysis & Design - Chapter 7
Section A - Very Short Answer
2 Marks EachHint & Explanation: The phase in the SDLC where requirements are translated into technical specifications, blueprints, and physical data structures for coding.
Study Tip: Design turns analyzed requirements into concrete implementation blueprints.
Hint & Explanation: Logical: defines abstract flows, database ERDs, and interface mockups. Physical: specifies exact programming languages, hardware setups, and SQL tables.
Study Tip: Logical is abstract ('what'); physical is concrete ('how').
Hint & Explanation: A hierarchical diagram showing the modules of a system, their relationships, and the data/control parameters passed between them.
Study Tip: It is the primary diagram used in structured design.
Hint & Explanation: A measure of how focused and single-purpose the statements or functions within a single module are.
Study Tip: High cohesion (modules doing only one thing) is desirable.
Hint & Explanation: A measure of the degree of interdependence and connection between different software modules in a system.
Study Tip: Low coupling (independent modules) is desirable.
Hint & Explanation: The physical arrangement of records in a data file on storage media, determining how records are accessed (sequential, indexed, direct).
Study Tip: Determines database read/write speeds.
Hint & Explanation: The design principle where modules perform one, and only one, specialized system function (functional cohesion).
Study Tip: High functional strength prevents side-effects in other modules.
Hint & Explanation: The layout technique of creating data entry screens (input) and reports (output) that are user-friendly, logical, and minimize error.
Study Tip: Focuses on user interface (UI) and user experience (UX).
Section B - Short Answer
7 Marks EachHint & Explanation: Logical: technology-independent, defines user screens, data entities, data flow logical paths. Physical: technology-dependent, specifies database type (MySQL), programming language (Python), hardware platforms, and security firewalls.
Study Tip: Explain that logical design is done first, followed by physical translation.
Hint & Explanation: Structured design modularizes systems. Structure Charts show the module hierarchy. Elements: modules (boxes), calls (lines), data couples (empty circle arrows), control flags (filled circle arrows).
Study Tip: Differentiate data couples (carrying data) from control flags (carrying control flags like EOF).
Hint & Explanation: Levels: Coincidental (worst), Logical, Temporal, Procedural, Communicational, Sequential, Functional (best). Functional cohesion means module does only one specialized task.
Study Tip: Strive for high cohesion: keep code in one module focused on one goal.
Hint & Explanation: Levels: Content coupling (worst - direct access to code), Common, Control, Stamp, Data coupling (best - only primitive data passed).
Study Tip: Strive for loose coupling: minimize what modules know about each other.
Hint & Explanation: Steps: mapping ERD to tables, normalizing to 3NF, choosing data types. File organization: sequential (reads start to end), indexed sequential (uses index tables), random/direct (uses hashing).
Study Tip: Choose sequential for batch processes; indexed/direct for instant lookups.
Hint & Explanation: Input: logical layout, grouping related fields, clear error validation, drop-down menus to speed typing. Output: clean report headers, clear summaries, page numbers, and print-friendly styling.
Study Tip: Design inputs to prevent errors; design outputs to present decisions.
Hint & Explanation: Tight coupling means changes in one module break code in another module. This causes cascading bugs, makes troubleshooting difficult, increases regression testing costs, and slows down system updates.
Study Tip: Explain that loose coupling isolates code edits, preventing side-effect bugs.
Section C - Long Answer
15 Marks EachHint & Explanation: 1. Structured Design: breaking system into modules. 2. Structure Charts: drawing hierarchy, modules, arguments, loops, selections. 3. Cohesion levels (aim for Functional). 4. Coupling levels (aim for Data). 5. Design rules: high cohesion, loose coupling, low fan-in, high fan-out.
Study Tip: Focus on the design rules: High Cohesion + Loose Coupling = High Maintainability.
Hint & Explanation: 1. Cohesion: internal focus (best: Functional; worst: Coincidental). 2. Coupling: external connections (best: Data; worst: Content). 3. Business impacts: modular systems reduce debug times, support parallel coding by team members, simplify regression testing, and reduce long-term maintenance costs.
Study Tip: Use simple code snippets to illustrate functional cohesion vs data coupling.
Hint & Explanation: 1. DB Design: schema mapping, primary/foreign keys. 2. Sequential file organization: simple, high tape storage fit, slow lookups. 3. Indexed Sequential (ISAM): index table lookups with sequential blocks; moderate speed. 4. Direct/Random access: hashing algorithms computing disk address directly from primary key; fastest lookup, poor sequential scans.
Study Tip: Use tables evaluating lookup speed, storage overhead, and application fit for the three file organization types.
Hint & Explanation: 1. Input Design: flow-matching layouts, tab order, validation (range checks, format checks, presence checks). 2. Output Design: screen display vs print reports. 3. User-centered design: minimizing user memory load, providing help tooltips, aesthetic balancing, and accessibility support.
Study Tip: Detail validation checks (range, type, limit, check digit) as critical front-end controls.
Hint & Explanation: 1. Schema mapping: entities become tables, attributes become columns, keys map. 2. 1NF: remove repeating groups, set primary key. 3. 2NF: remove partial dependencies (non-key fields depending on part of composite key). 4. 3NF: remove transitive dependencies (non-key fields depending on other non-key fields).
Study Tip: Use a simple Customer-Order database example to show the step-by-step normalization process to 3NF.
System Implementation
BIT 123 - System Analysis & Design - Chapter 8
Section A - Very Short Answer
2 Marks EachHint & Explanation: The phase in the SDLC where the hardware and software are installed, users are trained, and the system is put into daily operation.
Study Tip: The transition phase from design/development to live production.
Hint & Explanation: 1. Direct Cutover (instant switch). 2. Parallel Installation (running both old and new systems together).
Study Tip: Other options include phased and pilot installations.
Hint & Explanation: A planned and systematic pattern of actions required to provide confidence that the software product conforms to technical requirements.
Study Tip: Ensures software conforms to specifications and lacks bugs.
Hint & Explanation: A peer review session where a programmer leads team members through their code, checking for errors, coding standard compliance, and logic bugs.
Study Tip: It is an informal, educational peer review method.
Hint & Explanation: The process of fixing logic bugs, software errors, or hardware faults discovered in the system after it is deployed.
Study Tip: Addresses actual errors and bugs.
Hint & Explanation: Modifying the system to keep it compatible with changes in the operational environment (e.g., OS updates, new database versions, hardware upgrades).
Study Tip: Addresses environment changes, not bugs.
Hint & Explanation: The phase in software development where the integrated system is tested as a whole to confirm it meets user requirements and standards.
Study Tip: Validates the fully compiled system against requirements.
Hint & Explanation: A structured peer review meeting conducted by developers to verify that software meets design standards and to detect bugs early.
Study Tip: It is a formal, documented review with specific roles.
Section B - Short Answer
7 Marks EachHint & Explanation: Direct: fast, cheap, highest risk of failure. Parallel: low risk, high cost/labor (double work). Phased: modules installed in steps. Pilot: full system installed in one branch/department first.
Study Tip: Evaluate each based on risk, cost, and implementation speed.
Hint & Explanation: Walkthrough: informal, developer-led. Inspection: formal, checklist-driven, moderator-led. Formal Technical Review (FTR): check against requirements, produces formal report and changes list.
Study Tip: Compare them in terms of formality, checklists, and document output.
Hint & Explanation: Corrective: bug fixes. Adaptive: environment updates. Perfective: adding new features or performance improvements. Preventive: code tuning to avoid future failures.
Study Tip: Explain that perfective maintenance is typically driven by user feature requests.
Hint & Explanation: Unit: test individual functions. Integration: test combined modules. System: test entire integrated package. Acceptance (Alpha/Beta): test by end-users to confirm it meets business expectations.
Study Tip: Describe this as a V-model or funnel expanding from micro code to macro operations.
Hint & Explanation: The review checks whether: 1. System meets business goals. 2. Budget/timeline goals were met. 3. Users are satisfied. 4. Lessons can be learned for future software cycles.
Study Tip: Done 1-3 months after deployment to let the system stabilize.
Hint & Explanation: Training prevents user resistance, reduces entry errors, and speeds adoption. Documentation (User manuals, help files, developer API guides) ensures the system can be operated and updated over time.
Study Tip: Note that a technically perfect system will fail if users are not trained to use it.
Hint & Explanation: Process: 1. User submits ticket. 2. Analyst reviews and prioritizes (corrective gets priority). 3. Developer changes code. 4. Tester performs regression tests. 5. Admin updates documentation and deploys patch.
Study Tip: Emphasize regression testing to ensure patch doesn't break existing features.
Section C - Long Answer
15 Marks EachHint & Explanation: 1. Installation: detailed analysis of the 4 methods (Direct, Parallel, Phased, Pilot) comparing risk profiles, operational costs, and timing. 2. Data Conversion: schema migration, database formatting, extracting data from legacy files, cleaning dirty data, and loading into the new database.
Study Tip: Use an installation comparison matrix evaluating: Risk Level, Double-Work Cost, Rollback Ease, and Setup Time.
Hint & Explanation: 1. Walkthroughs: educational, informal peer feedback, finding syntax/logic bugs. 2. Code Inspections (Fagan inspections): moderator-led, strict checklists, metrics tracking (defects per KLOC). 3. FTRs: design check, verification of SRS specifications, producing formal project sign-offs.
Study Tip: Contrast the roles involved in Fagan inspections: Moderator, Author, Reader, Inspector, Recorder.
Hint & Explanation: 1. Categories: Corrective (bugs), Adaptive (platform changes), Perfective (enhancements), Preventive (tuning). 2. Cost Analysis: why maintenance accounts for 60-80% of total SDLC cost (system age, poor design, documentation lag). 3. Maintenance workflow: logging, impact analysis, code updates, regression testing, deployment.
Study Tip: Detail the financial impact of maintenance, showing that coding style affects long-term cost.
Hint & Explanation: 1. Black-box: tests input/output interfaces, boundary value analysis, partition testing. 2. White-box: checks code structure, loops, branch coverage. 3. Integration: top-down vs bottom-up stubs/drivers. 4. System: performance, security, load testing. 5. User Acceptance Testing (UAT): Alpha and Beta phases.
Study Tip: Use the V-Model diagram description to show how testing phases correspond directly to SDLC design stages.
Hint & Explanation: 1. Purpose: auditing performance vs target goals. 2. Evaluation criteria: system performance (response time, uptime), information quality (report accuracy), economic performance (actual ROI vs budget), organizational impact. 3. Audit steps: survey users, check server logs, review budget books. 4. Final Report structure.
Study Tip: Explain that the auditor should ideally be an independent analyst, not the lead developer, to avoid bias.