CIT851: ADVANCED SYSTEMS ANALYSIS AND DESIGN

MODULE 1
Unit 1: Introduction to Systems Analysis and Design
Examinable Points:
 Systems Analysis and Design (SAD): The process of examining a business situation
to improve it through better procedures and methods.
 Systems Development Life Cycle (SDLC): A framework for planning and executing
the development of information systems.
 What Systems Analysis Is NOT:
o Selecting computerized vs. non-computerized methods.
o Determining changes to be made (change is a result, not an intent).
o Focusing solely on information system problems (business problems come first).
 Traditional SDLC Problems:
o Poor communication between users and developers.
o Late, over-budget projects that don't meet user needs.
o Short-term solutions with poor implementation strategies.
o Difficulty and time required to make system changes.
o Outdated or missing documentation.
o Programmer reliance hindering knowledge transfer.
Self Assessment Exercise:
1. Two major components of systems development: Systems Analysis and Systems
Design.
2. List of at least four problems associated with systems development (any four from the
list above).
Tutor-Marked Assignment:
 Define systems analysis and design and explain its purpose.
 Discuss what systems analysis is NOT.
 Briefly explain the traditional SDLC and the problems associated with it.
UNIT 2: FUNDAMENTALS OF SYSTEMS
3.1 Fundamentals of Systems
 System: An organized grouping of interdependent components with a specific goal.
(Definition)
 Information System: A system with people, data, processes, information presentation,
and information technology that supports business operations and decision making.
(Definition)
Characteristics of a System:
 Organization: Structure and order for achieving objectives. (Examiner Point)
 Interaction: Components working together. (Examiner Point)
 Interdependence: Components relying on each other. (Examiner Point)
 Integration: How parts work together within the system. (Examiner Point)
1
 Central Objective: A clear goal for the system. (Examiner Point)
3.2 Important Terms Related to Systems
 Purpose: Reason for a system's existence and its success measurement. (Examiner
Point)
 Boundary: Defines what's inside and outside the system. (Examiner Point)
 Environment: Everything outside the system's boundary that affects it. (Examiner
Point)
 Inputs: Physical objects and information entering the system. (Examiner Point)
 Outputs: Physical objects and information leaving the system. (Examiner Point)
3.3 Classification of Systems
 Formal vs. Informal:
o Formal: Planned and scheduled with documented procedures. (Examiner Point)
o Informal: Not planned, works on an as-needed basis. (Examiner Point)
 Physical vs. Abstract:
o Physical: Tangible entities (e.g., computer, machine). (Examiner Point)
o Abstract: Conceptual entities (e.g., company). (Examiner Point)
 Open vs. Closed:
o Open: Receives and provides inputs/outputs to the environment. (Examiner Point)
o Closed: Isolated from the environment, self-contained. (Examiner Point)
 Manual vs. Automated:
o Manual: Requires human intervention. (Examiner Point)
o Automated: Doesn't require human intervention (e.g., traffic light system). (Examiner
Point)
3.4 Real Life Business Subsystems
 Subsystems: Components of a larger system that can also be considered individual
systems. (Examiner Point)
 Example: Manufacturing firm with subsystems for product design, production, sales,
delivery, and service. (Examiner Point)
Self Assessment and Tutor-Marked Assignment:
 Refer to the above examiner points for guidance on answering these sections.
Summary of Unit 3: Systems
Exam Points:
 Real-time systems: Defined as interactive processing systems with strict time
constraints. They are categorized into hard real-time (guaranteeing critical tasks) and
soft real-time (critical tasks get priority).
 Distributed systems: Data, processes, and interfaces are spread across multiple
locations in a network. Processors communicate and share resources.
 System Development Life Cycle (SDLC): A standard methodology for developing
information systems. It consists of four phases: System Analysis, System Design,
System Construction & Implementation, and System Support. Each phase has inputs,

2
 tasks, and outputs. Traditional SDLC is sequential, but newer approaches allow for
backtracking and concurrent work on phases.
 Principles for successful system development:
o Involve both customers and developers for accuracy.
o Adopt a problem-solving approach (study, define requirements, identify solutions,
design & implement, evaluate & refine).
o Establish phases and activities.
o Set standards for:
 Documentation (ongoing throughout SDLC)
 Quality (checks at every phase)
 Automated Tools (hardware/software platforms for development and maintenance)
o Consider development as a capital investment:
 Evaluate multiple solutions for cost-effectiveness (balance between
development/operating costs and benefits).
 Implement risk management (identify, evaluate, and control potential problems).
 Use feasibility checkpoints to decide if continuing is worthwhile.
o Divide and conquer complex problems by breaking them into smaller subsystems.
o Design for growth and change to accommodate future needs.
Unit 4: Approaches for Development of Information Systems
Exam Points:
 Various approaches for developing information systems:
o Model Driven: Uses pictorial system models to document existing/proposed systems.
The model becomes the blueprint for design and construction.
o Accelerated (Prototyping): Builds a scaled-down but functional version of the desired
system to test ideas and assumptions. Users can provide feedback for revisions.
o Joint Application Development (JAD): A structured approach where users, managers,
and analysts work together to define or review system requirements through intensive
meetings.
 Structured Analysis and Design (SAD): A model-driven development technique
focusing on analyzing existing systems and developing specifications for proposed
systems.
o Structured Analysis tasks:
 Preliminary Investigation
 Problem Analysis
 Requirement Analysis
 Decision Analysis
o Structured Analysis tools:
 Data Flow Diagram (DFD): Illustrates business process requirements.
 Entity Relationship Diagram (ERD): Illustrates business data requirements.
o Structured Design:

3
 Focuses on developing software specifications from analysis outputs.
 Goal: Create functionally independent program modules.
 Uses Structure Charts to illustrate program structure and interaction between modules.
 Design principles:
 Modularity and Partitioning: Break down systems into a hierarchy of modules.
 Coupling: Modules should have minimal dependence on each other.
 Cohesion: Modules should perform a single processing function.
 Span of Control: Modules should manage a limited number of lower-level modules.
 Size of Module: Keep module size small for better manageability.
 Shared use of Functions: Avoid duplicate functions; create reusable ones.
 Prototyping:
o Develops a working model of a system to test ideas and get user feedback.
o Steps:
 Identify user requirements and features.
 Develop a working prototype.
 Revise the prototype based on user feedback.
 Repeat until a satisfactory system is achieved.
