SE- sem 1- Module 1

#Introduction to Software Engineering

*Definition:-Software engineering is defined as a process of analyzing user requirements

and then designing, building, and testing software application which will satisfy those
requirements.
- The main goal of software Engineering is to develop software application for improving the
quality, budget and time efficiency.
-Software=Program+
Documentation+
Operating Procedures.
-This are the components
Of the software.
-program is a subset of
Software.
-Program is a combination
of source code and object code.
-Documentation consists of different types of manuals.

-Operating procedures consist of instructions to setup and use the software system and
instructions on how to react to system failure.
or
-Operating procedure manuals are prepared to help the customer to install, operate and
maintain the software. They are delivered along with program(s) at the time of release.
Some of the operating procedure manuals are given as:
*characteristics of software
1. Software Does Not Wear Out:-There is no concept of ‘ageing’ in software.
-Hardware parts of any product (say automobile) start malfunctioning after the
specified time due to ageing of various parts.
-The same is true for every hardware product.
-If we draw a graph between failure rate and time, we get a curve which is similar to
‘bath tub’ and is known as bath tub curve.
-The curve has three phases, namely, burn-in phase, useful life phase and wear-out
phase as shown in Figure 1.2.
-In the initial phase (burn-in phase),
the failure rate is high.
-When we start testing the product,
we detect faults.
-These faults are corrected which
results into a drop in the failure
Rate.
-therefore the drop may stabilize after
certain time of testing and the curve
becomes stable.
-This is the end of initial phase (burn-in phase)
which is expected to be performed in the company itself.
-Then the product is released to the customer.
-The second phase where the failure rate is less and it is called the useful life phase.
 - After the completion of the useful life phase, the failure rate again increases due to
the effects of environmental conditions (like temperature, humidity, pressure, etc.),
rains dusts and rusting on various parts of product.
-This means, various parts begin to wear out. This phase is called wear-out phase.
-We do not have the wear-out phase in software.
-The curve for software is shown in Figure 1.3.
-The software becomes reliable over time
instead of wearing out.
-It may become obsolete due to other
reasons but not because of wear-out.
-Some of such reasons are change in
technologies, change in expectations,
poor response time, deterioration in
the structure of the source code,
complexity issues, etc.

2. Flexibility of Software:-Flexibility of software may create confusion in stakeholders.

-This unique characteristic is a real strength of a software in terms of making
changes, incorporating new functionalities, modifying source code and managing
complexity.
-A stakeholder is a person who is having direct or indirect interest in the software
system, including customers, software developers, managers, users, testers and so
on.
-it is easy to modify the source code but it is very difficult to manage the effect of
changes in other parts of the source code.
-making changes in software is easier as compared to hardware and such changes
must be made after proper study and analysis of its impact on other parts of the
source code.
3. Reusability of Software:-If we manufacture a computer.
-We purchase the components from the market (like motherboard, UPS, SMPS, etc.)
and reuse those components for manufacturing of computers.
-but we didn’t make the components, we buy and use it.
-The reusable components are very common and popular and it is also reduce the
time and cost of manufacturing.
- In software companies, most of the projects are developed for specific customers.
-Every customer has unique requirements and expectations.
-The concept of reusability is rarely used.
 - Reusability is the process of integrating the already built well-tested components in
the new software.
-By reusing the existing source code, the development effort and cost of
development and testing are reduced.

*Broad categories of computer software/Types of software

● Application software:- it refers to software that performs specific functions for a
user.
-When a user interacts directly with a piece of software, it is called application
software.
-The sole purpose of application software is to assist the user in doing specified tasks.
-Microsoft Word and Excel, as well as popular web browsers like Firefox and Google
Chrome, are examples of application software.
-Application software is written in a high-level language like Java, C++,.Net, or PHP

● System software:-System software is an intermediator or a middle layer between the

user and the hardware.
-System software is a software that provides platform to other softwares.
-Some examples can be operating systems, antivirus softwares, disk formatting
softwares, Computer language translators etc.
-It is very difficult to design system software.
-System software is responsible to directly connect the computer with hardware that
enables the computer to run.
-System Software is difficult to understand.
-It is usually written in a low-level language.
-When the computer is turned on, system software begins to run and stops when the
computer is turned off.
-Without system software, a computer system cannot even start.

● Engineering/scientific software :-scientific software are used for scientific purposes.

-Scientific software is mainly developed to better understand or make predictions
about real world processes.
-software used to predict weather,and those used in prediction of genome
structure,automotive stress analysis,space shuttle orbital dynamics etc

● Embedded software:- it is placed in ROM of the product and control the various
functions of the product like automobile,security system.
-Examples are software used in instrumentation and control applications like washing
machines, satellites, microwaves, etc.
 ● Networking and Web Applications Software:- provides the required support
necessary for computers to interact with each other and with data storage facilities.
- Networking software is also used when software is running on a network of
computers (such as the World Wide Web).
-It includes all network management software, server software, security and
encryption software, and software to develop web-based applications like HTML,
PHP, XML, etc

● Business Software:-This category of software is used to support business

applications and is the most widely used category of software. Examples are software
for inventory management, accounts, banking, hospitals, schools, stock markets, etc.

● Entertainment Software:-Education and entertainment software provides a powerful

tool for educational agencies, especially those that deal with educating young
children.
-There is a wide range of entertainment software such as computer games,
educational games, translation software, mapping software, etc.

● Artificial Intelligence Software:-Software like expert systems, decision support

systems, pattern recognition software, artificial neural networks, etc. come under
this category.
-They involve complex problems which are not affected by complex computations
using non-numerical algorithms.
Or
-use of nonnumerical algorithms to solve complex problems. Applications within this
area include robotics, expert systems, pattern recognition , artificial neural networks,
theorem proving, and game playing.

*Software Myths
1. Software is easy to change:- It is true that source code files are easy to edit, but that
is quite different than saying that software is easy to change.
-Every change requires that the complete system be re-verified.
-If we do not take proper care, this will be an extremely boring and expensive
process.
2. Testing software correct can remove all the errors:- Testing can only show the
presence of errors.
-Our aim is to find the maximum possible errors.
-The more we test, the more we are confident about our design.
3. Reusing software increases safety:-Code reuse is a very powerful tool that can yield
dramatic improvement in development efficiency, but it still requires analysis to
determine its suitability and testing to determine if it works.
 4. Software with more features is better software:-This is, of course, almost the
opposite of the truth.
-The best, most enduring programs are those which do one thing well.

#The Software process:-Software is the set of instructions in the form of programs

to govern the computer system and to process the hardware components.
-To produce a software product the set of activities is used.
-This set is called a software process.
-These are four key process activities, which are common to all software processes. they are;
● Software Specifications:-In this process, detailed description of a software system to
be developed with its functional and non-functional requirements.
● Software Development:-In this process, designing, programming, documenting,
testing, and bug fixing is done.
● Software validation: The software must be validated to ensure that it does what the
customer wants.
● Software evolution: The software must evolve to meet changing client needs.

*Software engineering layers:-Software engineering is a layered technology.

-To develop software we need to go from one layer to another.
-All the layers are connected and each layer demands the fulfillment of the previous layer.
-There are four types of layers in Software Engineering such as – Tools, methods, process, A
quality focus.
1. A quality focus:-It defines the
continuous process improvement
principles of software.
-It provides integrity that means
providing security to the software so
that data can be accessed by only an
authorized person, no outsider can access the data.
-It also focuses on maintainability and usability.
2. Process:-It is the foundation or base layer of software engineering.
-It is key that glue all the layers together which enables the development of software
before the deadline or on time.
-Process defines a framework that must be established for the effective delivery of
software engineering technology.
-The software process covers all the activities, actions, and tasks required to be
carried out for software development.
-This layer can be broken down into five sub-layers they are;
 ● Communication: It is the first and foremost thing for the development of
software.
-Communication is necessary to know the actual demand of the client.
● Planning: It basically means drawing a map for reduce the complication of
development.
● Modelling: In this process, a model is created according to the client for
better understanding.
● Construction: It includes the coding and testing of the problem.
● Deployment:- It includes the delivery of software to the client for evaluation
and feedback.

3. Method:-The method provides the answers of all 'how-to' that are asked during the
process.
-It provides the technical way to implement the software.
-It includes collection of tasks starting from communication, requirement analysis,
analysis and design modelling, program construction, testing and support.
4. Tools: -Software engineering tools provide automated or semi-automated support
for the process and the methods.
-Tools are integrated which means information created by one tool can be used by
another.
[A process framework (five generic process framework and umbrella activities)]
*process framework:-The process framework is required for representing common
process activities.
-Five framework activities are described in a process framework for software engineering.
-Communication, planning, modelling, construction, and deployment are all examples of
framework activities.
1. Communication:-By communication, customer requirement gathering is done.
-Communication with consumers and stakeholders to determine the system’s
objectives and the software’s requirements.

2. Planning: Establish engineering work plan, describes technical risk, lists resources
requirements, work produced and defines work schedule.
3. Modelling: Architectural models and design to better understand the problem and
for work towards the best solution. The software model is prepared by:
o Analysis of requirements
o Design
4. Construction: Creating code, testing the system, fixing bugs, and confirming that all
criteria are met. The software design is mapped into a code by:
o Code generation
o Testing
 5. Deployment: In this activity, a complete or non-complete product or software is
represented to the customers to evaluate and give feedback. On the basis of their
feedback, we modify the product for the supply of better products.

→Umbrella activities:-Umbrella Activities are that take place during a software

development process for improved project management and tracking.
-it help a software team manage and control progress, quality, change, and risk.
-Typical umbrella activities include
1. Software project tracking and control:- This is an activity in which the team can
assess progress and take corrective action to maintain the schedule.
-Take action to keep the project on time by comparing the project’s progress against
the plan.
2. Risk management:-The risks that may affect project outcomes or quality can be
analyzed.
-assesses risks that may affect the outcome of the project or the quality of the
product
3. Software quality assurance:-These are activities required to maintain software
quality.
-Perform actions to ensure the product’s quality.
4. technical reviews:- It is required to assess engineering work products to uncover and
remove errors before they propagate to the next activity.
-At each level of the process, errors are evaluated and fixed.
5. Software configuration management:-manages the effects of change throughout
the software process
6. Work product preparation and production:- The activities to create models,
documents, logs, forms, and lists are carried out.
7. Reusability management:- It defines criteria for work product reuse. Reusable work
items should be backed up, and reusable software components should be achieved.

*Software product and software process:-

 Software Product Software Process
Software Products are nothing but software Process is a set of sequence steps that have
systems delivered to the customer with the to be followed to create a project. The main
documentation that describes how to install purpose of a process is to improve the
and use the system. quality of the project.

Software products are produced with the To produce a software product the set of
help of the software process. activities is used. This set is called a
software process.

Product is the final production of the project. process is a set of sequence steps that have
to be followed to create a project.

A product tends to be short-term. the process tends to be long-term.

The main goal of the product is to complete the purpose of the process is to make the
the work successfully. quality of the project better.

Product development focus is on final outcome. The process focuses on each step to be followed
during software product development.

#Process Models:-Process models were originally proposed to bring order to the

