Lecture notes # 1

Software Engineering | Introduction to Software Engineering

Software is a program or set of programs containing instructions that provide

desired functionality. And Engineering is the process of designing and building
something that serves a particular purpose and finds a cost-effective solution to
problems.
Software Engineering is the process of designing, developing, testing, and
maintaining software. It is a systematic and disciplined approach to software
development that aims to create high-quality, reliable, and maintainable
software. Software engineering includes a variety of techniques, tools, and
methodologies, including requirements analysis, design, testing, and
maintenance.
The software is a collection of integrated programs.
Software subsists of carefully-organized instructions and code written by
developers on any of various particular computer languages.
Computer programs and related documentation such as requirements, design
models and user manuals.
Engineering is the application of scientific and practical knowledge to invent,
design, build, maintain, and improve frameworks, processes, etc.
Software Engineering is an engineering branch related to the evolution of
software product using well-defined scientific principles, techniques, and
procedures. The result of software engineering is an effective and reliable
software product.

Key Principles of Software Engineering

 Modularity: Breaking the software into smaller, reusable components that
can be developed and tested independently.
 Abstraction: Hiding the implementation details of a component and
exposing only the necessary functionality to other parts of the software.
 Encapsulation: Wrapping up the data and functions of an object into a
single unit, and protecting the internal state of an object from external
modifications.
 Reusability: Creating components that can be used in multiple projects,
which can save time and resources.
 Maintenance: Regularly updating and improving the software to fix bugs,
add new features, and address security vulnerabilities.
 Testing: Verifying that the software meets its requirements and is free of
bugs.
 Design Patterns: Solving recurring problems in software design by
providing templates for solving them.
 Agile methodologies: Using iterative and incremental development
processes that focus on customer satisfaction, rapid delivery, and flexibility.
 Continuous Integration & Deployment: Continuously integrating the code
changes and deploying them into the production environment.
Software engineering is a rapidly evolving field, and new tools and technologies
are constantly being developed to improve the software development process.
By following the principles of software engineering and using the appropriate
tools and methodologies, software developers can create high-quality, reliable,
and maintainable software that meets the needs of its users.
Software Engineering is mainly used for large projects based on software
systems rather than single programs or applications. The main goal of Software
Engineering is to develop software applications for improving quality, budget,
and time efficiency. Software Engineering ensures that the software that has to
be built should be consistent, correct, also on budget, on time, and within the
required requirements.
Main Attributes of Software Engineering
Software Engineering is a systematic, disciplined, quantifiable study and
approach to the design, development, operation, and maintenance of a software
 system. There are Four main Attributes of Software Engineering.
 Efficiency
 Reliability
 Robustness
 Maintainability
Dual Role of Software
There is a dual role of software in the industry. The first one is as a product and
the other one is as a vehicle for delivering the product. We will discuss both of
them.
1. As a product
 It delivers computing potential across networks of Hardware.
 It enables the Hardware to deliver the expected functionality.
 It acts as an information transformer because it produces, manages, acquires,
modifies, displays, or transmits information.
2. As a vehicle for delivering a product
 It provides system functionality (e.g., payroll system)
 It controls other software (e.g., an operating system)
 It helps build other software (e.g., software tools)
Objectives of Software Engineering
 Maintainability: It should be feasible for the software to evolve to meet
changing requirements.
 Efficiency: The software should not make wasteful use of computing
devices such as memory, processor cycles, etc.
 Correctness: A software product is correct if the different requirements
specified in the SRS Document have been correctly implemented.
 Reusability: A software product has good reusability if the different
modules of the product can easily be reused to develop new products.
 Testability: Here software facilitates both the establishment of test criteria
and the evaluation of the software with respect to those criteria.
 Reliability: It is an attribute of software quality. The extent to which a
program can be expected to perform its desired function, over an arbitrary
time period.
 Portability: In this case, the software can be transferred from one computer
system or environment to another.
 Adaptability: In this case, the software allows differing system constraints
and the user needs to be satisfied by making changes to the software.
 Interoperability: Capability of 2 or more functional units to process data
cooperatively.
Program vs Software Product
Program Software Product

Software is when a program is made available

A program is a set of
for commercial business and is properly
instructions that are given
documented along with its licensing.
to a computer in order to
Software Product = Program + Documentation +
achieve a specific task.
Licensing.

Software Development usually follows a life

Program is one of the stages
cycle, which involves the feasibility study of
involved in the
the project, requirement gathering,
development of the
development of a prototype, system design,
software.
coding, and testing.

Advantages of Software Engineering

There are several advantages to using a systematic and disciplined approach to
software development, such as:
 Improved Quality: By following established software engineering
principles and techniques, the software can be developed with fewer bugs
and higher reliability.
 Increased Productivity: Using modern tools and methodologies can
streamline the development process, allowing developers to be more
productive and complete projects faster.
 Better Maintainability: Software that is designed and developed using
sound software engineering practices is easier to maintain and update over
time.
 Reduced Costs: By identifying and addressing potential problems early in
the development process, software engineering can help to reduce the cost of
fixing bugs and adding new features later on.
 Increased Customer Satisfaction: By involving customers in the
development process and developing software that meets their needs,
software engineering can help to increase customer satisfaction.
 Better Team Collaboration: By using Agile methodologies and continuous
integration, software engineering allows for better collaboration among
development teams.
 Better Scalability: By designing software with scalability in mind, software
engineering can help to ensure that software can handle an increasing
number of users and transactions.
 Better Security: By following the Software Development Life Cycle
 (SDLC) and performing security testing, software engineering can help to
prevent security breaches and protect sensitive data.
In summary, software engineering offers a structured and efficient approach to
software development, which can lead to higher-quality software that is easier
to maintain and adapt to changing requirements. This can help to improve
customer satisfaction and reduce costs, while also promoting better
collaboration among development teams.
Disadvantages of Software Engineering
While Software Engineering offers many advantages, there are also some
potential disadvantages to consider:
 High upfront costs: Implementing a systematic and disciplined approach
to software development can be resource-intensive and require a significant
investment in tools and training.
 Limited flexibility: Following established software engineering principles
and methodologies can be rigid and may limit the ability to quickly adapt to
changing requirements.
 Bureaucratic: Software Engineering can create an environment that is
bureaucratic, with a lot of processes and paperwork, which may slow down
the development process.
 Complexity: With the increase in the number of tools and methodologies,
software engineering can be complex and difficult to navigate.
 Limited creativity: The focus on structure and process can stifle creativity
and innovation among developers.
 High learning curve: The development process can be complex, and it
requires a lot of learning and training, which can be challenging for new
developers.
 High dependence on tools: Software engineering heavily depends on the
tools, and if the tools are not properly configured or are not compatible with
the software, it can cause issues.
 High maintenance: The software engineering process requires regular
maintenance to ensure that the software is running efficiently, which can be
costly and time-consuming.

Software Engineering is the process of developing a software product in a

well-defined systematic approach software engineering is the process of
analyzing user needs and then designing, constructing, and testing end-user
applications that will satisfy these needs through the use of software
programming languages.

The software should be produced at a reasonable cost, in a reasonable time,

 and should be of good quality. these three parameters often drive and define
a software project.
1. Cost: As the main cost of producing software is the manpower employed,
the cost of developing software is generally measured in terms of person-
months of effort spent in development. The productivity in the software
industry for writing fresh code generally ranges from a few hundred to about
1000 + LOC per person per month.
2. Schedule: The schedule is another important factor in many projects.
Business trends are dictating that the time to market a product should be
reduced; that is, the cycle time from concept to delivery should be small. this
means that software needs to be developed faster and within the specified
time.
3. Quality: Quality is one of the main mantras, and business strategies are
designed around it. Developing high-quality software is another fundamental
goal of software engineering.
4. Attributes of Software

The international standard on software product quality suggests that software

quality comprises six main attributes:
 Reliability: The capability to provide failure-free service.
 Functionality: The capability to provide functions that meet stated and
implied needs when the software is used.
 Usability: The capability to be understood, learned, and used.
 Efficiency: The capability to provide appropriate performance relative to the
amount of resources used.
 Maintainability: the capability to be modified for purposes of making
corrections, improvements, or adaptations.
 Portability: The capability to be adapted for different specified
environments without applying actions or means other than those provided
for this purpose in the product.

Classification of Software
The software can be classified based on various criteria, including:
 Purpose: Software can be classified as system software (e.g. operating
systems, device drivers) or application software (e.g. word processors,
games).
 Platform: Software can be classified as native software (designed for a
specific operating system) or cross-platform software (designed to run on
multiple operating systems).
 Deployment: Software can be classified as installed software (installed on
 the user’s device) or cloud-based software (hosted on remote servers and
accessed via the internet).
 License: Software can be classified as proprietary software (owned by a
single entity) or open-source software (available for free with the source
code accessible to the public).
 Development Model: Software can be classified as traditional software
(developed using a waterfall model) or agile software (developed using an
iterative and adaptive approach).
 Size: Software can be classified as small-scale software (designed for a
single user or small group) or enterprise software (designed for large
organizations).
 User Interface: Software can be classified as Graphical User Interface
(GUI) software or Command-Line Interface (CLI) software.
These classifications are important for understanding the characteristics and
limitations of different types of software, and for selecting the best software
for a particular need.
Types of Software
The software is used extensively in several domains including hospitals, banks,
schools, defense, finance, stock markets, and so on. It can be categorized
into different types:
 Based on Application
 Based on Copyright
Based on Application
The software can be classified on the basis of the application. These are to be
done on this basis.
1. System Software
System Software is necessary to manage computer resources and support the
execution of application programs. Software like operating systems,
compilers, editors and drivers, etc., come under this category. A computer
cannot function without the presence of these. Operating systems are needed
to link the machine-dependent needs of a program with the capabilities of
the machine on which it runs. Compilers translate programs from high-level
language to machine language.
2. Application Software
Application software is designed to fulfill the user’s requirement by interacting
with the user directly. It could be classified into two major categories:-
generic or customized. Generic Software is software that is open to all and
behaves the same for all of its users. Its function is limited and not
customized as per the user’s changing requirements. However, on the other
hand, Customized software is the software products designed per the client’s
 requirement, and are not available for all.
3. Networking and Web Applications Software
Networking 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.
4. Embedded Software
This type of software is embedded into the hardware normally in the Read-
Only Memory (ROM) as a part of a large system and is used to support
certain functionality under the control conditions. Examples are software
used in instrumentation and control applications like washing machines,
satellites, microwaves, etc.
5. Reservation Software
A Reservation system is primarily used to store and retrieve information and
perform transactions related to air travel, car rental, hotels, or other
activities. They also provide access to bus and railway reservations, although
these are not always integrated with the main system. These are also used to
relay computerized information for users in the hotel industry, making a
reservation and ensuring that the hotel is not overbooked.
6. 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.
7. 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.
8. 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.
9. Scientific Software
Scientific and engineering software satisfies the needs of a scientific or
engineering user to perform enterprise-specific tasks. Such software is
written for specific applications using principles, techniques, and formulae
particular to that field. Examples are software like MATLAB, AUTOCAD,
 PSPICE, ORCAD, etc.