o Prototypes are limited in functionality compared to final systems (no error checking,
data validation, etc.).
o Can be easily developed with 4GLs (fourth-generation languages) and CASE
(Computer Aided Software Engineering) tools.
 Joint Application Development (JAD):
o A structured approach where users, managers, and analysts collaborate to define
system requirements through intensive meetings.
o Key feature: Joint requirements planning (structured group meetings for problem
analysis and requirement definition).
o Participants:
 JAD Session Leader: Organizes and facilitates the JAD sessions.
 Users: Key participants with daily system usage experience.
 Managers: Approve project objectives, priorities, schedules, costs, training needs, and
implementation plans.
 Sponsors: High-level management who sponsor the JAD.
 Systems Analysts: Attend to learn from others, not dominate the process.
 Scribe: Takes notes during sessions.
 IS Staff: May attend to learn or contribute ideas on technical feasibility or limitations.
o Benefits:
 Actively involves users and management.
 Reduces development time.

4
 Sure, here are the examinable points identified in Unit 5 and Unit 6 of the Systems
Analyst - A Profession course:
Unit 5: Systems Analyst - A Profession
 Why Businesses Need Systems Analysts
o Businesses need computer-based information systems to provide accurate information
and respond faster to queries and events.
o Systems analysts bridge the communication gap between business users and
information technology professionals.
 Users
o System users are people who use information systems or are affected by them on a
regular basis.
o There are two main classes of system users:
 Internal users: Employees of the business for which an information system is built
(clerical staff, technical staff, managers, etc.)
 External users: Customers and other businesses that use a business's information
systems.
 Analysts in Various Functional Areas
o Traditional Business: Systems analysts may work in different functional areas, such as
system development, data administration, telecommunications, and end-user
computing.
o Modern Business: Systems analysts may be reassigned to different projects and work in
more decentralized, team-oriented environments. Outsourcing and consulting are also
used for software development.
Unit 6: Systems Analyst - Roles, Duties and Qualifications
 Roles of a Systems Analyst
o Change Agent: Introduces changes to the user organization and helps users accept
them.
o Investigator and Monitor: Investigates existing systems to find problems and monitors
projects to ensure they are completed on time, within budget, and with quality.
o Architect: Designs the information system architecture based on user requirements.
o Psychologist: Understands user needs and motivations through interaction.
o Motivator: Encourages user participation and system acceptance through training and
motivation.
o Intermediary: Represents user needs and tries to appease all parties involved in
implementing a system.
 Duties of a Systems Analyst
o Defining Requirements: Understands user requirements through fact-finding techniques
like interviews, questionnaires, and observation.
o Prioritizing Requirements: Sets priorities among requirements, considering user needs
and diplomacy.
o Analysis and Evaluation: Analyzes existing systems and finds the best characteristics
for the new system.
o Solving Problems: Identifies problems, analyzes them, and suggests solutions.
5
o Drawing Up Functional Specifications: Creates non-technical specifications of the
system to be designed.
o Designing Systems: Designs the system based on the specifications.
o Evaluating Systems: Evaluates the system after it has been implemented.
 Qualifications of a Systems Analyst
o Working knowledge of information technology
o Computer programming experience and expertise
o General business knowledge
o Problem-solving skills
o Communication skills
o Interpersonal skills
o Flexibility and adaptability
o Analytical skills
o Technical skills
o Management skills
o Understanding of organizational knowledge
o Problem identification and problem-solving skills
Overall, a Systems Analyst should possess a combination of technical skills,
analytical skills, communication skills, and interpersonal skills to be successful.
UNIT 7: PROCESS OF SYSTEM DEVELOPMENT
 System Development Life Cycle (SDLC): A common methodology for developing
information systems. It's a set of phases that mark the progress of the system analysis
and design.
 SDLC phases are not strictly sequential: You can revisit earlier phases if needed,
and some activities can be done in parallel.
 Iterative vs. Spiral vs. Waterfall Model:
o Iterative: Phases are repeated until a satisfactory system is found.
o Spiral: Phases are cycled through at different levels of detail.
o Waterfall: Phases progress linearly, with the output of one feeding the next (covered in
this unit).
 Custom vs. Generic Life Cycle: Every organization may have its own specifics, but
most follow a similar generic model.
SDLC Phases:
1. Project Identification and Selection: Identify the need for a new or improved system.
Prioritize needs and translate them into a development plan.
2. Project Initiation and Planning: Investigate identified problems and decide on system
implementation. Define project scope and create a detailed plan using the remaining
SDLC steps.
3. Analysis:
o Requirements Determination: Work with users to understand their expectations. This
includes studying current systems and structuring requirements.

6
o Feasibility Study: Assess if the proposed system is technically, economically,
behaviorally, operationally, legally, and timely feasible. If not, the project is rejected.
4. Logical Design: Design the system's functionalities without considering specific
hardware or software. Focus on how the system will work.
5. Physical Design: Convert the logical design into technical specifications. Decide on
programming language, database, platform, network environment, etc.
6. Implementation: Turn specifications into a working system. This includes coding,
testing (individual programs and entire system), and installation (direct conversion,
parallel conversion, phased conversion).
7. Maintenance: Fix errors, adapt to changing needs, and make improvements as
requested by users. This is an ongoing process.
Self Assessment Exercise Answers:
1. Five types of feasibilities in the analysis phase: Technical, Economic, Behavioral,
Operational, Legal, Time.
2. Three ways of installing a system: Direct conversion, Parallel conversion, Phased
conversion.
Tutor-Marked Assignment Answer:
Seven steps involved in the system development life cycle:
1. Project Identification and Selection
2. Project Initiation and Planning
3. Analysis
4. Logical Design
5. Physical Design
6. Implementation
7. Maintenance
Sure, the unit covers the main phases of the System Development Life Cycle (SDLC)
and some alternative approaches to development. Here are the key points covered in
each section:
3.1 Products of SDLC Phases
 This section outlines the deliverables for each phase of the SDLC. These deliverables
include project priorities, system architecture, plans, specifications, analysis
descriptions, and more.
3.2 Approaches to Development
 This section discusses alternative approaches to the traditional SDLC methodology.
 It covers Prototyping, Joint Application Design (JAD), and Participatory Design (PD).
 Prototyping is an iterative process where a simplified version of the system is built to
gather user feedback and refine requirements.
 Joint Application Design (JAD) brings together users, managers, and developers for
structured workshops to collaboratively define system requirements and designs.
 Participatory Design (PD) emphasizes user involvement throughout the development
process. In some cases, users may even have control over the design decisions.
3.3 Case Study

