Management Information System

Unit 3: System Analysis and Design

1.1 System
1.2 Meaning and definition
1.3 System Analysis
1.4 Meaning and definition of system analysis
1.5 Need for system analysis,
1.6 System analysis of the existing system,
1.7 System analysis of new requirements,
1.8 System Development Model,
1.9 Structured System Analysis and Design
1.10 Object-Oriented Analysis.
 System
• The word System is derived from Greek word “Systema”, which means
an organized relationship between any set of components to achieve
some common cause or objective.
• A system is an orderly grouping of interdependent components linked
together according to a plan to achieve a specific goal.
Elements of a System
The following diagram shows the elements of a system −
1. Outputs and Inputs:
• The main aim of a system is to produce an output which is useful for its user.
• Inputs are the information that enters into the system for processing.
• Output is the outcome of processing.
2. Processor(s):
• The processor is the element of a system that involves the actual transformation of input
into output.
• It is the operational component of a system. Processors may modify the input either
totally or partially, depending on the output specification.
• As the output specifications change, so does the processing. In some cases, input is also
modified to enable the processor for handling the transformation.
3. Control:
• The control element guides the system.
• It is the decision making subsystem that controls the pattern of activities governing input,
processing, and output.
• The behavior of a computer System is controlled by the Operating System and software.
In order to keep system in balance, what and how much input is needed is determined by
Output Specifications.
4. Feedback:
• Feedback provides the control in a dynamic system.
• Positive feedback is routine in nature that encourages the performance of the system.
• Negative feedback is informational in nature that provides the controller with
information for action.
5. Environment:
• The environment is the super system within which an organization operates.
• It is the source of external elements that strike on the system.
• It determines how a system must function. For example, vendors and competitors of
organizations environment, may provide constraints that affect the actual performance
of the business.
[Link] and Interface:
• A system should be defined by its boundaries. Boundaries are the limits that identify its
components, processes, and interrelationship when it interfaces with another system.
• Each system has boundaries that determine its sphere of influence and control.
• The knowledge of the boundaries of a given system is crucial in determining the nature
of its interface with other systems for successful design.
 Characteristics of system
• A system is an orderly grouping of interdependent components, structured to achieve a
specific, shared objective. It transforms inputs into outputs through organized processes,
interacting with its environment while operating within defined boundaries. Key
characteristics include organization, interaction, interdependence, integration, and a
central purpose.
• Here are the key characteristics of a system:
• Organization: This implies structure and order. Components are arranged in a specific,
intentional manner to achieve the system's objectives.
• Interaction: Components do not act in isolation; they work together. The manner in
which these components interact is critical for the system's functionality.
• Interdependence: Parts of the system are dependent on one another, meaning the
functionality of one component often relies on the output or action of another.
• Integration: Components are tied together, allowing the system to work as a whole
rather than a collection of separate parts. This holistic approach ensures the system
functions as a unified entity.
• Central Objective/Purpose: Every system is designed to achieve a goal or purpose,
which must be clearly defined for successful design.
• Boundary: Systems have a defined boundary that separates them from the outside environment,
defining what is inside and what is outside.
• Environment: The surroundings outside the system's boundary that may influence its operations,
often requiring the system to be adaptable.
• Input & Output: Systems receive input (data, material, energy) from the environment and
transform it into output (products, information, services).
• Feedback: Systems often use feedback mechanisms to monitor outputs and make necessary
adjustments, allowing for improved performance and stability.
 Types of Systems
The systems can be divided into the following types −
[Link] or Abstract Systems:
• Physical systems are tangible entities. We can touch and feel them.
• Physical System may be static or dynamic in nature. For example, desks and chairs are the physical parts of
computer center which are static. A programmed computer is a dynamic system in which programs, data,
and applications can change according to the user's needs.
• Abstract systems are non-physical entities or conceptual that may be formulas, representation or model of a
real system.
2. Open or Closed Systems:
• An open system must interact with its environment. It receives inputs from and delivers outputs to the
outside of the system. For example, an information system which must adapt to the changing environmental
conditions.
• A closed system does not interact with its environment. It is isolated from environmental influences. A
completely closed system is rare in reality.
3. Adaptive and Non Adaptive System:
• Adaptive System responds to the change in the environment in a way to improve their performance and to
survive. For example, human beings, animals.
• Non Adaptive System is the system which does not respond to the environment. For example, machines.
4. Permanent or Temporary System:
• Permanent System persists for long time. For example, business policies.
• Temporary System is made for specified time and after that they are demolished. For example, A DJ system is
set up for a program and it is dissembled after the program.
5. Natural and Manufactured System:
• Natural systems are created by the nature. For example, Solar system, seasonal system.
• Manufactured System is the man-made system. For example, Rockets, dams, trains.
6. Deterministic or Probabilistic System:
• Deterministic system operates in a predictable manner and the interaction between system components is known with
certainty. For example, two molecules of hydrogen and one molecule of oxygen makes water.
• Probabilistic System shows uncertain behavior. The exact output is not known. For example, Weather forecasting, mail
delivery.
7. Social, Human-Machine, Machine System:
• Social System is made up of people. For example, social clubs, societies.
• In Human-Machine System, both human and machines are involved to perform a particular task. For example, Computer
programming.
• Machine System is where human interference is neglected. All the tasks are performed by the machine. For example, an
autonomous robot.
8. Man Made Information Systems:
• It is an interconnected set of information resources to manage data for particular organization, under Direct
Management Control (DMC).
• This system includes hardware, software, communication, data, and application for producing information according to
the need of an organization.
• Man-made information systems are divided into three types −
• Formal Information System − It is based on the flow of information in the form of memos, instructions, etc., from top level to lower levels
of management.
• Informal Information System − This is employee based system which solves the day to day work related problems.
• Computer Based System − This system is directly dependent on the computer for managing business applications. For example, automatic
library system, railway reservation system, banking system, etc.
 Systems Analysis
• It is a process of collecting and interpreting facts, identifying the problems, and
decomposition of a system into its components.
• System analysis is conducted for the purpose of studying a system or its parts in order to
identify its objectives. It is a problem solving technique that improves the system and
ensures that all the components of the system work efficiently to accomplish their purpose.
• Analysis specifies what the system should do. System analysis is the initial phase of a
software development project where the requirements of the system are gathered,
analyzed, and documented.
• It involves understanding the problem domain, identifying the stakeholders, and defining
the scope and objectives of the system.
• Requirement Gathering− Identifying the needs and expectations of the users and
stakeholders.
• Requirement Analysis− Analyzing the gathered requirements to ensure consistency,
feasibility, and completeness.
• Feasibility Study− Assessing the technical, economic, and operational feasibility of the
proposed system.
• Process Modelling− Creating diagrams and models to represent the current and proposed
business processes.
• Data Modelling− Defining the data entities, attributes, and relationships within the system.
• Some of the key aspects of system analysis are:
• Problem Identification: It involves identifying the issues that the system is aiming
to address. Whether it is automating a business process, improving data
management, or improving the user experience, understanding the problem is
the first and most important step.
• Requirements Gathering: Once the problem is identified, the next step is to
gather and write down the requirements. This involves communicating with the
customer and developer to gather information about how the system is to be
designed.
• Feasibility study: Before going into development, it is important to check the
feasibility of the project. This includes the evaluation of technical, operational,
and financial aspects to determine the feasibility of the proposed solution.
• Analysis and modeling: To get a deep insight into the system, analysts develop
various models, such as Data Flow Diagrams(DFD), Use Cases, and Entity-
Relationship(ER) diagrams. These models help the customer to visualize the
system and its interactions.
• Scope Definition: Defining the scope of the system is important to prevent
adding excessive features to the system and ensure that the project stays within
its limits. It identifies what is part of the system and what is not.
 Need of system analysis