10. Utility Software
The programs coming under this category perform specific tasks and are
different from other software in terms of size, cost, and complexity.
Examples are anti-virus software, voice recognition software, compression
programs, etc.
11. Document Management Software
Document Management Software is used to track, manage, and store
documents to reduce the paperwork. Such systems are capable of keeping a
record of the various versions created and modified by different users
(history tracking). They commonly provide storage, versioning, metadata,
security, as well as indexing and retrieval capabilities.
Based on Copyright
Classification of Software can be done based on copyright. These are stated as
follows:
1. Commercial Software
It represents the majority of software that we purchase from software
companies, commercial computer stores, etc. In this case, when a user buys
software, they acquire a license key to use it. Users are not allowed to make
copies of the software. The company owns the copyright of the program.
2. Shareware Software
Shareware software is also covered under copyright but the purchasers are
allowed to make and distribute copies with the condition that after testing
the software, if the purchaser adopts it for use, then they must pay for it. In
both of the above types of software, changes to the software are not
allowed.
3. Freeware Software
In general, according to freeware software licenses, copies of the software can
be made both for archival and distribution purposes but here, distribution
cannot be for making a profit. Derivative works and modifications to the
software are allowed and encouraged. Decompiling of the program code is
also allowed without the explicit permission of the copyright holder.
4. Public Domain Software
In the case of public domain software, the original copyright holder explicitly
relinquishes all rights to the software. Hence software copies can be made
both for archival and distribution purposes with no restrictions on
distribution. Modifications to the software and reverse engineering are also
allowed.

What is SDLC?
SDLC stands for software development life cycle. It is a process followed for
software building within a software organization. SDLC consists of a precise
plan that describes how to develop, maintain, replace, and enhance specific
software. The life cycle defines a method for improving the quality of software
and the all-around development process.

What is the need for SDLC?

SDLC is a method, approach, or process that is followed by a software
development organization while developing any software. SDLC models were
introduced to follow a disciplined and systematic method while designing
software. With the software development life cycle, the process of software
design is divided into small parts, which makes the problem more
understandable and easier to solve. SDLC comprises a detailed description or
step-by-step plan for designing, developing, testing, and maintaining the
software.

Stages of the Software Development Life Cycle Model

SDLC specifies the task(s) to be performed at various stages by a software

engineer or developer. It ensures that the end product is able to meet the
customer’s expectations and fits within the overall budget. Hence, it’s vital for
a software developer to have prior knowledge of this software development
process.
The SDLC model involves six phases or stages while developing any software.
SDLC is a collection of these six stages, and the stages of SDLC are as
follows:
Stages of Software Development Life Cycle Model

Stage-1: Planning and Requirement Analysis

Planning is a crucial step in everything, just as in software development. In this
same stage, requirement analysis is also performed by the developers of the
organization. This is attained from customer inputs, and sales
department/market surveys.
The information from this analysis forms the building blocks of a basic project.
The quality of the project is a result of planning. Thus, in this stage, the basic
project is designed with all the available information.

Stage-2: Defining Requirements

In this stage, all the requirements for the target software are specified. These
requirements get approval from customers, market analysts, and stakeholders.
This is fulfilled by utilizing SRS (Software Requirement Specification). This
is a sort of document that specifies all those things that need to be defined and
created during the entire project cycle.

Stage-3: Designing Architecture

SRS is a reference for software designers to come up with the best architecture
for the software. Hence, with the requirements defined in SRS, multiple
designs for the product architecture are present in the Design Document
Specification (DDS).
This DDS is assessed by market analysts and stakeholders. After evaluating all
 the possible factors, the most practical and logical design is chosen for
development.

Stage-4: Developing Product

At this stage, the fundamental development of the product starts. For this,
developers use a specific programming code as per the design in the DDS.
Hence, it is important for the coders to follow the protocols set by the
association. Conventional programming tools like compilers, interpreters,
debuggers, etc. are also put into use at this stage. Some popular languages like
C/C++, Python, Java, etc. are put into use as per the software regulations.

Stage-5: Product Testing and Integration

After the development of the product, testing of the software is necessary to
ensure its smooth execution. Although, minimal testing is conducted at every
stage of SDLC. Therefore, at this stage, all the probable flaws are tracked,
fixed, and retested. This ensures that the product confronts the quality
requirements of SRS.

Documentation, Training, and Support: Software documentation is an essential

part of the software development life cycle. A well-written document acts as a
tool and means to information repository necessary to know about software
processes, functions, and maintenance. Documentation also provides
information about how to use the product. Training in an attempt to improve
the current or future employee performance by increasing an employee’s
ability to work through learning, usually by changing his attitude and
developing his skills and understanding.

Stage 6: Deployment and Maintenance of Products

After detailed testing, the conclusive product is released in phases as per the
organization’s strategy. Then it is tested in a real industrial environment. It is
important to ensure its smooth performance. If it performs well, the
organization sends out the product as a whole. After retrieving beneficial
feedback, the company releases it as it is or with auxiliary improvements to
make it further helpful for the customers. However, this alone is not enough.
Therefore, along with the deployment, the product’s supervision.

Software Development Life Cycle Models

To this day, we have more than 50 recognized SDLC models in use. But None of
them is perfect, and each brings its favorable aspects and disadvantages for a
 specific software development project or a team.
In this article, We’ve listed the top five most popular SDLC models below.

1. Waterfall Model
It is the fundamental model of the software development life cycle. This is a very
simple model. The waterfall model is not in practice anymore, but it is the
basis for all other SDLC models. Because of its simple structure, the waterfall
model is easier to use and provides a tangible output. In the waterfall model,
once a phase seems to be completed, it cannot be changed, and due to this less
flexible nature, the waterfall model is not in practice anymore.

Why Do We Use the Waterfall Model?

The waterfall model is a software development model used in the context of
large, complex projects, typically in the field of information technology. It is
characterized by a structured, sequential approach to project management and
software development.
The waterfall model is useful in situations where the project requirements are
well-defined and the project goals are clear. It is often used for large-scale
projects with long timelines, where there is little room for error and the project
stakeholders need to have a high level of confidence in the outcome.
Features of the Waterfall Model
1. Sequential Approach: The waterfall model involves a sequential approach
to software development, where each phase of the project is completed
before moving on to the next one.
2. Document-Driven: The waterfall model relies heavily on documentation to
ensure that the project is well-defined and the project team is working
towards a clear set of goals.
3. Quality Control: The waterfall model places a high emphasis on quality
control and testing at each phase of the project, to ensure that the final
product meets the requirements and expectations of the stakeholders.
4. Rigorous Planning: The waterfall model involves a rigorous planning
process, where the project scope, timelines, and deliverables are carefully
defined and monitored throughout the project lifecycle.
Overall, the waterfall model is used in situations where there is a need for a
highly structured and systematic approach to software development. It can be
effective in ensuring that large, complex projects are completed on time and
within budget, with a high level of quality and customer satisfaction.
Phases of Classical Waterfall Model
Waterfall Model is a classical software development methodology that was first
introduced by Winston W. Royce in 1970. It is a linear and sequential
 approach to software development that consists of several phases that must be
completed in a specific order. The phases include:
1. Requirements Gathering and Analysis: The first phase involves gathering
requirements from stakeholders and analyzing them to understand the scope
and objectives of the project.
2. Design: Once the requirements are understood, the design phase begins.
This involves creating a detailed design document that outlines the software
architecture, user interface, and system components.
3. Implementation: The implementation phase involves coding the software
based on the design specifications. This phase also includes unit testing to
ensure that each component of the software is working as expected.
4. Testing: In the testing phase, the software is tested as a whole to ensure that
it meets the requirements and is free from defects.
5. Deployment: Once the software has been tested and approved, it is
deployed to the production environment.
6. Maintenance: The final phase of the Waterfall Model is maintenance,
which involves fixing any issues that arise after the software has been
deployed and ensuring that it continues to meet the requirements over time.
The classical waterfall model divides the life cycle into a set of phases. This
model considers that one phase can be started after the completion of the
previous phase. That is the output of one phase will be the input to the next
phase. Thus the development process can be considered as a sequential flow in
the waterfall. Here the phases do not overlap with each other. The different
sequential phases of the classical waterfall model are shown in the below
figure.
Phases of Classical Waterfall Model
Let us now learn about each of these phases in detail.
1. Feasibility Study
The main goal of this phase is to determine whether it would be financially and
technically feasible to develop the software.
The feasibility study involves understanding the problem and then determining
the various possible strategies to solve the problem. These different identified
solutions are analyzed based on their benefits and drawbacks, The best solution
is chosen and all the other phases are carried out as per this solution strategy.
2. Requirements Analysis and Specification
The aim of the requirement analysis and specification phase is to understand the
exact requirements of the customer and document them properly. This phase
 consists of two different activities.
 Requirement gathering and analysis: Firstly all the requirements
regarding the software are gathered from the customer and then the gathered
requirements are analyzed. The goal of the analysis part is to remove
incompleteness (an incomplete requirement is one in which some parts of
the actual requirements have been omitted) and inconsistencies (an
inconsistent requirement is one in which some part of the requirement
contradicts some other part).
 Requirement specification: These analyzed requirements are documented
in a software requirement specification (SRS) document. SRS document
serves as a contract between the development team and customers. Any
future dispute between the customers and the developers can be settled by
examining the SRS document.
3. Design
The goal of this phase is to convert the requirements acquired in the SRS into a
format that can be coded in a programming language. It includes high-level
and detailed design as well as the overall software architecture. A Software
Design Document is used to document all of this effort (SDD)
4. Coding and Unit Testing
In the coding phase software design is translated into source code using any
suitable programming language. Thus each designed module is coded. The aim
of the unit testing phase is to check whether each module is working properly
or not.
5. Integration and System testing
Integration of different modules is undertaken soon after they have been coded
and unit tested. Integration of various modules is carried out incrementally
over a number of steps. During each integration step, previously planned
modules are added to the partially integrated system and the resultant system is
tested. Finally, after all the modules have been successfully integrated and
tested, the full working system is obtained and system testing is carried out on
this.
System testing consists of three different kinds of testing activities as described
below.
 Alpha testing: Alpha testing is the system testing performed by the
development team.
 Beta testing: Beta testing is the system testing performed by a friendly set
of customers.
 Acceptance testing: After the software has been delivered, the customer
performed acceptance testing to determine whether to accept the delivered
software or reject it.
6. Maintenance
Maintenance is the most important phase of a software life cycle. The effort spent
on maintenance is 60% of the total effort spent to develop a full software.
There are basically three types of maintenance.
 Corrective Maintenance: This type of maintenance is carried out to correct
errors that were not discovered during the product development phase.
 Perfective Maintenance: This type of maintenance is carried out to enhance
the functionalities of the system based on the customer’s request.
 Adaptive Maintenance: Adaptive maintenance is usually required for
porting the software to work in a new environment such as working on a
new computer platform or with a new operating system.
Advantages of the Classical Waterfall Model
The classical waterfall model is an idealistic model for software development. It
is very simple, so it can be considered the basis for other software development
life cycle models. Below are some of the major advantages of this SDLC
model.
 Easy to Understand: Classical Waterfall Model is very simple and easy to
understand.
 Individual Processing: Phases in the Classical Waterfall model are