7
 This section uses the example of a library management system to illustrate the SDLC
phases in action.
 It covers aspects like feasibility studies, design, and data dictionary creation.
3.4 Data Dictionary
 A data dictionary is a central repository that defines and stores information about the
data used in the system.
 It helps ensure consistency and understanding among team members.
3.5 Data Capture Information
 This section covers how data will be identified, retrieved, and captured within the
system.
Output Design
 The design of outputs should focus on usability, purpose, timeliness, and choosing the
right method (reports, messages, etc.).
Database Design
 This section provides an example of how the entities and attributes for the library
system might be modeled in a database.
Self Assessment Exercise
 The question asks about the main idea behind Joint Application Design (JAD), which is
to bring together various stakeholders for collaborative design and requirement
definition.
Conclusion
 The unit reviews the SDLC and alternative approaches like prototyping, JAD, and PD.
Summary
 This section highlights that the unit covers the deliverables produced during the different
SDLC phases.
Tutor-Marked Assignment
 The question asks for a definition of Prototyping, which is an iterative approach to
develop a basic version of the system to get user feedback and improve requirements.
UNIT 9: DOCUMENTATION OF SYSTEMS
Concepts and Process of Documentation
 Documentation is the process of communicating about a system.
 Documentation is needed to transfer knowledge, communicate among teams, meet
regulatory demands, and for maintenance and migration.
 The documentation process involves collecting source material, creating a plan,
reviewing the plan, creating the document, testing the document, and maintaining the
document.
Types of Documentation
 System Requirements Specification (SRS) - A document that specifies the complete
and precise properties of the software.
o Characteristics of a good SRS: Unambiguous, complete, realistic, verifiable and
consistent, modifiable, traceable, address implicit requirements.

8
o Rules for specifying software requirements: Use industry standards, use standard
models, limit structure of paragraphs, simple sentences.
o Structure of a typical SRS document: Introduction, informative description, functional
description, test and validation criteria, glossary, bibliography.
 System Design Specification (SDS) - A document that describes how the requirements
of the system will be implemented.
o Tools used to describe design: Data Dictionary, Table Definitions, Database Schema,
E-R Model, Security Model, Trade-Off Matrix, Decision Table, Timing Diagram, State
Machine Diagram, Object Interaction Diagram, Flowchart, Inheritance Diagram,
Aggregation Diagram, Structure Chart, Pseudocode.
o Contents of a typical SDS document: Introduction, system architecture description,
detailed description of components, appendices.
 Test Design Document (TDD) - A document that provides information for testing the
software.
o Typical content of a TDD: Introduction, test plan, recording of tests, reporting test
results, verification testing, validation testing.
 User Manual - A document that provides instructions for using the software.
o Different types of user manuals: Introductory manual, functional description, reference
manual, system administrator guide, installation document.
o Typical content of a user manual: Introduction, instructional manual, user reference
manual, installation information, maintenance manual.
Self Assessment Exercise
 The document asks you to explain the tools used in the system design specification to
describe various aspects of the design. Refer to the list of tools mentioned above under
System Design Specification (SDS).
Conclusion
 This unit covers the concepts, process, and types of documentation.
Summary
 This unit covers concepts and process of documentation.
Tutor-Marked Assignment
 The document asks you to explain the rules for specifying software requirements. Refer
to the bulleted list under Rules for Specifying Software Requirements.
Unit 10: Documentation Standards - Summary by Unit
Unit 10 covers Documentation Standards, a crucial aspect of software
development.
Key Points:
 Different Documentation Standards:
o Importance: Ensure consistent practices in creation, interpretation, change, and
revision of documents.
o Examples:
 ISO/IEC 12207: Software life cycle process (describes documentation as a supporting
process)

9
 ISO/EC 18019: User documentation guidelines for application software (format, style,
content)
 ISO/EC 15910: Software user documentation process (minimum process for creating
user documentation)
 IEEE 1063: Software user documentation (minimum requirements for structure, content,
format)
o Components of User Documentation (IEEE 1063):
 Identification (Title Page)
 Table of Contents
 List of Illustrations
 Introduction
 Information for Using the Software
 Concept of Operations
 Procedures
 Software Commands
 Error Messages & Problem Resolution
 Glossary
 Related Information Sources
 Navigational Features (electronic documents)
 Index
 Search Capability (electronic documents)
 Documentation and Software Quality:
o Inaccurate, incomplete, or missing documentation leads to poor software quality.
o ISO 9000 standards and SEI CMM (Capability Maturity Model) emphasize
documentation and document control for quality software.
o Good documentation is essential for reducing errors in development and maintenance.
o Higher maturity levels in documentation processes lead to higher quality software.
 Good Practices for Documentation:
o Document Early: Write documentation before actual design implementation to save
effort.
o Quality Reflection: Good documentation reflects the quality of the software and
professionalism of the developer.
o Competitive Advantage: Well-written documentation can be a competitive edge over
similar software.
Exam Points:
 Understand the purpose and benefits of documentation standards.
 Identify different documentation standards and their key features.
 Recognize the components of user documentation as specified in IEEE 1063.
 Explain the relationship between documentation quality and software quality.
 Describe good practices for effective software documentation.
10
 By understanding these points, you'll be well-prepared for the unit assessment.
MODULE 2: PLANNING AND DESIGNING INFORMATION SYSTEM
Sure, here is a summary of the unit by unit, pointing out all examinable points:
UNIT 1: PROCESS OF SYSTEMS PLANNING
3.1 Fact Finding Techniques
 Need for Fact Finding: To understand the existing system and its requirements for
developing a new system.
 Types of Fact-Finding Techniques:
o Interviews: Structured (predefined questions) or unstructured (open-ended questions).
 Advantages: Gather individual views, clarify problems, user requirements.
 Disadvantages: Time-consuming, interviewer skills dependent.
o Group Discussions: Involve a group of staff members to discuss problems and find
solutions.
 Advantages: Mutually acceptable solutions, considers all sections.
 Disadvantages: Difficulty scheduling meetings.
o Site Visits: Observe system activities firsthand.
 Advantages: Reliable data, identify complex processes.
 Disadvantages: Uncomfortable for observed staff, inaccurate data due to interruptions.
o Presentations: Customers present information about the existing system or project
requirements.
 Advantages: First-hand knowledge for prototyping.
 Disadvantages: Limited detailed information.
o Questionnaires: Collect data and opinions from a large audience.
 Advantages: Inexpensive, less skill required, convenient for respondents, quick