• System analysis is crucial for dissecting complex, existing, or proposed systems to identify
inefficiencies, risks, and functional requirements, ensuring that new or upgraded
solutions align with organizational goals, improve efficiency, and reduce costs. It serves
as the foundational, strategic planning phase that mitigates risks and optimizes resources
before software development or organizational changes.
• Key Reasons for the Importance of System Analysis:
• Operational Efficiency & Cost Savings: Identifies bottlenecks, redundancies, and
inefficiencies in workflows, leading to streamlined operations and optimized resource
use, which reduces costs and downtime.
• Improved Decision-Making: Provides structured, data-driven insights into how systems
function, enabling better strategic decisions.
• Risk Mitigation: Identifies potential threats and issues early in the developmental
lifecycle, allowing for proactive mitigation and preventing expensive failures later.
• Strategic Alignment: Ensures that new technological implementations or business
changes directly support the overarching goals of the organization.
• High-Quality Deliverables: Ensures systems are designed to meet exact user needs and
requirements, improving overall quality, reliability, and usability.
• Understanding Complex Systems: Breaks down complex, interdependent components
into manageable parts, allowing for better management of changes and improvements.
 System analysis of the existing system
• System analysis of an existing system is the structured process of examining current
business procedures, data handling, and technology to identify inefficiencies,
bottlenecks, and requirements for improvement. It involves gathering data, creating
models, and evaluating components to understand how to optimize operations,
typically as a precursor to upgrading or replacing a system.
Key Activities in Analyzing Existing Systems:
• Information Gathering: Collecting data through interviews with users, reviewing
documentation, studying forms, and evaluating existing system reports.
• System Decomposition: Breaking the complex system into smaller, manageable
components (subsystems or modules) to understand their relationships and
interdependencies.
• Problem Identification: Pinpointing bottlenecks, inefficient workflows, data
inaccuracies, or areas where technology is underutilized.
• Requirement Definition: Establishing what the system must do (functional) and
how it should perform (non-functional), including user interface, processing, and
security needs.
• Modeling: Creating visual representations of the current system, such as data flow
diagrams (DFDs), to map out information movement.
 System analysis of new requirements
• In the realm of systems analysis and design, requirement determination is a critical
phase that sets the foundation for successful software development. It involves
gathering, analyzing, and documenting the needs and expectations of stakeholders
to ensure that the final system meets its intended purpose. This article explores the
importance of requirement determination, its methodologies, challenges, and best
practices, providing a comprehensive overview for both novice and experienced
practitioners.
• Key Stages in Analyzing New Requirements
• Elicitation & Gathering: Interacting with stakeholders via interviews, surveys, and
workshops to gather requirements, identifying both in-scope and out-of-scope items.
• Feasibility Study: Assessing if the new requirements are technically, operationally,
and economically achievable.
• Requirements Analysis & Modeling: Creating technical artifacts such as Data Flow
Diagrams (DFD), Entity-Relationship (ER) diagrams, and Use Case diagrams to model
the new behavior.
• Validation & Documentation: Ensuring requirements are clear, consistent, and
documented in a Functional Specification or SRS (Software Requirements
Specification) document.
 System requirements
• In system analysis and design, system requirements are often categorized using
the IPOS cycle (Input, Processing, Output, Storage). This cycle defines how data
enters, is transformed, and is kept within a computer system.
1. Input Requirements:
Input refers to the raw data and instructions entered into the system for processing.
• Device Compatibility: Support for specific input hardware such as keyboards, mice,
scanners (OCR/OMR), microphones, or biometric sensors.
• Data Accuracy & Validation: Implementation of controls to ensure data is correct
at the point of entry (e.g., format checks like mm/dd/yy or range tests).
• User Interface Design: Provision of user-friendly entry methods, such as drop-
down menus, fill-in-the-blank forms, or graphical icons to reduce manual typing
errors.
• Volume Control: Strategies to reduce the amount of input required, such as using
abbreviations or pre-filling known fields.
• Interaction Mode: Specification of whether the system uses a command-driven
interface or a computer-initiated dialogue (questions and answers)
2. Processing Requirements:
Processing is the manipulation of raw data into meaningful information by the CPU and RAM.
• Central Processing Unit (CPU): Minimum requirements for clock speed (e.g., 1 GHz or 2.4 GHz) and architecture (e.g., 64-
bit with multiple cores).
• Random Access Memory (RAM): The amount of temporary space needed to hold active programs and data during
execution (e.g., 4 GB for basic OS tasks).
• Graphics Processing (GPU): Requirements for rendering 2D/3D images, often specifying VRAM and API compatibility
like DirectX.
• Throughput & Speed: Performance metrics such as the number of concurrent users supported or the required response
time for processing tasks.
• System Logic (ALU/CU): The internal requirement for the Control Unit to manage instructions and the Arithmetic Logic
Unit to perform calculations.
3. Output Requirements:
Output is the result of processing, delivered in a form the user can understand.
• Visual Display: Compatibility with specific screen resolutions (e.g., 800x600) or high-resolution monitors for detailed
work.
• Hard Copy Production: Requirements for printers (impact or non-impact) to produce permanent physical records like
invoices or reports.
• Reporting Formats: Specifications for the structure of outputs, such as detailed reports for planning or summary reports
for executive decision-making.
• Audio Output: Support for speakers or headphones to communicate alerts or multimedia content.
• Timing & Availability: Requirements stating that output must be available "on time" (e.g., real-time updates or daily
status reports) to be useful for decision-making
4. Storage Requirements:
• Storage saves data and information for future use, either temporarily or
permanently.
• Primary Storage: Use of fast, volatile memory (RAM) to store data
currently being processed.
• Secondary Storage Capacity: Minimum free disk space required on an HDD
or SSD to install software and store user files (e.g., 64 GB for Windows 11).
• Data Retrieval Speed: Preference for SSDs over HDDs in systems requiring
high-speed access to large datasets or system files.
• Backup & Redundancy: Requirements for cloud storage, external drives, or
RAID configurations to prevent data loss.
• Data Integrity & Security: Encryption requirements for data "at rest" and
structural integrity controls for databases to ensure data remains usable
over time.
 Requirements Determination/ fact findings
