DFD Up to Level 1: Online College Recommendation System

Context Diagram (Level 0 DFD)

The Level 0 DFD (Context Diagram) shows the entire system as a single process with all external entities.

                    Faculty Name
                    Standard
                    Location
        Student ─────────────────────────────► [0]
           ▲                                  Online
           │  Recommendations                College
           │  Notifications (Seats, Fees)  Recommendation ◄──── Admin
           └──────────────────────────────── System         │
                                                            │ Add/Delete/Update
                                                            │ College List
                                                            ▼
                                                       (System updates)

External Entities:

• Student: Provides search criteria and receives recommendations/notifications
• Admin: Manages college data (add, delete, update)

Level 1 DFD

Level 1 DFD decomposes the main system into its major sub-processes.

                Faculty Name / Standard / Location
                              │
                              ▼
Student ──────────► [1.0 Validate & Collect]
                    Student Requirements
                              │
                              │ Validated Requirements
                              ▼
                    [2.0 Search & Generate]──────────► D1: College Database
                    Recommendations          ◄──────────────────────────
                              │
                              │ Matched College List
                              ▼
Student ◄────────── [3.0 Display]
                    Recommendations
                              │
                              │
                    ┌─────────┘
                    │ College Intake Data
                    ▼
                    [4.0 Track College]──────────────► D2: Intake Records
                    Intake                ◄────────────────────────────
                              │
                              │ Seat Availability / Fee Info
                              ▼
Student ◄────────── [5.0 Send Notification]
                    (Remaining Seats, Fee Structure)
                              │
                              │
Admin ─────────────► [6.0 Manage College]
  Add/Delete/Update           │
  College Info                │ Updated College Records
                              ▼
                         D1: College Database

Detailed Level 1 DFD Description

External Entities

Processes

Data Stores

Data Flows Summary

Key Notes

• Level 0 treats the entire system as one black box showing only external entities and major I/O.
• Level 1 breaks the system into 6 major processes reflecting the functional requirements described in the scenario.
• Data stores D1 and D2 act as repositories that multiple processes read from and write to.
• All inputs and outputs from the context diagram are preserved and accounted for in Level 1.

Dialogue Design: Steps and Graphical Environment Issues

Note: The reference notes did not provide content for this topic. The answer below is based on standard Human-Computer Interaction (HCI) curriculum as taught in BSc CSIT programs, following Dix, Finlay, Abowd & Beale and similar standard texts used in TU syllabus.

Part A: Three Steps in Designing Dialogues [7 Marks]

A dialogue in HCI refers to the structure of interaction between a user and a system: the sequence of actions and responses that allow a user to accomplish a task. Designing dialogues involves the following three major steps:

Step 1: Conceptual Design (Task and User Analysis)

This is the first and foundational step, where the designer understands:

• Who the users are: their goals, mental models, experience levels, and expectations.
• What tasks the users need to perform: task analysis is carried out using techniques like hierarchical task analysis (HTA).
• What information needs to flow between the user and the system.

The designer identifies:

• The objects the user will manipulate (files, buttons, forms).
• The actions available to the user (open, save, delete).
• The sequence in which interactions will logically occur.

Output: A conceptual model of the dialogue, a high-level description of what the system will do and how users will interact with it.

Step 2: Formal Dialogue Specification (Notation and Modelling)

Once the conceptual design is ready, the dialogue is formally specified using notations that precisely describe the structure and flow of interaction. Common notations include:

a) State Transition Diagrams (STDs)

• Represent the system as a set of states and transitions.
• Each state represents a point in the dialogue; transitions are triggered by user actions.
• Easy to understand but can become complex for large systems.

[Idle] --login--> [Main Menu] --select file--> [File Open Dialog]

b) JSD (Jackson Structured Design) / Hierarchical Notation

• Dialogue is described as a tree structure showing sequences, selections, and iterations.

c) Production Rules

• IF-THEN rules describe what happens when a user performs an action.
• Example: IF user clicks "Submit" AND form is complete THEN process data.

d) Petri Nets

• Used to model concurrent dialogues where multiple interactions can happen simultaneously.

Output: A precise, unambiguous specification that can be reviewed, tested, and handed to developers.

Step 3: Prototyping and Evaluation (Iterative Refinement)

The third step involves building prototypes of the dialogue and evaluating them with real users or through expert review.