processed one at a time.
 Properly Defined: In the classical waterfall model, each stage in the model
is clearly defined.
 Clear Milestones: Classical Waterfall model has very clear and well-
understood milestones.
 Properly Documented: Processes, actions, and results are very well
documented.
 Reinforces Good Habits: Classical Waterfall Model reinforces good habits
like define-before-design and design-before-code.
 Working: Classical Waterfall Model works well for smaller projects and
projects where requirements are well understood.
Disadvantages of the Classical Waterfall Model
The Classical Waterfall Model suffers from various shortcomings, basically, we
can’t use it in real projects, but we use other software development lifecycle
models which are based on the classical waterfall model. Below are some
major drawbacks of this model.
 No Feedback Path: In the classical waterfall model evolution of software
from one phase to another phase is like a waterfall. It assumes that no error
is ever committed by developers during any phase. Therefore, it does not
incorporate any mechanism for error correction.
 Difficult to accommodate Change Requests: This model assumes that all
 the customer requirements can be completely and correctly defined at the
beginning of the project, but actually customer’s requirements keep on
changing with time. It is difficult to accommodate any change requests after
the requirements specification phase is complete.
 No Overlapping of Phases: This model recommends that a new phase can
start only after the completion of the previous phase. But in real projects,
this can’t be maintained. To increase efficiency and reduce cost, phases may
overlap.
 Limited Flexibility: The Waterfall Model is a rigid and linear approach to
software development, which means that it is not well-suited for projects
with changing or uncertain requirements. Once a phase has been completed,
it is difficult to make changes or go back to a previous phase.
 Limited Stakeholder Involvement: The Waterfall Model is a structured
and sequential approach, which means that stakeholders are typically
involved in the early phases of the project (requirements gathering and
analysis) but may not be involved in the later phases (implementation,
testing, and deployment).
 Late Defect Detection: In the Waterfall Model, testing is typically done
toward the end of the development process. This means that defects may not
be discovered until late in the development process, which can be expensive
and time-consuming to fix.
 Lengthy Development Cycle: The Waterfall Model can result in a lengthy
development cycle, as each phase must be completed before moving on to
the next. This can result in delays and increased costs if requirements change
or new issues arise.
 Not Suitable for Complex Projects: The Waterfall Model is not well-suited
for complex projects, as the linear and sequential nature of the model can
make it difficult to manage multiple dependencies and interrelated
components.
Applications of Classical Waterfall Model
 Large-scale Software Development Projects: The Waterfall Model is
often used for large-scale software development projects, where a structured
and sequential approach is necessary to ensure that the project is completed
on time and within budget.
 Safety-Critical Systems: The Waterfall Model is often used in the
development of safety-critical systems, such as aerospace or medical
systems, where the consequences of errors or defects can be severe.
 Government and Defense Projects: The Waterfall Model is also
commonly used in government and defense projects, where a rigorous and
structured approach is necessary to ensure that the project meets all
 requirements and is delivered on time.
 Projects with well-defined Requirements: The Waterfall Model is best
suited for projects with well-defined requirements, as the sequential nature
of the model requires a clear understanding of the project objectives and
scope.
 Projects with Stable Requirements: The Waterfall Model is also well-
suited for projects with stable requirements, as the linear nature of the model
does not allow for changes to be made once a phase has been completed.

2. Agile Model
The agile model was mainly designed to adapt to changing requests quickly. The
main goal of the Agile model is to facilitate quick project completion. The
agile model refers to a group of development processes. These processes have
some similar characteristics but also possess certain subtle differences among
themselves.

The Agile Model was primarily designed to help a project adapt quickly to
change requests. So, the main aim of the agile model is to facilitate quick
project completion. To accomplish this task, agility is required. Agility is
achieved by fitting the process to the project and removing activities that may
not be essential for a specific project. Also, anything that is a waste of time and
effort is avoided.
The Agile Model refers to a group of development processes. These processes
share some basic characteristics but do have certain subtle differences among
themselves.
Agile SDLC Models/Methods
 Models: Crystal Agile methodology places a strong emphasis on fostering
effective communication and collaboration among team members, as well as
taking into account the human elements that are crucial for a successful
development process. This methodology is particularly beneficial for
projects with a high degree of uncertainty, where requirements tend to
change frequently.
 Atern: This methodology is tailored for projects with moderate to high
uncertainty where requirements are prone to change frequently. Its clear-cut
roles and responsibilities focus on delivering working software in short time
frames. Governance practices set it apart and make it an effective approach
for teams and projects.
 Feature-driven development: This approach is implemented by utilizing a
series of techniques, like creating feature lists, conducting model
 evaluations, and implementing a design-by-feature method, to meet its goal.
This methodology is particularly effective in ensuring that the end product is
delivered on time and that it aligns with the requirements of the customer.
 Scrum: This methodology serves as a framework for tackling complex
projects and ensuring their successful completion. It is led by a Scrum
Master, who oversees the process, and a Product Owner, who establishes the
priorities. The Development Team, accountable for delivering the software,
is another key player.
 Extreme programming (XP): It uses specific practices like pair
programming, continuous integration, and test-driven development to
achieve these goals. Extreme programming is ideal for projects that have
high levels of uncertainty and require frequent changes, as it allows for
quick adaptation to new requirements and feedback.
 Lean Development: It is rooted in the principles of lean manufacturing and
aims to streamline the process by identifying and removing unnecessary
steps and activities. This is achieved through practices such as continuous
improvement, visual management, and value stream mapping, which helps
in identifying areas of improvement and implementing changes accordingly.
 Unified Process: Unified Process is a methodology that can be tailored to
the specific needs of any given project. It combines elements of both
waterfall and Agile methodologies, allowing for an iterative and incremental
approach to development. This means that the UP is characterized by a
series of iterations, each of which results in a working product increment,
allowing for continuous improvement and the delivery of value to the
customer.
All Agile methodologies discussed above share the same core values and
principles, but they may differ in their implementation and specific practices.
Agile development requires a high degree of collaboration and communication
among team members, as well as a willingness to adapt to changing
requirements and feedback from customers.
In the Agile model, the requirements are decomposed into many small parts that
can be incrementally developed. The Agile model adopts Iterative
development. Each incremental part is developed over an iteration. Each
iteration is intended to be small and easily manageable and can be completed
within a couple of weeks only. At a time one iteration is planned, developed,
and deployed to the customers. Long-term plans are not made.
Steps in the Agile Model
The agile model is a combination of iterative and incremental process models.
The steps involve in agile SDLC models are:
 Requirement gathering
  Design the Requirements
 Construction / Iteration
 Testing / Quality Assurance
 Deployment
 Feedback

Steps in Agile Model

1. Requirement Gathering:- In this step, the development team must gather the
requirements, by interaction with the customer. development team should plan
the time and effort needed to build the project. Based on this information you
can evaluate technical and economical feasibility.
2. Design the Requirements:- In this step, the development team will use user-
flow-diagram or high-level UML diagrams to show the working of the new
features and show how they will apply to the existing software. Wireframing
and designing user interfaces are done in this phase.
3. Construction / Iteration:- In this step, development team members start
working on their project, which aims to deploy a working product.
4. Testing / Quality Assurance:- Testing involves Unit Testing, Integration
Testing, and System Testing. A brief introduction of these three tests is as
follows:
5. Unit Testing:- Unit testing is the process of checking small pieces of code to
ensure that the individual parts of a program work properly on their own. Unit
testing is used to test individual blocks (units) of code.
 Integration Testing:- Integration testing is used to identify and resolve any
issues that may arise when different units of the software are combined.
 System Testing:- Goal is to ensure that the software meets the requirements
of the users and that it works correctly in all possible scenarios.
5. Deployment:- In this step, the development team will deploy the working
project to end users.
6. Feedback:- This is the last step of the Agile Model. In this, the team receives
feedback about the product and works on correcting bugs based on feedback
provided by the customer.
The time required to complete an iteration is known as a Time Box. Time-box
refers to the maximum amount of time needed to deliver an iteration to
customers. So, the end date for an iteration does not change. However, the
development team can decide to reduce the delivered functionality during a
Time-box if necessary to deliver it on time. The Agile model’s central
principle is delivering an increment to the customer after each Time-box.
Principles of the Agile Model
 To establish close contact with the customer during development and to gain
a clear understanding of various requirements, each Agile project usually
includes a customer representative on the team. At the end of each iteration
stakeholders and the customer representative review, the progress made and
re-evaluate the requirements.
 The agile model relies on working software deployment rather than
comprehensive documentation.
 Frequent delivery of incremental versions of the software to the customer
representative in intervals of a few weeks.
 Requirement change requests from the customer are encouraged and
efficiently incorporated.
 It emphasizes having efficient team members and enhancing
communications among them is given more importance. It is realized that
improved communication among the development team members can be
achieved through face-to-face communication rather than through the
exchange of formal documents.
 It is recommended that the development team size should be kept small (5 to
9 people) to help the team members meaningfully engage in face-to-face
communication and have a collaborative work environment.
 The agile development process usually deploys Pair Programming. In Pair
programming, two programmers work together at one workstation. One does
coding while the other reviews the code as it is typed in. The two
programmers switch their roles every hour or so.
Characteristics of the Agile Process
 Agile processes must be adaptable to technical and environmental changes.
That means if any technological changes occur, then the agile process must
accommodate them.
 The development of agile processes must be incremental. That means, in
each development, the increment should contain some functionality that can
be tested and verified by the customer.
  The customer feedback must be used to create the next increment of the
process.
 The software increment must be delivered in a short span of time.
 It must be iterative so that each increment can be evaluated regularly.
When To Use the Agile Model?
 When frequent modifications need to be made, this method is implemented.
 When a highly qualified and experienced team is available.
 When a customer is ready to have a meeting with the team all the time.
 when the project needs to be delivered quickly.
 Projects with few regulatory requirements or not certain requirements.
 projects utilizing a less-than-strict current methodology
 Those undertakings where the product proprietor is easily reachable
 Flexible project schedules and budgets.
Advantages of the Agile Model
 Working through Pair programming produces well-written compact
programs which have fewer errors as compared to programmers working
alone.
 It reduces the total development time of the whole project.
 Agile development emphasizes face-to-face communication among team
members, leading to better collaboration and understanding of project goals.
 Customer representatives get the idea of updated software products after
each iteration. So, it is easy for him to change any requirement if needed.
 Agile development puts the customer at the center of the development
process, ensuring that the end product meets their needs.
Disadvantages of the Agile Model
 The lack of formal documents creates confusion and important decisions
taken during different phases can be misinterpreted at any time by different
team members.
 It is not suitable for handling complex dependencies.
 The agile model depends highly on customer interactions so if the customer
is not clear, then the development team can be driven in the wrong direction.
 Agile development models often involve working in short sprints, which can
make it difficult to plan and forecast project timelines and deliverables. This
can lead to delays in the project and can make it difficult to accurately
estimate the costs and resources needed for the project.
 Agile development models require a high degree of expertise from team
members, as they need to be able to adapt to changing requirements and
work in an iterative environment. This can be challenging for teams that are
not experienced in agile development practices and can lead to delays and
difficulties in the project.
  Due to the absence of proper documentation, when the project completes
and the developers are assigned to another project, maintenance of the
developed project can become a problem.