• A requirement is a vital feature of a new system which may include processing or capturing of
data, controlling the activities of business, producing information and supporting the
management. Requirements determination involves studying the existing system and
gathering details to find out what are the requirements, how it works, and where
improvements should be made.
Requirements Anticipation:
• It predicts the characteristics of system based on previous experience which include certain
problems or features and requirements for a new system.
• It can lead to analysis of areas that would otherwise go unnoticed by inexperienced analyst.
But if shortcuts are taken and bias is introduced in conducting the investigation, then
requirement Anticipation can be half baked.
Requirements Investigation:
• It is studying the current system and documenting its features for further analysis.
• It is at the heart of system analysis where analyst documenting and describing system
features using fact-finding techniques, prototyping, and computer assisted tools.
Requirements Specifications:
• It includes the analysis of data which determine the requirement specification, description of
features for new system, and specifying what information requirements will be provided.
• It includes analysis of factual data, identification of essential requirements, and selection of
Requirement-fulfillment strategies.
 Fact Finding Techniques
• To study any system the analyst needs to do collect facts and all relevant information. the
facts when expressed in quantitative form are termed as data. The success of any project is
depended upon the accuracy of available data. Accurate information can be collected with
help of certain methods/ techniques.
• These specific methods for finding information of the system are termed as fact finding
techniques. Interview, Questionnaire, Record View and Observations are the different fact
finding techniques used by the analyst. The analyst may use more than one technique for
investigation.
1. Interview:
• This method is used to collect the information from groups or individuals. Analyst selects the
people who are related with the system for the interview. In this method the analyst sits face
to face with the people and records their responses. The interviewer must plan in advance
the type of questions he/ she is going to ask and should be ready to answer any type of
question. He should also choose a suitable place and time which will be comfortable for the
respondent.
• The information collected is quite accurate and reliable as the interviewer can clear and cross
check the doubts there itself. This method also helps gap the areas of misunderstandings and
help to discuss about the future problems. Structured and unstructured are the two sub
categories of Interview. Structured interview is more formal interview where fixed questions
are asked and specific information is collected whereas unstructured interview is more or less
like a casual conversation where in-depth areas topics are covered and other information
apart from the topic may also be obtained.
2. Questionnaire:
• It is the technique used to extract information from number of people. This
method can be adopted and used only by an skillful analyst. The Questionnaire
consists of series of questions framed together in logical manner.
• The questions are simple, clear and to the point. This method is very useful for
attaining information from people who are concerned with the usage of the
system and who are living in different countries. The questionnaire can be mailed
or send to people by post. This is the cheapest source of fact finding.
3. Record View:
• The information related to the system is published in the sources like newspapers,
magazines, journals, documents etc. This record review helps the analyst to get
valuable information about the system and the organization.
4. Observation:
• Unlike the other fact finding techniques, in this method the analyst himself visits
the organization and observes and understand the flow of documents, working of
the existing system, the users of the system etc. For this method to be adopted it
takes an analyst to perform this job as he knows which points should be noticed
and highlighted. In analyst may observe the unwanted things as well and simply
cause delay in the development of the new system.
 System Development Life Cycle (SDLC)
• SDLC stands for Software Development Life Cycle. SDLC is a process that consists of a
series of planned activities to develop or alter the Software Products. This tutorial
will give you an overview of the SDLC basics, SDLC models available and their
application in the industry. This tutorial also elaborates on other related
methodologies like Agile, RAD and Prototyping.
• It is also called as Software Development Process.
• SDLC is a framework defining tasks performed at each step in the software
development process.
• ISO/IEC 12207 is an international standard for software life-cycle processes. It aims
to be the standard that defines all the tasks required for developing and maintaining
software.
• Software Development Life Cycle (SDLC) is a process used by the software industry
to design, develop and test high quality softwares. The SDLC aims to produce a high-
quality software that meets or exceeds customer expectations, reaches completion
within times and cost estimates.
• SDLC is a process followed for a software project, within a software organization. It
consists of a detailed plan describing how to develop, maintain, replace and alter or
enhance specific software. The life cycle defines a methodology for improving the
quality of software and the overall development process.
 SDLC Models
• There are various software development life cycle models defined
and designed which are followed during the software development
process. These models are also referred as Software Development
Process Models. Each process model follows a Series of steps unique
to its type to ensure success in the process of software development.
• Following are the most important and popular SDLC models followed
in the industry −
• Waterfall Model
• Spiral Model
• Rapid Application Development
• Prototyping Models.
1. Waterfall Model:
• The Waterfall Model was the first Process Model to be introduced. It is also
referred to as a linear-sequential life cycle model. It is very simple to understand
and use. In a waterfall model, each phase must be completed before the next
phase can begin and there is no overlapping in the phases.
• The Waterfall model is the earliest SDLC approach that was used for software
development.
• The waterfall Model illustrates the software development process in a linear
sequential flow. This means that any phase in the development process begins
only if the previous phase is complete. In this waterfall model, the phases do not
overlap
Waterfall Model - Design
• Waterfall approach was first SDLC Model to be used widely in Software
Engineering to ensure success of the project. In "The Waterfall" approach, the
whole process of software development is divided into separate phases. In this
Waterfall model, typically, the outcome of one phase acts as the input for the
next phase sequentially.
• The following illustration is a representation of the different phases of the
Waterfall Model.
Phases in Waterfall model
• Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification
document.
• System Design − The requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system architecture.
• Implementation − With inputs from the system design, the system is first developed in
small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment. To fix
those issues, patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name
"Waterfall Model". In this model, phases do not overlap.
 Waterfall Model - Application
• Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and
external factors. Some situations where the use of Waterfall model is most appropriate are −
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.
Waterfall Model - Advantages
• The advantages of waterfall development are that it allows for departmentalization and control. A schedule can be set
with deadlines for each stage of development and a product can proceed through the development process model
phases one by one.
• Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up
at operation and maintenance. Each phase of development proceeds in strict order.
Some of the major advantages of the Waterfall Model are as follows −
• Simple and easy to understand and use.
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
 Waterfall Model - Disadvantages
• The disadvantage of waterfall development is that it does not allow much
reflection or revision. Once an application is in the testing stage, it is very difficult
to go back and change something that was not well-documented or thought upon
in the concept stage.
The major disadvantages of the Waterfall Model are as follows −
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.
2. Spiral Model:
The spiral model combines the idea of iterative development with the systematic,
controlled aspects of the waterfall model. This Spiral model is a combination of
iterative development process model and sequential linear development model i.e.
the waterfall model with a very high emphasis on risk analysis. It allows
incremental releases of the product or incremental refinement through each
iteration around the spiral.
Spiral Model - Design
• The spiral model has four phases. A software project repeatedly passes through
these phases in iterations called Spirals.
• Identification:
• This phase starts with gathering the business requirements in the baseline spiral.
In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in this
phase.
• This phase also includes understanding the system requirements by continuous
communication between the customer and the system analyst. At the end of the
spiral, the product is deployed in the identified market.
Phases of Spiral model
• Design:
• The Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and the final
design in the subsequent spirals.
• Construct or Build:
• The Construct phase refers to production of the actual software product at every spiral.
In the baseline spiral, when the product is just thought of and the design is being
developed a POC (Proof of Concept) is developed in this phase to get customer feedback.
• Then in the subsequent spirals with higher clarity on requirements and design details a
working model of the software called build is produced with a version number. These
builds are sent to the customer for feedback.
• Evaluation and Risk Analysis:
• Risk Analysis includes identifying, estimating and monitoring the technical feasibility and
management risks, such as schedule slippage and cost overrun. After testing the build, at
the end of first iteration, the customer evaluates the software and provides feedback.
Based on the customer evaluation, the software development process enters the next
iteration and subsequently follows the linear approach to implement the feedback
suggested by the customer. The process of iterations along the spiral continues throughout
the life of the software.
 Spiral Model Application