confusion of software development.
-History has indicated that these models have brought a certain amount of useful structure
to software engineering work .
-A process model provides a specific roadmap for software.
-It defines the flow of all activities, actions and tasks, the degree of iteration, the work
products, and the organization of the work that must be done.
-Software engineers and their managers adapt a process model for their needs.
-The goal of a software process model is to provide guidance for controlling and
coordinating the tasks to achieve the end product and objectives as effectively as possible.
-There are many kinds of process models for meeting different requirements.
-We refer to these as SDLC models (Software Development Life Cycle models).

1. Prescriptive Process Models:-A prescriptive process model tries for structure and
order in software development.
-Prescriptive process models are sometimes referred to as “traditional” process
models.
-Prescriptive process models defi ne a prescribed set of process elements and a
predictable process work flow.
-There are three types of prescriptive process models. They are:
● The Waterfall Model
● Incremental Process model
● RAD model
( incremental process model and rad model explain cheyandaaa)

● The 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 or 'Classic life cycle
model'.
-In this model, each phase is fully completed before the beginning of the next
phase.
-This model is used for the small projects.
-In this model, feedback is taken after each phase to ensure that the project is
on the right path.
-Testing part starts only after the development is complete.
-Activities are carried out in a linear and systematic fashion.

→fig explain
-The process starts with communication, where requirements are gathered
from the customer and recorded.
-Then goes to the planning stage where the cost and time constraints are
estimated.
-Modelling is where a design based on the requirements and keeping the
project constraints in mind is created.
-After this, code is generated and the actual building of the product is started
in the construction phase.
-Testing (unit testing, integration testing) is done after code completion in
this phase.
-Deployment is the last stage where the product is delivered, customer
feedback is received and, support and maintenance for the product are
provided.

→Advantages of waterfall model

-The waterfall model is simple and easy to understand, implement, and use.
-Easily understandable workflow.
-All the requirements are known at the beginning of the project, hence it is
easy to manage.
-It avoids overlapping of phases because each phase is completed at once.
-This model is preferred for those projects where the quality is more important
as compared to the cost of the project.
or
-Can be applied to projects where quality is preferred over cost.
 →Disadvantages of the waterfall model
-This model is not good for complex and object oriented projects.
-It is a poor model for long projects.
-The problems with this model are uncovered, until the software testing.
-The amount of risk is high.

*v model:-The V-model is a type of SDLC

(Software Development Life Cycle models).
-model where process executes in a sequential
manner in V-shape.
-It is also known as Verification and Validation
model.
-it is based on the association of a testing phase for
each corresponding development stage.
-Development of each step directly associated with
the testing phase.
-he next phase starts only after completion of the
previous phase i.e. for each development activity,
there is a testing activity corresponding to it.
-V-Model contains Verification phases on one side of the
Validation phases on the other side.
-Verification and Validation phases are joined by coding phase
in V-shape. Thus it is called V-Model.
→ Design Phase:
● Requirement Analysis: This phase contains detailed communication with the
customer to understand their requirements and expectations.
● System Design: This phase contains the system design and the complete hardware
and communication setup for developing product.
● Architectural Design: System design is broken down further into modules taking up
different functionalities.
-The data transfer and communication between the internal modules and with the
outside world (other systems) is clearly understood.
● Module Design: In this phase the system breaks down into small modules. The
detailed design of modules is specified, also known as Low-Level Design (LLD).

2.Evolutionary Process Models:-Evolutionary model is a combination of Iterative and

Incremental model of software development life cycle.
-They allow to develop more complete versions of the software.
-It is a very suitable model because of user feedback and other factors that make the model
very suitable for the development of complete Software.
-The user feedback is very helpful for the development of the next stage because after the
completion of one stage we get the feedback to the user,
-the user feedback is very essential for the development of the next phase.
- “Iterative” + “Incremental model” = Evolutionary model
-Following are the evolutionary process models./we present two common evolutionary
process models: Prototyping , The Spiral Model.
● The prototyping model
● The spiral model
● Concurrent development model

(Concurrent development model explain cheyandaaa)

● Prototyping Model:-In cases when the requirements are unclear and are likely to
change or when the developer is
doubtful about working of an
algorithm, a solution is to build
a prototype and find out what is
actually needed.
-A quick design is what occurs in a
prototype model.
-The client evaluates the prototype
and gives feedback and other
requirements which are incorporated
in the next prototype.
-This is repeated until the prototype
becomes a complete product that is
acceptable to the client.
-It does not provide more
functionalities. In other words, few functionalities are provided in this first form or
initial product skeleton,

→different phases of Prototyping model are:

➢ Communication:-In this phase, developer and customer meet and discuss the
overall objectives of the software.
➢Quick Design: Detailed plan is not visible rather this phase helps the
developer to work on the prototype,
➢Modelling Quick Design: Software is developed and it gives the developer to
understand the exact requirement.
➢Construction of prototype: Customer evaluates the prototype.
➢ Deployment, delivery, feedback:-If the user is not satisfied with current
prototype then it refines according to the requirements of the user.
-The process of refining the prototype is repeated until all the requirements
of users are met.
-When the users are satisfied with the developed prototype then the system
is developed on the basis of final prototype.

→Advantages of prototyping
➢ Active involvement of the user.
➢ Errors are detected earlier.
➢ Feedback after each prototype helps in understanding the system better.
 ➢ Does not need to know detailed processes, input and output from the
beginning.
→Disadvantages of prototyping
➢ Multiple prototypes can slow down the process.
➢ Frequent changes can increase complexity.
➢ The customer may not be interested or satisfied after evaluating the initial
prototype.
➢ The client involvement is more and it is not always considered by the
developer.
➢ It is a slow process because it takes more time for development.

● Spiral models:- Originally proposed by Barry Boehm,

-In spiral model, the software is developed through a series of increments.
-The diagram looks like a spiral with loops where each loop is a phase. -Each phase is
split into four sectors/quadrant.
-It is a combination of prototype and sequential model or waterfall model.
-This model is also known as risk-driven,

-the software team performs activities that are implied by a circuit around the spiral
in a clockwise direction, beginning at the center.
-each phase in spiral model begins with design goal and ends with client reviewing.
-software is developed in a series of incremental releases.
-it is divided into different task regions.
 ➢ communication:-In this phase, developer and customer meet and discuss
About the software. About the requirement that customer want.
➢ Planning:-nothing but the estimation ,scheduling and risk analysis are come
under the planning.
➢ Modelling:- after planning we have to model.
-in modelling we analysis and design.
➢ Construction:- first write the code and the test the code.
-to identify that the code is correct or not.
-code and test come under the construction phase.
➢ Deployment:- After the project is done .
-in deployment phase deliver of project ,support if any need to the customer
about the project and the feedback from the customer.

→Advantages of spiral model

It reduces high amount of risk.
Recommended for complex projects.
Strong documentation helps in better management.
It is good for large and critical projects.
→Disadvantages of spiral model
Costly and not recommended for small projects.
Looping is a complex process.
Heavy documentation.

#Agile view of process:-The meaning of Agile is swift or versatile.

-The Agile Model is an incremental and iterative process of software development.
-Agile Methods break the product into small incremental builds.
-These builds are provided in iterations.
-Each iteration typically lasts from about one to three weeks.

→Agile principles
-The highest priority is to satisfy the customer.
-deliver a working software in small time span.
-Business individuals and developers should work along daily throughout the project.
Or
-Throughout the project business people and developers work together on daily basis.
-Face to face interaction is the most efficient method of moving information in the
development team.
-Agile process helps in sustainable development.
-From self organizing teams the best architecture, design and requirements are emerged.
-Simplicity is necessary in development.

*Human factors in agile models:-

1. Competency/knowledge/skill:- we must have the specific skills necessary to
understand software and know the technologies involved in a particular projects.
-In addition, individuals would need to be familiar with the processes used.
-You cannot say that a team cannot work in an agile way if it does not know the key
concepts of this process.
-In many companies, the team has all the technical skills, but do not know the
process.
-It can be done through a simple workshop run by someone who already knows the
process.
2. Collaboration:-Working in a team is an important skill.
-It is important for people to cooperate with one another, in order to achieve the
project's goals.
-Even the most senior developers have much to learn fromother colleagues.
3. Focus:-all team members must be focused on one common goal: to deliver the
customer an increment of working software within time.
-The team should focus on continuous improvements, of the process.
-Keep in mind that the team itself needs to pause from time to time to think about
what is right and what can be improved in the work process.
4. Decision making:-the development team should have the freedom to control their
own destiny.
5. Trust and respect:-the team needs to be consistent and trustworthy to make a strong
team.
- Remember that the main objective is to make the team strong.
6. Self-organization:-You must examine at every moment what can be improved in the
process to make it better to the environment.
-Self-organization has technical benefits, but it is very important to improve
collaboration.
7. Fuzzy problem-solving ability:- good software team must be allowed the freedom to
control its own destiny .
- the team gives decision making authority for both technical and project issues.
*Agile Process models:-Agile SDLC model is a combination of iterative and incremental
process models.
--Following are the Agile Process models.
1. Extreme programming
2. Scrum

1. Extreme programming / eXtreme Programming(XP):-Extreme programming

(XP) is one of the most important software development framework of Agile models.
-It is used to improve software quality and responsive to customer requirements.
-It is used when customers are constantly changing demands or requirements, or
when they are not sure about the system's performance.
-The Extreme Programming is commonly used agile process model.
-It uses the concept of object-oriented programming.
-a set of rules and practices that occur within the context of four framework activities
are; / The XP process comprises four framework activities are;
➢ Planning:-Planning starts with
the requirements gathering
which enables XP team to
understand the rules for the
software.
-The customer and developer
work together for the final
requirements.
➢ Design:-The XP design follows
the 'keep it simple' principle.
-A simple design always prefers the more difficult representation.
➢ Coding:-The coding is started after the initial design work is over.
-After the initial design work is done, the team creates a set of unit tests
which can test each situation that should be a part of the release.
-The developer is focused on what must be implemented to pass the test.
-Two people are assigned to create the code. It is an important concept in
coding activity.
➢ Testing:-Validation testing of the system occurs on a daily basis. It gives the XP
team a regular indication of the progress.
-'XP acceptance tests' are known as the customer test.

→Applications of Extreme Programming (XP): Some of the projects that are

suitable to develop using the XP model are given below:
➢ Small projects: XP model is very useful in small projects consisting of small
teams as the face-to-face meeting is easier to achieve.
➢ Projects involving new technology or Research projects: This type of project
face changing requirements rapidly and technical problems. So XP model is
used to complete this type of project.
 2. Scrum:- Scrum is the type of Agile framework.
-Scrum is an agile software development method.
-It includes the framework activities like requirement, analysis, design, evolution and
delivery.
-Scrum uses Iterative process.
-it basically concentrates on how to manage tasks within a team-based development
environment.

→Silent features of Scrum are;

➢ Scrum is light-weighted framework.
➢ Scrum focus self-organization.
➢ Scrum is simple to understand.
➢ Scrum framework help the team to work together.

→Lifecycle of Scrum:

● Sprint:- A Sprint is a time-box of one month or less.

-A new Sprint starts immediately after the completion of the previous Sprint.
● Release:- When the product is completed then it goes to the Release stage.
● Sprint Review:- If the product still have some non-achievable features then it
will be checked in this stage and then the product is passed to the Sprint
Retrospective stage.
● Sprint Retrospective:- In this stage quality or status of the product is checked.
● Product Backlog:- According to the prioritize features the product is
organized.
● Sprint Backlog:- Sprint Backlog is divided into two parts Product assigned
features to sprint and Sprint planning meeting.