3. Iterative Model
In the iterative model, each cycle results in a semi-developed but deployable
version; with each cycle, some requirements are added to the software, and the
final cycle results in the software with the complete requirement specification.

4. Spiral Model
The spiral model is one of the most crucial SDLC models that provides support
for risk handling. It has various spirals in its diagrammatic representation; the
number of spirals depends upon the type of project. Each loop in the spiral
structure indicates the Phases of the Spiral model.

The Spiral Model is a Software Development Life Cycle (SDLC) model that
provides a systematic and iterative approach to software development. It is
based on the idea of a spiral, with each iteration of the spiral representing a
complete software development cycle, from requirements gathering and
analysis to design, implementation, testing, and maintenance.
What Are the Phases of Spiral Model?
The Spiral Model is a risk-driven model, meaning that the focus is on managing
 risk through multiple iterations of the software development process. It
consists of the following phases:
 Planning: The first phase of the Spiral Model is the planning phase, where
the scope of the project is determined and a plan is created for the next
iteration of the spiral.
 Risk Analysis: In the risk analysis phase, the risks associated with the
project are identified and evaluated.
 Engineering: In the engineering phase, the software is developed based on
the requirements gathered in the previous iteration.
 Evaluation: In the evaluation phase, the software is evaluated to determine
if it meets the customer’s requirements and if it is of high quality.
 Planning: The next iteration of the spiral begins with a new planning phase,
based on the results of the evaluation.
 The Spiral Model is often used for complex and large software development
projects, as it allows for a more flexible and adaptable approach to software
development. It is also well-suited to projects with significant uncertainty or
high levels of risk.
The Radius of the spiral at any point represents the expenses(cost) of the project
so far, and the angular dimension represents the progress made so far in the
current phase.
Spiral Model
Each phase of the Spiral Model is divided into four quadrants as shown in the
above figure. The functions of these four quadrants are discussed below-
 Objectives determination and identify alternative
solutions: Requirements are gathered from the customers and the objectives
are identified, elaborated, and analyzed at the start of every phase. Then
alternative solutions possible for the phase are proposed in this quadrant.
 Identify and resolve Risks: During the second quadrant, all the possible
solutions are evaluated to select the best possible solution. Then the risks
associated with that solution are identified and the risks are resolved using
the best possible strategy. At the end of this quadrant, the Prototype is built
for the best possible solution.
 Develop the next version of the Product: During the third quadrant, the
identified features are developed and verified through testing. At the end of
the third quadrant, the next version of the software is available.
 Review and plan for the next Phase: In the fourth quadrant, the Customers
evaluate the so-far developed version of the software. In the end, planning
for the next phase is started.
Risk Handling in Spiral Model
A risk is any adverse situation that might affect the successful completion of a
software project. The most important feature of the spiral model is handling
these unknown risks after the project has started. Such risk resolutions are
easier done by developing a prototype. The spiral model supports coping with
risks by providing the scope to build a prototype at every phase of software
development.
The Prototyping Model also supports risk handling, but the risks must be
identified completely before the start of the development work of the project.
But in real life, project risk may occur after the development work starts, in
that case, we cannot use the Prototyping Model. In each phase of the Spiral
Model, the features of the product dated and analyzed, and the risks at that
point in time are identified and are resolved through prototyping. Thus, this
model is much more flexible compared to other SDLC models.
Why Spiral Model is called Meta Model?
The Spiral model is called a Meta-Model because it subsumes all the other SDLC
models. For example, a single loop spiral actually represents the Iterative
Waterfall Model. The spiral model incorporates the stepwise approach of
the Classical Waterfall Model. The spiral model uses the approach of
the Prototyping Model by building a prototype at the start of each phase as a
risk-handling technique. Also, the spiral model can be considered as
supporting the Evolutionary model – the iterations along the spiral can be
considered as evolutionary levels through which the complete system is built.
Advantages of the Spiral Model
Below are some advantages of the Spiral Model.
 Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development
model to follow due to the risk analysis and risk handling at every phase.
 Good for large projects: It is recommended to use the Spiral Model in large
and complex projects.
 Flexibility in Requirements: Change requests in the Requirements at a later
phase can be incorporated accurately by using this model.
 Customer Satisfaction: Customers can see the development of the product
at the early phase of the software development and thus, they habituated
with the system by using it before completion of the total product.
 Iterative and Incremental Approach: The Spiral Model provides an
iterative and incremental approach to software development, allowing for
flexibility and adaptability in response to changing requirements or
unexpected events.
 Emphasis on Risk Management: The Spiral Model places a strong
emphasis on risk management, which helps to minimize the impact of
 uncertainty and risk on the software development process.
 Improved Communication: The Spiral Model provides for regular
evaluations and reviews, which can improve communication between the
customer and the development team.
 Improved Quality: The Spiral Model allows for multiple iterations of the
software development process, which can result in improved software
quality and reliability.
Disadvantages of the Spiral Model
Below are some main disadvantages of the spiral model.
 Complex: The Spiral Model is much more complex than other SDLC
models.
 Expensive: Spiral Model is not suitable for small projects as it is expensive.
 Too much dependability on Risk Analysis: The successful completion of
the project is very much dependent on Risk Analysis. Without very highly
experienced experts, it is going to be a failure to develop a project using this
model.
 Difficulty in time management: As the number of phases is unknown at the
start of the project, time estimation is very difficult.
 Complexity: The Spiral Model can be complex, as it involves multiple
iterations of the software development process.
 Time-Consuming: The Spiral Model can be time-consuming, as it requires
multiple evaluations and reviews.
 Resource Intensive: The Spiral Model can be resource-intensive, as it
requires a significant investment in planning, risk analysis, and evaluations.
The most serious issue we face in the cascade model is that taking a long length
to finish the item, and the product became obsolete. To tackle this issue, we
have another methodology, which is known as the Winding model or spiral
model. The winding model is otherwise called the cyclic model.
When To Use the Spiral Model?
 When a project is vast in software engineering, a spiral model is utilized.
 A spiral approach is utilized when frequent releases are necessary.
 When it is appropriate to create a prototype
 When evaluating risks and costs is crucial
 The spiral approach is beneficial for projects with moderate to high risk.
 The SDLC’s spiral model is helpful when requirements are complicated and
ambiguous.
 If modifications are possible at any moment
 When committing to a long-term project is impractical owing to shifting
economic priorities.
5. V-Shaped Model
The V-shaped model is executed in a sequential manner in V-shape. Each stage
or phase of this model is integrated with a testing phase. After every
development phase, a testing phase is associated with it, and the next phase
will start once the previous phase is completed, i.e., development & testing. It
is also known as the verification or validation model.
The V-Model is a software development life cycle (SDLC) model that provides a
systematic and visual representation of the software development process. It is
based on the idea of a “V” shape, with the two legs of the “V” representing the
progression of the software development process from requirements gathering
and analysis to design, implementation, testing, and maintenance.
The V-Model is a linear and sequential model that consists of the following
phases:
1. Requirements Gathering and Analysis: The first phase of the V-Model is the
requirements gathering and analysis phase, where the customer’s
requirements for the software are gathered and analyzed to determine the
scope of the project.
2. Design: In the design phase, the software architecture and design are
developed, including the high-level design and detailed design.
3. Implementation: In the implementation phase, the software is actually built
based on the design.
4. Testing: In the testing phase, the software is tested to ensure that it meets the
customer’s requirements and is of high quality.
5. Deployment: In the deployment phase, the software is deployed and put into
use.
6. Maintenance: In the maintenance phase, the software is maintained to ensure
that it continues to meet the customer’s needs and expectations.
7. The V-Model is often used in safety-critical systems, such as aerospace and
defense systems, because of its emphasis on thorough testing and its ability
to clearly define the steps involved in the software development process.
Verification: It involves static analysis technique (review) done without
executing code. It is the process of evaluation of the product development
phase to find whether specified requirements meet.
Validation: It involves dynamic analysis technique (functional, non-functional),
testing done by executing code. Validation is the process to evaluate the
software after the completion of the development phase to determine whether
software meets the customer expectations and requirements.
So 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. This stage is
known as Requirement Gathering.
 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).
Testing Phases:

 Unit Testing: Unit Test Plans are developed during module design phase.
These Unit Test Plans are executed to eliminate bugs at code or unit level.
 Integration testing: After completion of unit testing Integration testing is
performed. In integration testing, the modules are integrated and the system
is tested. Integration testing is performed on the Architecture design phase.
This test verifies the communication of modules among themselves.
 System Testing: System testing test the complete application with its
functionality, inter dependency, and communication.It tests the functional
and non-functional requirements of the developed application.
 User Acceptance Testing (UAT): UAT is performed in a user environment
that resembles the production environment. UAT verifies that the delivered
system meets user’s requirement and system is ready for use in real world.
Industrial Challenge: As the industry has evolved, the technologies have
become more complex, increasingly faster, and forever changing, however,
there remains a set of basic principles and concepts that are as applicable today
as when IT was in its infancy.

 Accurately define and refine user requirements.

 Design and build an application according to the authorized user
requirements.
 Validate that the application they had built adhered to the authorized
business requirements.
Principles of V-Model:

 Large to Small: In V-Model, testing is done in a hierarchical perspective,

For example, requirements identified by the project team, create High-Level
Design, and Detailed Design phases of the project. As each of these phases
is completed the requirements, they are defining become more and more
refined and detailed.
 Data/Process Integrity: This principle states that the successful design of
any project requires the incorporation and cohesion of both data and
processes. Process elements must be identified at each and every
 requirements.
 Scalability: This principle states that the V-Model concept has the
flexibility to accommodate any IT project irrespective of its size, complexity
or duration.
 Cross Referencing: Direct correlation between requirements and
corresponding testing activity is known as cross-referencing.
Tangible Documentation: This principle states that every project needs to create
a document. This documentation is required and applied by both the project
development team and the support team. Documentation is used to maintaining
the application once it is available in a production environment.
Why preferred?
 It is easy to manage due to the rigidity of the model. Each phase of V-Model
has specific deliverables and a review process.
 Proactive defect tracking – that is defects are found at early stage.
When to use?
 Where requirements are clearly defined and fixed.
 The V-Model is used when ample technical resources are available with
technical expertise.
 Small to medium-sized projects with set and clearly specified needs are
recommended to use the V-shaped model.
 Since it is challenging to keep stable needs in large projects, the project
should be small.
Advantages:

 This is a highly disciplined model and Phases are completed one at a time.
 V-Model is used for small projects where project requirements are clear.
 Simple and easy to understand and use.
 This model focuses on verification and validation activities early in the life
cycle thereby enhancing the probability of building an error-free and good
quality product.
 It enables project management to track progress accurately.
 Clear and Structured Process: The V-Model provides a clear and structured
process for software development, making it easier to understand and
follow.
 Emphasis on Testing: The V-Model places a strong emphasis on testing,
which helps to ensure the quality and reliability of the software.
 Improved Traceability: The V-Model provides a clear link between the
requirements and the final product, making it easier to trace and manage
changes to the software.
 Better Communication: The clear structure of the V-Model helps to improve
 communication between the customer and the development team.
Disadvantages:

 High risk and uncertainty.

 It is not a good for complex and object-oriented projects.
 It is not suitable for projects where requirements are not clear and contains