• The Spiral Model is widely used in the software industry as it is in sync with
the natural development process of any product, i.e. learning with maturity
which involves minimum risk for the customer as well as the development
firms.
The following pointers explain the typical uses of a Spiral Model −
• When there is a budget constraint and risk evaluation is important.
• For medium to high-risk projects.
• Long-term project commitment because of potential changes to economic
priorities as the requirements change with time.
• Customer is not sure of their requirements which is usually the case.
• Requirements are complex and need evaluation to get clarity.
• New product line which should be released in phases to get enough
customer feedback.
• Significant changes are expected in the product during the development
cycle.
 Spiral Model - Pros and Cons
• The advantage of spiral lifecycle model is that it allows elements of
the product to be added in, when they become available or known.
This assures that there is no conflict with previous requirements and
design.
• This method is consistent with approaches that have multiple
software builds and releases which allows making an orderly
transition to a maintenance activity. Another positive aspect of this
method is that the spiral model forces an early user involvement in
the system development effort.
• On the other side, it takes a very strict management to complete such
products and there is a risk of running the spiral in an indefinite loop.
So, the discipline of change and the extent of taking change requests
is very important to develop and deploy the product successfully.
The advantages of the Spiral SDLC Model are as follows −
• Changing requirements can be accommodated.
• Allows extensive use of prototypes.
• Requirements can be captured more accurately.
• Users see the system early.
• Development can be divided into smaller parts and the risky parts can be
developed earlier which helps in better risk management.
The disadvantages of the Spiral SDLC Model are as follows −
• Management is more complex.
• End of the project may not be known early.
• Not suitable for small or low risk projects and could be expensive for small
projects.
• Process is complex
• Spiral may go on indefinitely.
• Large number of intermediate stages requires excessive documentation.
3. RAD Model:
• The RAD (Rapid Application Development) model is based on prototyping and iterative
development with no specific planning involved. The process of writing the software
itself involves the planning required for developing the product.
• Rapid Application Development focuses on gathering customer requirements through
workshops or focus groups, early testing of the prototypes by the customer using
iterative concept, reuse of the existing prototypes (components), continuous integration
and rapid delivery.
• Rapid application development is a software development methodology that uses
minimal planning in favor of rapid prototyping. A prototype is a working model that is
functionally equivalent to a component of the product.
• In the RAD model, the functional modules are developed in parallel as prototypes and
are integrated to make the complete product for faster product delivery. Since there is no
detailed preplanning, it makes it easier to incorporate the changes within the
development process.
• RAD projects follow iterative and incremental model and have small teams comprising of
developers, domain experts, customer representatives and other IT resources working
progressively on their component or prototype.
• The most important aspect for this model to be successful is to make sure that the
prototypes developed are reusable.
 RAD Model Design
• The following illustration describes the RAD Model in detail.
RAD model distributes the analysis, design, build and test phases into a series of short,
iterative development cycles.
• Business Modelling: The business model for the product under development is designed
in terms of flow of information and the distribution of information between various
business channels. A complete business analysis is performed to find the vital
information for business, how it can be obtained, how and when is the information
processed and what are the factors driving successful flow of information.
• Data Modelling: The information gathered in the Business Modelling phase is reviewed
and analyzed to form sets of data objects vital for the business. The attributes of all data
sets is identified and defined. The relation between these data objects are established
and defined in detail in relevance to the business model.
• Process Modelling: The data object sets defined in the Data Modelling phase are
converted to establish the business information flow needed to achieve specific business
objectives as per the business model. The process model for any changes or
enhancements to the data object sets is defined in this phase. Process descriptions for
adding, deleting, retrieving or modifying a data object are given.
• Application Generation: The actual system is built and coding is done by using
automation tools to convert process and data models into actual prototypes.
• Testing and Turnover: The overall testing time is reduced in the RAD model as the
prototypes are independently tested during every iteration. However, the data flow and
the interfaces between all the components need to be thoroughly tested with complete
test coverage. Since most of the programming components have already been tested, it
reduces the risk of any major issues.
 RAD Model Vs Traditional SDLC
• The traditional SDLC follows a rigid process models with high
emphasis on requirement analysis and gathering before the coding
starts. It puts pressure on the customer to sign off the requirements
before the project starts and the customer doesnt get the feel of the
product as there is no working build available for a long time.
• The customer may need some changes after he gets to see the
software. However, the change process is quite rigid and it may not
be feasible to incorporate major changes in the product in the
traditional SDLC.
• The RAD model focuses on iterative and incremental delivery of
working models to the customer. This results in rapid delivery to the
customer and customer involvement during the complete
development cycle of product reducing the risk of non-conformance
with the actual user requirements.
 RAD Model - Application
RAD model can be applied successfully to the projects in which clear
modularization is possible. If the project cannot be broken into modules,
RAD may fail.
• The following pointers describe the typical scenarios where RAD can be
used −
• RAD should be used only when a system can be modularized to be
delivered in an incremental manner.
• It should be used if there is a high availability of designers for Modelling.
• It should be used only if the budget permits use of automated code
generating tools.
• RAD SDLC model should be chosen only if domain experts are available
with relevant business knowledge.
• Should be used where the requirements change during the project and
working prototypes are to be presented to customer in small iterations of
2-3 months.
 RAD Model - Pros and Cons