→Advantage of using Scrum framework

● Scrum framework is fast moving and money efficient.
● Scrum framework works by dividing the large product into small
sub-products. It’s like a divide and conquer strategy
● In Scrum customer satisfaction is very important.
● Scrum is adaptive in nature because it have short sprint.
 ● As Scrum framework rely on constant feedback therefore the quality of
product increases in less amount of time
→Disadvantage of using Scrum framework:
● Scrum framework do not allow changes into their sprint.
● Scrum framework is not fully described model. If you wanna adopt it you
need to fill in the framework with your own details like Extreme
Programming(XP), Kanban, DSDM.
● It can be difficult for the Scrum to plan, structure and organize a project that
lacks a clear definition.
● The daily Scrum meetings and frequent reviews require substantial resources.

___________________________________________________________________________

Module -2

#Requirements engineering:-The process to gather the software requirements

from client, analyze and document them is known as requirement engineering.
-Requirements engineering is one of the most crucial activity in this creation process.
-Without well-written requirements specifications, developers do not know what to build,
customers do not know what to expect, and there is no way to validate that the built system
satisfies the requirements.
-This process consists of four steps ;

1. Requirements elicitation:- This is also known as gathering of requirements.

-This is the process of gathering information about the needs and expectations of
stakeholders for the software system.
-This step involves interviews, surveys, focus groups, and other techniques to gather
information from stakeholders or customers.
 2. Requirements Analysis:- This step involves analyzing the information gathered in the
requirements elicitation step to identify the high-level goals and objectives of the
software system.
-It also involves identifying any constraints or limitations that may affect the
development of the software system.
3. Requirements Documentation:- This is the end product of requirements elicitation
and analysis.
-The documentation is very important as it will be the foundation for the design of
the software.
-The document is known as software requirements specification(srs).
4. Requirements Review:-The review process is carried out to improve the quality of
the SRS.
-It may also be called as requirements verification.

(stateholders?)

→Advantages of Requirements engineering

-Helps ensure that the software being developed meets the needs and expectations of the
stakeholders or customers.
- identify issues or problems early in the development process and can fix it.
-ensure that the software is developed in a cost-effective and efficient manner.
-Can improve communication and collaboration between the development team and
stakeholders or customers

→DisAdvantages of Requirements engineering

-Can be time-consuming and costly
- difficult to ensure that all stakeholders’ needs and expectations are taken into account.
-challenging to ensure that the requirements are clear, consistent, and complete.
-Changes in requirements can lead to delays and increased costs in the development
process.

*Requirements engineering tasks:-it consists of seven different tasks they are;

1. Inception:-This is the first phase of the requirements analysis process.

-This phase gives an outline of how to get started on a project.
-Inception is a task where the requirement engineering asks a set of questions to
establish a software process.
-In this task, it understands the problem and evaluates with the proper solution.
-Effective communication is very important in this stage.
-Communication and collaboration between the customer and developer.

2. Elicitation:-This is the second phase of the requirements analysis process.

-This phase focuses on gathering the requirements from the stakeholders.
-The requirements are difficult because the following problems occur in elicitation.
● Problem of scope: The customer give the unnecessary technical detail rather
than clarity of the overall system objective. Or The requirements given are of
unnecessary detail, ill-defined, or not possible to implement.
 ● Problem of Understanding: Not having a clear-cut understanding between
the developer and customer when putting out the requirements needed.
-Sometimes the customer might not know what they want or the developer
might misunderstand one requirement for another.
● Problem of volatility: In this problem, the requirements change from time to
time and it is difficult while developing the project.
-It can lead to loss and wastage of resources and time.

3. Elaboration:-This is the third phase of the requirements analysis process.

-This phase is the result of the inception and elicitation phase.
-In the elaboration process, it takes the requirements that have been stated and
gathered in the first two phases and refines them.
-Its main task is developing pure model of software using functions, feature and
constraints of a software.

4. Negotiation:-This is the fourth phase of the requirements analysis process.

-This phase highlights to discussion and exchanging conversation on what is needed
and what is to be eliminated.
- In the negotiation phase, negotiation is between the developer and the customer.
-Consumers are asked to rank their important needs in order and make guesstimates
on the conflicts that may arise in it.
-Risk requirements are taken into consideration and negotiated in a way where the
customer and developer are both satisfied .
-The following are discussed in the negotiation phase:
● Availability of Resources.
● Delivery Time.
● Scope of requirements.
● Project Cost.
● estimations on development.

5. Specification:-This is the fifth phase of the requirements analysis process.

-In the specification phase, the requirements engineer gathers all the requirements
and develops a working model.
-The models used in this phase include ER (Entity Relationship) diagrams, DFD (Data
Flow Diagram), FDD (Function Decomposition Diagrams), and Data Dictionaries.
-A software specification document is submitted to the customer in a language that
he/she will understand, to give a glimpse of the working model.

6. Validation:-This is the sixth phase of the requirements analysis process.

-This phase focuses on checking for errors and debugging. In the validation phase,
the developer scans the specification document and checks for the following:
● All the requirements have been stated and met correctly
● Errors have been debugged and corrected.
● Work product is built according to the standards
-This requirements validation mechanism is known as the formal technical review.
-The review team that works together and validates the requirements include
software engineers, customers, users, and other stakeholders.
 - Everyone in this team takes part in checking the specification by examining for any
errors, missing information, or anything that has to be added or checking for any
unrealistic and problematic errors.

7. Requirements Management:-This is the last phase of the requirements analysis

process.
-In this phase,New requirements emerge and how this new change will affect the
overall system, and how to address and deal with the change.
-Based on this phase, the working model will be analyzed carefully and ready to be
delivered to the customer.

*Types of requirements:-

1. Known requirements:- Stakeholder tells to be implemented.

2. unknown requirements:- forgotten by stakeholder
-not needed right now
-needed only by another stakeholder.
3. undreamt requirements:- stakeholder didn’t think of this due to limited domain
knowledge

→STAKEHOLDER: Who have some direct or indirect influence on the system requirements
- Users who interact with the system.
-All those who are affected by it.

→Functional and Non-functional requirements:-A Known, Unknown or undreamt

requirement may be functional or non-functional.
-Requirements are generally split into two types: FUNCTIONAL and NON-FUNCTIONAL
● Functional requirements:-Functional requirements describe what the
software has to do.
-(bakki net ill nokkikkonam)
● Non-functional requirements:-These are basically the quality constraints that the
system must satisfy according to the project contract.
-they are also called non-behavioral requirements.
-they basically deal with issues like:
✦ Security ✦ Maintainability ✦ Reliability
✦ Scalability ✦Performance ✦ Reusability
✦Flexibility
”note e types of requirement onnu youtube ill nokkikkonam 👆 ”
*Feasibility Study:-is a study to evaluate feasibility of proposed project or system.
-It specifies whether the proposed software project is practically possible or not.
-Whenever we need a software you don’t directly jump in developing the particular
software.
-Instead, we must first analyze certain facts to realize whether the software is worthwhile or
not and this is called the feasibility study.
→Types of Feasibility Study:- there are mainly 5 types they are;
1. Technical Feasibility:-evaluating the technical resources available to the organization.
-it helps organizations to determine whether the technical resources meet its
capacity and weather the technical team is capable of converting the ideas into
working systems.
2. Operational Feasibility:-it is a measure of how well the solution will work in the
organization.
-it also measure how people feel about the system/project.
-there are two aspects to be considered
● Is the problem worth solving.
● How do the end user and management feel about the problem.
3. Economic Feasibility:-It involves a cost /benefits analysis of the project,helping
organizations to determine the viability ,cost,and benefits associated with a project
before financial resources are allocated.
4. Legal Feasibility:-In Legal Feasibility study project is analyzed in legality point of view.
-This includes analyzing barriers of legal implementation of project, data protection
acts or social media laws, project certificate, license, copyright etc.
5. Schedule Feasibility:-Some projects are initiated with specific deadlines.
-It is required to determine if the deadline is desirable or mandatory.
-If the deadline is mandatory then a penalty could be associated with missing such a
deadline.
- If the deadline is desirable then the analyst can propose an alternative schedule.

→Feasibility Study Process :-The below steps are carried out during entire feasibility
analysis.
1. Information assessment 2. Information collection
3. Report writing 4. General information

→Purpose of Feasibility Study:-Feasibility study is so important and it gives a conclusion of

whether to go ahead with proposed project or to stop proposed project.
- Feasibility study helps in identifying risk factors involved in developing.

#Eliciting requirements / Requirements Elicitation:-also called

requirements gathering.
-The goal of requirements elicitation is to ensure that the software development process is
based on a clear and full understanding of the customer needs and requirements.
-Requirements elicitation involves the identification, collection, analysis, and refinement of
the requirements for a software system.
-It is a critical part of the software development life cycle and is typically performed at the
beginning of the project.
-Requirements elicitation involves stakeholders from different areas of the organization,
including business owners, end-users, and technical experts.
-Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development.
-It can be successful only through an effective customer-developer partnership.
-It is needed to know what the users really need.

*Requirements elicitation Methods:-There are a number of requirements elicitation

methods. Few of them are listed below.
1.Interview 2.Brainstorming Sessions
3.Facilitated Application Specification Technique (FAST)
4.Quality Function Deployment (QFD) 5.Use Case Approach

1. Interviews:-This is the most common technique used for requirement elicitation.

-Interview techniques should be used for building strong relationships between
developer and stakeholders.
-In this technique, the interviewer directs the question to stakeholders to obtain
information.
-One to one interview is the most commonly used technique.
-It is impossible to interview every stakeholder, so selected persons from groups are
selected based on their expertise and credibility.
-Interviews maybe be open-ended or structured.
● In open-ended interviews there is no pre-set agenda. Context free questions
may be asked to understand the problem. Or If the interviewer is not having
any particular format or any specific questions, then it’s called an
unstructured interview.
● In structured interview/Closed -ended interview, agenda of fairly open
questions is prepared. Sometimes a proper questionnaire is designed for the
interview. Or If the interviewer has a predefined set of questions
-Open-ended questions are used to provide detailed information. In this interviewer
cannot say Yes or No only.
-Closed questions can be answered in Yes or No form

->Drawbacks of interviews
● Time is required to plan and conduct interviews.
● Commitment is required from all the participants.
● Sometimes training is required to conduct effective interviews.

2. Brainstorming Sessions:-This technique is used to generate new ideas and find a

solution for a specific issue.
-It is a group technique
-It is intended to generate lots of new ideas hence providing a platform to share
views
-A highly trained facilitator is required to handle group bias and group conflicts.
-Every idea is documented so that everyone can see it.
 -This session is generally conducted around the table discussion.
-All participants should be given an equal amount of time to express their ideas.
→Benefits:
● Creative thinking is the result of the brainstorming session.
● Plenty of ideas in a short time.
● Promotes equal participation.
→Drawbacks:
● Participants can be involved in debating ideas.
● There can be multiple duplicate ideas.

3. Facilitated Application Specification Technique (FAST):-A team oriented

Its objective is to approach is developed for needs gathering and is called facilitated application
bridge the
expectation gap – specification Techniques FAST
the difference -This approach supports the creation of a joint team of customers and developers
between what the who work together to understand the expectations and propose of set of
developers think requirements.
they are
supposed to build →guidelines of FAST are given below:
and what ● Arrange a meeting at a neutral site for developers as well as customers.
customers think ● Establishment of the rules for preparation and participation.
they are going to ● Prepare as well as informal agenda that encourages free flow of ideas.
get.
● Appoint a facilitator to manage the meeting. A facilitator may be a developer
or a customer and or an outside expert. Organize a definition flip chart,
mechanism-Board, worksheets and wall stickiest and so on.
● Participants must not criticize or debate.