high risk of changing.
 This model does not support iteration of phases.
 It does not easily handle concurrent events.
 Inflexibility: The V-Model is a linear and sequential model, which can make
it difficult to adapt to changing requirements or unexpected events.
 Time-Consuming: The V-Model can be time-consuming, as it requires a lot
of documentation and testing.
 Overreliance on Documentation: The V-Model places a strong emphasis on
documentation, which can lead to an overreliance on documentation at the
expense of actual development work.

6.Big Bang Model

The Big Bang model in SDLC is a term used to describe an informal and
unstructured approach to software development, where there is no specific
planning, documentation, or well-defined phases.

What is SWOT Analysis?

SWOT stands for Strengths, Weaknesses, Opportunities, and Threats. A SWOT
analysis is a framework to help assess and understand the internal and external
forces that may create opportunities or risks for an organization.
Strengths and weaknesses are internal factors. They are characteristics of a
business that give it a relative advantage (or disadvantage, respectively) over
its competition.
Opportunities and threats, on the other hand, are external factors. Opportunities
are elements of the external environment that management can seize upon to
improve business performance (like revenue growth or improved margins).
Threats are elements of the external environment that may endanger a
firm’s competitive advantage(s), or even its ability to operate as a going
concern (think regulatory issues or technological disruption).

Key Highlights
SWOT is used to help assess the internal and external factors that contribute to a
company’s relative advantages and disadvantages.
A SWOT analysis is generally used in conjunction with other assessment
frameworks, like PESTEL and Porter’s 5-Forces.
Findings from a SWOT analysis will help inform model assumptions for the
analyst community.

Examples
Strengths
Strengths may be any number of areas or characteristics where a company excels
and has a competitive advantage over its peers. Advantages may be more
qualitative in nature and therefore difficult to measure (like a great corporate
culture, strong brand recognition, proprietary technology, etc.), or they may be
more quantitative (like best-in-class margins, above-average inventory
turnover, category-leading return on equity, etc.).

Weaknesses
Weaknesses are areas or characteristics where a business is at a
competitive disadvantage relative to its peers. Like strengths, these can also be
more qualitative or quantitative. Examples include inexperienced management,
high employee turnover, low (or declining) margins, and high (or excessive)
use of debt as a funding source.

Opportunities
The “Opportunities” section should highlight external factors that represent
potential growth or improvement areas for a business. Consider opportunities
like a growing total addressable market (TAM), technological advancements
that might help improve efficiency, or changes in social norms that are creating
new markets or new sub-segments of existing markets.

Threats
Threats are external forces that represent risks to a business and its ability to
operate. The categories tend to be similar to the “Opportunities” section, but
directionally opposite. Consider examples like an industry in decline (which is
the same as a decreasing TAM), technological innovation that could disrupt the
existing business and its operations, or evolving social norms that make
existing product offerings less attractive to a growing number of consumers.
How to Conduct a SWOT Analysis
A SWOT analysis is rarely completed in isolation; it generally makes up one part
of a broader business analysis. And while it is itself an assessment framework,
a SWOT analysis is also an effective tool to help summarize other findings.
For example, an analyst can’t really assess a company’s strengths and
weaknesses without first understanding the business and its industry. They may
wish to leverage other tools and frameworks in order to accomplish this,
including:
Hax’s Delta Model – This will help to understand competitive positioning.
Ansoff’s Matrix – This will help visualize the relative risk of a management
team’s growth strategies.
Financial ratio analysis – This will help identify trends (year-over-year), as well
as a firm’s relative performance (using benchmarking data).

The same is true for external factors – opportunities and threats. It’s nearly
impossible to understand these without first considering:
The industry life cycle – Does the business operate in a growing, mature, or
declining industry? This itself informs both opportunities and threats.
An analysis of the broader business environment or the industry itself – Think
frameworks like PESTEL or Porter’s 5 Forces.
What is a SWOT Analysis Used For?
A SWOT analysis is used differently by different stakeholders.
For example, a management team will use the framework to support strategic
planning and risk management. SWOT helps them visualize the firm’s relative
advantages and disadvantages in order to better understand where and how the
organization should allocate resources, either towards growth or risk reduction
initiatives.
The analyst community, on the other hand, may seek to understand (and
quantify) strengths, weaknesses, opportunities, and threats in order to assess
the business more completely.
Consider that findings from a SWOT analysis may help inform model
assumptions among analysts. It could be an equity researcher trying to estimate
the fair market value of a company’s shares, or a credit analyst looking to
better understand a borrower’s creditworthiness.
In general, the SWOT framework is considered by many to be one of the most
useful tools available for strategic planning and business analysis.

Software Engineering | Requirements Engineering Process

Requirements engineering is the process of identifying, eliciting, analyzing,

specifying, validating, and managing the needs and expectations of
stakeholders for a software system. The requirements engineering process is an
iterative process that involves several steps, including:
• Requirements Elicitation: 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.
• 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.
• Requirements Specification: This step involves documenting the requirements
identified in the analysis step in a clear, consistent, and unambiguous manner.
This step also involves prioritizing and grouping the requirements into
manageable chunks.
• Requirements Validation: This step involves checking that the requirements
are complete, consistent, and accurate. It also involves checking that the
requirements are testable and that they meet the needs and expectations of
stakeholders.
• Requirements Management: This step involves managing the requirements
throughout the software development life cycle, including tracking and
controlling changes, and ensuring that the requirements are still valid and
relevant.
• The Requirements Engineering process is a critical step in the software
development life cycle as it helps to ensure that the software system being
developed meets the needs and expectations of stakeholders, and that it is
developed on time, within budget, and to the required quality.
Requirement Engineering is the process of defining, documenting and
maintaining the requirements. It is a process of gathering and defining service
provided by the system. it is the disciplined application of proven principle ,
methods ,tools and notations to describe a proposed system’s intended
behavior and its associated constraints.
Tools involved in requirement engineering:
• observation report
• Questionnaire ( survey , poll )
• Use cases
• User stories
• Requirement workshop
• Mind mapping
• Role playing
• Prototyping
Requirements Engineering Process consists of the following main activities:
• Requirements elicitation
• Requirements specification
• Requirements verification and validation
• Requirements management
Requirements Elicitation:
It is related to the various ways used to gain knowledge about the project domain
and requirements. The various sources of domain knowledge include
customers, business manuals, the existing software of same type, standards and
other stakeholders of the project. The techniques used for requirements
elicitation include interviews, brainstorming, task analysis, Delphi technique,
prototyping, etc. Some of these are discussed here. Elicitation does not produce
formal models of the requirements understood. Instead, it widens the domain
knowledge of the analyst and thus helps in providing input to the next stage.
Requirements elicitation is the process of gathering information about the needs
and expectations of stakeholders for a software system. This is the first step in
the requirements engineering process and it is critical to the success of the
software development project. The goal of this step is to understand the
 problem that the software system is intended to solve, and the needs and
expectations of the stakeholders who will use the system.
There are several techniques that can be used to elicit requirements, including:
• Interviews: These are one-on-one conversations with stakeholders to gather
information about their needs and expectations.
• Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.
• Focus Groups: These are small groups of stakeholders who are brought
together to discuss their needs and expectations for the software system.
• Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
• Prototyping: This technique involves creating a working model of the software
system, which can be used to gather feedback from stakeholders and to
validate requirements.
It’s important to document, organize and prioritize the requirements obtained
from all these techniques to ensure that they are complete, consistent and
accurate.
Requirements specification:
This activity is used to produce formal software requirement models. All the
requirements including the functional as well as the non-functional
requirements and the constraints are specified by these models in totality.
During specification, more knowledge about the problem may be required
which can again trigger the elicitation process. The models used at this stage
include ER diagrams, data flow diagrams(DFDs), function decomposition
diagrams(FDDs), data dictionaries, etc.
Requirements specification is the process of documenting the requirements
identified in the analysis step in a clear, consistent, and unambiguous manner.
This step also involves prioritizing and grouping the requirements into
manageable chunks.
The goal of this step is to create a clear and comprehensive document that
describes the requirements for the software system. This document should be
understandable by both the development team and the stakeholders.
There are several types of requirements that are commonly specified in this step,
including:
• Functional Requirements: These describe what the software system should do.
They specify the functionality that the system must provide, such as input
validation, data storage, and user interface.
• Non-Functional Requirements: These describe how well the software system
should do it. They specify the quality attributes of the system, such as
performance, reliability, usability, and security.
• Constraints: These describe any limitations or restrictions that must be
considered when developing the software system.
• Acceptance Criteria: These describe the conditions that must be met for the
software system to be considered complete and ready for release.
In order to make the requirements specification clear, the requirements should be
written in a natural language and use simple terms, avoiding technical jargon,
and using a consistent format throughout the document. It is also important to
use diagrams, models, and other visual aids to help communicate the
requirements effectively.
Once the requirements are specified, they must be reviewed and validated by the
stakeholders and development team to ensure that they are complete,
consistent, and accurate.
Requirements verification and validation:
Verification: It refers to the set of tasks that ensures that the software correctly
implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that
has been built is traceable to customer requirements. If requirements are not
validated, errors in the requirement definitions would propagate to the
successive stages resulting in a lot of modification and rework. The main steps
for this process include:
• The requirements should be consistent with all the other requirements i.e no
two requirements should conflict with each other.
• The requirements should be complete in every sense.
• The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used for
this.
Requirements verification and validation (V&V) is the process of checking that
the requirements for a software system are complete, consistent, and accurate,
and that they meet the needs and expectations of the stakeholders. The goal of
V&V is to ensure that the software system being developed meets the
requirements and that it is developed on time, within budget, and to the
required quality.
• Verification is the process of checking that the requirements are complete,
consistent, and accurate. It involves reviewing the requirements to ensure that
they are clear, testable, and free of errors and inconsistencies. This can include
reviewing the requirements document, models, and diagrams, and holding
meetings and walkthroughs with stakeholders.
• Validation is the process of checking that the requirements meet the needs and
expectations of the stakeholders. It involves testing the requirements to ensure
that they are valid and that the software system being developed will meet the
 needs of the stakeholders. This can include testing the software system through