analysis.
 Disadvantages: Low response rates, misunderstandings, inaccurate answers.
o Types of Questionnaires:
 Free-formed: Open ended questions with blank spaces for responses.
 Fixed-formed: Multiple choice questions with answer choices provided.
3.2 Conducting Interviews
 Importance of proper preparation for interview (location, time, appointment).
 Steps for a successful interview:
o Introduction: Introduce yourself, explain purpose and confidentiality.
o Asking Questions: Use structured questions exactly as worded, ask in the same
sequence.
o Recording the Interview: Keep a record with source and time of data collection.
o Final Check: Prepare a report of the interview for the interviewee's signature and
verification.
3.3 Group Discussions

11
 Gather individuals from different sections to discuss problems and find solutions.
3.4 Site Visits
 Objectives: Closely examine the existing system and record its activities.
 Guidelines:
o Conduct visits during normal workload, then observe peak hours.
o Collect input/output forms and documents during the visit.
o Maintain a low profile, obtain permission, inform those being observed, take notes
immediately, avoid assumptions.
3.5 Presentations
 Customers present information about the existing system or project requirements.
3.6 Questionnaires
 Types: free-formed and fixed-formed.
UNIT 2: FEASIBILITY STUDY
3.1 Issues Involved in Feasibility Study
 Importance of conducting feasibility studies throughout the project lifecycle to avoid
wasted time and resources.
 Feasibility study stages:
o Preliminary investigation: Estimate project urgency and development cost.
o Problem analysis: Study the current system to understand the problem and estimate
development costs and benefits.
o Feasibility analysis: Investigate technical, operational, economic, and legal feasibility.
3.2 Technical Feasibility
 Concerns the availability of hardware, software, and technical expertise for system
development.
 Considers:
o Maturity and capability of proposed technology.
o Availability of required hardware and software.
o Availability of skilled technical manpower.
3.3 Operational Feasibility
 Examines the likelihood of the developed system being used and its impact on
operations.
 Considers:
o User acceptance and willingness to use the system.
o Adequacy, timeliness, accuracy, and usefulness of information provided by the system.
o System response time and efficiency.
o Security of information and data.
o Ability of the system to provide reliable services.
3.4 Economic Feasibility
 Measures the cost-effectiveness of the project.

12
 Compares the project's benefits to its costs to determine if it is worthwhile.
 Cost-benefit analysis is a detailed examination of costs and benefits conducted when
specific requirements and solutions are identified.
3.5 Legal Feasibility
 Examines legal issues arising from system development.
 Considers:
o Copyright law, labor law, antitrust legislation, foreign trade regulations, etc.
o Contractual obligations (number of users, licenses).
o Ownership of code and permissions for installation.
o Tax laws and foreign currency transfer regulations (for international projects).
Examiner Points:
 Be able to explain the different fact-finding techniques and their advantages and
disadvantages.
 Understand the importance of conducting interviews and how to conduct them