4. Quality Function Deployment (QFD):-In this technique customer satisfaction is of

prime concern, hence it focus on the criteria that are important to the client.
-The major steps involved in this procedure are –
● Identify all the stakeholders, eg. Users, developers, customers etc
● List out all requirements from customer.
● A value indicating degree of importance is assigned to each requirement.In
the end the final list of requirements is categorized as –
a.It is possible to achieve
b.It should be deferred and the reason for it
c.It is impossible to achieve and should be dropped off

5. Use Case Approach:-This technique combines text and pictures to provide a better
understanding of the requirements.
-The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a
functional view of the system.
-The components of the use case design includes three major things – Actor, Use
cases, use case diagram.
1. Actor:-An actor maybe a person, machine etc. It is represented as a stick
figure. Actors can be primary actors or secondary actors.
● Primary actors – It requires assistance from the system to achieve a
goal.
 ● Secondary actor – It is an actor from which the system needs
assistance.
2. Use cases :-They describe the sequence of interactions between actors and
the system. They capture who(actors) do what(interaction) with the system. A
complete set of use cases specifies all possible ways to use the system.
3. Use case diagram :-A use case diagram graphically represents what happens
when an actor interacts with a system. It captures the functional aspect of the
system.
a. A stick figure is used to represent an actor.
b. An oval is used to represent a use case.
c. A line is used to represent a relationship between an actor and a use
case.

→Advantages of Requirements Elicitation:

-Helps to clarify and refine the customer requirements.
-Improves communication and collaboration between stakeholders.
-Increases the chances of developing a software system that meets the customer needs.
-Avoids misunderstandings and helps to manage expectations.
-Supports the identification of potential risks and problems early in the development cycle.
-Facilitates the development of a comprehensive and accurate project plan.
-Increases user and stakeholder confidence in the software development process.
-Supports the identification of new business opportunities and revenue streams.

→Disadvantages of Requirements Elicitation:

-Can be time-consuming and expensive.
-Requires specialized skills and expertise.
-May be impacted by changing business needs and requirements.
-Can be impacted by political and organizational factors.
-Can result in a lack of buy-in and commitment from stakeholders.
-Can be impacted by conflicting priorities and competing interests.
-May result in incomplete or inaccurate requirements if not properly managed.
-Can lead to increased development costs and decreased efficiency if requirements are not
well-defined.

#Requirement Analysis:Requirements analysis is very important and essential

activity after elicitation.
- refine and scrutinize the gathered requirements in order tomake consistent and
unambiguous requirements.
-This activity reviews all requirements and may provide a graphical view of the entire
system.
-After the completion of the analysis, it is expected that the understandability of the project
may improve significantly.
-Here, we may also use the interaction with the customer to clarify points of confusion and
to understand which requirements are more important than others.
-The various steps of requirement analysis they are;

● Draw the context diagram:- The context diagram is a simple model .

-that defines the boundaries and interfaces of the proposed systems with the
external world.
-It identifies the entities outside the proposed system that interact with the system.
● Development of a Prototype (optional):- One effective way to find out what the
customer wants is to construct a prototype, something that looks and preferably acts
as part of the system they say they want.
-use their feedback to modify the prototype until the customer is satisfied
continuously.
-the prototype helps the client to visualize the proposed system and increase the
understanding of the requirements.
-When developers and users are not sure about some of the elements, a prototype
may help both the parties to take a final decision.
-The prototype should be built quickly and at a relatively low cost.
-Hence it will always have limitations and would not be acceptable in the final
system.
-This is an optional activity.
 ● Model the requirements:- This process usually consists of various graphical
representations of the functions, data entities, external entities, and the
relationships between them.
-The graphical view may help to find incorrect, inconsistent, missing, and superfluous
requirements.
-Such models include the Data Flow diagram, Entity-Relationship diagram, Data
Dictionaries, State-transition diagrams, etc.
● Finalise the requirements:- After modeling the requirements, we will have a better
understanding of the system behavior.
-The inconsistencies and ambiguities have been identified and corrected.
-Now we finalize the analyzed requirements, and the next step is to document these
requirements in a prescribed format.

*Data flow diagrams (DFD):-Data flow diagrams (DFD) are used widely for modeling the
requirements.
-DFDs show the flow of data through a system.
or
-The flow of data of a system or a process is represented by DFD.
-The system may be a company, an organization, a set of procedures, a computer hardware
system, a software system, or any combination of the preceding.
-A neat and clear DFD can depict the right amount of the system requirement graphically.
-It shows how data enters and leaves the system, what changes the information, and where
data is stored.
-The DFD is also known as a data flow graph or a bubble chart.
- DFD does not have control flow and no loops or decision rules are present.

→The following observations about DFDs are important they are;

1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the
order of events; arrows in DFD represents flowing data.

→Standard symbols for DFDs are;

 or

● Circle: A circle (bubble) shows a process that transforms data inputs into data
outputs. Or It represents as a process that gives us information. It is also called
processing box.
● Data Flow: A curved line shows the flow of data into or out of a process or data
store.
● Data Store: A set of parallel lines shows a place for the collection of data items. A
data store indicates that the data is stored which can be used at a later stage or by
the other processes in a different order. The data store can have an element or group
of elements.
● Source or Sink: Source or Sink is an external entity and acts as a source of system
inputs or sink of system outputs.

→Levels in Data Flow Diagrams:-Levels in DFD are numbered 0, 1, 2 or beyond.

-Here, we will see primarily three levels in the data flow diagram, which are:
● 0-level DFD
● 1-level DFD
● 2-level DFD.

1. 0-level DFD:- It is also known as fundamental system model, or context diagram

represents the entire software requirement as a single bubble with input and output
data denoted by incoming and outgoing arrows.
-It’s a basic overview of the whole system or process being analyzed or modeled.
-It represents the entire system as a single bubble with input and output data
indicated by incoming/outgoing arrows.
-t should be easily understood by a wide audience, including stakeholders, business
analysts, data analysts and developers.

-The Level-0 DFD of a railway reservation system is shown below

2. 1-level DFD:-DFD Level 1 provides a more detailed breakout of pieces of the Context
Level Diagram.
-it highlight the main functions carried out by the system, as it break down the
high-level process of the Context Diagram into its subprocesses.
0r
-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.

3. 2-level DFD:-DFD Level 2 then goes one step deeper into parts of Level 1.
-It can be used to plan or record the specific/necessary detail about the system’s
functioning.

→Disadvantages of DFD
● At times DFD can confuse the programmers regarding the system.
● Data Flow Diagram takes long time to be generated, and many times due to this
reasons analysts are denied permission to work on it.
*Data Dictionary:-A data dictionary is a file or a set of files that includes a database's
metadata.
-The data dictionary hold records about other objects in the database, such as data
ownership, data relationships to other objects, and other data.
-The data dictionary is very important as it contains information such as what is in the
database, who is allowed to access it, where is the database physically stored etc.
-The data dictionary is an essential component of any relational database., because of its
importance, it is invisible to most database users. ,Typically, only database administrators
interact with the data dictionary.
or
-The users of the database normally don't interact with the data dictionary, it is only handled
by the database administrators.
-The data dictionary contains the following information they are;
● Name of the item: It can be your choice.
● Aliases: It represents another name.
● Description: Description of what the actual text is all about.
● Related data items: with other data items.
● Range of values: It will represent all possible answers.

→Data Dictionary Notations tables :-The Notations used within the data dictionary are
given in the table below.

Notations Meaning
X = a+b X consists of data elements a and b.
X = [a/b] X consists of either elements a or b.
X=aX X consists of optimal data elements a.
X = y[a] X consists of y or more events of data element a
X = [a] z X consists of z or less events of data element a
X = y [a] z X consists of some events of data elements between y and z.

→Uses of Data Dictionary:-Used for creating the ordered list of data items
-Used for creating the ordered list of a subset of the data items
-Used for Designing and testing software in Software Engineering
-Used for finding data items from a description in Software Engineering
or
*ER diagrams:-ER-modeling is a data modeling method used in software engineering to
produce a conceptual data model of an information system. -Diagrams created using this
ER-modeling method are called Entity-Relationship Diagrams or ER diagrams or ERDs.
-An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities”
such as people, objects or concepts relate to each other within a system.
-ER diagrams are created based on three basic concepts: entities, attributes and
relationships.
-components of er model are:-
● entities:- rectangles to represent entities,
● attributes :-ovals to define attributes
● relationships:-diamond shapes to represent relationships.
or

1. Entity:-An entity can be a real-world object,

- An entity is denoted as a rectangle in an ER diagram.
- For example, in a school database, students, teachers, classes, and courses offered can be
treated as entities.
-All these entities have some attributes or properties that give them their identity.

→Entity Set:-An entity set is a collection of related types of entities.

-An entity set may include entities with attribute sharing similar values.
-For example, a Student set may contain all the students of a school; likewise, a Teacher set
may include all the teachers of a school from all faculties.
- Entity set need not be disjoint.

-or
2. Attributes:-Attributes are the properties that define the entity type.
-For example, Roll_No, Name, DOB, Age, Address, Mobile_No are the attributes that define
entity type Student.
-In ER diagram, the attribute is represented by an oval.

→There are the types of Attributes:-

● Key attribute:-Key is an attribute or collection of attributes that uniquely identifies
an entity among the entity set.
-For example, the roll_number of a student makes him identifiable among students.
-in ER diagram, key attribute is represented by an oval with underlying lines.

-There are mainly three types of keys:

➢ Super key: A set of attributes that collectively identifies an
entity in the entity set.
➢ Candidate key: A minimal super key is known as a candidate key. An entity set
may have more than one candidate key.
➢ Primary key: A primary key is one of the candidate keys chosen by the
database designer to uniquely identify the entity set.

● Composite attribute:-An attribute composed of many other attribute is called as

composite attribute.
-For example, Address attribute of student Entity type consists of Street, City, State,
and Country.
- In ER diagram, composite attribute is represented by an oval comprising of ovals.

● Single-valued attribute:- Single-valued attribute contain a single value. For example,

Social_Security_Number.
 ● Multi-valued attribute:-An attribute consisting 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.

● 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. Relationships:-The association among entities is known as relationship.

-Relationships are represented by the diamond-shaped box.
→relationship set:-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 is enrolled in C1, and S3 is
enrolled in C3.

→Degree of a relationship set:-The number of different entity sets participating in a

relationship set is called as the degree of a relationship set.

➢ Unary Relationship(degree1):-When there is only ONE entity set participating in a

relation, the relationship is called a unary relationship.
-For example, one person is married to only one person.

➢ Binary Relationship (degree2):-When there are TWO entities set participating in a

relationship, the relationship is called a binary relationship.
-For example, a Student is enrolled in a Course. Or For example, the Teacher teaches
the subject.

➢ Ternary Relationship (degree3):-It is a relationship amongst instances of three entity

types. In fig, the relationships "may have" provide the association of three entities,
i.e., TEACHER, STUDENT, and SUBJECT. All three entities are many-to-many
participants. There may be one or many participants in a ternary relationship.
→Cardinality:-The 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 a male can marry one female and a female can marry one male.
So the relationship will be one-to-one.