simulation, testing with prototypes, and testing with the final version of the
software.
• V&V is an iterative process that occurs throughout the software development
life cycle. It is important to involve stakeholders and the development team in
the V&V process to ensure that the requirements are thoroughly reviewed and
tested.
It’s important to note that V&V is not a one-time process, but it should be
integrated and continue throughout the software development process and even
in the maintenance stage.
Requirements management:
Requirement management is the process of analyzing, documenting, tracking,
prioritizing and agreeing on the requirement and controlling the
communication to relevant stakeholders. This stage takes care of the changing
nature of requirements. It should be ensured that the SRS is as modifiable as
possible so as to incorporate changes in requirements specified by the end
users at later stages too. Being able to modify the software as per requirements
in a systematic and controlled manner is an extremely important part of the
requirements engineering process.
Requirements management is the process of managing the requirements
throughout the software development life cycle, including tracking and
controlling changes, and ensuring that the requirements are still valid and
relevant. The goal of requirements management is to ensure that the software
system being developed meets the needs and expectations of the stakeholders
and that it is developed on time, within budget, and to the required quality.
There are several key activities that are involved in requirements management,
including:
• Tracking and controlling changes: This involves monitoring and controlling
changes to the requirements throughout the development process, including
identifying the source of the change, assessing the impact of the change, and
approving or rejecting the change.
• Version control: This involves keeping track of different versions of the
requirements document and other related artifacts.
• Traceability: This involves linking the requirements to other elements of the
development process, such as design, testing, and validation.
• Communication: This involves ensuring that the requirements are
communicated effectively to all stakeholders and that any changes or issues are
addressed in a timely manner.
• Monitoring and reporting: This involves monitoring the progress of the
development process and reporting on the status of the requirements.
Requirements management is a critical step in the software development life
cycle as it helps to ensure that the software system being developed meets the
needs and expectations of stakeholders, and that it is developed on time, within
budget, and to the required quality. It also helps to prevent scope creep and to
ensure that the requirements are aligned with the project goals.
ADVANTAGES OF DISADVANTAGES:
The advantages of disadvantages of the requirements engineering process in
software engineering include:
Advantages:
• Helps ensure that the software being developed meets the needs and
expectations of the stakeholders
• Can help identify potential issues or problems early in the development
process, allowing for adjustments to be made before significant
• Helps ensure that the software is developed in a cost-effective and efficient
manner
• Can improve communication and collaboration between the development team
and stakeholders
• Helps to ensure that the software system meets the needs of all stakeholders.
• Provides a clear and unambiguous description of the requirements, which helps
to reduce misunderstandings and errors.
• Helps to identify potential conflicts and contradictions in the requirements,
which can be resolved before the software development process begins.
• Helps to ensure that the software system is delivered on time, within budget,
and to the required quality standards.
• Provides a solid foundation for the development process, which helps to reduce
the risk of failure.
Disadvantages:
• Can be time-consuming and costly, particularly if the requirements gathering
process is not well-managed
• Can be difficult to ensure that all stakeholders’ needs and expectations are
taken into account
• Can be 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.
• As a best practice, Requirements engineering should be flexible, adaptable, and
should be aligned with the overall project goals.
• It can be time-consuming and expensive, especially if the requirements are
complex.
• It can be difficult to elicit requirements from stakeholders who have different
 needs and priorities.
• Requirements may change over time, which can result in delays and additional
costs.
• There may be conflicts between stakeholders, which can be difficult to resolve.
• It may be challenging to ensure that all stakeholders understand and agree on
the requirements.
Requirements engineering is a critical process in software engineering that
involves identifying, analyzing, documenting, and managing the requirements
of a software system. The requirements engineering process consists of the
following stages:
1. Elicitation: In this stage, the requirements are gathered from various
stakeholders such as customers, users, and domain experts. The aim is to
identify the features and functionalities that the software system should
provide.
2. Analysis: In this stage, the requirements are analyzed to determine their
feasibility, consistency, and completeness. The aim is to identify any conflicts
or contradictions in the requirements and resolve them.
3. Specification: In this stage, the requirements are documented in a clear,
concise, and unambiguous manner. The aim is to provide a detailed description
of the requirements that can be understood by all stakeholders.
4. Validation: In this stage, the requirements are reviewed and validated to ensure
that they meet the needs of all stakeholders. The aim is to ensure that the
requirements are accurate, complete, and consistent.
5. Management: In this stage, the requirements are managed throughout the
software development lifecycle. The aim is to ensure that any changes or
updates to the requirements are properly documented and communicated to all
stakeholders.
6. Effective requirements engineering is crucial to the success of software
development projects. It helps ensure that the software system meets the needs
of all stakeholders and is delivered on time, within budget, and to the required
quality standards.
Main types of software requirement can be of 3 types:
• Functional requirements
• Non-functional requirements
• Domain requirements

Functional Requirements: These are the requirements that the end user
 specifically demands as basic facilities that the system should offer. It can be a
calculation, data manipulation, business process, user interaction, or any other
specific functionality which defines what function a system is likely to
perform. All these functionalities need to be necessarily incorporated into the
system as a part of the contract. These are represented or stated in the form of
input to be given to the system, the operation performed and the output
expected. They are basically the requirements stated by the user which one can
see directly in the final product, unlike the non-functional requirements. For
example, in a hospital management system, a doctor should be able to retrieve
the information of his patients. Each high-level functional requirement may
involve several interactions or dialogues between the system and the outside
world. In order to accurately describe the functional requirements, all scenarios
must be enumerated. There are many ways of expressing functional
requirements e.g., natural language, a structured or formatted language with no
rigorous syntax and formal specification language with proper syntax.
Functional Requirements in Software Engineering are also called Functional
Specification.
Non-functional requirements: These are basically the quality constraints that the
system must satisfy according to the project contract. Nonfunctional
requirements, not related to the system functionality, rather define how the
system should perform The priority or extent to which these factors are
implemented varies from one project to other. They are also called non-
behavioral requirements. They basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
NFR’s are classified into following types:
• Interface constraints
• Performance constraints: response time, security, storage space, etc.
• Operating constraints
• Life cycle constraints: maintainability, portability, etc.
• Economic constraints
The process of specifying non-functional requirements requires the knowledge of
the functionality of the system, as well as the knowledge of the context within
which the system will operate.
They are divided into two main categories: Execution qualities like security and
usability, which are observable at run time. Evolution qualities like testability,
maintainability, extensibility, and scalability that embodied in the static
structure of the software system.
Domain requirements: Domain requirements are the requirements which are
characteristic of a particular category or domain of projects. Domain
requirements can be functional or nonfunctional. Domain requirements
engineering is a continuous process of proactively defining the requirements
for all foreseeable applications to be developed in the software product line.
The basic functions that a system of a specific domain must necessarily exhibit
come under this category. For instance, in an academic software that maintains
records of a school or college, the functionality of being able to access the list
of faculty and list of students of each grade is a domain requirement. These
requirements are therefore identified from that domain model and are not user
specific.
Other common classifications of software requirements can be:
1. User requirements: These requirements describe what the end-user wants from
the software system. User requirements are usually expressed in natural
language and are typically gathered through interviews, surveys, or user
feedback.
2. System requirements: These requirements specify the technical characteristics
of the software system, such as its architecture, hardware requirements,
software components, and interfaces. System requirements are typically
expressed in technical terms and are often used as a basis for system design.
3. Business requirements: These requirements describe the business goals and
objectives that the software system is expected to achieve. Business
requirements are usually expressed in terms of revenue, market share,
customer satisfaction, or other business metrics.
4. Regulatory requirements: These requirements specify the legal or regulatory
standards that the software system must meet. Regulatory requirements may
include data privacy, security, accessibility, or other legal compliance
requirements.
5. Interface requirements: These requirements specify the interactions between
the software system and external systems or components, such as databases,
web services, or other software applications.
6. Design requirements: These requirements describe the technical design of the
software system. They include information about the software architecture,
data structures, algorithms, and other technical aspects of the software.
By classifying software requirements, it becomes easier to manage, prioritize,
and document them effectively. It also helps ensure that all important aspects
 of the system are considered during the development process.
Advantages of classifying software requirements include:
1. Better organization: Classifying software requirements helps organize them
into groups that are easier to manage, prioritize, and track throughout the
development process.
2. Improved communication: Clear classification of requirements makes it easier
to communicate them to stakeholders, developers, and other team members. It
also ensures that everyone is on the same page about what is required.
3. Increased quality: By classifying requirements, potential conflicts or gaps can
be identified early in the development process. This reduces the risk of errors,
omissions, or misunderstandings, leading to higher quality software.
4. Improved traceability: Classifying requirements helps establish traceability,
which is essential for demonstrating compliance with regulatory or quality
standards.
Disadvantages of classifying software requirements include:
1. Complexity: Classifying software requirements can be complex, especially if
there are many stakeholders with different needs or requirements. It can also be
time-consuming to identify and classify all the requirements.
2. Rigid structure: A rigid classification structure may limit the ability to
accommodate changes or evolving needs during the development process. It
can also lead to a siloed approach that prevents the integration of new ideas or
insights.
3. Misclassification: Misclassifying requirements can lead to errors or
misunderstandings that can be costly to correct later in the development
process.

What is SRS?
A software requirements specification (SRS) is a description of a software
system to be developed. It lays out functional and non-functional requirements
and may include a set of use cases that describe user interactions that the
software must provide.
The output of requirement engineering is the requirement specification document
(SRD). it can be considered as a contract between the development team and
the customer which can be also used to resolve any disagreement that may
arise in future.
it is the specification for the particular software product , program or set of
programs that perform certain function. it serves a number of purposes
depending upon who is writing it. the srs document must be written in two
phase:
First SRS should be written by the customer and second SRS should be written
 by the developer. first srs is used to define an expectations of the user and
second srs is written for different purpose and serves as a contract document
between customer and developer.
Why SRS?
In order to fully understand one’s project, it is very important that they come up
with an SRS listing out their requirements, how are they going to meet them
and how will they complete the project. It helps the team to save upon their
time as they are able to comprehend how are going to go about the project.
Doing this also enables the team to find out about the limitations and risks
early on.
The following is a sample SRS that I wrote for one of my projects.
SRS’s characteristics include:
 Correct
 Unambiguous
 Complete
 Consistent
 Ranked for importance and/or stability
 Verifiable
 Modifiable
 Traceable
Project Plan: MeetUrMate
1. Introduction
This document lays out a project plan for the development of the “MeetUrMate”
open source repository system by Anurag Mishra.
The intended readers of this document are current and future developers working
on “MeetUrMate” and the sponsors of the project. The plan will include, but is
not restricted to, a summary of the system functionality, the scope of the
project from the perspective of the “MeetUrMate” team (me and my mentors),
scheduling and delivery estimates, project risks, and how those risks will be
mitigated, the process by which I will develop the project, and metrics and
measurements that will be recorded throughout the project.
2. Overview
In today’s world, owning to the heavy workload on the employees, they are
having a huge amount of stress in their lives. Even with the presence of so
many gadgets in and around them, they are not able to relieve their stress. I aim
to develop an application that would enable them to share the thing of their
liking and meet the person who has the same passion as theirs. For eg. If
someone wants to share their art, they can share it through the platform, if
someone wants to sing any song, they can record it and share the same. They
can also share videos (with some funny commentary in the background), share
 mysteries that other people can solve, post any question. Through my platform,
I’ll enable them to meet people who share common interests and passions, chat
with them, and have some fun.
2.1 Customers
Everyone. Anyone can use this application ranging from a child to an old-age
person.
2.2 Functionality
 Users should be able to register through their already existing accounts.
 They should be able to share snaps/videos/snaps.
 People should be able to like and comment on any post. One person can
follow another person who shares common interests and likings which
would enable them to find mates apart from their usual friend circle.
 Each user can have his/her profile picture, status
 People can post mysteries and other people can solve the mysteries.
 Users will get points for the popularity of their posts/the number of
mysteries they solve.
 Add own funny commentary on any video
 Post any questions regarding their interests and people can answer.