• RAD model enables rapid delivery as it reduces the overall development
time due to the reusability of the components and parallel development.
RAD works well only if high skilled engineers are available and the
customer is also committed to achieve the targeted prototype in the given
time frame. If there is commitment lacking on either side the model may
fail.
The advantages of the RAD Model are as follows −
• Changing requirements can be accommodated.
• Progress can be measured.
• Iteration time can be short with use of powerful RAD tools.
• Productivity with fewer people in a short time.
• Reduced development time.
• Increases reusability of components.
• Quick initial reviews occur.
• Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues.
The disadvantages of the RAD Model are as follows −
• Dependency on technically strong team members for identifying
business requirements.
• Only system that can be modularized can be built using RAD.
• Requires highly skilled developers/designers.
• High dependency on Modelling skills.
• Inapplicable to cheaper projects as cost of Modelling and automated
code generation is very high.
• Management complexity is more.
• Suitable for systems that are component based and scalable.
• Requires user involvement throughout the life cycle.
• Suitable for project requiring shorter development times.
4. Prototype Model:
• The Software Prototyping refers to building software application
prototypes which displays the functionality of the product under
development, but may not actually hold the exact logic of the original
software.
• Software prototyping is becoming very popular as a software development
model, as it enables to understand customer requirements at an early
stage of development. It helps get valuable feedback from the customer
and helps software designers and developers understand about what
exactly is expected from the product under development.
• Prototype is a working model of software with some limited functionality.
The prototype does not always hold the exact logic used in the actual
software application and is an extra effort to be considered under effort
estimation.
• Prototyping is used to allow the users evaluate developer proposals and try
them out before implementation. It also helps understand the
requirements which are user specific and may not have been considered by
the developer during product design.
Following is a stepwise approach explained to design a software prototype.
• Basic Requirement Identification: This step involves understanding the very basics product
requirements especially in terms of user interface. The more intricate details of the internal
design and external aspects like performance and security can be ignored at this stage.
• Developing the initial Prototype: The initial Prototype is developed in this stage, where the very
basic requirements are showcased and user interfaces are provided. These features may not
exactly work in the same manner internally in the actual software developed. While, the
workarounds are used to give the same look and feel to the customer in the prototype developed.
• Review of the Prototype: The prototype developed is then presented to the customer and the
other important stakeholders in the project. The feedback is collected in an organized manner and
used for further enhancements in the product under development.
• Revise and Enhance the Prototype: The feedback and the review comments are discussed during
this stage and some negotiations happen with the customer based on factors like time and budget
constraints and technical feasibility of the actual implementation. The changes accepted are again
incorporated in the new Prototype developed and the cycle repeats until the customer
expectations are met.
• Prototypes can have horizontal or vertical dimensions: A Horizontal prototype displays the user
interface for the product and gives a broader view of the entire system, without concentrating on
internal functions. A Vertical prototype on the other side is a detailed elaboration of a specific
function or a sub system in the product.
• The purpose of both horizontal and vertical prototype is different. Horizontal prototypes are used
to get more information on the user interface level and the business requirements. It can even be
presented in the sales demos to get business in the market. Vertical prototypes are technical in
nature and are used to get details of the exact functioning of the sub systems. For example,
database requirements, interaction and data processing loads in a given sub system.
 Prototyping - Types
There are different types of software prototypes used in the industry. Following are the major
software prototyping types used widely −
• Throwaway/Rapid Prototyping: Throwaway prototyping is also called as rapid or close ended
prototyping. This type of prototyping uses very little efforts with minimum requirement
analysis to build a prototype. Once the actual requirements are understood, the prototype is
discarded and the actual system is developed with a much clear understanding of user
requirements.
• Evolutionary Prototyping: Evolutionary prototyping also called as breadboard prototyping is
based on building actual functional prototypes with minimal functionality in the beginning.
The prototype developed forms the heart of the future prototypes on top of which the entire
system is built. By using evolutionary prototyping, the well-understood requirements are
included in the prototype and the requirements are added as and when they are understood.
• Incremental Prototyping: Incremental prototyping refers to building multiple functional
prototypes of the various sub-systems and then integrating all the available prototypes to
form a complete system.
• Extreme Prototyping: Extreme prototyping is used in the web development domain. It
consists of three sequential phases. First, a basic prototype with all the existing pages is
presented in the HTML format. Then the data processing is simulated using a prototype
services layer. Finally, the services are implemented and integrated to the final prototype. This
process is called Extreme Prototyping used to draw attention to the second phase of the
process, where a fully functional UI is developed with very little regard to the actual services.
 Prototyping - Application
• Software Prototyping is most useful in development of systems having
high level of user interactions such as online systems. Systems which
need users to fill out forms or go through various screens before data
is processed can use prototyping very effectively to give the exact
look and feel even before the actual software is developed.
• Software that involves too much of data processing and most of the
functionality is internal with very little user interface does not usually
benefit from prototyping. Prototype development could be an extra
overhead in such projects and may need lot of extra efforts.
Prototyping - Pros and Cons
• Software prototyping is used in typical cases and the decision should
be taken very carefully so that the efforts spent in building the
prototype add considerable value to the final software developed.
The model has its own pros and cons discussed as follows.
The advantages of the Prototyping Model are as follows −
• Increased user involvement in the product even before its implementation.
• Since a working model of the system is displayed, the users get a better understanding of
the system being developed.
• Reduces time and cost as the defects can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily.
• Confusing or difficult functions can be identified.
The Disadvantages of the Prototyping Model are as follows −
• Risk of insufficient requirement analysis owing to too much dependency on the
prototype.
• Users may get confused in the prototypes and actual systems.
• Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
• Developers may try to reuse the existing prototypes to build the actual system, even
when it is not technically feasible.
• The effort invested in building prototypes may be too much if it is not monitored properly.
 Structured System Analysis and Design(SSAD)
• Structured Analysis and Structured Design (SA/SD) is a diagrammatic notation that is designed to
help people understand the system. The basic goal of SA/SD is to improve quality and reduce the
risk of system failure. It establishes concrete management specifications and documentation. It
focuses on the solidity, pliability, and maintainability of the system.
• Structured Analysis and Structured Design (SA/SD) is a software development method that was
popular in the 1970s and 1980s. The method is based on the principle of structured programming,
which emphasizes the importance of breaking down a software system into smaller, more
manageable components.
• In SA/SD, the software development process is divided into two phases: Structured Analysis and
Structured Design. During the Structured Analysis phase, the problem to be solved is analyzed and
the requirements are gathered. The Structured Design phase involves designing the system to meet
the requirements that were gathered in the Structured Analysis phase.
• Structured Analysis and Structured Design (SA/SD) is a traditional software development
methodology that was popular in the 1980s and 1990s. It involves a series of techniques for
designing and developing software systems in a structured and systematic way. Here are some key
concepts of SA/SD:
1. Functional Decomposition: SA/SD uses functional decomposition to break down a complex system
into smaller, more manageable subsystems. This technique involves identifying the main functions of
the system and breaking them down into smaller functions that can be implemented independently.
2. Data Flow Diagrams (DFDs): SA/SD uses DFDs to model the flow of data through the system. DFDs
are graphical representations of the system that show how data moves between the system's various
components.
3. Data Dictionary: A data dictionary is a central repository that contains
descriptions of all the data elements used in the system. It provides a clear
and consistent definition of data elements, making it easier to understand
how the system works.
4. Structured Design: SA/SD uses structured design techniques to develop
the system's architecture and components. It involves identifying the major
components of the system, designing the interfaces between them, and
specifying the data structures and algorithms that will be used to implement
the system.
5. Modular Programming: SA/SD uses modular programming techniques to
break down the system's code into smaller, more manageable modules. This
makes it easier to develop, test, and maintain the system.
• Some advantages of SA/SD include its emphasis on structured design and
documentation, which can help improve the clarity and maintainability of
the system. However, SA/SD has some disadvantages, including its rigidity
and inflexibility, which can make it difficult to adapt to changing business
requirements or technological trends. Additionally, SA/SD may not be well-
suited for complex, dynamic systems, which may require more agile
development methodologies.
The following are the steps involved in the SA/SD process:
• Requirements gathering: The first step in the SA/SD process is to gather
requirements from stakeholders, including users, customers, and business
partners.
• Structured Analysis: During the Structured Analysis phase, the requirements are
analyzed to identify the major components of the system, the relationships
between those components, and the data flows within the system.
• Data Modeling: During this phase, a data model is created to represent the data
used in the system and the relationships between data elements.
• Process Modeling: During this phase, the processes within the system are
modeled using flowcharts and data flow diagrams.
• Input/Output Design: During this phase, the inputs and outputs of the system
are designed, including the user interface and reports.
• Structured Design: During the Structured Design phase, the system is designed to
meet the requirements gathered in the Structured Analysis phase. This may
include selecting appropriate hardware and software platforms, designing
databases, and defining data structures.
• Implementation and Testing: Once the design is complete, the system is
implemented and tested.
 Characteristics of Structured System Analysis and Design(SSAD)
Structured System Analysis and Design (SSAD) is a traditional, process-oriented software
development methodology focused on modularity, top-down decomposition, and rigorous
documentation. It uses graphical tools like Data Flow Diagrams (DFDs) to map data movement and
structures, emphasizing clear separation between analysis (what the system does) and design (how
it does it).
• Process-Oriented Approach: SSAD focuses on the processes (functions) that the system performs,
transforming inputs into outputs, rather than focusing on data objects.
• Top-Down Decomposition: The methodology breaks down complex systems into smaller, more
manageable modules or sub-systems, starting from the high-level overview down to detailed
specifications.
• Graphical Representation: It heavily utilizes diagrams—specifically Data Flow Diagrams (DFDs),
structure charts, and Entity-Relationship Diagrams (ERDs)—to visualize system functionality, data
storage, and flows.
• Logical Before Physical Design: Analysis is initially "logical" (describing what is done without
referring to specific technology), which later gets converted into a "physical" design
(specifying how it is implemented on hardware/software).
• Documentation-Driven: SSAD emphasizes comprehensive documentation, such as Data
Dictionaries, to ensure clear communication and maintainability.
• Structured Tools: Techniques used include Structured English, Decision Trees, and Decision Tables
to define complex logic and business rules.
• Systematic SDLC Phase: It strictly follows the Systems Development Life Cycle (SDLC) phases,
including investigation, feasibility study, design, implementation, and maintenance.
 Objectives of Structured System Analysis and Design(SSAD)
Structured System Analysis and Design (SSAD) aims to create high-quality, reliable
information systems by breaking complex projects into manageable components, ensuring
they align with user needs. Key objectives include enhancing system maintainability,
improving documentation, strengthening communication among stakeholders, improving
project control, and increasing development productivity.
• System Decomposition: To break down large, complex systems into smaller, manageable,
and functional modules, improving understanding and design efficiency.
• Improve Maintainability: To produce a structured system that is easy to maintain,
document, and update over time.
• Accurate Requirement Definition: To define user needs precisely, ensuring the final
system meets all requirements.
• Standardized Documentation: To use standardized tools—like Data Flow Diagrams
(DFDs), Data Dictionaries, and Entity Relationship Diagrams (ERD)—to document the
logical design.
• Improved Communication: To provide a clear framework and common language for
communication between technical staff and business stakeholders.
• Enhanced Quality and Reliability: To increase the reliability of the software by designing
it in a structured manner, making it easier to test and validate.
• Project Control and Consistency: To ensure projects remain on schedule, within budget,
and are resilient to staff turnover by adhering to a structured, documented methodology
 Stages of Structured System Analysis and Design(SSAD)
The Structured Systems Analysis and Design Method (SSADM) is a formal, waterfall-based methodology
primarily used for developing information systems. It breaks a project down into seven distinct stages, moving
from a high-level feasibility assessment to detailed physical construction.
• Stage 0: Feasibility Study
Determines if the project is technically, financially, and organizationally viable. It investigates whether the
proposed system aligns with business goals and if the benefits outweigh the costs.
• Stage 1: Investigation of the Current Environment
Analysts study the existing system (even if it's manual) to understand current processes, terminology, and
problems. Key products include a Users' Catalogue and requirements for the new system.
• Stage 2: Business System Options (BSO)
Developers present several "business options" to the stakeholders—ranging from doing nothing to building a
completely new system. This stage helps define the boundary between the system and its users.
• Stage 3: Requirements Specification
This is often considered the most complex stage. It involves creating a full logical specification of what the
system must do, using techniques like Data Flow Diagrams (DFDs) and Logical Data Models (LDM).
• Stage 4: Technical System Options (TSO)
Focuses on the implementation environment, such as selecting hardware, software, and network
architectures. Several technical possibilities are narrowed down to a final chosen option.
• Stage 5: Logical Design
Expands the requirements into detailed designs for human-computer interaction, including menu structures
and user dialogues. This stage remains independent of specific hardware.
• Stage 6: Physical Design
The final stage where logical specifications are converted into actual physical structures, such as database
schemas and program specifications for specific hardware and software.
Advantages of Structured Analysis and Structured Design (SA/SD):
• Clarity and Simplicity: The SA/SD method emphasizes breaking down complex systems
into smaller, more manageable components, which makes the system easier to
understand and manage.
• Better Communication: The SA/SD method provides a common language and framework
for communicating the design of a system, which can improve communication between
stakeholders and help ensure that the system meets their needs and expectations.
• Improved maintainability: The SA/SD method provides a clear, organized structure for a
system, which can make it easier to maintain and update the system over time.
• Better Testability: The SA/SD method provides a clear definition of the inputs and
outputs of a system, which makes it easier to test the system and ensure that it meets its
requirements.
Disadvantages of Structured Analysis and Structured Design (SA/SD):
• Time-Consuming: The SA/SD method can be time-consuming, especially for large and
complex systems, as it requires a significant amount of documentation and analysis.
• Inflexibility: Once a system has been designed using the SA/SD method, it can be difficult
to make changes to the design, as the process is highly structured and documentation-
intensive.
• Limited Iteration: The SA/SD method is not well-suited for iterative development, as it is
designed to be completed in a single pass.
 Structured System Analysis and Design Tools
Various tools and techniques are used for structured system analysis and design .
Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State Transition diagram and ER diagram.
Design Phase: It uses Structure Chart and Pseudo Code.
1. Analysis Phase:
Analysis Phase involves data flow diagram, data dictionary, state transition diagram, and entity-relationship
diagram.
A) Data Flow Diagrams: In the data flow diagram, the model describes how the data flows through the system. We
can incorporate the Boolean operators and & or link data flow when more than one data flow may be input or
output from a process. DFD can be explained as a graphical representation of the flow of data through a system. It
used to visualize the movement of data and interactions within a system. Helps developers, business analysts, and
stakeholders understand the process without technical complexities.
For example, if we have to choose between two paths of a process we can add an operator or and if two data flows
are necessary for a process we can add an operator. The input of the process "check-order" needs the credit
information and order information whereas the output of the process would be a cash-order or a good-credit-
order.
• DFD Components and Symbols:
• Processes− Represented by circles or rounded rectangles. Describe how each process transforms inputs into
outputs.
• Data Stores− Represented by open-ended rectangles, symbolizing where data is stored within the system.
• Data Flows− Arrows indicate data movement between components, labelled with the type of data being
transferred.
• External Entities (Sources/Sinks)− Represented by squares, indicating external systems or users interacting with
the system.
• Example DFD with simple use case