2. 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 a student can take only one course but one course can be taken
by many students. So the cardinality will be n to 1.

3. 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 a student can take more than one course and one course can be
taken by many students.
-So the relationship will be many to many.

4. Many to One: More than one entity from entity set A can be associated with at most
one entity of entity set B, however an entity from entity set B can be associated with
more than one entity from entity set A.
-For example - many students can study in a single college, but a student cannot
study in many colleges at the same time.
*prototyping:-It is a technique of constructing a partial implementation of a system so
that customers,developers or users can learn more about a problem or solution.
-Two Approaches:
1. Throwaway Prototyping:-As its name suggests, a throwaway prototype is ‘thrown
out’ once the product design is finalised.
-Also known as rapid prototyping,
-It is quickly developed to show how the requirement will look visually.
-Once the client and the developer have understood the initial requirements with the
help of the prototype and know what to expect in the final product,
-this prototype is either partially re- used or discarded completely.
-Thus, throwaway prototyping is fast and low-effort

2. Evolutionary Prototyping:-Evolutionary prototyping is a software development

method where the developer or development team first constructs a prototype.
-After receiving initial feedback from the customer, subsequent prototypes are
produced, each with additional functionality or improvements, until the final product
emerges.
-that evolutionary prototyping is similar to incremental development
”more details inu net ill nokkikkonam”

# Requirement documentation and review

*Requirement documentation:-Requirements documentation is a very important

activity after requirements elicitation and analysis.
- Requirements document is called Software Requirement Specification(SRS).
-requirements document (also known as software requirements specifications) is a
document that describes the intended use-case, features, and challenges of a software
application.
-Software requirements are written up by the tech team depending on the project they are
working on.
- requirement documents provide an important map of the product being built, the features
that will be included, and much more.
-It helps to ensure that the product is built meeting the needs whether it’s for internal
purposes, for users or clients.

*Nature of SRS:-The SRS is a specification that a particular software product, program

need.
-It serves a number of purposes depending on who is writing it.
-First, the SRS could be written by the customer of the system.
-Second, SRS could be written by developer of the system.
-In first case, SRS is used to define the needs and expectations of the users.
-The second case, SRS is written for different purpose and serve as a contract document
between customer and developer.
-A Software Requirements Specification (SRS) is a complete description of the behaviour of
the system to be developed.
→The SRS should address following issues they are;
● functionality:-What the software is supposed to do?
● External Interfaces: How does the software interact with people, system's hardware,
other hardware and other software?
● Performance: What is the speed, availability, response time, recovery time etc.
● Attributes: What are the considerations for portability, correctness, maintainability,
security, reliability etc.
● Design Constraints Imposed on an Implementation: Are there any required
standards in effect, implementation language, policies for database integrity,
resource limits, operating environment etc.
→SRS writer should be careful for following points they are;
● SRS should correctly define all the software requirements. A software requirement
may exist because of the nature of the task to be solved or because of a specific
characteristic of the project.
● SRS should not describe any design or implementation details. These should be
described in the design stage of the project.
● SRS should not impose additional constraints on the software. These are properly
specified in other documents such as software quality assurance plan.
-Therefore, a properly written SRS limits the range of valid designs but does not specify any
particular design.
”note ethu fullum nature of SRS ina akathu varunnathannu”

* Characteristics of good SRS:-Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in
the SRS.
-SRS is said to be perfect if it covers all the needs that are truly expected from the
system.
-There are no real tools or procedures that ensure correctness.
-If the software must respond to all button presses within 5 seconds and the SRS
stated that “the software shall respond to all button presses within 10 seconds”, then
that requirement is incorrect.
2. Completeness: -software system will perform each and every functions as per the
SRS
-and it should contain all the features requested by a client.
-It is one of the most difficult properties to spot.
3. Consistency:-Requirements in SRS are said to be consistent if there are no conflicts
between any set of requirements.
-Examples of conflict include differences in terminologies used at separate places,
logical conflicts like time period of report generation, etc.
4. Unambiguousness:-A SRS is said to be unambiguous if all the requirements stated
have only 1 interpretation.
-Some of the ways to prevent unambiguousness include the use of modelling
techniques like ER diagrams, proper reviews and buddy checks, etc.
 5. Ranking for importance and stability:-There should be a criteria to classify the
requirements as less or more important or more specifically as desirable or essential.
-An identifier mark can be used with every requirement to indicate its rank or
stability.
6. Modifiability:-SRS should be made as modifiable as possible and should be capable
of easily accepting changes to the system to some extent.
-Modifications should be properly 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:- has unique identity ,cannot be broken into parts
-google ill nokkanam

*Organization of an SRS-IEEE standard format for SRS

-The Institute of Electrical and Electronics Engineers (IEEE) has published guidelines and
standards to organize an SRS document.
-Different projects may require their requirements to be organized differently, that is, there
is no one method that is suitable for all projects.
- It provides different ways of structuring the SRS.
-The first two sections of the SRS are the same in all of them.
-The specific tailoring occurs in section 3 entitled"specific requirements".
-The general organization of an SRS is given below.

1. Introduction:-
2. The Overall Description
3. Specific Requirements
4. Change Management Process
5. Document Approvals
6. Supporting Information

1. Introduction
1.1 Purpose:-describe purpose of the SRS
1.2 Scope:-
1.3 Definitions, Acronyms, and Abbreviations:-
1.4 References:-
1.5 Overview:-
2. The Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies.
2.6 Apportioning of Requirements
3. 3. Specific Requirements
 3.1 External interfaces
3.2 Functions
3.3 Performance Requirements
3.4 Logical Database Requirements
3.6 Design Constraints

3.7 Software System Attributes

3.7 Organizing the Specific Requirements
3.8 Additional Comments
4. Change Management Process
5. Document Approvals
6. Supporting Information
Note net ill nokkikkonam - basic matram explain cheythal mathii

*requirements review process:-Requirement review holds greater importance role in

software development.
-A requirements review is a manual process that involves people from both client and
developer side.
-They check the requirements document for errors and eliminate them.
-The review process may be managed in the same way as program inspections.
-Alternatively, it may be organized as a broader activity with different people checking
different parts of the document.
-The purpose of a requirements review is to ensure that:

● The product will meet the needs of the customer

● All stakeholders understand what is required
● The product can be built within the given constraints
● There are no conflict or gaps in the requirements.
-bakki mukalii undee.

___________________________________________________________________________

Module-3

#Software Design:-Software design is a mechanism to transform user requirements

into some suitable form, which helps the programmer in software coding and
implementation.
-The software design phase is the first step in SDLC (Software Design Life Cycle), which
moves the concentration from the problem domain to the solution domain.

*conceptual and technical design:-To transform requirements into a working system

designers must satisfy both customers and the system builders.
-The customers should understand what the system try to do .
-at the same time the system builders must understand how to do.
-To accomplish these design is divided into two parts they are;
-A software design has two parts
1. Conceptual design or preliminary design.
2. Technical design or detailed design.

1.Conceptual design:-First the conceptual design

is produced that tells the customer exactly what
the system will do.
-Conceptual design is an initial/starting phase.
-It tells the customers that what actually the
system will do
-Conceptual design is a key parameter in
designing a good quality product.
-Common methods used for conceptual designs
are-
• Wireframes
• Mockups & Flow chart

2.Technical design:-A Technical design is a phase in which the event team writes the code
and describes the minute detail of either the whole design or some parts of it.
-It tells the designers that what actually the system will do.
-Common methods of technical designs are-
• Class Diagrams • Activity diagram
• Sequence diagram • State Diagram

→Difference between conceptual design and technical design

Conceptual Design Technical Design

It describes that what will happen to the It describes the functions or methods of the
data in the system. system.

Mukaliithathum diff ill ezhutham

*design objectives:-Following are the purposes of Software design:

1. Correctness:Software design should be correct as per requirement.
Or
-A good design should be correct i.e.
-it should correctly implement all the functionalities of the system.
2. Completeness:The design should have all components like data structures, modules,
and external interfaces, etc.
3. Efficiency:Resources should be used efficiently by the program.
Or
-A good software design should address the resources, time, and cost optimization
issues.
4. Flexibility:Able to modify on changing needs.
5. Consistency:There should not be any inconsistency in the design.
 6. Maintainability: The design should
be so simple so that it can be
easily maintainable by other
designers.

*importance of design:-Software design

is basically a mechanism of preparing a plan
, a layout for structuring the code of your
software application.

-Following are some points that make software design so important:

● Modularity,:- the first concept of software design it is.
-It means cleaving your huge software project into small modules.
- It simply means splitting the software project into small pieces, small tasks called
modules for the simplicity of work.
-Splitting your critical software project into modules only makes it easier to work on
every requirement of the project.
-It also gives the convenience of making changes in the future.
- If in case, the requirement of your client changes, then you can anytime go for
restructuring a module, not the whole project.
-It gives you the ease of finding errors in the modules
● Maintainability:-As software design is performed by creating modules, it makes the
task easier to maintain.
-Tasks like finding bugs, debugging, restructuring, and changing the functionality of
specific elements in the software application become quite easy due to software
design.
-For example; in case you have already completed the creation of a software
application, but now you need a change in its interface then you can just make
changes in the module that relates to the interface, you need not mess up with any
other module.
-This is how software design helps in the maintenance of your software application.
● flexible:-Better designed software is more Flexible. So, you can add a new
component to the existing software without affecting the existing software.
● Reusability:-Well-designed software increases Reusability. Because if you follow
design patterns strictly, your software would be more modular ie. consisting of small
components that do only one task. So, these small components can be reused easily.
● Easy to understand:- It has been always a headache to explain projects to new
hires/team members. But if you have good design & documentation, you can easily
communicate the idea of the software to your new team member.
● Cost-efficiency is increased. You might be thinking how can designing can affect the
cost of the software.
-To understand this, consider a situation in which you and your team started building
software based on some assumptions, but after developing 50% of the software, you
realize that you’ve met a dead-end and you can’t go ahead with those assumptions.
-Now, you’ll have to start the software again which would definitely be very costly.
-So, if you’ve focused on the design first, you could have figured out the dead-end
earlier and saved a lot of time, work-force and money.
#Modularity:-The module simply means the software components that are been
created by dividing the software.
-The software is divided into various components that work together to form a single
functioning item but sometimes they can perform as a complete function if not connected
with each other.
-This process of creating software modules is known as Modularity in software engineering.
-Some of the projects or software designs are very complex that it’s not easy to understand
its working and functioning.
-In such cases, modularity is a key weapon that helps in reducing the complexity of such
software or projects.

*module coupling:-the coupling is the degree of interdependence between software

modules.
- Two modules that are tightly coupled are strongly dependent on each other.
-However, two modules that are loosely coupled are not dependent on each other.
-Uncoupled modules have no interdependence at all within them.
-The various types of coupling techniques are shown in fig

-coupling simply means to connect two or more things together. It means the pairing of two
things
→Types of Module Coupling
1. Data Coupling: When data of one module is passed to
another module, this is called data coupling.--------------->
2. Control Coupling:-it simply means to control data sharing
Between modules.
- if the modules interact or connects by sharing controlled
data,then they are said to be control coupled.
3. Common coupling:-Two modules are common coupled if they share information
through some global data items.
 4. Content Coupling: Content Coupling exists among two modules if they share code,