P.S. Italic points features can be inculcated later.
2.3 Platform
It will be launched both as a Web-based application and a Mobile app for
Android.
2.4 Development Responsibility
I, Anurag Mishra, would be developing the software and I am responsible for the
creation of the Database and all the other related kinds of stuff.
3. Goals and Scopes
 Users should be able to register through their already existing accounts.
 They should be able to share snaps/videos/snaps.
 People should be able to like and comment on any post.
 One person can follow another person who shares common interests and
likings which would enable them to find mates apart from their usual friend
circle.
 Each user can have his/her profile picture, status.
 People can post mysteries and other people can solve the mysteries.
 Users will get points for the popularity of their posts/the number of
mysteries they solve.
4. Deliverables
I’ll deliver the following during the course of development:
 Feature specification
 Product design
  Test plan
 Development document
 Source code
5. Risk Management
5.1 Risk Identification
Following will be the risk involved in my project:
1) People are already using Facebook to find friends. So, what would be the real
cause that would motivate them to join my application?
5.2 Risk Mitigation
Even though most of the users would already be using Facebook, our platform
would still offer them many things that are not there on Facebook. For eg.
1. They don’t meet people who share common interests and passions as much.
Our application would enable them to meet people (apart from usual friends)
who share common interests and passions on a more frequent basis.
2. Users of FB cannot share songs on the go that they have sung whereas on
our app they can do that on the go.
3. People can post mysteries/cases and other people can solve them. Moreover,
people will get points in case they solve the mysteries or on the basis of the
popularity of their posts.
4. More importantly, people need not register for my application, instead, they
can log in using their already existing accounts of Google/Facebook.
Thus, I think that there is a considerable amount of difference between
Facebook/Instagram/Twitter and my application and it would attract many
people.
6. Scheduling and Estimates
Milestone Description Release Date Release

Iteration

M1 Application view and Design October 5, 2015 R1

(Front-end development)

M2 Database for my application October 17, 2015 R1

(Back-end)

Integrating views and

M3 November 12, 2015 R1
designs
 (Integrating front-end and

back-end)

M4 Testing for initial release November 20, 20015 R2

M5 Issue tracker, user reviews, December 1, 2015 R2

web design integration

M6 Final release December 23, 2015 R2

7. Technical Process
Following would be the languages I would use to develop my application within
the stipulated time period:
Front-end development: Jquery, HTML, CSS, PHP.
Back-end development: PHP, MySQL.
For Android app: Java on Android SDK.
The blog is contributed by Anurag Mishra.
An SRS (Software Requirements Specification) is a document that outlines the
requirements for a software project. A well-written SRS is essential for a
successful software development project. Here are some tips for writing a good
SRS for your project:
 Start with a clear introduction: Provide an overview of the project and its
goals. Define the scope of the project and explain what the software is
intended to do.
 Use clear and concise language: The SRS should be easy to read and
understand. Avoid using technical jargon and complex sentences. Use bullet
points and tables to organize information.
 Describe the functional requirements: List the features and functionality
of the software. Explain how the software will work and what it will do. Use
cases to describe the interactions between the user and the software.
 Describe the non-functional requirements: In addition to functional
requirements, there may be non-functional requirements that are important
for the software. Examples include performance, scalability, security, and
usability.
 Specify any constraints: There may be constraints that limit the software
development project. For example, there may be limitations on the hardware
or software platforms that the software can run on.
 Use diagrams and visual aids: Use diagrams, flowcharts, and other visual
 aids to help explain the software and its features. This can help to make the
SRS more engaging and easier to understand.
 Define the acceptance criteria: Specify the criteria that must be met for the
software to be considered complete and ready for release. This should
include testing criteria and user acceptance criteria.
 Review and revise: Once the SRS is complete, review it carefully to ensure
that all requirements are clearly defined and that there are no ambiguities.
Make revisions as needed to improve the clarity and completeness of the
document.
Quality characteristics of a good Software Requirements Specification (SRS)
document include:
1. Complete: The SRS should include all the requirements for the software
system, including both functional and non-functional requirements.
2. Consistent: The SRS should be consistent in its use of terminology and
formatting, and should be free of contradictions.
3. Unambiguous: The SRS should be clear and specific, and should avoid using
vague or imprecise language.
4. Traceable: The SRS should be traceable to other documents and artifacts,
such as use cases and user stories, to ensure that all requirements are being
met.
5. Verifiable: The SRS should be verifiable, which means that the requirements
can be tested and validated to ensure that they are being met.
6. Modifiable: The SRS should be modifiable, so that it can be updated and
changed as the software development process progresses.
7. Prioritized: The SRS should prioritize requirements, so that the most
important requirements are addressed first.
8. Testable: The SRS should be written in a way that allows the requirements
to be tested and validated.
9. High-level and low-level: The SRS should provide both high-level
requirements (such as overall system objectives) and low-level requirements
(such as detailed functional requirements).
10.Relevant: The SRS should be relevant to the software system that is being
developed, and should not include unnecessary or irrelevant information.
11.Human-readable: The SRS should be written in a way that is easy for non-
technical stakeholders to understand and review.
12.Aligned with business goals: The SRS should be aligned with the overall
business goals and objectives of the organization, so that the software
system meets the needs of the business.
13.Agile methodologies: Agile methodologies, such as Scrum and Kanban,
provide an iterative approach to requirements capturing and validation,
 where requirements are captured and validated in small chunks of
functionality and feedback is gathered from the customer.
By keeping these quality characteristics in mind, developers and stakeholders can
ensure that the SRS document is clear, complete, and accurate, which in turn
can help to ensure that the final software system meets the needs of the
business and its users.
Following are the characteristics of a good SRS document:

1. Correctness:
User review is used to ensure the correctness of requirements stated in the
SRS. SRS is said to be correct if it covers all the requirements that are
actually expected from the system.

2. Completeness:
Completeness of SRS indicates every sense of completion including the
numbering of all the pages, resolving the to be determined parts to as much
extent as possible as well as covering all the functional and non-functional
requirements properly.

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 a criterion 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:
A SRS is verifiable if there exists a specific technique to quantifiably
measure the extent to which every requirement is met by the system. For
example, a requirement starting that the system must be user-friendly is not
verifiable and listing such requirements should be avoided.

8. Traceability:
One should be able to trace a requirement to design component and then to
code segment in the program. Similarly, one should be able to trace a
requirement to the corresponding test cases.

9. Design Independence:
There should be an option to choose from multiple design alternatives for
the final system. More specifically, the SRS should not include any
implementation details.

10.Testability:
A SRS should be written in such a way that it is easy to generate test cases
and test plans from the document.

11.Understandable by the customer:

An end user maybe an expert in his/her specific domain but might not be an
expert in computer science. Hence, the use of formal notations and symbols
should be avoided to as much extent as possible. The language should be
kept easy and clear.

12.Right level of abstraction:

If the SRS is written for the requirements phase, the details should be
explained explicitly. Whereas, for a feasibility study, fewer details can be
used. Hence, the level of abstraction varies according to the purpose of the
SRS.

Advantages of having a good Software Requirements Specification (SRS)

document include:
1. Improved communication and understanding between stakeholders and
developers, as the SRS clearly defines the requirements for the software
system
2. Increased efficiency in the software development process, as a well-written
SRS can help to reduce the need for rework and change requests
 3. Improved quality of the final software system, as a well-written SRS helps
to ensure that all requirements are met
4. Increased stakeholder satisfaction, as a well-written SRS helps to ensure that
the software system meets the needs of the business and its users
5. Improved traceability and verifiability, as a well-written SRS can be traced
to other documents and artifacts and its requirements can be tested and
validated.
6. Clarity and Completeness: A good SRS document provides clear and
complete specifications for the software project, which ensures that all
stakeholders have a common understanding of the requirements and
objectives.

7. Traceability: A good SRS document includes detailed requirements and

specifications, which enables traceability throughout the software
development process.

8. Testability: A good SRS document can serve as a basis for test cases and
verification, which can ensure that the software meets the requirements and
specifications.

9. Improved Communication: A good SRS document can serve as a

communication tool between different stakeholders, such as project
managers, developers, testers, and customers.

10.Reduced Rework: A good SRS document can help to identify and resolve
issues early in the development process, which can reduce the need for
rework and improve the overall quality of the software.
Disadvantages of having a poorly written SRS include:
1. Confusion and misunderstandings between stakeholders and developers, as
the requirements are not clearly defined or are vague
Increased rework and change requests, as the SRS does not accurately
capture the requirements of the software system
2. Reduced quality of the final software system, as a poorly written SRS can
result in requirements being missed or not fully met
3. Reduced stakeholder satisfaction, as a poorly written SRS does not
accurately capture the needs of the business and its users
4. Reduced traceability and verifiability, as a poorly written SRS can’t be
traced to other documents and artifacts and its requirements can’t be tested
and validated.
5. It is important to note that, regardless of the quality of the SRS, gathering
 and validating requirements is an iterative process, that should be
continuously reviewed and updated throughout the software development
process.
6. Time-consuming: Creating a good SRS document can be a time-consuming
process, especially for complex software projects, which can delay the
development process.

7. Changes and Updates: Changes or updates to the SRS document can cause
delays in the software development process and can be difficult to manage.

8. Lack of Flexibility: A detailed SRS document can restrict the flexibility of

the development process, which can be challenging for projects that require
agile development methodologies.

9. Limited Stakeholder Involvement: The process of creating an SRS document

can limit the involvement of stakeholders in the software development
process, which can lead to a lack of collaboration and input from different
perspectives.

10.Ambiguity: A poorly written SRS document can lead to ambiguity and

misunderstandings, which can cause issues throughout the software
development process.

Software Engineering | Requirements Elicitation

Requirements elicitation is the process of gathering and defining the

requirements for a software system. The goal of requirements elicitation is to
ensure that the software development process is based on a clear and
comprehensive understanding of the customer’s 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. The output of the requirements elicitation process is a set of clear,
concise, and well-defined requirements that serve as the basis for the design
and development of the software system.
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 Activities:
Requirements elicitation includes the subsequent activities. Few of them are
listed below –
 Knowledge of the overall area where the systems is applied.
 The details of the precise customer problem where the system is going to be
applied must be understood.
 Interaction of system with external requirements.
 Detailed investigation of user needs.
 Define the constraints for system development.
Requirements elicitation Methods:
There are a number of requirements elicitation methods. Few of them are listed
below –
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
The success of an elicitation technique used depends on the maturity of the
analyst, developers, users, and the customer involved.
1. Interviews:
Objective of conducting an interview is to understand the customer’s
expectations from the software.
It is impossible to interview every stakeholder hence representatives from
groups are selected based on their expertise and credibility.
Interviews maybe be open-ended or structured.
1. In open-ended interviews there is no pre-set agenda. Context free questions
may be asked to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared.
Sometimes a proper questionnaire is designed for the interview.
2. Brainstorming Sessions:
 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.
 Finally, a document is prepared which consists of the list of requirements
and their priority if possible.
3. Facilitated Application Specification Technique:
ts objective is to bridge the expectation gap – the difference between what the
developers think they are supposed to build and what customers think they are
going to get. A team-oriented approach is developed for requirements
gathering. Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
Each participant prepares his/her list, different lists are then combined, redundant
entries are eliminated, team is divided into smaller sub-teams to develop mini-
specifications and finally a draft of specifications is written down using all the
inputs from the meeting.
4. Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it
emphasizes on the requirements which are valuable to the customer.
3 types of requirements are identified –
 Normal requirements –