Types and Levels of Data Flow Diagrams:

• A Data Flow Diagram (DFD) is a visual representation used in systems
analysis and design to depict how data flows within a system. It consists of
processes, data stores, data flow arrows, and external entities. Processes
represent tasks or functions, while data stores indicate where data is stored
within the system.
• Data flows are arrows connecting these components, illustrating the
movement of data between them. DFDs provide a clear and concise way to
understand and communicate how data is processed, transformed, and
stored within a system, making them a valuable tool for system analysis
and design.
Here are the different levels in data flow diagrams (DFD):
• Level 0 DFD (context diagram): A zero level DFD or context level diagram is the highest abstraction level,
depicting the entire system as a single process. A context level data flow diagram highlights the interactions
between the system and external entities. provides an overview of the entire system, portraying it as a single
process. It showcases how external entities interact with the system, offering a bird's-eye view of data flow.
Here is the snapshot of a context diagram level 0:
• Level 1 DFD: A 1-level DFD provides a detailed breakdown of the processes in the Level 0 DFD. It further
decomposes the main processes into sub-processes, showing more granularity. It goes deeper into the
processes outlined in Level 0. It breaks down main processes into sub-processes, offering a more detailed
view of data flow. Here is a level 1 DFD example:
• Level 2 DFD: The 2-level DFD further decomposes Level 1 processes into sub-processes, enhancing
granularity and revealing intricate data exchanges and transformations within the system. This level provides
a deeper understanding of system functionality. Here is a level 2 DFD example:
B) Data Dictionary (DD):
A data dictionary is a centralized repository documenting technical metadata
for data elements within databases or datasets. It specifies technical details
like object names, data types, field lengths, classification, constraints, and
allowed values. Organizations use data dictionaries to standardize definitions
and ensure teams understand data structure without relying on tribal
knowledge.
CORE CHARACTERISTICS OF AN EFFECTIVE DATA DICTIONARY:
• Technical specifications: Data types, field names, sizes, constraints, default
values, and validation rules.
• Descriptive metadata: Business context, ownership, source systems, and
update timestamps.
• Structural relationships: Foreign keys, entity relationships, and
dependencies between tables.
• Quality indicators: Allowed value ranges, null handling, completeness
metrics, and statistical summaries.
• Governance elements: Approval workflows, version history, stewardship
assignments, and change logs.
• Types of data dictionaries:
There are two main types of data dictionary: active and passive.
• Active: An active data dictionary in database management is integrated
with and automatically synchronizes to your system. This means that any
updates, changes, and modifications made within the host database are
reflected automatically in the data dictionary.
• The benefits of data dictionary integration and automation include
increased data consistency and accuracy, reduced maintenance at scale,
and real-time access to data to allow analysts to make quick decisions.
• Passive: A passive data dictionary is a centralized repository that’s separate
from the database management system. Updates and modifications must
be completed manually by data administrators, which is time-consuming
and opens a wider door for data inconsistencies and inaccuracies to occur.
• While passive dictionaries offer the benefit of user-friendliness, their lack
of automation makes them an unreliable solution for most modern
businesses.
• A data dictionary may contain different components depending on the specific needs and
requirements of your business, along with the types of data being documented.
Generally, the contents of a data dictionary include the following information for every
data element:
• Names: Every data dictionary element should be defined with a clear, unique name.
• Descriptions: This is a brief description of what the data element is and what it’s used for,
providing context to the element.
• Attributes: A summary of the key properties of the data element, such as the data type,
sizes, and indexes.
• Format: Information on formatting details if relevant, such as address formats, date
formats, decimal places, and capitalizations.
• Relationships and dependencies: How the data element relates to, or depends upon,
any other data element in the database.
• Source: This includes where the original data was collected from along with details about
the process of data collection and maintenance.
• Constraints: Information pertaining to the rules and constraints of data elements, such
as validation, data quality, and business rules.
• Ownership: Details who is responsible for the data elements.
Example: Employee Table Entry
• This table shows how a single entry might look in a Data Dictionary
Template:
C) Entity Relationship Diagram(ER):
• The Entity-Relationship Model (ER Model) is a conceptual model for designing a
database. This model represents the logical structure of a database, including
entities, their attributes, and relationships between them.
• Entity: An object that is stored as data. E.g: Student, Course, or Company.
• Attribute: Properties that describe an entity. E.g: StudentID, CourseName, or
EmployeeEmail.
• Relationship: A connection between entities. E.g: Student enrolls in a Course.
ER Model in Database Design Process
We typically follow the below steps for designing a database for an application.
1. Gather the requirements (functional and data) by asking questions to the
database users.
2. Create a logical or conceptual design of the database. This is where ER model
platheys a role. It is the most used graphical representation of the conceptual
design of a database.
3. After this, focus on physical database design (like indexing) and external design
(like views).
Uses of ER Diagrams in DBMS
• ER diagrams represent the E-R model in a database, making them easy to convert
into relations (tables).
• These diagrams serve the purpose of real-world modeling of objects which makes
them intently useful.
• Unlike technical schemas, ER diagrams require no technical knowledge of the
underlying DBMS used.
• They visually model data and its relationships, making complex systems easier to
understand.
Symbols Used in ER Model:
ER Model is used to model the logical view of the system from a data
perspective which consists of these symbols:
 Components of ER Diagram
1. Entity: It represents a real-world object, concept or thing about which data is stored
in a database. It act as a building block of a database. Tables in relational database
represent these entities.
Example of entities:
• Real-World Objects: Person, Car, Employee etc.
• Concepts: Course, Event, Reservation etc.
• Things: Product, Document, Device etc.
The entity type defines the structure of an entity, while individual instances of that
type represent specific entities.
• Entity Set: Refers to an individual object of an entity type, and the collection of all
entities of a particular type is called an entity set. For example, E1 is an entity that
belongs to the entity type "Student," and the group of all students forms the entity
set.
We can represent the entity sets in an ER Diagram but we can't represent individual
entities because an entity is like a row in a table, and an ER diagram shows the
structure and relationships of data, not specific data entries (like rows and columns).
An ER diagram is a visual representation of the data model, not the actual data itself.
Types of Entity
There are two main types of entities:
1. Strong Entity: A type of entity that has a key Attribute that can uniquely identify each instance of the entity. A Strong
Entity does not depend on any other Entity in the Schema for its identification. It has a primary key that ensures its
uniqueness and is represented by a rectangle in an ER diagram.
2. Weak Entity: It cannot be uniquely identified by its own attributes alone. It depends on a strong entity to be identified. A
weak entity is associated with an identifying entity (strong entity), which helps in its identification. A weak entity are
represented by a double rectangle. The participation of weak entity types is always total. The relationship between the weak
entity type and its identifying strong entity type is called identifying relationship and it is represented by a double diamond.
Example:
• A company may store the information of dependents (Parents, Children, Spouse) of an Employee. But the dependents
can't exist without the employee. So dependent will be a Weak Entity Type and Employee will be identifying entity type for
dependent, which means it is Strong Entity Type.
2. Attributes in ER Model: Attributes are the properties that define the entity type. For example, for a Student
entity Roll_No, Name, DOB, Age, Address, and Mobile_No are the attributes that define entity type Student. In
ER diagram, the attribute is represented by an oval.