e.g., a branch from one module into another module.
5. Stamp Coupling: Two modules are stamp coupled if they communicate using
composite data items such as structure, objects, etc.
-When the module passes non-global data structure or entire structure to another
module, they are said to be stamp coupled.
6. External Coupling: External Coupling arises when two modules share an externally
imposed data format, communication protocols, or device interface.
-This is related to communication to external tools and devices.
-The strength of coupling from lowest coupling (best) to highest coupling(worst).

*module cohesion:-cohesion defines to the degree to which the elements of a module

belong together.
-Thus, cohesion measures the strength of relationships between pieces of functionality
within a given module.
-For example, in highly cohesive systems, functionality is strongly related.
-Cohesion is an ordinal type of measurement and is generally described as "high cohesion"
or "low cohesion."
→Types of Modules Cohesion- 👇
 1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of
a module, cooperate to achieve a single function.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the element
of a module form the components of the sequence, where the output from one
component of the sequence is input to the next.
3. Communicational Cohesion: A module is said to have communicational cohesion, if
all tasks of the module refer to or update the same data structure, e.g., the set of
functions defined on an array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of
purpose of the module are all parts of a procedure in which particular sequence of
steps has to be carried out for achieving a goal, e.g., the algorithm for decoding a
message.
5. Temporal Cohesion: When a module includes functions that are associated by the
fact that all the methods must be executed in the same time, the module is said to
exhibit temporal cohesion.
6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the
module perform a similar operation. For example Error handling, data input and data
output, etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs
a set of tasks that are associated with each other very loosely, if at all.

→Differentiate between Coupling and Cohesion

*relationship between coupling and cohesion:-If the software is not properly

modularized, an apparently unimportant improvement or changes will result into death of
the project.
-Therefore, a software engineer must design the modules with goal of high cohesion and low
coupling.
-A good example of a system that has high cohesion and low coupling is the
‘plug and play’ feature of the computer system.
-Various slots in the mother board of the system simply facilitate to add or remove the
various services/functionalities without affecting the entire system.
-This is because the add on components provide the services in highly cohesive manner.
-provides a graphical review of cohesion and coupling.

-Module design with high cohesion and low coupling characterizes a module as
black box when the entire structure of the system is described.
-Each module can be dealt separately when the module functionality is described.

*Strategy of design:-A good system design is to organize the program modules in such a
way that are easy to develop and change.
-Structured design techniques help developers to deal with the size and complexity of
programs.
-Analysts create instructions for the developers about how code should be written and how
pieces of code should fit together to form a program.
-System design is a critical component of software engineering and involves making
decisions about the architecture, components, modules, interfaces, and data for a software
system.
-There are many strategies or techniques for performing system design. They are:

● Bottom-up approach:-The design starts with the lowest level components and
subsystems.
- By using these components, the next immediate higher-level components and
subsystems are created or composed.
-The process is continued till all the components and subsystems are composed into
a single component, which is considered as the complete system.
-The amount of abstraction grows high as the design moves to more high levels.
 -It can be used to hide the low-level details of implementation and be merged with the
top-down technique.
-High-quality bottom-up solutions are very hard to construct.
-If we get it wrong, then at a higher level, we will find that it is not as per
requirements; then we have to redesign at a lower level.

● Top-down approach:- Each system is divided into several subsystems and

components.
-Each of the subsystems is further divided into a set of subsystems and components.
-This process of division facilitates forming a system hierarchy structure.
-The complete software system is considered a single entity and in relation to the
characteristics, the system is split into sub-systems and components.
-The same is done with each of the sub-systems.
-This process is continued until the lowest level of the system is reached.
-The design is started initially by defining the system as a whole and then keeps on
adding definitions of the subsystems and components.
-When all the definitions are combined together, it turns out to be a complete
system.
-For the solutions of the software that need to be developed from the ground level, a
top-down design best suits the purpose.

● Hybrid Design:-It is a combination of both top-down and bottom-up design

strategies. In this, we can reuse the modules.

→Advantages of using a System Design Strategy:

● Improved quality: A well-designed system can improve the overall quality of the
software, as it provides a clear and organized structure for the software.
● Ease of maintenance: A well-designed system can make it easier to maintain and
update the software, as the design provides a clear and organized structure for the
software.
● Improved efficiency: A well-designed system can make the software more efficient,
as it provides a clear and organized structure for the software that reduces the
complexity of the code.
 ● Better communication: A well-designed system can improve communication
between stakeholders, as it provides a clear and organized structure for the software
that makes it easier for stakeholders to understand and agree on the design of the
software.
● Faster development: A well-designed system can speed up the development process,
as it provides a clear and organized structure for the software that makes it easier for
developers to understand the requirements and implement the software.

→Disadvantages of using a System Design Strategy:

● Time-consuming: Designing a system 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, it can be difficult to make changes to
the design, as the process is often highly structured and documentation-intensive.

*Function oriented design:-Function Oriented design is a method to software design

where the model is decomposed into a set of interacting units or modules where each unit
or module has a clearly defined function.
-Thus, the system is designed from a functional viewpoint.
-Function Oriented Design Strategies are as follows/function-oriented design, the design can
be represented graphically or mathematically by the following:
● Data Flow Diagram:-These diagrams show how data flows through a system and how
the output is derived from the input through a
series of functional transformations.
-Data-flow diagrams are a useful and
intuitive way of describing a system.
-They are generally understandable without
specialized training,
-They show end-to-end processing.
-It uses defined symbols like rectangles, circles
and arrows, plus short text labels, to show data
inputs, outputs, storage points and the routes
between each destination.
-bakki venakkill mukallill undee
● Data Dictionaries:-A data dictionary lists all data
elements appearing in the DFD model of a system.
-The data items listed contain all data flows and the contents of all data stores
looking on the DFDs in the DFD model of a system.
-Data dictionaries are simply repositories to store information about all data items
defined in DFDs.
-At the requirement stage, data dictionaries contains data items.
-Data dictionaries include Name of the item, Aliases (Other names for items),
Description / purpose, Related data items, Range of values, Data structure definition
/ form.
● Structured Charts:-It is the hierarchical representation of system which partitions the
system into black boxes (functionality is known to users but inner details are
unknown).
 -Components are read from top to bottom and left to right.
-When a module calls another, it views the called module as black box, passing
required parameters and receiving results.
● Pseudo-code:-Pseudo Code is system description in short English like phrases
describing the function.
-It use keyword and indentation. Pseudo codes are used as replacement for flow
charts.
-It decreases the amount of documentation required.

*Object oriented design:-in the object-oriented design method, the system is viewed as
a collection of objects (i.e., entities).
-The state is distributed among the objects, and each object handles its state data.
-each object is a member of some class. Classes may inherit features from the superclass.
-An analysis model created using object-oriented analysis is transformed by object-oriented
design into a design model that works as a plan for software creation.
-The different terms related to object design are:
● Objects: All entities involved in the solution design are known as objects. For
example, person, banks, company, and users are considered as objects.
-Every entity has some attributes associated with it and has some methods to
perform on the attributes.
● Classes: A class is a generalized description of an object. An object is an instance of a
class.
- A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.
● Messages: Objects communicate by message passing. Messages consist of the
integrity of the target object, the name of the requested operation, and any other
action needed to perform the function.
-Messages are often implemented as procedure or function calls.
● Abstraction In object-oriented design, complexity is handled using abstraction.
-Abstraction is the removal of the irrelevant and the amplification of the essentials.
● Encapsulation: Encapsulation is also called an information hiding concept.
-The data and operations are linked to a single unit.
-Encapsulation not only bundles essential information of an object together but also
restricts access to the data and methods from the outside world.
● Inheritance: OOD allows similar classes to stack up in a hierarchical manner where
the lower or sub-classes can import, implement, and re-use allowed variables and
functions from their immediate superclasses.
-This property of OOD is called an inheritance.
-This makes it easier to define a specific class and to create generalized classes from
specific ones.
● Polymorphism: OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned the same name.
-This is known as polymorphism, which allows a single interface is performing
functions for different types.
- Depending upon how the service is invoked, the respective portion of the code gets
executed.
*steps to analyze and design object oriented systems (youtube)

___________________________________________________________________________

Module - 4

# Software Testing:-Testing is the process of executing a program to find errors.

-To make our software perform well it should be error-free.
-If testing is done successfully it will remove all the errors from the software.
-The purpose of software testing is to identify errors, gaps or missing requirements.
-Software Testing is Important because if there are any bugs or errors in the software, it can
be identified early and can be solved before delivery of the software product.
-Properly tested software product ensures reliability, security and high performance which
further results in time saving, cost effectiveness and customer satisfaction.
-benefits of using software testing is
● Cost-Effective: It is one of the important advantages of software testing.
-In case if the bugs caught in the earlier stage of software testing, it costs less to fix.
● Security: It is the most vulnerable and sensitive benefit of software testing.
-People are looking for trusted products.
-It helps in removing risks and problems earlier.
● Product quality: It is an essential requirement of any software product.
-Testing ensures a quality product is delivered to customers.
● Customer Satisfaction: The main aim of any product is to give satisfaction to their
customers.

*verification and validation

verification validation

check whether we are developing the right check whether the developed product is
product or not. right.

Verification is also known as static testing. Validation is also known as dynamic testing.

In verification testing, we can find the bugs In the validation testing, we can find those
early in the development phase of the bugs, which are not caught in the
product. verification process.

Verification testing is executed by the Validation testing is executed by the testing

development team team to test the application.

Verification is done before the validation After verification testing, validation testing
testing. takes place.

It is cheaper than validation testing Validation testing is costlier than

 verification testing.

*criteria for completion of testing:-One of the most difficult questions to answer

when testing a program is determining when to stop, since there is no way of knowing if the
error just detected is the last remaining error.
-if errors are not present with in two days of testing then it is the time to end the testing
-otherwise program manager or other superious seed the bug in the program and ask the
tester to find the error.
-and the tester almost find the error or full error means it is the time to end the testing .
-this type of adding bug to the program is called error seeding.
-A check against the test exit criteria is very much essential before we claim that the testing
is completed.
-Before putting an end to test process the product quality is measured against the test
completion criteria.
-If criterion has not met, the test cannot be stopped.
-Any changes to the test completion criterion must be documented and signed off by the
stakeholders.

#Test strategies for conventional software:-There are many strategies that

can be used to test software.
-one way is you can wait until the system is fully constructed and then conduct tests on the
overall system in hopes of finding errors.
-this approach may cause a large error.
-on the other hand you could conduct tests, whenever any part of the system
is constructed.
-This approach can be very effective and error can be find in the early stage.
-there are several type they are;

*Unit testing:-Unit Testing is a type of software testing where individual units or

components of a software are tested.
-The purpose is to validate that each unit of the software code performs as expected.
-Unit Testing is done during the development (coding phase) of an application by the
developers.
-It is the first level of functional testing.
-In a testing level hierarchy, unit testing is the
first level of testing done before integration
and other remaining levels of the testing.
-Unit testing, a testing technique using which
individual modules are tested to determine if
there are any issues by the developer himself.
-it is done by developer.
-algorithm error,mixed,incorrected error are
Corrected by unit testing.
→ support required for unit testing are;
-unit testing need driver and sub software.
-driver is the one which calls the unit, and provides some data to it .
-sub is the one which the units needs to call and uses the result of the other
unit to produce its results.
-assume module a is developed and it goes testing but it requires module b
,which isn’t developed yet.
-so in this case ,we use the sub or drivers that simulates all features and
functionality that might be shown by actual module b.

