CA2203
CA2203
Syllabus
Introduction to System Concepts: Definition, Elements of System, Characteristics of System, Types of System,
System Concepts.
Introduction to Software Engineering: Definition, Need for software Engineering, Software Characteristics,
Software Qualities (McCall’s Quality Factors)
Software Development Methodologies: SDLC (System Development Life Cycle), Waterfall Model, Spiral Model,
Prototyping Model.
Requirement Analysis: Definition of System Analysis, Requirement Anticipation, Knowledge and Qualities of
System Analyst, Role of a System Analyst, Feasibility Study And It’s Types, User Transaction Requirement, User
design Requirements, SRS(System Requirement Specification)
Analysis and Design Tools: Entity Relationship Diagrams, Data Flow Diagrams (DFD), Data Dictionary & Elements of
Data Dictionary, Pseudo code, Input and Output Design.
Structured System Design: Modules Concepts and Types of Modules, Structured Chart, Qualities of Good Design,
Coupling, Types of Coupling, Cohesion, Types of Cohesion.
Software Testing: Definition, Test characteristics, Types of testing - BlackBox Testing, White-Box Testing, Stress
Testing, Performance Testing.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Assessment Plan
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Reference Books:
1. R. S. Pressman, Software Engineering, (5e), Tata McGraw Hills, 2009.
2. I. Sommerville, Software Engineering, (6e), Pearson Education Asia, 2005.
3. P. Jalote, An Integrated Approach to Software Engineering, (3e), Narosa, 2010.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Definition
➢ A system is a collection of interrelated components or elements that work together to achieve a specific
goal or purpose.
➢ It can be as simple as a mechanical system or as complex as an ecosystem or information system.
➢ A system is basically a group of things or parts that work together in an organized way to achieve a
common goal. Think of it like a team where each member has a specific role, and everyone works
together to get the job done.
➢ It operates through a network of relationships, exchanges, and processes, where each component
plays a unique role in contributing to the overall operation.
➢ A system can exist in various forms—natural, artificial, physical, abstract, or a combination of these—
and interacts with its surroundings, known as the environment
➢ The goal of the system is to achieve something, like solving a problem, creating a product, or
maintaining balance.
Introduction to System Concepts
Elements of a System
A system is made up of several key elements or components that work together to achieve the
system's goal. Here are the main elements of a system:
1. Input and Output
These are the resources (such as data, materials, energy, or information) that are put into a
system to be processed.
The result or product that is produced after the input has been processed by the system.
2. Process
The actions or operations that are performed on the input to transform it into an output.
3. Control
The control element guides the system. It is the decision—making sub-system that controls the pattern
of activities governing input, processing and output. (Example Project Manager)
Introduction to System Concepts
4. Feedback
Feedback is information about the output that helps the system adjust its behavior or
performance. It can be used to maintain or improve the system's functioning.
5. Environment
The external factors that influence the system but are not part of it. The environment interacts
with the system, and the system responds to these external factors. The software environment,
consisting of vendors, users, competitions and others, may provide constraints and
consequently influence the actual performance of software.
6. Boundary
The boundary defines the limits of the system, distinguishing it from the environment. It shows
what is included in the system and what is not.
Introduction to System Concepts
7. Subsystems
These are smaller systems that exist within a larger system. They may function
independently but also interact with the larger system.
Introduction to System Concepts
Characteristics of System
➢ Organization : Organization implies structure and order. It is the arrangement of components that helps to
achieve objectives. Hierarchical relationship starting with the president on top and leading downward to the blue
collar worker represent the organization structure.
➢ Interaction : Interaction refers to the manner in which each component interact with other components of the
system. In an organization, for example purchasing must interact with production, advertising with sales and
payroll with personnel.
➢ Interdependence : Independence means that parts of the organization or computer system depend on one
another. They are coordinated and linked together according to a plan. One subsystem depends on the input of
another subsystem for proper functioning; that is, the output of one subsystem is the required input for another
subsystem.
➢ Integration : Integration refers to the holism of system. Synthesis follows analysis to achieve the central objective
of the organization. Integration is concerned with how a system is tied together. It is more than sharing a physical
part or a location. It means that parts of the system work together within the system even though each part
performs a unique function.
➢ Central Objectives: Then objective of the system must be a common objective. Every system exists to achieve a
defined purpose or objective. Example: A transportation system aims to move people and goods efficiently.
Introduction to System Concepts
Types of Systems
➢ Physical : Physical systems are tangible entities that may be static or dynamic in operation (example Computer
system). The physical part of the computer center are desk and chair is static. The computer is a dynamic system in
which programs, data and applications can change according to the users need. Example solar systems.
➢ Abstract systems are conceptual or non-physical entities which may be as straightforward as formulas of relationships
among sets of variables or models – the abstract conceptualization of physical situations. (Example: system layout,
diagram, formulas, operating system, economic systems.
➢ Open : An open system continually interacts with its environments. It receives inputs from and delivers output to the
outside. Example: A user comes to a company tells the requirement of software and the company delivers it. It adapt
to the changing demands of the user.
➢ Closed Systems: In contrast, a closed system is isolated from environmental influences. In reality, completely closed
systems are rare. No dynamic nature in closed system.
➢ Adaptive System: Adaptive system responds to the change in the environment in a way to improve their performance
and to survive. (Change according to demand and need. A software company teach new languages to employes.)
➢ Non- Adaptive system is the system which does not respond to environment changes. For example : Machines, maps.
Introduction to System Concepts Types of Systems
➢ Temporary systems: Made for specific duration of time for specific use and after that they are demolished. Example
event management systems, construction sites, election systems.
➢ Permanent System: persist for longer duration for long goals. Example Power supply grid, banking system, education
system.
➢ Deterministic Systems: A deterministic system is one in which the occurrence of all events is perfectly determined or
fixed. If we get the description of the system state at a particular time, the next state can be easily described. Example
Algebras laws, Mathematics equations.
➢ Probabilistic system is one in which the occurrence of events cannot be perfectly predicted. Example weather
forecast, stock prediction.
Introduction to Software Engineering
➢ Software engineering is the discipline of designing, developing, testing, and maintaining software systems using
systematic, structured, and well-defined methods.
➢ It involves applying engineering principles to the entire software development life cycle to create software that is
reliable, efficient, maintainable, and meets the needs of users.
➢ In simple terms, software engineering is the process of building software in a planned and organized way, much
like how engineers design and build bridges or buildings.
➢ The goal is to produce high-quality software that works as expected and is easy to maintain over time.
➢ Software engineers apply engineering principles and knowledge of programming languages to build software
solutions for end users.
Introduction to Software Engineering
The need for software engineering arises due to the increasing complexity, scale, and impact of modern
software systems. Here are some key reasons why software engineering is essential:
5. Team Collaboration
•Modern software development involves large, often geographically distributed teams.
➢ Modularity: Breaking the software into smaller, reusable components that can be developed and tested
independently.
➢ Abstraction: Hiding the implementation details of a component and exposing only the necessary functionality
to other parts of the software.
➢ Encapsulation: Wrapping up the data and functions of an object into a single unit, and protecting the internal
state of an object from external modifications.
➢ Reusability: Creating components that can be used in multiple projects, which can save time and resources.
➢ Maintenance: Regularly updating and improving the software to fix bugs, add new features, and address
security.
➢ Testing: Verifying that the software meets its requirements and is free of bugs.
➢ Design Patterns: Solving recurring problems in software design by providing templates for solving them.
➢ Agile methodologies: Using incremental development processes that focus on customer satisfaction, rapid
delivery, and flexibility.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
McCall's Quality Model is a software quality model introduced by James McCall in the early 1970s. It
focuses on identifying and improving the key factors that determine the quality of software products.
Introduction to Software Engineering
These factors are related to the operational aspects of the software and how it performs in a
production environment:
•Correctness: The extent to which the software satisfies the specified requirements.
•Reliability: The ability of the software to perform its required functions under specified
conditions for a specified period.
•Efficiency: The software's ability to perform its functions with optimal use of resources (e.g.,
time, memory).
•Integrity: The ability to protect the software from unauthorized access and ensure data
security.
•Usability: The ease with which the software can be used by its intended users.
Introduction to Software Engineering
These factors pertain to the software's maintainability and adaptability over time:
•Maintainability: The ease with which the software can be modified to correct
defects, improve performance, or adapt to new requirements.
•Flexibility: The ability of the software to accommodate changes and new features
with minimal effort.
•Testability: The ease with which the software can be tested to ensure it is working
as expected.
These factors focus on how the software can be transferred or adapted for use in
different environments or systems:
•Interoperability: The ability of the software to interact and work with other systems or
software without issues.
•Portability: The effort required to transfer a program from one platform to another.
Introduction to Software Engineering
•The model provides a framework for evaluating software quality from different
perspectives.
•It helps to define and measure quality attributes that should be prioritized during the
software development lifecycle.
•By assessing these factors, developers can make informed decisions about improving
various aspects of software quality.
• SDLC specifies the task(s) to be performed at various stages by a software engineer or developer.
• It ensures that the end product is able to meet the customer’s expectations and fits within the overall
budget.
• Hence, it’s vital for a software developer to have prior knowledge of this software development
process. SDLC is a collection of these six stages, and the stages of SDLC are as follows:
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
• It is the first phase in most Software Development Life Cycle (SDLC) models. It involves understanding what
the system is supposed to do, analyzing the project's feasibility, and planning its execution.
• This phase ensures that the development team clearly understands the requirements and prepares
adequately before proceeding.
• The information from this analysis forms the building blocks of a basic project.
• Defining requirements is a critical phase in the Software Development Life Cycle (SDLC).
• It involves gathering, analyzing, and documenting the needs and expectations of stakeholders to provide a
clear understanding of what the software system should achieve.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
• In the Software Development Life Cycle (SDLC), designing the architecture is a crucial phase where
the structure of the system is planned, which includes defining the high-level components, modules,
interfaces, and data flows.
• This phase ensures that the software is built on a solid foundation, supporting both functional and non-
functional requirements.
• The architecture design phase can vary depending on the SDLC model used.
• Developing Product (also known as the Development Phase) follows the planning and design phases
and focuses on the actual creation of the software product.
• It is the phase where the development team writes the code to build the system based on the design
specifications.
• Some popular languages like C/C++, Python, Java, etc. are put into use as per the software
regulations.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
• Product testing and integration are two crucial phases in the Software Development Life Cycle (SDLC) that
focus on ensuring the product functions as intended and works seamlessly with other components or
systems..
• Product testing is the process of validating and verifying the software product to ensure it meets the defined
requirements and works as expected in different environments.
• Integration in SDLC refers to the phase where different software modules, components, or systems are
combined and tested together to ensure they work seamlessly.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
• In the Software Development Life Cycle (SDLC), Deployment and Maintenance are two critical stages that
occur after the development and testing phases.
• These stages ensure that the product is successfully delivered to end-users and continues to perform
effectively over time.
• Deployment refers to the process of delivering the software to the production environment, making it
available for use by end-users. This step involves the installation, configuration, and launch of the application
in the target environment.
• Maintenance involves all activities required to keep the software operational and effective after its initial
release. This stage includes fixing defects, updating the software to address user feedback, and ensuring the
product continues to meet business and user needs over time.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Waterfall Model
• The Waterfall Model is a traditional
Software Development Life Cycle
(SDLC) model that follows a linear and
sequential approach to software
development.
• It was one of the earliest SDLC models,
first introduced by Dr. Winston W. in
1970.
• The waterfall model is useful in
situations where the project
requirements are well-defined and the
project goals are clear.
• It is often used for large-scale projects
with long timelines, where there is little
room for error and the project
stakeholders need to have a high level of
confidence in the outcome.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
2.Document-Driven: The waterfall model depended on documentation to ensure that the project is well-
defined and the project team is working towards a clear set of goals.
3.Quality Control: The waterfall model places a high emphasis on quality control and testing at each
phase of the project, to ensure that the final product meets the requirements and expectations of the
stakeholders.
4.Rigorous Planning: The waterfall model involves a careful planning process, where the project scope,
timelines, and deliverables are carefully defined and monitored throughout the project lifecycle.
Overall, the waterfall model is used in situations where there is a need for a highly structured and
systematic approach to software development. It can be effective in ensuring that large, complex
projects are completed on time and within budget, with a high level of quality and customer satisfaction.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
2. System Design:
▪ Based on the requirements gathered in the first phase, the system’s architecture and design are created.
▪ This phase includes:
▪ High-Level Design (HLD): The system architecture, components, modules, and their connections.
▪ Low-Level Design (LLD): Detailed design for each module, including data flow diagrams, algorithms,
and interface details.
3. Implementation (Coding):
▪ The actual coding of the system takes place in this phase.
▪ Developers write code based on the design documents.
▪ The coding is done in programming languages and follows the coding guidelines, standards, and best
practices.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
5. Deployment (Installation):
▪ After successful testing, the software is deployed in the production environment.
▪ It is installed, configured, and made operational for end-users.
▪ Documentation and user manuals are typically provided to users for better understanding and use.
6. Maintenance:
▪ Post-deployment, the software enters the maintenance phase, which involves fixing issues, addressing
bugs, and making updates or improvements.
▪ Maintenance continues as long as the software is in use and requires periodic updates, support, or scaling.
SDLC models
Iterative Model
➢ The iterative model is a software development approach that breaks down projects into
smaller, manageable chunks called iterations.
➢ Each iteration involves planning, analysis, design, development, testing, and
deployment.
➢ It strongly focuses on collaboration, which involves regular meetings and feedback
sessions between the development team and customers.
➢ Each iteration builds upon the last, integrating new feedback.
➢ Issues are spotted early, minimizing future problems.
➢ Maintains clarity of project objectives among all parties.
➢ The iterative model is an improvement over the waterfall model. The waterfall model
is linear, while the iterative model is cyclical.
➢ This model is particularly useful in projects where the end product is not fully defined
or when there is a need for frequent feedback and continuous improvement.
SDLC models
Iterative Model
Iterative Model
➢ In the iterative model, an initial base software is created using the set of requirements.
➢ Then features are constantly added to this base product in successive iterations until we
have a final product satisfying all requirements.
➢ We build and improve the product step by step.
➢ The functionality of the software product boosts incrementally as we progress through
various iterations.
➢ Following the initial phase, some phases repeatedly occur, expecting some improvement
with the fulfillment of each phase.
➢ Customer feedback can be incorporated easily into this model.
➢ Since there are no feedback pathways in the standard waterfall model, there is no
mechanism for error correction.
SDLC models
Iterative Model
Iterative Model
3. Implementation
➢ All needs, planning, and design plans have been carried out.
➢ The chosen design will be implemented by the developer using predefined coding and metrics
standards.
➢ They must implement a unit test at each stage of code development and should strive to produce a
fully functional, testable system for that iteration.
4. Testing
➢ This stage entails comparing the current build iteration to a set of rules and norms to determine
whether or not it fits them.
➢ This sort of testing includes performance testing, security testing, requirements testing, system
testing , usability testing, and so on.
➢ We can also check in with the project stakeholders to perform some tests and get their input.
➢ A developer or tester must guarantee that correcting one bug does not result in the appearance of
new bugs in the system.
SDLC models
Iterative Model
5. Deployment
➢ After completing all the phases, the software is deployed to its work environment.
6. Review
➢ In this phase, after the product deployment, we check the behavior and validity of the deployed product.
➢ If any errors are found, the process starts again.
7. Maintenance
➢ In the maintenance phase, after software deployment in the working environment, there may be some bug
fixes or new updates required.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Spiral Model
• The Spiral Model is a Software Development Life Cycle (SDLC) model that provides a systematic and
iterative approach to software development.
• The Spiral Model is a combination of the waterfall model and the iterative model. It provides support for Risk
Handling.
• In its diagrammatic representation, looks like a spiral with many loops.
• The exact number of loops of the spiral is unknown and can vary from project to project. Each loop of the
spiral is called a phase of the software development process.
Some Key Points regarding the phase of a Spiral Model:
1.The exact number of phases needed to develop the product can be varied by the project manager depending
upon the project risks.
2.As the project manager dynamically determines the number of phases, the project manager has an important
role in developing a product using the spiral model.
3.It is based on the idea of a spiral, with each iteration of the spiral representing a complete software development
cycle, from requirements gathering and analysis to design, implementation, testing, and maintenance.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
The Spiral Model is a risk-driven model, meaning that the focus is on managing risk through multiple
iterations of the software development process. It consists of the following phases:
1.Objectives Defined: The first phase of spiral model clarify what the project aims to achieve, including
functional and non-functional requirements.
2.Risk Analysis: In the risk analysis phase, the risks associated with the project are identified and evaluated.
3.Engineering: In the engineering phase, the software is developed based on the requirements gathered in
the previous iteration.
4.Evaluation: In the evaluation phase, the software is evaluated to determine if it meets the customer’s
requirements and if it is of high quality.
5.Planning: The next iteration of the spiral begins with a new planning phase, based on the results of the
evaluation.
➢ The Spiral Model is often used for complex and large software development projects, as it allows for a
more flexible and adaptable approach to software development. It is also well-suited to projects with
significant uncertainty or high levels of risk.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Each phase of the Spiral Model is divided into four quadrants as shown in the above figure. The
functions of these four quadrants are discussed below:
1.Objectives determination and identify alternative solutions: Requirements are gathered from the
customers and the objectives are identified, elaborated, and analyzed at the start of every phase. Then
alternative solutions possible for the phase are proposed in this quadrant.
2.Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select
the best possible solution. Then the risks associated with that solution are identified and the risks are
resolved using the best possible strategy. At the end of this quadrant, the Prototype is built for the best
possible solution.
3.Develop the next version of the Product: During the third quadrant, the identified features are
developed and verified through testing. At the end of the third quadrant, the next version of the software is
available.
4.Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so-far
developed version of the software. In the end, planning for the next phase is started.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
1.Requirement analysis: In Requirement Analysis At any time, the plan is made just for the next increment
and not for any kind of long-term plan. Therefore, it is easier to modify the version as per the needs of the
customer.
2.Design & Development: The Development Team first undertakes to develop core features (these do not
need services from other features) of the system. Once the core features are fully developed, then these are
refined to increase levels of capabilities by adding new functions in Successive versions. Each incremental
version is usually developed using an iterative waterfall model of development.
3.Deployment and Testing: After Requirements gathering and specification, requirements are then split into
several different versions starting with version 1, in each successive increment, the next version is
constructed and then deployed at the customer site. in development and Testing the product is checked and
tested for the actual process of the model.
4.Implementation: In implementation After the last version (version n), it is now deployed at the client site.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Prototyping Model
• The Prototyping Model is one of the most popularly used Software Development Life Cycle Models (SDLC
models).
• This model is used when the customers do not know the exact project requirements beforehand.
• In this model, a prototype of the end product is first developed, tested, and refined as per customer feedback
repeatedly till a final acceptable prototype is achieved which forms the basis for developing the final product.
• In this process model, the system is partially implemented before or during the analysis phase thereby
allowing the customers to see the product early in the life cycle.
• The process starts by interviewing the customers and developing the incomplete high-level paper model.
• This document is used to build the initial prototype supporting only the basic functionality as desired by the
customer.
• Once the customer figures out the problems, the prototype is further refined to eliminate them.
• The process continues until the user approves the prototype and finds the working model to be satisfactory.
• A classic example of a prototype model in SDLC would be developing a basic, interactive version of an online shopping
website.
• Where users can browse product categories, add items to a cart, and proceed to a checkout page, allowing customers
to provide feedback on the layout, navigation, and functionality before building the full-fledged website.
• This allows for adjustments to the design based on user experience before committing to a final product.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
2.User Description – This phase consists of taking user feedback and building the prototype using
developer tools. In other words, it includes re-examination and validation of the data collected in the first
phase. The dataset attributes are also identified and explained in this phase.
3.Construction – In this phase, refinement of the prototype and delivery takes place. It includes the actual
use of powerful automated tools to transform processes and data models into the final working product.
All the required modifications and enhancements are to be done in this phase.
4.Cutover – All the interfaces between the independent modules developed by separate teams have to
be tested properly. The use of powerfully automated tools and subparts makes testing easier. This is
followed by acceptance testing by the user.
For example, the popular ride-sharing app, Uber, employed the RAD model to quickly release its initial product,
facilitating user feedback and accelerating improvements.
As a result, Uber was able to gain a significant market share in a short time and revolutionised the transportation
industry.
Requirement Analysis
System analysis is the process of studying a system to identify its goals, and then designing and implementing
solutions to achieve those goals.
It's a problem-solving technique that involves breaking down a system into its components and analyzing how
they work together.
What does system analysis involve?
Gathering data
Interpreting information
Identifying issues
Designing a system
Testing the system
Evaluating the system
Putting the system into action
Maintaining the system
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Requirements Analysis
System Analysis
It is the very first step in any system development and the critical phase where developers come together to
understand the problem, needs, and objectives of the project.
Some of the key aspects of system analysis are:
1.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.
2.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.
3.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.
4.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.
5.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.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
The Systems analyst performs the following roles during various phases of SDLC. He works as a:
•Problem Investigator: The analyst studies the problems and needs of an organization during feasibility and
requirements analysis phases of SDLC. He visits the various departments of the organization and interviews the
users. He analyses the problems of the current system and collects their new requirements.
•Problem Solver: The analyst solves the problems of the current system faced by the users. He determines how
people, method and technology can improve the current system. After feasibility analysis, he presents the system
proposal to the management.
•Motivator: The analyst motivates users to participate in development and implementation of the proposed
system. This helps to understands user’s feelings about the proposed system. The analyst interprets the thoughts
of users and hence, draws conclusions.
•Project Manager: The analyst monitors the development and implementation of software in relation to quality,
cost and time. He works with the project leader for managing the project properly.
•Systems Designer : The analyst creates a detailed logical (proposed) design of the system.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Success in systems analysis requires interpersonal and technical skills of the analyst. The systems analyst is
expected to possess the following qualities:
•Qualified: The analyst must be highly qualified in software technology. Besides software, he should have a good
knowledge of hardware and latest communication and networking technology. He must have a thorough awareness
about the working (manual and computerized) of financial accounting, sales and marketing, invoicing, inventory
control, production and other information systems of different organization.
•Analytical Thinker: The analyst must be capable to extract real problems of the users by analyzing the existing
system. He is expected to provide the best solutions to the problems. He should be able to provide more than one
solution to a single problem so that the users can select the best one. The systems analyst must be capable of
tackling any problem of the user. He must be a problem solver and not a problem creator.
•Good Communicator: The analyst must have a good communication and presentation skills. He must have an
excellent command on the language which the user can understand. There should not be any communication gap
between the systems analyst and users.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
•Experienced: The analyst should be experienced in both information and management technologies. He
should be associated with all types of business concerns ( viz., Manufacturing, Trading, Financial, etc.). The
present day systems analysts are expected to possess a good experience in development of software using
4GLS (such as Oracle, Sybase, etc.) and object-oriented languages (such as C++).
•Creator: The analyst should possess excellent creativity skills that help to convert ideas of the users into
concrete plans. He/she should be capable of creating plans and designing systems by drawing diagrams,
charts and other illustrations.
•Trainer: The analyst should be a good teacher for educating and training users in computer based information
systems.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Technical feasibility
• Technical Feasibility analyzes/evaluates current resources for hardware, software, and technology
needed to develop the project.
• This technical feasibility study provides information on whether the appropriate resources and
technology required for use in project development are in place.
• In addition, the feasibility study also analyzes the technical strength and capabilities of the technical
team, whether existing technology can be used, and whether the selected technology is easy to
maintain and upgrade.
• Analyze the technical skills and capabilities of software development team members.
• Determine if the relevant technology is stable and established.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Operational Feasibility
• Operational feasibility is a measure of how well a proposed system can solve problems and meet
requirements.
• It's a part of a feasibility study that assesses an organization's ability to complete a project.
• Along with these other operational areas, it determines the product’s usability, whether the software
development team’s decisions for the proposed solution are acceptable, and so on.
• Determine if the expected issue in the user request is a high priority.
• Determine if the organization is satisfied with alternative solutions proposed by the software
development team.
• Determine if the solution proposed by the software development team is acceptable.
• Analyze whether users are comfortable with new software.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Economic feasibility
• Project costs and benefits are analyzed in a profitability study. This means that as part of this
feasibility study, a detailed analysis of the costs of the development project will be made.
• This includes all costs necessary for the final development, such as hardware and software
resources required, design and development costs, operating costs, etc.
• It is then analyzed whether the project is financially beneficial to the organization.
• The costs incurred in software development generate long-term benefits for an organization.
• Costs required to conduct a complete software study (e.g., requirements extraction and
requirements analysis).
• Hardware, software, development team, and training costs.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Legal Feasibility
• In a legal feasibility study, the project is analyzed from the view of legality.
• This includes analysis of obstacles in the legal implementation of the project, data protection or
social media laws, project certificates, licenses, copyrights, etc.
• Overall, a legal feasibility study is a study to determine whether a proposed project meets legal and
ethical requirements.
Schedule Feasibility
• “User transaction requirements" refer to the specific actions or steps a user needs to perform
within a system to complete a task.
• It gives the expected inputs, processes, and outputs from the user's perspective, essentially
detailing what the user needs to do to interact with the system to achieve a desired outcome.
• These requirements are crucial for designing user interfaces and functionalities that align with user
expectations and needs.
Example of a user transaction requirement:
•"A customer should be able to search for products by name, category, or price range, select desired
items, add them to their shopping cart, review the order summary, and proceed to checkout with
secure payment options."
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
User Transaction: Automatic License Plate Recognition (ALPR) for Parking Entry
1. User Action:
•A vehicle approaches the parking entry gate.
•The camera captures the license plate image.
•The system processes the image to recognize the license plate number.
•If the plate is valid, the gate opens.
•The system logs the entry time and stores vehicle details.
2. System Requirements for This Transaction:
Functional Requirements
•Capture and process the license plate image.
•Extract and match the plate number with the database.
•Grant or deny access based on the result.
Data Integrity & Security
•Ensure the recognized number is stored correctly.
•Protect vehicle data from unauthorized access.
Error Handling
•If recognition fails, retry or request manual entry.
•Log errors for future analysis.
Performance & Scalability
•Process transactions within 2 seconds.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Software Requirements
•Functional requirements
•Non-functional requirements
•Domain requirements
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Functional Requirements
Definition: Functional requirements describe what the software should do. Functional
requirements define all specific features and functionalities that a system must offer. These
are directly visible in the final product.
Examples:
•User Authentication: The system must allow users to log in using a username and password.
•Search Functionality: The software should enable users to search for products by name or
category.
•Report Generation: The system should be able to generate sales reports for a specified date
range.
Explanation: Functional requirements specify the actions that the software needs to perform.
These are the basic features and functionalities that users expect from the software.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Non-functional Requirements
Definition: Non-functional requirements focus on quality attributes and constraints rather than
specific functionalities. It specifies how the system performs a particular function, rather than what
the system performs. These requirements are concerned with the quality of the system.
Examples:
1)Security: Authorization, authentication and confidentiality.
Explanation: Non-functional requirements are about the system’s behavior, quality, and constraints. They
ensure that the software meets certain standards of performance, usability, reliability, and security.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Domain Requirements
Definition: Domain requirements are specific to the domain or industry in which the software
operates. They include terminology, rules, and standards relevant to that particular domain.
Examples:
•Healthcare: The software must comply with WHO regulations for handling patient data.
•Finance: The system should adhere to GAAP standards for financial reporting.
•E-commerce: The software should support various payment gateways like PayPal, Stripe,
and credit cards.
Explanation: Domain requirements reflect the unique needs and constraints of a particular
industry. They ensure that the software is relevant and compliant with industry-specific
regulations and standards.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Depending upon information gathered after interaction, SRS is developed which describes requirements of
software that may include changes and modifications that is needed to be done to increase quality of product
and to satisfy customer’s demand.
• Introduction
➢ Purpose of this Document – At first, main aim of why this document is necessary and what’s purpose of
document is explained and described.
➢ Scope of this document – In this, overall working and main objective of document and what value it will
provide to customer is described and explained. It also includes a description of development cost and time
required.
➢ Overview – In this, description of product is explained. It’s simply summary or overall review of product.
• General description
In this, general functions of product which includes objective of user, a user characteristic, features, benefits,
about why its importance is mentioned. It also describes features of user community.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
• Functional Requirements
In this, possible outcome of software system which includes effects due to operation of program is fully
explained. All functional requirements which may include calculations, data processing, etc. are placed in a
ranked order. Functional requirements specify the expected behavior of the system-which outputs should be
produced from the given inputs. They describe the relationship between the input and output of the system. For
each functional requirement, detailed description all the data inputs and their source, the units of measure, and
the range of valid inputs must be specified.
• Interface Requirements
In this, software interfaces which mean how the system interacts with external entities such as hardware,
software, users, and other systems. These requirements ensure compatibility, communication, and integration
between different components of the system.
• Performance Requirements
In this, how a software system performs desired functions under specific condition is explained. It also explains
required time, required memory, maximum error rate, etc. The performance requirements part of an SRS specifies
the performance constraints on the software system. All the requirements relating to the performance
characteristics of the system must be clearly specified. There are two types of performance requirements: static
and dynamic. Static performance refers to the system’s performance under a predefined, fixed workload or
resource conditions. Dynamic performance refers to the system’s ability to handle changing conditions such as
variable workloads, user interactions, and resource demands.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
• Design Constraints
Design Constraints in a Software Requirements Specification (SRS) define the limitations and restrictions
that impact the system’s architecture, development, and implementation. These constraints ensure the
system meets regulatory, technical, and business requirements while maintaining feasibility. Example:
Ram, Memory, Operating system, database usage.
• Non-Functional Attributes
In this, non-functional attributes are explained that are required by software system for better
performance. An example may include Security, Portability, Reliability, Reusability, Application
compatibility, Data integrity, Scalability capacity, etc.
• Preliminary Schedule and Budget
In this, initial version and budget of project plan are explained which include overall time duration
required and overall cost required for development of project.
• Appendices
In this, additional information like references from where information is gathered, definitions of some
specific terms, acronyms, abbreviations, etc. are given and explained.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
5. Ranking for importance and stability: The SRS is ranked for importance and
stability if each requirement in it has an identifier to indicate either the significance
or stability of that particular requirement.
6. Modifiability: SRS should be made as modifiable as likely and should be capable of
quickly obtain changes to the system to some extent. Modifications should be
perfectly indexed and cross-referenced.
7. Verifiability: SRS is correct when the specified requirements can be verified with a
cost-effective system to check whether the final software meets those requirements.
The requirements are verified with the help of reviews.
8. Traceability: The SRS is traceable if the origin of each of the requirements is clear
and if it facilitates the referencing of each condition in future development or
enhancement documentation.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
• A Data Flow Diagram (DFD) is a graphical representation of the flow of data within a
system, commonly used in software engineering for system analysis and design.
• A Data Flow Diagram (DFD) is a structured analysis tool used to visualize how data
moves through a system.
• It helps in understanding the flow of information, inputs, processes, outputs, and
data storage.
3. Components of DFD
1.External Entities – an outside system that sends or receives data, communicating with
the system being diagrammed. They are the sources and destinations of information
entering or leaving the system.
2.Processes – any process that changes the data, producing an output. It might perform
computations, or sort data based on logic, or direct the data flow based on business
rules. A short label is used to describe the process, such as “Submit payment.”
3.Data Stores – files or repositories that hold information for later use, such as a
database table or a membership form. Each data store receives a simple label, such as
“Orders.”
4.Data Flows – the route that data takes between the external entities, processes and
data stores. It portrays the interface between the other components and is shown with
arrows, typically labeled with a short data name, like “Billing details.”
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
0-level DFD
• It is also known as a context diagram.
• It’s designed to be an abstraction view.
• It’s a basic overview of the whole system or process being analyzed or modeled.
• It’s designed to be an at-a-glance view, showing the system as a single high-level process, with its relationship
to external entities.
• It should be easily understood by a wide audience, including stakeholders, business analysts, data analysts
and developers.
• It represents the entire system as a single bubble with input and output data indicated by
incoming/outgoing arrows.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
DFD Level 1
•DFD Level 1 provides a more detailed breakout of pieces of the Context Level Diagram.
•This level provides a more detailed view of the system by breaking down the major processes identified
in the level 0 DFD into sub-processes.
•Each sub-process is depicted as a separate process on the level 1 DFD.
•The data flows and data stores associated with each sub-process are also shown.
•In 1-level DFD, the context diagram is decomposed into multiple bubbles/processes.
•In this level, we highlight the main functions of the system and breakdown the high-level process of 0-
level DFD into subprocesses.
2-level DFD
• This level provides an even more detailed view of the system by breaking down the sub-processes
identified in the level 1 DFD into further sub-processes.
• Each sub-process is depicted as a separate process on the level 2 DFD.
• The data flows and data stores associated with each sub-process are also shown.
Level 1 DFD
Level 2 DFD
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Data Dictionary
• A data dictionary is a centralized repository that contains information about the data in a
database.
• It serves as a detailed reference that describes each data element, including its structure,
purpose, and usage.
• In database design, a data dictionary helps ensure data consistency, integrity, and proper
documentation, making it a vital tool for developers, analysts, and administrators.
Symbols : = is equivalent to
= and
[ ] either/or
{ } iterations of
( ) optional
* Encloses annotation
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Pseudo Code
Pseudo code is a simplified, informal way of describing a program’s logic using plain language. It is not
written in any specific programming syntax but rather outlines the steps a program should follow. Pseudo
code is widely used in algorithm design before actual coding begins.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Concept of Modules
• A module is an independent unit of code that performs a specific function or set of related
functions.
• In software development, modular design breaks a large system into smaller, manageable
parts called modules.
• Each module typically has its own functionality, making the system easier to build,
maintain, and test.
Types of Modules
Modules are categorized based on their design, purpose, and role in a system.
1. Functional Modules: Focus on specific business logic or functional requirements. Example: A
PaymentProcessing module for handling transactions.
2. Data Modules: Handle data storage, retrieval, and management. Example: A Database Connector module
that interacts with a database.
3. Control Modules: Manage the flow of data and coordinate other modules. Example: A Workflow Controller
that guides the sequence of tasks.
4. Utility Modules: Provide reusable helper functions or general-purpose features. Example: A String Utils
module for text processing.
5. Service Modules: Offer specialized services via APIs or web interfaces. Example: An Email Service module
for sending automated emails.
6. UI/Presentation Modules: Handle user interface elements, such as web pages or app screens. Example:
A LoginScreen module with form design and input validation.
7. Security Modules: Ensure system protection through encryption, authentication, or authorization.
Example: An authorized Module for managing user logins and permissions.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Software Design
• Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software.
• Software design is the process of defining the architecture, components, interfaces, and other
characteristics of a software system. It involves planning how the software will meet specified
requirements and ensuring its structure is efficient, maintainable, and scalable.
• McGlaughlin suggests three characteristics that serve as a guide for the evaluation of a good
design:
➢ The design must implement all of the explicit requirements contained in the analysis model,
and it must accommodate all of the implicit requirements desired by the customer.
➢ The design must be a readable, understandable guide for those who generate code and for
those who test and subsequently support the software.
➢ The design should provide a complete picture of the software, addressing the data, functional,
and behavioural domains from an implementation perspective.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Design Principles
Design Concepts
Design Concepts
1. Abstraction: Hides complex implementation details and exposes only essential features.
• Purpose: Simplifies design by focusing on high-level functionality.
• Example: A Car class with methods like start(), stop(), and drive() without exposing internal engine
mechanics.
2. Refinement: Gradually elaborating the system design by breaking high-level tasks into detailed steps.
• Purpose: Progressively narrows the focus from general to specific.
• Example: Starting with a broad plan for license plate recognition, then refining steps into detection,
dehazing, and text extraction.
3. Modularity: Divides the system into independent, interchangeable modules.
• Purpose: Enhances maintainability, reusability, and scalability.
• Example: Separating your Admission model, Finance detection, and Result into distinct modules.
4. Software Architecture: Describes the overall structure, components, and interactions of the system.
• Purpose: Provides a blueprint for software design.
• Example: Using Layered Architecture for better separation of concerns.
5. Control Hierarchy (Program Structure)
• Definition: Defines the flow of control between modules or components.
• Purpose: Ensures clear communication and minimizes dependency issues.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Cohesion
• Cohesion refers to the degree to which the elements within a module or component
are related and work together to achieve a single, well-defined purpose.
• In simpler terms, it measures how well the parts of a module work together to
achieve a single purpose.
• Think of a module as a team — if all team members are working toward the same
goal, the team is cohesive. If everyone is doing unrelated tasks, the team lacks
cohesion.
• A cohesive software module should focus on just one task or purpose.
Why Cohesion Matters
High cohesion leads to:
•Better maintainability
•Improved readability
•Enhanced reusability
•Easier testing and debugging
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Coupling
Types of Coupling
1. Content Coupling :One module directly modifies or relies on the internal details of another.
Example: Module A directly accesses or changes variables in Module B.
2. Common Coupling: Multiple modules share a global variable.
Example: Modules A and B both read/write data from a shared global file.
3. External Coupling: Modules depend on external systems or hardware interfaces.
Example: A module that requires a specific database schema or API format.
4. Control Coupling: One module controls another’s behavior by passing control flags or
conditions.
Example: Passing a mode flag 'train' or 'test'.
5. Stamp Coupling: Modules pass complex data structures rather than specific data items.
Example: Sending an entire image object when only image_size is needed
6. Data Coupling :Modules share only necessary data via parameters.
Example: A vehicle detection module calls a image enhancement function by passing
only image_data.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
• SC shows the static structure, not the logic and different from flow charts.
• Structure is decided during design.
• SC represents modules and interconnections
• Each module is represented by a box
• If A invokes B, an arrow is drawn from A to B
• Arrows are labeled by data items
• Different types of modules in a SC exist such as Input, output, transform,
coordinate and composite modules.
• Implementation does not change structure and structure affects
maintainability.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Steps of SDM
1. Identify most abstract inputs and most
abstract outputs in a DFD
2. First level factoring
3. Factoring of input, output, transform
modules
4. Improving the structure
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Step 1
Most abstract inputs:
• data elements in DFD that are furthest from the actual
inputs, but can still be considered as incoming. These are
logical data items for the transformation.
• Travel from physical inputs towards outputs until data can
no longer be considered incoming.
• Go as far as possible, without loosing the incoming nature.
Most abstract outputs:
• Similar as of most abstract inputs.
• Represents a value judgment, but choice is often obvious.
Bubbles between mai and mao: central transforms
• These transforms perform the basic transformation
• With mai and mao the central transforms can concentrate
on the transformation
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Step 4
• The above steps should not be followed blindly
• The structure obtained should be modified if needed
• Low coupling, high cohesion being the goal
• Design heuristics used to modify the initial design
• Design heuristics - A set of thumb rules that are generally useful
➢ Module Size: Indication of module complexity Carefully examine modules
less than a few lines or greater than about 100 lines
➢ Fan out: no. of arrows going out of the module, indicating the no. of sub
ordinates of the module
➢ fan in: no. of arrows coming in the module, indicating the no. of super
ordinates of the module
➢ A high fan out is not desired, should not be increased beyond 5 or 6
➢ Fan in should be maximized
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Testing Objectives
• Glen Myers states a number of rules that can serve well as
testing objectives:
1. Testing is a process of executing a program with the
intent of finding an error.
2. A good test case is one that has a high probability of
finding an as-yet-undiscovered error.
3. A successful test is one that uncovers an as-yet-
undiscovered error.
• In a word, our objective is to design tests that
systematically uncover different classes of errors and to
do so with a minimum amount of time and effort.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Testing Benefits
1. If testing is conducted successfully, it will uncover errors in
the software.
2. Testing demonstrates that software functions appear to be
working according to specification, that behavioural and
performance requirements appear to have been met.
3. Data collected as testing is conducted to provide a good
indication of software reliability and some indication of
software quality as a whole.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Testing Principles
• All tests should be traceable to customer requirements.
• Tests should be planned long before testing begins.
• The Pareto principle applies to software testing
• Testing should begin “in the small” and progress toward
testing “in the large.”
• Exhaustive testing is not possible.
• To be most effective, testing should be conducted by an
independent third party.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
The first test approach is called black-box testing and the second,
white-box testing.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
Black-Box Testing
• Black-box testing, also called behavioural testing, focuses on
the functional requirements of the software. That is, black-box
testing enables the software engineer to derive sets of input
conditions
that will fully exercise all functional requirements for a program.
System Testing
• System testing is actually a series of different tests whose primary purpose is to fully
exercise the computer-based system. Although each test has a different purpose, all
work to verify that system elements have been properly integrated and perform
allocated functions.
• Recovery testing is a system test that forces the software to fail in a variety of ways and
verifies that recovery is properly performed. If recovery is automatic (performed by the
system itself), reinitialization, checkpointing mechanisms, data recovery, and restart are
evaluated for correctness.
• Security testing attempts to verify that protection mechanisms built into a system will, in
fact, protect it from improper penetration. During security testing, the tester plays the
role(s) of the individual who desires to penetrate the system.
• Stress testing executes a system in a manner that demands resources in abnormal
quantity, frequency, or volume. For example, (1) special tests may be designed that
generate ten interrupts per second, when one or two is the average rate, (2) input data
rates may be increased by an order of magnitude to determine how input functions will
respond, (3) test cases that require maximum memory or other resources are executed,
Essentially, the tester attempts to break the program.
• Performance testing is designed to test the run-time performance of software within the
context of an integrated system. Performance testing occurs throughout all steps in the
testing process.