effectively.
 Know the four issues studied in feasibility analysis (technical, operational, economic,
and legal
Sure, the unit covers system analysis which includes cost-benefit analysis, preparing
schedules, and gathering requirements. Here are the examinable points:
UNIT 3: ANALYSIS OF THE SYSTEM
3.1 Cost Benefit Analysis
 Two components of economic feasibility: Costs and benefits.
 Costs:
o Tangible costs: Hardware, software, human resources.
o Intangible costs: Quality of the system, efficiency.
 Benefits:
o Tangible benefits: Measurable in terms of savings or profits (e.g., reduced staff).
o Intangible benefits: Improved customer satisfaction, better decision making.
3.2 Preparing Schedule
 Schedule feasibility: Ensuring the project can be completed within the planned
timeframe.
 Factors to consider for schedule feasibility: Team size, resource availability,
outsourcing.
3.3 Gathering Requirements of System
 Importance of accurate requirements: Avoids delays, rework, and ensures the
system meets user needs.
 Two techniques for gathering requirements:
o Joint Application Development (JAD): Group meetings to define requirements.
 Participants: Sponsor, facilitator, user manager, IT staff.
 Success factors: Proper planning, agenda preparation, facilitator following guidelines.

13
o Prototyping: Building a scaled-down version of the system to get user feedback.
 Useful when requirements are unclear, complex, or communication issues exist.
Self Assessment Exercise
 Question 1: What is prototyping? (Answer: A scaled-down, functional version of a
desired system used to gather requirements.)
 Question 2: What are the two components in economic feasibility? (Answer: Costs and
benefits.)
Tutor-Marked Assignment
 Describe two types of costs associated with a project. (Answer: The answer should
describe tangible costs (e.g., hardware, software) and intangible costs (e.g., quality,
efficiency).)
Unit 4 focuses on the principles of design for creating a system. Here are the key
examinable points:
UNIT 4: PRINCIPLES OF DESIGN
3.1 Design Principles
 Problem Partitioning (Divide and Conquer): Breaking down a large problem into
smaller, manageable modules that interact with each other. Improves efficiency.
 Abstraction: Focusing on the essential details of a component without worrying about
implementation specifics. Comes in two forms:
o Functional abstraction: Specifying a module by its function.
o Data abstraction: Hiding data behind functions, forming the basis for object-oriented
design.
3.2 Top-Down Design
 Starts from the highest-level system component and decomposes it into lower-level
modules until the desired detail is achieved.
 Often involves stepwise refinement, where each step makes the design more concrete
until it's ready for implementation.
 Suitable for systems built from scratch where you can start with the main menu and
work down.
3.3 Bottom-Up Design
 Starts from the lower-level modules and combines them to create larger ones,
eventually reaching the top-level module.
 Requires more intuition to decide the functionalities of each module.
 More suitable for building systems from existing modules.
Self Assessment Exercise
 Question 1: What do you understand by abstraction? (Answer: Focusing on essential
details of a component without implementation specifics.)
 Question 2: What policy is adopted in problem partitioning? (Answer: Divide and
Conquer)
Tutor-Marked Assignment
 Describe two strategies that help implement design principles. (Answer: The answer
should explain top-down design (starting from the highest level) and bottom-up design
(starting from the bottom level).)
14
 Unit 5: Structural Design Exam Points
3.1 Structure Charts
 Function: Depict the hierarchical organization of an information system's components.
 Elements:
o Modules (rectangles): Represent program or system functions. Named descriptively
(ideally one function per module).
o Data couples (empty circles with arrows): Indicate data flow between modules.
o Control flags (filled circles with arrows): Indicate control flow between modules (e.g.,
conditional execution).
o Superordinate/Subordinate relationships: Arrows show calling relationships (higher-level
calls lower-level).
Exam Points:
 Understand the purpose and structure of structure charts.
 Identify different symbols used in structure charts and their meanings.
 Interpret the flow of data and control between modules in a structure chart.
3.2 Modularity
 Definition: Breaking down a program into smaller, independent, and reusable
components (modules).
 Benefits:
o Improves code readability, maintainability, testability, and debuggability.
o Promotes code reusability across projects.
Exam Points:
 Explain the concept of modularity in software design.
 Describe the benefits of using a modular design approach.
3.3 Goals of Design
 Modular structure: System is built from modules organized hierarchically.
 Control hierarchy: Each module controls a suitable number of subordinate modules.
 Minimal coupling: Modules should communicate as little as possible, ideally through
parameters.
 Appropriate module size: Modules should be neither too small nor too large for
manageability.
 Single function per module: Each module should perform a single, well-defined
function.
 Generic coding: Modules should be coded for general use whenever possible.
Exam Points:
 Identify the key goals of good software design.
 Explain the importance of each design goal for creating a well-structured system.
3.4 Coupling
 Definition: The degree of interdependence between modules. Lower coupling is
preferred.

15
 Types of Coupling (from least to most dependent):
o Data coupling: Modules communicate through data parameters.
o Stamp coupling: Modules communicate through entire data structures (less ideal).
o Control coupling: Superordinate module controls subordinate with control information
(increases dependency).
o Common coupling: Modules share global data areas (tight coupling, not
recommended).
o Content coupling: One module directly accesses and modifies another's internal data
(strongly discouraged).
Exam Points:
 Define coupling in software design.
 Understand different types of coupling and their relative merits/demerits.
 Identify the best and worst types of coupling for achieving loose coupling.
3.5 Cohesion
 Definition: Degree to which a module focuses on a single task. Higher cohesion is
preferred.
 Types of Cohesion (from most to least cohesive):
o Functional cohesion: Module performs a single, well-defined function.
o Sequential cohesion: Module instructions process data sequentially.
o Communicational cohesion: Module instructions use the same data but may not be
strictly sequential.
o Procedural cohesion: Instructions are related by control flow, potentially leading to
calls to other modules.
o Temporal cohesion: Instructions are unrelated but grouped for temporal reasons (e.g.,
end-of-day tasks).
o Logical cohesion: Instructions are loosely related, potentially executed based on flags
from a superordinate module.
o Coincidental cohesion: Instructions are unrelated and grouped for convenience (worst
type).
Exam Points:
 Define cohesion in software design.
 Understand different types of cohesion and their relative strengths/weaknesses.
 Identify the best and worst types of cohesion for achieving functional focus within
modules.
Additional Notes:
 The unit emphasizes the importance of designing systems with well-defined modules
that communicate effectively while remaining relatively independent.
 Understanding coupling and cohesion concepts is crucial for creating maintainable and
reusable software.
Unit 6: Logical and Physical Design - Summary of Examinable Points
This unit covers the logical design phase of the system development life cycle (SDLC).
Here's a breakdown of the key points for exams:
16
 3.1 Logical Design
 Defines the system's functional features without relying on specific computer platforms.
 Involves designing forms, reports, user interfaces, and logical databases.
 Works closely with the analysis phase and ensures consistency between design
elements.
3.2 Form Design
 Principles: Capture essential data, avoid redundant data capture, use codes effectively,
include clear instructions, and organize data entry logically.
 Common GUI controls: Text box, radio button, checkbox, list box, dropdown list,
combination box, spin box.
 Steps: Identify inputs, select GUI controls, design, validate, and test using layout or
prototyping tools.
3.3 Report Design
 Output types based on distribution and purpose: Internal (detailed, summary) and
External.
 Implementation methods: Tabular, zoned, screen, graphic.
 Guidelines: Simplicity, timely delivery, sufficient distribution, user-friendliness.
 Steps: Identify outputs, specify physical requirements, design external forms if needed,
design, validate, and test using layout, prototyping, or code-generating tools.
3.4 User Interface Design
 Focuses on user-computer interaction, including system startup, input/output
presentation, and overall screen flow.
 Guidelines: Clear user guidance, consistent screen formatting, appropriate message
display duration, sparing use of display attributes, default values, error handling, and
preventing catastrophic actions.
3.5 Logical Database Design
 Uses data modeling (entity-relationship model - E-R model) to create a conceptual data
model.
 E-R model helps design relational databases (collections of tables representing entities
and attributes).
 Normalization: Process to eliminate data redundancy and ensure data integrity.
Note: This unit mentions physical design briefly, but the focus is on logical design.
Physical design involves aspects like:
 Designing physical files and databases for storage and access.
 Designing system and program structure.
 Designing distributed processing strategies.
Self-Assessment Exercise
 Describe user interface design (refer to guidelines).
 Explain two types of outputs (e.g., internal detailed reports, external invoices).
Exam Tip: Be prepared to discuss these points in detail and apply your understanding
to specific scenarios.

17
 Sure, the unit covers data modeling and process specification tools. Here are the
examinable points by unit:
Unit 7: Process Modeling
 Components of a Data Flow Diagram (DFD):
o Process
o Data Flow
o Source or Sink (External Entity)
o Data Store
 Rules for Drawing a DFD:
o Rules for Process
o Rules for Data Store
o Rules for Source/Sink
o Rules for Data Flow
Unit 8: Data Modeling
 Entity-Relationship (ER) Diagram:
o Entities
o Attributes
o Relationships
 Cardinality
 Degree
 Recursive Relationship
 Process Specification Tools:
o Decision Table
o Decision Tree
o Structured English Notation (SE)
 Data Dictionary:
o Purpose
o Data Elements
o Data Structures
Self-Assessment Exercises:
 Unit 7: List the components of a DFD and mention four rules for drawing a DFD.
 Unit 8: What is the ER Diagram? Describe a recursive relationship with the aid of a
diagram.
Tutor-Marked Assignments:
 Unit 6: Discuss the categories of a data flow diagram (not covered in this excerpt).
 Unit 8: Define the term "Data Modeling".

18
 Sure, the unit covers designing forms and reports. Here are the main points you should
learn according to the unit:
Unit 9: Forms and Reports Design I
 Forms are used to collect data. They offer advantages like a user-friendly interface,
data entry validation, and the ability to present data in a formatted way.
 Reports are used to present information retrieved from a database. They can be used
for various purposes like summarizing data, identifying trends, or showcasing
exceptions.
Key Differences Between Forms and Reports
 Forms are primarily used for data input, while reports are used for data output.
 Forms typically deal with one record at a time, while reports can handle multiple
records.
 Reports offer more flexibility in presenting data including functionalities like calculations,
grouping and summaries.
Process of Designing Forms and Reports
 Identify the purpose and target audience: Clearly define what information needs to
be collected or presented and who will be using the form/report.
 Gather requirements: Ask questions like "who, what, when, where, and how" to
understand user needs and usage scenarios.
 Develop a prototype: Create a preliminary design of the form/report for user review
and feedback.
 Refine the design: Incorporate feedback and iterate on the design until it meets user
requirements.
 Test and validate: Ensure the design is functional, user-friendly and delivers accurate
information.
Deliverables and Outcomes
 Design Specifications: A document that outlines the purpose, target audience,
functionalities and layout of the form/report.
Unit 10: Forms and Reports Design II
 Types of Information:
o Internal Information: Data used within the organization for day-to-day operations or
management decisions. (e.g., sales reports, inventory listings)
o External Information: Data shared with external parties like customers, suppliers, or
regulators. (e.g., invoices, product brochures)
o Turnaround Documents: Documents that are initially sent out and then returned with
additional information. (e.g., warranty cards, acknowledgement slips)
 Criteria for Form Design
o Organization: Arrange data logically and group related information together.
o Consistency: Maintain a consistent layout and style across all forms used within the
organization.
o Completeness: Capture all necessary data to avoid the need for additional data entry.
o Flexible Entry: Allow for data entry by hand or using a computer.
o Economy: Minimize the overall cost of design, printing, and data entry.
19
 Criteria for Report Design
o Relevance: Include only the information relevant to the report's purpose.
o Accuracy: Ensure the data presented is accurate and free of errors.
o Clarity: Present information in a clear, well-organized, and easy-to-understand manner.
o Timeliness: Deliver reports promptly while the information is still relevant for decision-
making.
o Cost: Balance the cost of report preparation and distribution with the expected benefits.
MODULE 3: SYSTEM DESIGN, IMPLEMENTATION AND MAINTENANCE
Unit 1 Summary: Database Design Fundamentals
This unit focuses on the foundational concepts of database design, transitioning from
flat files to relational databases.
Key Examinable Points:
 Advantages of Databases over Flat Files: Be prepared to explain how databases
offer benefits like improved data organization, reduced redundancy, and better data
integrity compared to flat files.
 Database Design Steps: Understand the different stages involved in database design,
including analysis, design, and implementation.
 Entity-Relationship (E-R) Model: Be familiar with how the E-R model maps real-world
entities and their relationships into database tables. You may be asked to identify
entities, attributes, and relationships from a scenario and translate them into an E-R
Model.
 Database Field Design: This is a crucial area for exams. Be prepared to:
o Differentiate between primary key, secondary key (alternate key), and foreign key:
 Primary key uniquely identifies each record in a table.
 Secondary key is an optional alternative for unique identification.
 Foreign key references the primary key of another table, establishing relationships.
o Explain the rules for naming tables and fields (unique, meaningful, short).
o Understand database field properties: Name, data type, size, null values, domain (valid
values), default value, and referential integrity.
Exam Tip:
 Master the different key types and how they establish connections between tables.
 Grasp the concept of referential integrity for ensuring data consistency across tables.
This might be a specific exam question like "Define referential integrity".
Additional Notes:
 While not explicitly mentioned as examinable points, understanding the purpose of
descriptive fields (attributes storing data) and the importance of data types for efficient
storage and retrieval would be beneficial.
This summary should equip you for the Unit 1 exam. Remember to focus on the key
examinable points and practice applying your knowledge to scenarios.
Unfortunately, without access to the specific content of Unit 2, I can only provide a
general outline of what it might cover based on its likely connection to Unit 1.
Unit 2: Likely Focus on Advanced Database Design
20
 Building on the foundation of Unit 1, Unit 2 might delve into more advanced database
design techniques:
 Normalization: This involves a series of steps to refine the database structure by
eliminating data redundancy and anomalies. Understanding different normalization
forms (e.g., first normal form, second normal form) and their application would be
crucial.
 Data Integrity Constraints: This likely expands on referential integrity from Unit 1,
exploring additional constraints like entity integrity (primary key cannot be null) and
domain integrity (ensuring values fall within a specific range).
 Structured Query Language (SQL): Unit 2 might introduce SQL, the standard
language for interacting with relational databases. You might learn basic SQL
commands for creating tables, inserting, updating, and retrieving data.
Exam Tips:
 Be prepared to explain the different normalization forms and their advantages.
 Understand how data integrity constraints help maintain data accuracy and consistency.
 If SQL is covered, focus on mastering basic commands for data manipulation.
Remember:
This is a general assumption based on the typical progression in database design
courses. Refer to your course materials or consult your instructor for the specific
examinable points in Unit 2.
Unit 3 Summary: CASE Tools for System Development I
This unit focuses on Computer-Aided Software Engineering (CASE) tools, used to
support various activities within the software development process.
Key Points:
 Definition: CASE tools are software applications that automate tasks or provide
assistance for different phases of software development. They can improve efficiency,
consistency, and documentation quality.
 Benefits for Organizations:
o Standardize development methodology
o Facilitate rapid application development (RAD)
o Enhance testing through automation and improved test coverage
o Generate high-quality and consistent documentation
o Improve project management activities
o Increase developer productivity and reduce costs
 Roles of CASE Tools:
o Project management
o Data dictionary management
o Code generation
o User interface design
o Schema generation
o Data warehouse metadata creation
o Reverse engineering (recreating models from existing code)
21
o Re-engineering (redesigning legacy systems)
o Documentation generation
o Version control
o Object-oriented analysis and design
o Software testing
o Data modeling
o Project scheduling
o Cost estimation
 Types of CASE Tools:
o Planning and Management Tools: Support information planning and project
management activities at the beginning of the development process.
o Analysis Tools: Help ensure accurate capture of business requirements during the
analysis phase.
o Design Toolset: Provides detailed system specifications.
o Information Integrator: Ensures consistency and completeness of system specifications
and stores them in a central repository.
o Code Generator: Automatically generates code based on system specifications.
o Database Design Toolset: Suggests database design and generates system control
information.
o User Interface Generator: Generates user interfaces based on system specifications.
o Report Generator: Generates reports based on specifications.
 Forward vs. Reverse Engineering:
o Forward Engineering: Generates code skeletons from models created during the design
phase.
o Reverse Engineering: Analyzes existing code to create a corresponding model, useful
for understanding undocumented legacy systems.
Unit 4 Summary: CASE Tools for System Development II
This unit builds upon Unit 3, exploring advanced CASE tools and their functionalities.
Key Points:
 Visual CASE Tools: Enable rapid creation of user interfaces and related code
skeletons through visual modeling techniques.
 Traditional vs. CASE-Based Development:
o Traditional: Emphasis on coding, testing, and documentation after the fact.
Specifications are paper-based, coding is manual, and documentation is often
incomplete.
o CASE-Based: Focuses on analysis and design with rapid prototyping, automated code
and documentation generation, design checking, and easier maintenance of design
specifications.
 CASE Environment: A collection of integrated CASE tools and supporting components
that cover most or all phases of the software development life cycle (SDLC), operating
on a common platform. Tools interact with each other to improve efficiency.
Examples of Visual CASE Tools:
22
 Oracle 2000 Designer
 Evergreen EasyCase
 Aonix: Software Through Pictures
 Popkin System Architect
 Cadre Teamwork
 ColdFusion
 Rational Rose Visual CASE Enterprise Architect
UML Modeling: The Unified Modeling Language (UML) is a standardized graphical
language for specifying software system components and their interactions. It doesn't
prescribe a specific design process but offers a notation for documenting designs.
Tasks Supported by CASE Tools:
 UML modeling
 Code generation for various programming languages
 Database design
 Code generation for C, C++, etc. across platforms
 Component testing
Object-Oriented CASE Tools: These tools are similar to general CASE tools but
specifically designed to support object-oriented development methodologies like
Rumbaugh's Object Management Technique (OMT). They offer features for creating
class diagrams, text specifications, and generating source code in object-oriented
languages.
Emerging CASE Tools:
 Integrated CASE (I-CASE) tools offer a comprehensive development environment with
various tools for creating diagrams, forms, and reports. They provide analysis, reporting,
and code generation facilities while seamlessly sharing and integrating data across
tools.
Remember:
This summary provides a high-level overview. Refer to your course materials for a more
detailed understanding of specific CASE tools and their functionalities.
Unit 5 Summary: System Implementation
This unit focuses on the activities involved in implementing a designed information
system. Here's a breakdown of the key points:
 Implementation Process:
o Coding: Translating the design specifications into working computer software.
o Testing: Identifying and fixing errors in the developed modules and the entire system.
(Types covered later)
o Hardware and Network Setup: Ensuring necessary infrastructure exists for the system
to run.
o User Training: Equipping end-users with the knowledge to operate the system
effectively.
 System Testing:
o Importance: Crucial to ensure the system functions as intended before deployment.
23
o Objectives:
 Identify and fix bugs to prevent system failures.
 Verify the system meets user requirements.
o Types of Testing:
 Recovery Testing: Evaluating system behavior during error situations.
 Security Testing: Assessing the system's vulnerability to unauthorized access.
 Stress Testing: Testing performance under heavy load conditions.
 Performance Testing: Measuring system responsiveness and execution speed.
 Response Testing: Focusing on the system's reaction time to user actions.
 Usability and Documentation Testing: Evaluating user-friendliness and the quality of
documentation.
o Test Planning: Defining the scope, procedures, and resources needed for testing.
o User Acceptance Testing (UAT): Involving users in testing to ensure the system meets
their needs.
 Alpha Testing: Conducted by the customer at the developer's site.
 Beta Testing: Conducted at customer sites with real-world data.
 Conversion Plan:
o A document outlining steps to transition from the existing system to the new one.
o Importance: Minimizing disruption to normal business operations during the switch.
o Conversion Strategies:
 Direct Conversion: Abrupt switch, risky but economical.
 Pilot Conversion: Limited rollout at a single location for testing.
 Parallel Conversion: Running both systems simultaneously until users are comfortable
with the new one (least risky but expensive).
 Phased Conversion: Gradual introduction of new system modules.
 User Manuals:
o Importance: Providing clear instructions for users to operate the system effectively.
o Components:
 Title and Version Information
 Table of Contents
 Salient Features
 Installation Guide and System Requirements
 Getting Started Guide
 Frequently Asked Questions (FAQs)
 Sample Scenarios
 Glossary of Terms
 Known Bugs and Workarounds
 Training:

24
o Importance: Equipping users with the skills and knowledge to utilize the system
effectively.
o Training Methods:
 Computer-Aided Training (CAT)
 Classroom Tutorials
 Interactive Training Manuals
 Resident Technical Experts
 One-on-One Training
 External Training Resources
 Information Centers/Help Desks
Unit 6 Summary: System Maintenance
This unit highlights the importance of maintaining an information system after
implementation.
 Maintenance Activities:
o Involves more than 80% of a software product's lifecycle.
o Focuses on:
 Monitoring system performance and user feedback.
 Evaluating the need for modifications.
 Implementing changes to address issues and enhance functionality.
o Stages of Maintenance:
 Help Desk: Receiving and analyzing user change requests.
 Analysis: Assessing the feasibility and impact of proposed changes.
 Implementation: Making the changes, testing, and releasing the updated system.
 Release: Deploying the updated system to users with proper documentation.
 Types of Maintenance:
o Corrective Maintenance: Fixing errors and bugs identified after implementation (highest
percentage of effort).
o Adaptive Maintenance: Modifying the system to adapt to changes in the environment
(e.g., new regulations, hardware).
o Perfective Maintenance: Adding new features and functionalities to improve the
system's value.
o Preventive Maintenance: Making changes to improve maintainability and prevent future
failures.
 Issues in Software Maintenance:
o Cost: Maintenance activities can be resource-intensive.
o Difficulty in Maintaining Legacy Systems: Systems built with outdated technology and
poor documentation can be challenging to maintain.
o Maintainability: Factors like well-structured code and clear documentation influence
maintenance ease.

25
o Impact Analysis: Assessing how changes in one part of the system might affect other
components.
o Regression Testing: Ensuring existing functionalities are not broken by new changes.
 Solutions for Legacy Systems:
o Subcontracting maintenance.
o Replacing with a new software package.
o Re-implementing from scratch.
o Discontinuing the software and phasing in a new system.
o Reverse engineering and developing a new software
Unit 7: Audit of Computer Systems
This unit focuses on the process of auditing computer systems to ensure their reliability,
security, and efficiency.
Key Points:
 Definition of Audit: An assessment of an information system performed by a
professional to provide recommendations and improve system performance and
security. Audits can be internal or external.
 Objectives of Audit:
o Improve system and process controls.
o Prevent and detect errors and fraud.
o Reduce risk and enhance system security.
o Plan for contingencies and disaster recovery.
o Manage information system development.
o Prepare for independent audits.
o Evaluate resource usage efficiency and effectiveness.
o Achieve cost control and competitive advantage.
 Responsibilities of the System Auditor:
o Maintain professionalism and ethics.
o Clearly state the basis for each assessment.
o Demand data and materials from the audited division.
o Request reports on implemented improvements.
 Confidentiality: Auditors must maintain strict confidentiality of information obtained
during the audit.
 Audit Planning: The Information Systems Auditor must plan the audit to address
objectives and comply with professional auditing standards.
Types of Audits:
 Auditing Transactions: This involves examining transaction details like who made
changes, what changes were made, and whether they were authorized. This helps track
changes and ensures regulatory compliance.
 Audit of Computer Security: This reviews physical and logical security measures,
including access controls, password protection, and network vulnerability assessments.

26
 Audit of Applications: This assesses both manual and programmed internal controls
related to information systems. It covers control environment, data input controls,
processing controls, and output controls.
Benefits of Audits:
 Improved system and process controls
 Reduced risk and enhanced security
 Disaster recovery planning
 Information system development management
 Cost control and competitive advantage
Computer Assisted Audit Techniques (CAATTs):
Auditors use various software tools to assist with audits, including:
 Audit Software: Programs for processing audit data, like generalized data processing
tools or special-purpose programs designed for specific tasks.
 Test Data: Artificial data used to test the correctness of software processing.
Audit Trail:
A log of changes made to data, settings, and related changes. Analyzing the audit trail
helps identify unauthorized access attempts and user activity.
Unit 8: Security of Computer Systems
This unit emphasizes the importance of computer system security and explores various
threats and risk management strategies.
Key Points:
 Security Issues: Modern IT systems are complex and require robust security measures
to protect information and functionality. Security breaches can cause significant financial
losses and reputational damage.
 Threats:
o Natural disasters (earthquakes, floods)
o Human actions (riots, sabotage)
o Unauthorized access (hacking)
o Internal threats (employee actions)
 Risk Assessment and Management:
o Identify threats and vulnerabilities.
o Estimate potential losses.
o Implement appropriate security controls based on risk level.
o Quantitative vs. Qualitative Risk Analysis methods.
 Security Policy: A document outlining an organization's approach to security,
addressing:
o Authentication (user verification)
o Authorization (user access privileges)
o Information integrity (data protection)
o Detection and response to security incidents

27
 Potential Threats:
o Denial-of-Service (DoS) attacks
o IP Spoofing (impersonating a trusted system)
o Trojan Horses (malicious programs)
o Viruses (self-replicating programs)
Disaster Recovery:
 Disaster Recovery Plan: Outlines procedures for emergency response, backup
operations, and recovery from system outages or physical damage.
 Contingency Plans: Address specific threats and help prevent minor incidents from
escalating into disasters.
 Levels of Backup:
o In-House Backup: Minimum level, regular backups of critical data.
o Alternate Storage Area: Offsite storage of critical data for disaster recovery.
Disaster Recovery Toolkit:
A collection of resources to assist with business continuity in case of disasters,
including:
 Contingency audit questionnaire
 Dependency analysis documents
 Business Impact Analysis questionnaire
 Disaster recovery/business continuity plan audit questionnaire
 Disaster recovery checklist and framework
Contingency Planning:
Preparing for potential disruptions to normal operations through:
 Identifying potential events and appropriate actions.
 Addressing loss of data, software, communications, hardware, personnel, and facilities.
 Establishing recovery procedures for each type of loss.
These summaries provide a high-level overview of Units 7 and 8. Refer to your course
materials for more detailed information and specific examples.
Unit 9: Management Information System (MIS)
Key Points:
 What is MIS?
o Helps organizations improve decision-making, problem-solving, control operations, and
create new products/services.
o Used more by larger corporations than smaller businesses.
 Roles of MIS:
o Supports day-to-day operations (inventory, sales trends, etc.)
o Supports managerial decision-making (short-term planning, control)
o Supports strategic decision-making and competitive advantage
o Optimizes operational costs

28
o Provides timely and accurate information
o Offers expert advice to managers on specific areas
 Examples of MIS Use:
o Inventory control
o Sales performance analysis
o Customer and employee information management
Unit 10: Types of Information Systems
Key Points:
 Types of Information Systems (based on end use):
o Operational Information Systems: Support business operations (e.g., transaction
processing systems)
o Management Information Systems (MIS): Help managers make decisions (e.g.,
reports, analysis)
3.1 Transaction Processing Systems (TPS)
 Processes data resulting from business transactions (sales, purchases, etc.)
 Captures and records transaction data
 Examples: Sales transaction systems, inventory control systems
 Can be:
o Online (OLTP): Processes data immediately after a transaction occurs (e.g., Point-of-
Sale systems)
o Batch Processing: Accumulates data over time and processes it periodically
3.2 Management Information Systems (MIS)
 Provides specific information to individual managers for long-term and strategic
decision-making
 Focuses on providing strategic information required by top management
 Uses data from various sources, including external databases
 Presents information in reports (textual and graphical) with features like:
o Trend analysis
o Exception reporting
o What-if analysis (e.g., simulating the impact of price changes)
3.3 Decision Support Systems (DSS)
 Designed to help managers make specific decisions
 Provides information tailored to individual managers' decision-making styles
 Supports interactive inquiries and responses
 Uses data and models to analyze situations and identify solutions
 Examples: Data-driven DSS, Model-driven DSS
3.4 Expert Systems
 Simulates the judgment and behavior of a human expert in a specific field
 Captures knowledge and expertise of an expert and applies it to new situations
29
 Provides expert advice on a problem within a specific domain
 Uses reasoning and explanation capabilities
 Examples: Medical diagnosis systems, Sales forecasting systems
Remember:
 MIS, DSS, and Expert Systems all support decision-making but differ in their focus and
capabilities.
 MIS provides general information for various decisions.
 DSS helps analyze data and explore options for specific decisions.
 Expert Systems offer expert-level advice within a narrow domain.

30