Types of Prototypes:

Evaluation Methods:

• Usability testing: real users attempt tasks; problems are recorded.
• Heuristic evaluation: experts check against Nielsen's 10 usability heuristics.
• Cognitive walkthrough: designers simulate user thought processes step by step.

Iterative Cycle:

Design --> Prototype --> Evaluate --> Redesign --> ...

Problems found during evaluation feed back into Steps 1 and 2, making dialogue design an iterative process.

Output: A refined, validated dialogue design ready for full implementation.

Part B: Dialogue Design Issues in a Graphical Environment [3 Marks]

A Graphical User Interface (GUI) environment introduces specific dialogue design challenges because interaction is visual, direct, and event-driven. Key issues include:

1. Consistency

• GUI dialogues must be consistent in layout, terminology, and behavior across all windows and screens.
• Inconsistent button placement, icon meanings, or color usage confuses users.
• Example: "OK" and "Cancel" buttons should always appear in the same position.

2. Direct Manipulation and Feedback

• In a graphical environment, users directly manipulate objects (drag, drop, resize).
• The system must provide immediate visual feedback for every action.
• Poor feedback (e.g., no indication that a file was deleted) leads to errors and confusion.

3. Complexity and Dialogue Overload

• GUIs can present too many options simultaneously (menus, toolbars, pop-ups, dialog boxes).
• Designers must balance functionality vs. simplicity to avoid overwhelming the user.
• Modal vs. non-modal dialogues must be chosen carefully:
  • Modal dialog: Blocks other interaction until resolved (e.g., "Save before closing?")
  • Non-modal dialog: Allows parallel interaction (e.g., a Find toolbar)

4. Error Prevention and Recovery

• Graphical dialogues must be designed to prevent errors (e.g., graying out unavailable options) and allow easy undo/redo.
• Confirmation dialogs for destructive actions (e.g., "Are you sure you want to delete?") are essential.

Summary Table

Conclusion: Effective dialogue design requires systematic analysis, formal modelling, and iterative testing. In graphical environments, additional care must be taken to ensure consistency, meaningful feedback, manageable complexity, and robust error handling.

Normalization

Definition

Normalization is the process of organizing the attributes and relations of a relational database to minimize data redundancy, eliminate undesirable insertion, deletion, and update anomalies, and ensure data integrity by decomposing larger tables into smaller, well-structured tables based on functional dependencies.

First Normal Form (1NF)

A relation is said to be in First Normal Form (1NF) if:

• All attributes contain only atomic (indivisible) values (no multi-valued or composite attributes).
• Each column contains values of a single type.
• Each row is unique (there is a primary key).
• There are no repeating groups or arrays in any column.

Example

Not in 1NF (multi-valued attribute):

Converted to 1NF:

Now each cell holds only one atomic value.

Second Normal Form (2NF)

A relation is said to be in Second Normal Form (2NF) if:

1. It is already in 1NF, AND
2. Every non-key attribute is fully functionally dependent on the entire primary key (i.e., there is no partial dependency).

Partial Dependency: A non-key attribute depends on only a part of a composite primary key, not the whole key.

2NF is relevant only when the primary key is composite (made up of two or more attributes).

Example

In 1NF but NOT in 2NF:

• Primary Key: (StudentID, CourseID)
• StudentName depends only on StudentID (partial dependency)
• CourseName depends only on CourseID (partial dependency)
• Grade depends on both StudentID and CourseID (full dependency)

Converted to 2NF (remove partial dependencies):

Student Table:

Course Table:

Enrollment Table:

Now every non-key attribute is fully dependent on the entire primary key.

Summary

Information Gathering Techniques

Information gathering (also called requirements elicitation) is the process of collecting information about the existing system and user needs during system analysis. Below are three important techniques:

1. Interview

An interview is a direct, face-to-face conversation between the system analyst and the stakeholders (users, managers, clients) to gather information about the current system and requirements.

Types:

• Structured Interview: Predefined set of questions are asked in a fixed order.
• Unstructured Interview: Open-ended, flexible conversation without a fixed question list.

Advantages:

• Allows in-depth understanding of user needs.
• Analyst can ask follow-up questions immediately.
• Non-verbal cues can also be observed.

Disadvantage:

• Time-consuming and costly if many users are involved.