→Unit Testing Techniques:There are 3 types of Unit Testing Techniques.

They are;
● Black Box Testing: This testing technique is used in covering the unit tests for input,
user interface, and output parts.
● White Box Testing: This technique is used in testing the functional behavior of the
system by giving the input and checking the functionality output including the
internal design structure and code of the modules.
● Gray Box Testing: This technique is used in executing the relevant test cases, test
methods, test functions, and analyzing the code performance for the modules.

→Advantages of Unit Testing:

-it reduces more bug compared to other testing.
-Unit testing uses module approach due to that any part can be tested without waiting for
completion of another parts testing.

*integration testing:-integration testing is the process of testing the interface between

two units or modules.
-It focuses on determining the correctness of the interface.
-The purpose of integration testing is to expose faults in the interaction between integrated
units.
-Once all the modules have been unit tested, integration testing is performed.
-the goal of integration testing is to identify any problems or bugs that arise when different
components are combined and interact with each other.
-Integration testing is typically performed after unit testing and before system testing.
-Integration testing is the second level of the software testing.
→Integration test approaches :-There are four types of integration testing approaches.
Those approaches are ;
● Big-Bang Integration Testing: – It is the simplest integration testing approach, where
all the modules are combined.
- it contain only one step.
- In simple words, all the modules of the system are simply put together and tested.
-This approach is used only for very small systems.
-If an error is found during the integration testing, it is very difficult to locate the
error.
- So, debugging errors is very expensive to fix.
-Big-Bang integration testing is a software testing approach in which all components
or modules of a software application are combined and tested at once.
-it is not Good for long Projects.
● Bottom-Up Integration Testing: – In bottom-up testing, each module at lower levels
is tested with higher modules until all modules are tested.
-In bottom-up testing, no stubs are required only drivers are required.
-In this testing, the complexity that occurs when the system is made up of a large
number of small subsystems.
- This integration testing uses test drivers to drive and pass appropriate data to the
lower level modules.
● Top-Down Integration Testing –-In this
integration testing, testing takes place
from top to bottom.
-First, high-level modules are
tested and then low-level modules.
-Few or no drivers needed And need sub.
-In this, design defects can be found in the early
stages.
● Mixed Integration Testing – A mixed integration
testing is also called sandwiched integration
testing.
-it is a combination of top down and bottom-up
testing approaches.
-In top-down approach, testing can start only after the top-level module have been
coded and unit tested.
- In bottom-up approach, testing can start only after the bottom level modules are
ready.
-in sandwich or mixed approach when the module is completed then we can tested.
-also, stubs and drivers are used in mixed integration testing are low.

→Regression testing:-Each time a new module is added as part of integration testing, the
software changes.
-New data flow paths are established,or new I/O may occur.
-These changes may cause problems the previous working.
-Regression testing is the process of rerunning a portion of tests that have already been run
as part of an integration test strategy to make sure that modifications haven't had any
unexpected side effects.
-if error occur the correct them.
-Regression testing is not conducted in changed part not only it also Regression testing in
the unchanged part also.
-to check both changed and unchanged part working fine or not.

→Smoke testing:-Smoke testing is an integration testing approach that is commonly used

when product software is developed.
-Smoke Testing is a software testing process that determines whether the deployed software
build is stable or not.
-It is a time-saving process. It reduces testing time because testing is done only when the key
features of the application are not working or if the key bugs are not fixed.
-In the smoke testing, we only focus on the positive flow of the application and enter only
valid data, not the invalid data.
-In smoke testing, we verify every build is testable or not.
-the new build is installed, we will perform one round of smoke testing.
- smoke testing is used in the beginning and detect the bugs in the basic features and send it
to the development team so that the development team will have enough time to fix the
bugs.
-We do smoke testing to make sure that the application is installed correctly.
-it is used to determine if a new software build is ready for the next testing phase.
- the term 'smoke testing” originated in the plumbing industry. Plumbers usually would use
smoke to test for leaks and cracks in pipe systems before water follow through pipe.

*validation testing:-it is the process of evaluating a system at the end of development

process to determine whether it satisfies the specified requirement.
-validation testing ensures that the product actually meets the client’s need.
-it begins at the end of integration testing.
-the scenario of validation testing is that the customer is satisfied with the software or not
,this process is validation.
-it is the process to ensure whether the product is developed is right or not.
-the main goal is to check the customer satisfaction.

→validation-testing approach are;

➢ Configuration Review:-An important element of the validation process is a
configuration review.
-the objective of the review is to ensure that all element of the software
configuration have been properly developed.
-it is also called auditing.
➢ Alpha and Beta Testing:-alpha testing is done in front of the environment of the
company and environment of the developer who develop the project.
-the user click something ,its good the developer will notice the reaction that what
the user is thinking and every thing is noting down.
-that the customer like that feature or not, if not like then what is the reason,and
why didn’t like .
-alpha test is exactly opposite to beta testing.
 -in beta testing the product is delivered to the user /friendly user ,in the absence of
developer and the company.
-so the testing report is prepared by the user itself.
-in alpha testing the test report are made by the developer.
-the report contain details of difficulties faced by the user during the product
operation.
-beta testing is not done in the presence of environment of company and not infront
of the developer.

*software testing:- First each unit is tested by unit testing.

-and then combine that unit/module and we again test by integration testing ,it is done by
developer team.
-after success of integration testing we conduct software testing.
-In software testing the whole system is combined and test to find any error occur or not.
-it is basically performed by a testing team.
-types of system testing are; (4 types)
1. Recovery testing:-software fails in variety of way, when ever in such a situation the
recovery is getting back the software in a proper manner or not
-to test e use recovery testing.
-it check whether the system must recover from fault or not.
-fault like current failure, software crash etc.
-fault should not bring down the entire system.
2. Security testing:-it is used to check the security of the software.
-security is the main aspect of a software.
-it check the the software is protected from various of threads .
3. Stress testing:-it determines the behaviour of the software under abnormal
situations.
-we intentionally input the wrong input and check the software behaviour towards
the error .
-it shows the alert message towards the wrong input like we input ph no 12 digits
instead of 10 and it take the value or show the alert message or not.
-or we enter email address without ‘@’ symbol and the system show the alert
message or not etc.
-and also we check how it response to the wrong inputs
4. Performance testing:-it check all the performance related issues.
-like speed for opening a new page.
-how mush is the response time?
-is it giving quick response time or not?
-speed,scalability,stability,reliability of software are checked during the performance
testing.

→acceptance testing:- it is tested by the customer whether to check to accept or reject the
software and it satisfied the requirement or not.
-it is conducted by end user/customer.
Acceptance Testing is a method of
software testing where a system is
tested for acceptability. The major aim of
this test is to evaluate the compliance of
the system with the business
requirements and assess whether it is
acceptable for delivery or not.
#Testing Tactics

*Black box:-Black box testing is a technique of software testing which examines the
functionality of software without peering into its internal structure or coding.
-In this method, tester selects a function and gives input value to examine its functionality,
and checks whether the function is giving expected output or not.
-If the function produces correct output, then it is passed in testing, otherwise failed.
-After completing testing of all functions if there are severe problems, then it is given back to
the development team for correction.
-The black box test is based on the specification of requirements, so it is examined in the
beginning.
-in black box testing we didn't know procedures or steps that under goes.
-we only give input and it gives output we can’t see any
Procedure or internal structure or step in the black box
Testing.
-The testing is done without the internal
knowledge of the products.
-Testers do not require technical knowledge, programming
or IT skills to test black box testing.
-Black-box testing, also called behavioral testing
-There are different techniques involved in Black Box testing they are;

1. Equivalence Partitioning:-Equivalence partitioning is a black-box testing method that

divides the input domain of a program into classes of data from which test cases can
be derived.
-Equivalence partitioning is a technique of software testing in which input data is
divided into partitions of valid and invalid values, and it is mandatory that all
partitions must exhibit the same behaviour.
- Each value of every equal partition must exhibit the same behavior as other.
-The advantage of this approach is, it helps to reduce the time of testing due to a
smaller number of test cases from infinite to finite.
-Equivalence Partitioning Method is also known as Equivalence class partitioning
(ECP)
-eg;Example-1:
Let us consider an example of any college admission process. There is a college that
gives admissions to students based upon their percentage.

Consider percentage field that will accept percentage only between 50 to 90 %, more
and even less than not be accepted, and application will redirect user to an error
page. If percentage entered by user is less than 50 %or more than 90 %, that
equivalence partitioning method will show an invalid percentage. If percentage
entered is between 50 to 90 %, then equivalence partitioning method will show valid
percentage.
 2. Graph-Based Testing Methods: bakki explain cheyandaaa
3. Boundary Value Analysis :-explain cheyandaa
4. Orthogonal Array Testing:-explain cheyandaa.

*White box testing:-It is also known as glass box is testing, structural testing, clear box
testing, open box testing and transparent box testing.
-It tests internal coding and infrastructure of a software focus on checking of predefined
inputs against expected and desired outputs.
-The primary goal of white box testing is to focus on the flow of inputs and outputs through
the software and strengthening the security of the software.
-Developers do white box testing.
-In this, the developer will test every line of the code of the program.
-The developers perform the White-box testing and then send the application or the
software to the testing team, where they will perform the black box testing and verify the
application along with the requirements and identify the bugs and sends it to the developer.
-The developer fixes the bugs and does one round of white box testing and sends it to the
testing team.
-Here, fixing the bugs implies that the bug is deleted, and the particular feature is working
fine on the application.
-White box testing is a software testing technique that involves testing the internal structure
and workings of a software application.
-The tester has access to the source code and uses this knowledge to design test cases that
can verify the correctness of the software at the code level.
-The white box testing contains various tests are;
→White box-Basis path testing
-Basis path testing is a white-box testing technique first proposed by Tom McCabe
[McC76].
-The objective of basis path testing is to define the number of independent paths.
-In software engineering, Basis path testing involves execution of all possible blocks in a
program and achieves maximum path coverage with the least number of test cases.
-It helps to reduce the redundant tests
-Basis path testing helps to determine all
faults lying within a piece of code.
-example
-In the above example, we can see there
are few conditional statements that is
executed depending on what condition it
suffice.
-Here there are 3 paths or condition that
need to be tested to get the output,
● Path 1: 1,2,3,5,6, 7
● Path 2: 1,2,4,5,6, 7
● Path 3: 1, 6, 7

-4 types of Basis path testing

1. Flow Graph Notation:-Before we consider the basis path method, a simple notation
for the representation of control flow, called a flow graph (or program graph) must
be introduced.
-it is a directed graph which represents the control structure of a program or module.
A control flow graph (V, E) has V number of nodes/vertices and E number of edges in
it.
-The notations used while constructing a flow graph are;

*sequence *if *while

*until *case
 →Cyclomatic Complexity – The cyclomatic complexity V(G) is said to be a measure of
the logical complexity of a program. It can be calculated using three different
formulae : V(G) = e - n + 2 or total boundary +1

2. Deriving Test Cases:-

● Using the design or code, draw the corresponding flow graph.
● Determine the cyclomatic complexity of the flow graph.
● Determine a basis set of independent paths.
● Prepare test cases that will force execution of each path in the basis set.
(explanation youtube ill nokkikkonam)

3. Independent Program Paths :-An independent path in the control flow graph is the
one which introduces at least one new edge that has not been traversed before the
path is defined.
-The cyclomatic complexity gives the number of independent paths present in a flow
graph.
-Note that each new path introduces a new edge.
4. Graph Matrices:- ethu onnum explain cheyandaa

Note
-all error/mistakes are note fault
Eg type <= instead of < so it means an error but it is not an fault or it cause an bug
-and all fault/defect/bug are not failure

___________________________________________________________________________

Module-5

#Object Oriented Modeling:-Object-oriented modeling (OOM) is an approach to

modeling an application that is used at the beginning of the software life cycle when using
an object-oriented approach to software development.
-The stages of the software life cycle are usually broken down into abstract descriptions of
the issue, designs, code, testing, and deployment.
-Modeling is done at the beginning of the process.
-Object-oriented modeling is usually done with use cases and abstract definitions of the
most important objects.
-The most common language used to do object-oriented modeling is the Object
Management Group's Unified Modeling Language (UML).
-Object oriented modeling is entirely a new way of thinking about problems.
-Object oriented models are represented
by diagrams. A good model always helps communication among project teams, and to
assure architectural soundness.
-It is important to note that with the increasing complexity of systems, importance of
modeling techniques increases.
-Because of its characteristics Object Oriented Modeling is a suitable modeling technique for
handling a complex system.
-OOM basically is building a model of an application, which includes implementation details
of the system, during design of the system.

*Use Case model :-The Use-case model is defined as a model which is used to show how
users interact with the system in order to solve a problem.
-As such, the use case model defines the user's objective, the interactions between the
system and the user, and the system's behavior required to meet these objectives.
-Various model elements are contained in use-case model, such as actors, use cases, and the
association between them.
-We use a use-case diagram to graphically represent a part of the model in order to make
the communication simpler.
-There are various components of the basic model:
1. Actor:-Usually, actors are people involved with the system defined on the basis of
their roles.
-An actor can be anything such as human or another external system.
-Actors are located outside the system.
2. Use Case:-The use case defines how actors use a system to accomplish a specific
objective.
-The use cases are generally introduced by the user to meet the objectives of the
activities and variants involved in the achievement of the goal.
Or
-A use case is a written description of how users will perform tasks on your website.
-It outlines, from a user's point of view, a system's behavior as it responds to a
request.
-Each use case is represented as a sequence of simple steps, beginning with a user's
goal and ending when that goal is fulfilled.
3. Associations:-Associations are another component of the basic model.
-It is used to define the associations among actors and use cases they contribute in.
-This association is called communicates-association.
→Scenario:-A Scenario is a formal description of the flow of events that occur during the
execution of a use case instance.
-It defines the specific sequence of events between the system and the external actors.
- It is normally described in text and corresponds to the textual representation of the
sequence diagram.

→Basic Use Case Diagram Symbols and Notations:-There are following use-case
diagram symbols and notations:
● System:-With the help of the rectangle, we can draw the boundaries of the system,
which includes use-cases.
-We need to put the actors outside the system's boundaries.

● Use-Case:-With the help of the Ovals, we can draw the use-cases.

-With the verb we have to label the ovals in order to represent the functions of the
system.

● Actors:-Actors mean the system's users.

-If one system is the actor of the other system, then with the actor stereotype, we
have to tag the actor system.

● Relationships:-With the simple line we can represent relationships between an actor

and use cases.
-For relationships between use-case, we use arrows which are labeled either
"extends" or "uses".
-The "extends" relationship shows the alternative options under the specific use
case.
-The "uses" relationship shows that single use-case is required to accomplish a job.
*drawing Use Case Diagrams:-It is essential to analyze the whole system before
starting with drawing a use case diagram, and then the system's functionalities are found.
-And once every single functionality is identified, they are then transformed into the use
cases to be used in the use case diagram.
-After that we will list the actors that will interact with the system.
-The actors are the person or a thing that invokes the functionality of a system.
-Once both the actors and use cases are found, the relation between the actor and use case/
system is checked.
-It identifies the number of times an actor communicates with the system.
-Basically, an actor can interact multiple times with a use case or system at a particular
instance of time.
-Following are some rules that must be followed while drawing a use case diagram:
● A relevant and meaningful name should be assigned to the actor or a use case of a
system.
● The communication of an actor with a use case must be defined in an
understandable way.
● Specified notations to be used as and when required.
● The most important interactions must be expressed among many interactions
between use cases and actors.
● If the use case diagram is large and more complex, then it should be drawn more
generalized.
●
-eg of use case diagram of a ATM bank
→Three common use case formats are;
● Brief - A use case brief is typically one paragraph which summarizes the main success
scenario and at times the main failures.
- It is written during early requirements analysis and only takes a few minutes to
create.
● Casual - A casual use case consists of multiple paragraphs which cover the main
success scenario and alternative success and failure scenarios.
-It is written in a narrative form without the use of numbered steps.
● Fully Dressed - A fully dressed use case describes the main success scenario,
alternative scenarios, and failure scenarios in full detail.
-They typically use numbered steps to aid readability of alternative scenarios that
branch from the main scenario and to clearly convey where a scenario that returns
back to the main flow would continue.

*The system sequence diagram (SSD):-A sequence diagram is a type of interaction

diagram because it describes how—and in what order—a group of objects works together.
-These diagrams are used by software developers and business professionals to understand
requirements for a new system or to document an existing process.
-Sequence Diagrams are time focus and they show the order of the interaction visually by
using the vertical axis of the diagram to represent time what messages are sent and when.
-The sequence diagram represents the flow of messages in the system and is also termed as
an event diagram.
- It helps in envisioning several dynamic scenarios.
-It portrays the communication between any two lifelines as a time-ordered sequence of
events, such that these lifelines took part at the run time.
-In UML, the lifeline is represented by a vertical bar, whereas the message flow is
represented by a vertical dotted line that extends across the bottom of the page.
→Notations of a Sequence Diagram

● Actors: – An actor in a UML diagram represents a type of role where it

interacts with the system and its objects.
-It is important to note here that an actor is always outside the scope of the
system we aim to model using the UML diagram.
-A role played by an entity that interacts with the subject is called as an actor.
-It is out of the scope of the system.
-It represents the role, which involves human users and external hardware
or subjects.

● Lifeline:-An individual participant in the sequence diagram is represented by a

lifeline.
- It is positioned at the top of the diagram.
-So basically each instance in a sequence diagram is represented by a lifeline.
-The standard in UML for naming a lifeline follows the following format –
Instance Name : Class Name
● Messages:-The messages depict the interaction between the objects and are
represented by arrows.
-They are in the sequential order on the lifeline.
-The core of the sequence diagram is formed by messages and lifelines.
-Following are types of messages enlisted below:
1. Call Message: It defines a particular communication between the lifelines of
an interaction, which represents that the target lifeline has invoked an
operation.

2. Return Message: It defines a particular communication between the lifelines

of interaction that represent the flow of information from the receiver of the
corresponding caller message.

3. Self Message: It describes a communication, particularly between the lifelines

of an interaction that represents a message of the same lifeline, has been
invoked.
4. Recursive Message: A self message sent for recursive purpose is called a
recursive message. In other words, it can be said that the recursive message is
a special case of the self message as it represents the recursive calls.

5. Create Message: It describes a communication, particularly between the

lifelines of an interaction describing that the target (lifeline) has been
instantiated.

6. Destroy Message: It describes a communication, particularly between the

lifelines of an interaction that depicts a request to destroy the lifecycle of the
target.

7. Duration Message: It describes a communication particularly between the

lifelines of an interaction, which portrays the time passage of the message
while modeling a system.

8. Lost Message – A Lost message is used to represent a scenario where the

recipient is not known to the system.
It is represented using an arrow directed towards an end point from a lifeline.
 ● Note:-A note is the capability of attaching several remarks to the element.
-It basically carries useful information for the modelers.

example
→A sequence diagram for an emotion based music player

-a sequence diagram for an emotion based music player

-The above sequence diagram depicts the sequence diagram for an emotion based music
player:

● Firstly the application is opened by the user.

● The device then gets access to the web cam.
● The webcam captures the image of the user.
● The device uses algorithms to detect the face and predict the mood.
● It then requests database for dictionary of possible moods.
● The mood is retrieved from the database.
● The mood is displayed to the user.
● The music is requested from the database.
● The playlist is generated and finally shown to the user.

→Benefits of a Sequence Diagram

● Used to understand the detailed functionality of current or future systems.
● Visualise how messages and tasks move between objects or components in a system.
 ● It explores the real-time application.
● It depicts the message flow between the different objects.
● It has easy maintenance.
● It is easy to generate.
● It can easily update as per the new change in the system.

→drawback of a Sequence Diagram

● In the case of too many lifelines, the sequence diagram can get more complex.
● The incorrect result may be produced, if the order of the flow of messages changes.
● Since each sequence needs distinct notations for its representation, it may make the
diagram more complex.
● The type of sequence is decided by the type of message.

# UML Interaction diagrams:-From the term Interaction, it is clear that the

diagram is used to describe some type of interactions among the different elements in the
model.
-It does not manipulate the data associated with the particular communication path.
-Interaction diagrams mostly focus on message passing and how these messages make up
one functionality of a system.
-Interaction diagrams are designed to display how the objects will realize the particular
requirements of a system.
-The critical component in an interaction diagram is lifeline and messages.
-The details of interaction can be shown using several notations such as sequence diagram,
timing diagram, communication/collaboration diagram.
-Interaction diagrams capture the dynamic behavior of any system.
-Following are the different types of interaction diagrams defined in UML:

● Sequence diagram:-The purpose of a sequence diagram in UML is to visualize the

sequence of a message flow in the system.
-The Sequence Diagram in Software Engineering shows the interaction between two
lifelines as a time-ordered sequence of events.
-explanation down ill unde
● Collaboration /communication diagram:-The Collaboration Diagram in UML is also
called a communication diagram.
-The purpose of a collaboration diagram is to emphasize structural aspects of a
system, i.e., how various lifelines in the system connects.

→Purpose of an Interaction Diagram

-To visualize the dynamic behavior of the system.
-To envision the interaction and the message flow in the system.
-To portray the structural aspects of the entities within the system.
-To represent the order of the sequenced interaction in the system.
-To visualize the real-time data and represent the architecture of an object-oriented system.
*Sequence diagram:-A Sequence Diagram simply represent interaction between objects
in a sequential order.
-The purpose of a sequence diagram in UML is to visualize the sequence of a message flow
in the system.
-The sequence diagram shows the interaction between two lifelines as a time-ordered
sequence of events.
-Notations in Sequence Diagram.

*Collaboration /communication diagram:-The second interaction diagram is the

collaboration diagram.
-Collaboration Diagram represent the relationships and interactions among software
objects.
-They are used to understand the object architecture within a system rather than the flow of
a message as in a sequence diagram.
-They are also known as “Communication Diagrams.”
-As per Object-Oriented Programming (OOPs), an object entity has various attributes
associated with it.
-Usually, there are multiple objects present inside an object-oriented system where each
object can be associated with any other object inside the system.
-Collaboration Diagrams are used to explore the architecture of objects inside the system.
-The message flow between the objects can be represented using a collaboration diagram.
-
→difference between sequence and communication diagram,

-Basic sequence diagram notation, Basic communication diagram notation.-youtube

Join for more MCA short note : https://t.me/mgu_mca_shortnote