• Types of Attributes:
1. Key Attribute:
• The attribute which uniquely identifies each entity in the entity set is called the key attribute. For example,
Roll_No will be unique for each student. In ER diagram, the key attribute is represented by an oval with an
underline.

2. Composite Attribute:
• An attribute composed of many other attributes is called a composite attribute. For example, the Address
attribute of the student Entity type consists of Street, City, State, and Country. In ER diagram, the composite
attribute is represented by an oval comprising of ovals.
3. Multivalued Attribute
• An attribute consisting of more than one value for a given entity. For example, Phone_No (can be more than
one for a given student). In ER diagram, a multivalued attribute is represented by a double oval.

4. Derived Attribute
• An attribute that can be derived from other attributes of the entity type is known as a derived attribute. e.g.;
Age (can be derived from DOB). In ER diagram, the derived attribute is represented by a dashed oval.

• The Complete Entity Type Student with its Attributes can be represented as:
3. Relationship Type and Relationship Set
• A Relationship Type represents the association between entity types. For example, ‘Enrolled in’ is a
relationship type that exists between entity type Student and Course. In ER diagram, the relationship type is
represented by a diamond and connecting the entities with lines.

• A set of relationships of the same type is known as a relationship set. The following relationship set depicts
S1 as enrolled in C2, S2 as enrolled in C1, and S3 as registered in C3. A set of relationships of the same type is
known as a relationship set. The following relationship set depicts S1 as enrolled in C2, S2 as enrolled in C1,
and S3 as registered in C3.
Degree of a Relationship Set
The number of different entity sets participating in a relationship set is called the degree of a relationship set.
1. Unary/Recursive Relationship: When there is only ONE entity set participating in a relation. For example,
one person is married to only one person.

2. Binary Relationship: When there are TWO entities set participating in a relationship. For example, a Student
is enrolled in a Course.

3. Ternary Relationship: When there are three entity sets participating in a relationship.

4. N-ary Relationship: When there are n entities set participating in a relationship, the relationship is called an
n-ary relationship.
Cardinality in ER Model
The maximum number of times an entity of an entity set participates in a relationship set is known as cardinality.
Cardinality can be of different types:
1. One-to-One
• When each entity in each entity set can take part only once in the relationship, the cardinality is one-to-one. Let
us assume that one person can be issued only one passport, and one passport is issued to only one person. So,
the relationship will be One-to-One (1 : 1), meaning that each person has a single passport, and each passport
belongs to a single person.
2. One-to-Many
• In a one-to-many relationship, one entity can be associated with multiple entities. For example, a single Surgeon
Department can have many Doctors. Therefore, the cardinality of this relationship is 1 to M, meaning one
department can have many doctors.
3. Many-to-One
• When entities in one entity set can take part only once in the relationship set and entities in other entity sets can take
part more than once in the relationship set, cardinality is many to one.
• Let us assume that multiple surgeries can be performed by one surgeon, but one surgery is performed by only one
surgeon. So, the cardinality will be M to 1, meaning that many surgeries can be done by a single surgeon, but each
surgery is done by only one surgeon.
• 4. Many-to-Many
• When entities in all entity sets can take part more than once in the relationship cardinality is many to many. Let us
assume that an employee can work on multiple projects and each project can have multiple employees working on it.
So, the relationship will be many-to-many (M:N), meaning that one employee may be associated with several projects,
and one project may involve several employees.
2. Design Phase: It uses Structure Chart and Pseudo Code.
A) Structure Chart: A structure chart is a top-down hierarchical diagram used in software engineering to represent a
system's architecture, showing modules (functional units), their interrelationships, and the data/control parameters
passed between them. Key notations include rectangular boxes for modules, and arrows for data/control flow,
representing hierarchical design.
Core Notations of a Structure Chart:
Structure charts provide a blueprint of the system, helping developers visualize the breakdown of complex systems
into smaller, manageable, and reusable components.
• Module (Rectangular Box): Represents a process, function, or subroutine.
• Control Module: A higher-level module that calls lower-level modules (submodules).
• Library Module: A reusable submodule called by multiple other modules.
• Module Connection (Line): Shows a hierarchical relationship where a module above calls a module below.
• Data Flow (Arrow with Empty Circle): Depicts data (e.g., input values) passed between modules, represented by a
directed arrow with an empty circle
• Control Flow (Arrow with Filled Circle): Represents a signal or flag (e.g., a status boolean) passed between modules,
depicted by a filled circle
• Selection (Diamond): Indicates that a control module selects one of several submodules based on a condition.
• Loop (Curved Arrow): Represents repetitive execution of a submodule.
 Object Oriented Analysis(OOAD)
In the system analysis or object-oriented analysis phase of software development, the system
requirements are determined, the classes are identified and the relationships among classes are
identified.
The three analysis techniques that are used in conjunction with each other for object-oriented analysis
are object modelling, dynamic modelling, and functional modelling.
Object Modelling:
Object modelling develops the static structure of the software system in terms of objects. It identifies
the objects, the classes into which the objects can be grouped into and the relationships between the
objects. It also identifies the main attributes and operations that characterize each class.
The process of object modelling can be visualized in the following steps −
• Identify objects and group into classes
• Identify the relationships among classes
• Create user object model diagram
• Define user object attributes
• Define the operations that should be performed on the classes
• Review glossary
• Dynamic Modelling:
• After the static behavior of the system is analyzed, its behavior with respect to time and external changes needs to be
examined. This is the purpose of dynamic modelling.
• Dynamic Modelling can be defined as a way of describing how an individual object responds to events, either internal
events triggered by other objects, or external events triggered by the outside world.
• The process of dynamic modelling can be visualized in the following steps −
• Identify states of each object
• Identify events and analyze the applicability of actions
• Construct dynamic model diagram, comprising of state transition diagrams
• Express each state in terms of object attributes
• Validate the statetransition diagrams drawn
• Functional Modelling:
• Functional Modelling is the final component of object-oriented analysis. The functional model shows the processes
that are performed within an object and how the data changes as it moves between methods. It specifies the meaning
of the operations of object modelling and the actions of dynamic modelling. The functional model corresponds to the
data flow diagram of traditional structured analysis.
• The process of functional modelling can be visualized in the following steps −
• Identify all the inputs and outputs
• Construct data flow diagrams showing functional dependencies
• State the purpose of each function
• Identify constraints
• Specify optimization criteria
Advantages/Disadvantages of Object Oriented Analysis