2. Questionnaire / Survey

A questionnaire is a written set of questions distributed to a large number of users or stakeholders to collect information simultaneously.

Types:

• Open-ended questions: Allow free-form answers.
• Closed-ended questions: Provide fixed choices (Yes/No, multiple choice).

Advantages:

• Can reach a large number of people at once.
• Less time-consuming and cost-effective.
• Respondents can answer at their own convenience.

Disadvantage:

• No opportunity to clarify misunderstood questions.
• Response rate may be low.

3. Observation

Observation involves the analyst directly watching how users perform their tasks and interact with the existing system in their actual work environment.

Types:

• Active Observation: The analyst participates in the work process.
• Passive Observation: The analyst silently watches without interfering.

Advantages:

• Provides firsthand, accurate information about actual workflows.
• Reveals tasks that users may forget to mention in interviews.
• Helps identify bottlenecks and inefficiencies in the current system.

Disadvantage:

• Users may change their behavior when they know they are being observed (Hawthorne effect).
• Time-consuming for complex processes.

Summary Table

Principles of Agile Development and Its Advantages

Note: The reference notes did not contain this topic. The following answer is based on standard software engineering curriculum (Sommerville, Pressman) as taught in BSc CSIT.

Principles of Agile Development

The Agile Manifesto defines 12 principles of agile development:

Advantages of Agile Development

1. Faster delivery: Working software is delivered in short iterations (sprints), providing value to the customer quickly.

2. Flexibility to change: Requirements can be modified at any stage, making it suitable for dynamic and evolving projects.

3. Improved customer satisfaction: Continuous customer involvement ensures the product meets actual needs.

4. Early defect detection: Frequent testing and reviews within each iteration help identify and fix bugs early.

5. Better team collaboration: Daily stand-ups and close teamwork improve communication and productivity.

Summary: Agile focuses on iterative development, collaboration, and adaptability, making it highly effective for modern software projects where requirements frequently change.

Short Notes: Single-Location Installation Decision Tree

Single-Location Installation Decision Tree

A Decision Tree is a graphical, tree-shaped diagram used to evaluate decisions under conditions of uncertainty by mapping out possible choices, chance events, and their outcomes.

A Single-Location Installation Decision Tree is applied when an organization must decide whether, when, and how to install a system (or facility) at one specific location, considering costs, probabilities, and expected payoffs.

Structure of a Decision Tree

Key Components

1. Decision Alternatives - e.g., Install now, Delay installation, Do not install
2. States of Nature - e.g., High demand, Low demand (with associated probabilities)
3. Probabilities - Each chance branch has a probability; all branches from a chance node must sum to 1.0
4. Payoffs - Net benefit or cost at each end node

Steps to Solve

1. Draw the tree from left to right (decisions first, then chance events)
2. Assign probabilities to chance branches
3. Assign payoffs to terminal nodes
4. Roll back (right to left):
   • At chance nodes: compute Expected Monetary Value (EMV) $$EMV = \sum_{i} P_i \times \text{Payoff}_i$$
   • At decision nodes: select the alternative with the highest EMV

Worked Example

Suppose a company decides whether to install a system at a single location:

• Alternative 1: Install Now - Cost = Rs. 50,000

  • High demand (P = 0.6): Revenue = Rs. 1,20,000 → Net = Rs. 70,000
  • Low demand (P = 0.4): Revenue = Rs. 30,000 → Net = Rs. -20,000

• Alternative 2: Do Not Install - Net payoff = Rs. 0

EMV Calculation:

$$EMV(\text{Install Now}) = (0.6 \times 70{,}000) + (0.4 \times -20{,}000)$$ $$= 42{,}000 - 8{,}000 = \textbf{Rs. 34,000}$$

$$EMV(\text{Do Not Install}) = \textbf{Rs. 0}$$

Decision: Install Now, since Rs. 34,000 > Rs. 0

Advantages

• Provides a visual and systematic approach to complex decisions
• Handles uncertainty through probability
• Easy to understand and communicate to stakeholders

Limitations

• Probabilities may be subjective or difficult to estimate
• Can become complex with many branches
• Assumes outcomes are mutually exclusive

Conclusion: The Single-Location Installation Decision Tree is a powerful tool for evaluating installation decisions at one site by comparing expected values of alternatives, helping managers make rational, data-driven choices.