In this the objective and goals of the proposed software are discussed with
the customer. Example – normal requirements for a result management
system may be entry of marks, calculation of results, etc
 Expected requirements –
These requirements are so obvious that the customer need not explicitly state
them. Example – protection from unauthorized access.
 Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be
very satisfying when present. Example – when unauthorized access is
detected, it should backup and shutdown all processes.
The major steps involved in this procedure are –
1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as –
 It is possible to achieve
 It should be deferred and the reason for it
 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 –
It is the external agent that lies outside the system but interacts with it in
some way. 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 stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use
case.
Features of requirements elicitation:
1. Stakeholder engagement: Requirements elicitation involves engaging with
stakeholders such as customers, end-users, project sponsors, and subject
matter experts to understand their needs and requirements.
2. Gathering information: Requirements elicitation involves gathering
information about the system to be developed, the business processes it will
support, and the end-users who will be using it.
3. Requirement prioritization: Requirements elicitation involves prioritizing
requirements based on their importance to the project’s success.
4. Requirements documentation: Requirements elicitation involves
documenting the requirements in a clear and concise manner so that they can
be easily understood and communicated to the development team.
5. Validation and verification: Requirements elicitation involves validating
and verifying the requirements with the stakeholders to ensure that they
accurately represent their needs and requirements.
6. Iterative process: Requirements elicitation is an iterative process that
involves continuously refining and updating the requirements based on
feedback from stakeholders.
7. Communication and collaboration: Requirements elicitation involves
 effective communication and collaboration with stakeholders, project team
members, and other relevant parties to ensure that the requirements are
clearly understood and implemented.
8. Flexibility: Requirements elicitation requires flexibility to adapt to changing
requirements, stakeholder needs, and project constraints.
Advantages of Requirements Elicitation:
 Helps to clarify and refine customer requirements.
 Improves communication and collaboration between stakeholders.
 Increases the chances of developing a software system that meets 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.
Software Engineering | Challenges in eliciting requirements

Eliciting requirements is one of the most challenging aspects of software

engineering. Some common challenges include:
1. Understanding the user’s needs: Requirements are often poorly defined
and may change over time, making it difficult for engineers to understand
the user’s true needs.
2. Managing stakeholders: There may be multiple stakeholders with different
goals and priorities, making it difficult to satisfy everyone’s requirements.
3. Identifying and mitigating risks: Engineers must identify and mitigate
potential risks associated with the requirements, such as security
 vulnerabilities or scalability issues.
4. Handling ambiguity: Requirements may be ambiguous, inconsistent, or
incomplete, making it difficult for engineers to understand what the system
should do.
5. Keeping up with changing technology: Requirements must be aligned with
the latest technology trends and innovations, which can be difficult to
predict and keep up with.
6. Maintaining a balance between feasibility, cost and time: Engineers need to
balance the feasibility of implementing a requirement, the cost of
implementation, and the time required to implement it.
7. Maintaining traceability: Engineers need to maintain traceability of
requirements throughout the development process to ensure that all
requirements are met and any changes are tracked.
Eliciting requirements is the first step of the Requirement Engineering process. It
helps the analyst to gain knowledge about the problem domain which in turn is
used to produce a formal specification of the software. There are a number of
issues and challenges encountered during this process.
Prerequisite – Requirements Elicitation
Some of them are as follows:
1. Understanding large and complex system requirements is difficult: The
word ‘large’ represents 2 aspects:
 (i) Large constraints in terms of security, etc. due to a large number of
users.
 (ii) a Large number of functions to be implemented.
2. Undefined system boundaries: There might be no defined set of
implementation requirements. The customer may go on to include several
unrelated and unnecessary functions besides the important ones, resulting in
an extremely large implementation cost that may exceed the decided
budget.
3. Customers/Stakeholders are not clear about their needs: Sometimes, the
customers themselves may be unsure about the exhaustive list of
functionalities they wish to see in the software. This might happen when
they have a very basic idea about their needs but haven’t planned much
about the implementation part.
4. Conflicting requirements are there: There is a possibility that two
different stakeholders of the project express demands which contradict each
other’s implementation. Also, a single stakeholder might also sometimes
express two incompatible requirements.
5. Changing requirements is another issue: In the case of successive
interviews or reviews from the customer, there is a possibility that the
 customer expresses a change in the initial set of specified requirements.
While it is easy to accommodate some of the requirements, it is often
difficult to deal with such changing requirements.

6. Partitioning the system suitably to reduce complexity: The projects can

sometimes be broken down into small modules or functionalities which are
then handled by separate teams. Often, more complex and large projects
require more partitioning. It needs to be ensured that the partitions are non-
overlapping and independent of each other.
7. Validating and Tracing requirements: Cross-checking the listed
requirements before starting the implementation part is very important. Also,
there should be forward as well as backward traceability. For eg, all the
entity names should be the same everywhere, i.e., there shouldn’t be a case
where ‘STUDENT’ and ‘STUDENTS’ are used at separate places to refer to
the same entity.
8. Identifying critical requirements: Identifying the set of requirements that
have to be implemented at any cost is very important. The requirements
should be prioritized so that crucial ones can be implemented first with the
highest priority.
9. Resolving the “to be determined” part of the requirements: The TBD set
of requirements include those requirements which are yet to be resolved in
the future. The number of such requirements should be kept as low as
possible.
10.Proper documentation, proper meeting time, and budget constraints –
Ensuring proper documentation is an inherent challenge, especially in the
case of changing requirements. The time and budget constraints too need to
be handled carefully and systematically.
Solutions to Overcome Challenges in Eliciting Requirements:
1. Maintaining proper documentation.
2. Trying to understand from a stakeholder’s perspective.
3. Establishing proper communication with stakeholders.
4. Identifying conflicting requirements from the stakeholder side.
5. Establishing structured and insightful discussions with end-users.
6. Performing proper market research and competitor analysis.
Advantages or Disadvantages:
Advantages of eliciting requirements in software engineering include:
1. Improved communication: Eliciting requirements helps to improve
communication between stakeholders, developers, and users, which can
result in a better understanding of the user’s needs and a more successful end
product.
 2. Reduced rework: By identifying and addressing requirements early on in the
development process, engineers can reduce the likelihood of costly rework
later on.
3. Increased user satisfaction: By thoroughly understanding and addressing the
user’s needs, engineers can create software that is more likely to meet the
user’s expectations and result in increased satisfaction.
4. Improved system quality: By identifying and mitigating risks associated
with the requirements, engineers can improve the overall quality of the
system.
5. Better alignment with business goals: By aligning the requirements with the
business goals, engineers can ensure that the software is developed in a way
that supports the overall objectives of the organization.
Disadvantages of eliciting requirements in software engineering include:
1. Time-consuming: Eliciting requirements can be a time-consuming process,
which can slow down the development process.
2. Costly: Gathering requirements can be costly, especially when involving
multiple stakeholders.
3. Risk of changing requirements: Requirements may change over time, which
can lead to confusion and require additional work to keep the project aligned
with the updated requirements.
4. Difficulty in identifying all the requirements: It can be difficult to identify
all the requirements, especially when dealing with complex systems or new
technologies.
5. Difficulty in predicting future requirements: It can be difficult to predict
future requirements, which can result in the software becoming outdated or
needing to be redesigned.
6. Difficulty in handling user’s changing needs: As the users start using the
system they might realize that they need something that was not anticipated
during the requirements gathering phase.

Software Engineering | Architectural Design

Introduction: The software needs the architectural design to represents the

design of software. IEEE defines architectural design as “the process of
defining a collection of hardware and software components and their interfaces
to establish the framework for the development of a computer system.” The
software that is built for computer-based systems can exhibit one of these
many architectural styles.
The software architecture of a program or computing system is the
Structure or structures of the system, which comprise software elements, the
externally visible properties of those elements, and the relationships among
them.
Each style will describe a system category that consists of :

 A set of components(eg: a database, computational modules) that will

perform a function required by the system.
 The set of connectors will help in coordination, communication, and
cooperation between the components.
 Conditions that how components can be integrated to form the system.
 Semantic models that help the designer to understand the overall properties
of the system.
The use of architectural styles is to establish a structure for all the components of
the system.

Taxonomy of Architectural styles:

1] Data centered architectures:

 A data store will reside at the center of this architecture and is accessed
frequently by the other components that update, add, delete or modify the
data present within the store.
 The figure illustrates a typical data centered style. The client software access
a central repository. Variation of this approach are used to transform the
repository into a blackboard when data related to client or data of interest for
the client change the notifications to client software.
 This data-centered architecture will promote integrability. This means that
the existing components can be changed and new client components can be
added to the architecture without the permission or concern of other clients.
 Data can be passed among clients using blackboard mechanism.
Advantage of Data centered architecture
 Repository of data is independent of clients
 Client work independent of each other
 It may be simple to add additional clients.
 Modification can be very easy
Data centered architecture
2] Data flow architectures:

 This kind of architecture is used when input data is transformed into output
data through a series of computational manipulative components.
 The figure represents pipe-and-filter architecture since it uses both pipe and
filter and it has a set of components called filters connected by lines.
 Pipes are used to transmitting data from one component to the next.
 Each filter will work independently and is designed to take data input of a
certain form and produces data output to the next filter of a specified form.
The filters don’t require any knowledge of the working of neighboring
filters.
 If the data flow degenerates into a single line of transforms, then it is termed
as batch sequential. This structure accepts the batch of data and then applies
a series of sequential components to transform it.
Advantages of Data Flow architecture
 It encourages upkeep, repurposing, and modification.
 With this design, concurrent execution is supported.
The disadvantage of Data Flow architecture
 It frequently degenerates to batch sequential system
 Data flow architecture does not allow applications that require greater user
engagement.
 It is not easy to coordinate two different but related streams
Data Flow architecture
3] Call and Return architectures: It is used to create a program that is easy
to scale and modify. Many sub-styles exist within this category. Two of them
are explained below.

 Remote procedure call architecture: This components is used to present in

a main program or sub program architecture distributed among multiple
computers on a network.
 Main program or Subprogram architectures: The main program structure
decomposes into number of subprograms or function into a control
hierarchy. Main program contains number of subprograms that can invoke
other components.
4] Object Oriented architecture: The components of a system encapsulate
data and the operations that must be applied to manipulate the data. The
coordination and communication between the components are established via
the message passing.
Characteristics of Object Oriented architecture
 Object protect the system’s integrity.
 An object is unaware of the depiction of other items.
Advantage of Object Oriented architecture
 It enables the designer to separate a challenge into a collection of
autonomous objects.
 Other objects are aware of the implementation details of the object, allowing
changes to be made without having an impact on other objects.
5] Layered architecture:

 A number of different layers are defined with each layer performing a well-
defined set of operations. Each layer will do some operations that becomes
closer to machine instruction set progressively.
 At the outer layer, components will receive the user interface operations and
at the inner layers, components will perform the operating system
interfacing(communication and coordination with OS)
 Intermediate layers to utility services and application software functions.
 One common example of this architectural style is OSI-ISO (Open Systems
Interconnection-International Organisation for Standardisation)
 communication system.

Layered architecture: