UNIT-I

Introduction: Software and its Characteristics, Evolving Role of Software, Software Product,
Software Processes, Software Crisis, ‘Software Engineering’ Evolution, Principles of
Software Engineering, Programming-in-the-small vs. Programming-in-the-large, Software
Components, Software Engineering Processes.
Software Life Cycle (SLC) Models: Water Fall Model, Prototype Model, Spiral Model,
Evolutionary Development Models, Iterative Enhancement Models, Object Oriented Models
and other latest Models.
Software Requirements: Functional and Non-Functional, User requirements, System
requirements. Software Requirements Document – Requirement Engineering Process:
Feasibility Studies, Requirements elicitation and analysis, requirements validation,
requirements management.

What is Software Engineering?

The term Software Engineering is made of two words, software and engineering.
Software is more than just a program code. A program is an executable code, which serves
some computational purpose. Software is considered to be collection of executable
programming code, associated libraries and documentations. Software, when made for a
specific requirement is called software product.
Engineering on the other hand, is all about developing products, using well defined, scientific
principles and methods. It is the application of scientific and practical knowledge to invent,
design, build, maintain, and improve frameworks, processes, etc.
Software engineering is an engineering branch associated with development of software
product using well-defined scientific principles, methods and procedures. The outcome of
software engineering is an efficient and reliable software product.
The software is a collection of programming codes, procedures, rules, documents, and data
that perform a particular task and fulfil a particular requirement. Software is never exhausted
or worn out. In a computer system, software controls integrate and manage the hardware
components.

Characteristics of Software
The quality of a software product is determined by what it offers and how easily it can be used.
Software is judged by different people on different grounds. Customers, for instance, want software
that meets their specific needs. Similarly, developers engaged in designing, coding, and maintaining
the software determine the quality of the software by assessing its internal characteristics. Let’s check
them out…
1. Functionality
The functionality of software refers to its ability to perform and function according to design
specifications. In simple terms, software systems should function correctly, i.e. perform all the
functions for which they are designed. The functions refer to the features that the end user, as well as
the business, expect as basic facilities from the system. All these functions must be integrated into the
system.
2. Usability (User-friendly)
The user-friendliness of the software is characterized by its ease of use. In other words, learning how
to use the software should require less effort or time. If a software program isn’t user-friendly, users
may have trouble navigating the software and using some of its features. Software should require less
time or effort to learn. Ideally, software should be easy to use even by people with no IT experience.
3. Efficiency
Essentially, it refers to the software’s ability to utilize human and system resources such as time,
effort, CPU, memory, computation power, network bandwidth, files, databases, etc., as effectively and
efficiently as possible. For a software project to succeed, efficiency is crucial. In addition to meeting
the needs for which the software was made, it must also provide excellent features designed to assist
users in completing their tasks faster. Software should make efficient use of storage space and execute
commands according to timing requirements.
In order to be efficient, software must offer users proper value in terms of their time and cash. The
market is filled with products that cater to various industries, but only a handful of products are
efficient enough to benefit individuals and businesses. The medical billing software that Open
Practice Solutions provides, for instance, makes billing processes much more efficient for clients than
those offered by other companies.
4. Flexibility
Software Flexibility refers to the ability of the software solution to adapt to potential or future changes
in its requirements. When evaluating the flexibility of software, look at how simple it is to add,
modify, or remove features without interfering with the current operation.
It is essential to keep up with rapidly changing markets, technologies, and customer needs. In
software development, change is inevitable; it can arise during the development process itself or as
the result of future requirements. Flexibility is therefore highly valued. Consequently, any software
product must be scalable, flexible, and easily adaptable to future technology.
5. Reliability
The reliability of a software product describes the likelihood it will operate without failure over a
specified period of time under certain conditions. It determines the ability of software to maintain its
level of performance (provide desired functionality) under specified conditions for a specified period
of time.
6. Maintainability
Maintainability refers to how easily you can repair, improve and comprehend software code. In some
ways, maintaining is similar to being flexible. Maintainability deals with the modification of errors
and minor alterations to software code, while flexibility focuses on major functional extensions. It
also involves maintaining the services and functionality of the software.
7. Portability
Software portability is a critical factor that cannot be ignored. Portability refers to the ability to use
software in different environments. This is the ease with which software can be ported from one
platform to another without (or with minimal) changes, while obtaining similar results. As simple as it
may sound, it refers to the ability of software to work on different hardware platforms without any (or
little) modifications needed.
8. Integrity

Integrity is key for demonstrating the safety, security, and maintainability of your software.
In addition, software that needs to be compliant with industry regulations and coding
standards requires high code integrity. Achieving software integrity can be difficult. Yet, with
the right practices to improve safety, security, and maintainability, the challenge can be easily
overcome. In these days of increased security threats, all software must include this factor.

Software Evolution

Software evolution refers to the process of adapting, improving, and maintaining software
over time to meet changing user needs, fix issues, and keep up with technological
advancements. Software is not static; it undergoes continuous changes throughout its
lifecycle to remain useful and effective in a dynamic environment.

Why is Software Evolution Necessary?

1. Changing User Needs

As time passes, user’s requirements evolve. For example, a business may need new
features to handle increased workloads or adapt to market trends. Software must
change to accommodate these new demands.
2. Advances in Technology
Technology evolves rapidly. New operating systems, programming tools, and
hardware emerge, making older software obsolete. To stay compatible and leverage
new capabilities, software must be updated.
3. Bug Fixing and Reliability
No software is perfect. Bugs or security vulnerabilities may surface after deployment.
These need to be addressed promptly to ensure that the software remains reliable and
secure.
4. Improved Performance
Over time, users expect software to be faster, more efficient, and scalable. Updates
may focus on optimizing the software to handle more data, run faster, or consume
fewer resources.
5. Competition and Market Trends
To stay competitive, software must incorporate the latest features, integrate with new
tools, and meet modern standards. Failure to evolve can result in losing relevance in
the market.

Software Products

Software Products are nothing but software systems delivered to the customer with the
documentation that describes how to install and use the system. In certain cases, software
products may be part of system products where hardware, as well as software, is delivered
to a customer. Software products are produced with the help of the software process. The
software process is a way in which we produce software.

Types of Software Products

Software products fall into two broad categories:
1. Generic products: Generic products are stand-alone systems that are developed by a
production unit and sold on the open market to any customer who can buy them (e.g.,
Microsoft Word, web browsers).
2. Customized Products: Customized products are the systems that are commissioned by
a particular customer. Some contractor develops the software for that customer (e.g.,
payroll systems, enterprise applications).

Software Processes

Software processes refer to the structured steps and methodologies followed to design,
develop, deploy, and maintain software. A well-defined software process ensures quality,
efficiency, and timely delivery of software products.

Key Phases in a Software Process:

1. Requirement Analysis: Understanding and documenting user needs.

2. Design: Creating a blueprint for the software, including architecture and user
interface.
3. Implementation (Coding): Writing and testing the code.
4. Testing: Identifying and fixing bugs to ensure the software works as intended.
5. Deployment: Delivering the software to the end-users.
6. Maintenance: Updating and fixing the software after deployment.

Software Process Models:

1. Waterfall Model: Sequential and linear, with clear stages and no overlap.
2. Agile Model: Iterative and incremental, emphasizing flexibility and customer
collaboration.
3. Spiral Model: Combines iterative development with risk analysis.
4. DevOps: Integrates development and operations for continuous delivery and
deployment.

 Reduction in software over budget.

 The quality of the software must be high.
 Less time is needed for a software project.
 Experienced and skilled people working on the software project.
 Software must be delivered.
 Software must meet user requirements.

Software Crisis
There are lots of meaning of term software crisis. First of all we go in history and what was
the scenario at that time.
Hardware Oriented World: There was more focus on the hardware and software as people
were more focusing on thathow instructions can be executed fast.Not on how bugs should
be removed frequently.
Cost: Hardware vs Software
Rapid increase in software cost and Rapid fall in hardware cost need more resources and well
defined and systematic model for software development.
Inexperienced Developer:
Developer were hardly one year of experienced old so quite difficult for them to fulfill all
coding based requirement.
Failures in Big project:
Big failure in project cost government billions of dollars like
1) the North East blackout in 2003- has been major power system failures in the history of
north which involves 100 power plants, 50 million customer faced problem, $ 6 million
dollar financial loss.
2) Year 2000(Y2k) refers to the widespread snags in processing date after the Year 2000. In
1960-80 when shortened the four digit date format like 1972 to a 2 digit format like 72
because of "Limited Memory. Because of that 2000 was shortened to 00. Million dollar
were spent to handle this problem.
3) Arian- 5 Space Rocket: In 1996, developed at cost of $7000 Million Dollars over a
period of 10 years was destroyed within less than 1 minutes after its launch. As there was
software bugs in rocket guidance system.
4) "Dollar 924 lakhs": In 1996, US bank credit accounts of nearly 800 customer with dollar
924 lakhs. This problem was due to main programming bug in the banking system.
5)1991 during Gulf War, :The USA use patriot missiles as a defence against Iraqi scud
missile . However, patriot failed to hit the scud many times with cost life of 28 USA
soldiers.In an inquiry it is found that a small bug had resulted in miscalculation of
missile path.
User changing requirement:
As user changes its requirement slightly as world and technology changing rapidly.

What is Software Crisis :

The difficulty of writing the code for a computer program which is correct and understandable is referred

to as software crisis.

or Software crisis is also referred to as inability to hire enough qualified programmers.

Causes of Software Crisis
Following are the causes of Software Crisis:
1. The cost of owning and maintaining software was as expensive as developing the
software.
2. At that time Projects were running overtime.
3. At that time Software was very inefficient.
4. The quality of the software was low quality.
5. Software often did not meet user requirements.
6. The average software project overshoots its schedule by half.
7. At that time Software was never delivered.
8. Non-optimal resource utilization.
9. Challenging to alter, debug, and enhance.
10. The software complexity is harder to change.
11. Factors Contributing to Software Crisis

Factor Contributing to Software Crisis are:

1. Poor project management.
2. Lack of adequate training in software engineering.
3. Less skilled project members.
4. Low productivity improvements.
5. Solution of Software Crisis:
There is no single solution to the crisis. One possible solution to a software crisis is Software
Engineering because software engineering is a systematic, disciplined, and quantifiable
approach. For preventing software crises, there are some guidelines:
1. Reduction in software over budget.
2. The quality of the software must be high.
3. Less time is needed for a software project.
4. Experienced and skilled people working on the software project.
 5. Software must be delivered.
6. Software must meet user requirements.

Principles of Software Engineering

The principles of software engineering provide engineers with guidelines about how they
should write error-free, clear, and maintainable code.
The following are the principles and tactics we must employ to stay grounded and to make
reasonable technical choices based upon requirements, budgets, timelines, and expectations.
Living by these principles will help your project progress seamlessly.
KISS (Keep It Simple, Stupid)
The principle of simplicity states that codes should be as simple as possible without a
complicated structure, otherwise debugging and maintenance might be more difficult.
Moreover, another programmer will have a harder time understanding the code logic, which
will entail more time and effort.
You, along with co-workers, can identify bugs faster with Always Keep It Simple, Stupid
(KISS). The principle also makes it easier to modify and improve code.
DRY (Don’t Repeat Yourself)
The principle of DRY states that we shouldn’t repeat the same thing too many times in too
many places. In software systems, it aims to reduce repetitive code and effort. Developers
unknowingly re-write code repeatedly. When writing your code, don’t copy-paste the same
code repeatedly. If you don’t, then you’ll need to keep them in sync; any change in code at
one place will need to be done at other places. It will take extra time, effort, and attention
(which isn’t always easy).
YAGNI (You Aren’t Gonna Need It)
In accordance with this principle, programmers should not include functionality unless it is
absolutely necessary. It states that you shouldn’t introduce things to solve future problems
that don’t exist yet. In most cases, programmers try to implement all the functionality at once,
right from the beginning.
It is recommended to implement only the essential features first, and then, as necessary,
expand them. YAGNI also avoids complexity, specifically that which comes from adding
features that may be necessary for the future.
BDUF (Big Design Upfront)
According to this principle, a developer should design the project first, create the flow of the
diagram, and then implement it later. Before developing functionality, we should first think
about the architecture and design of the whole system to the smallest details, and then follow
the steps outlined in our plan to implement it.
This helps uncover issues at the requirements stage and resolve them quickly. It is possible,
however, that software requirements may change during the project’s life cycle and such
changes to software requirements may result in difficulties or may even render the design
obsolete. The best way to handle this would be by designing the architecture first, then
dividing the requirements into stages according to their priority. Develop from the highest
priority stage to the lowest during the development process. Prior to coding, implement the
BDUF principle at each step.
SOLID
SOLID is an acronym for a collection of object-oriented design principles. Each letter in
the”SOLID” stands for one of the following principles:
S – SRP (Single Responsibility Principle): According to the Single Responsibility
Principle, a class, function, module, or service must have only one reason to change, i.e., it
must have only one responsibility. Yet why is this so important?
When you write classes or functions that are dedicated to a single functionality, it becomes
easier to understand, maintain, and modify your code.
If you want to modify the functionality of the system, you would know the exact DRY
location where you have to modify the code.
It makes the code more organized and readable. It also makes reusing the code easier.
O – OCP (Open Closed Principle): In software development, we work in phases. As a team,
we implement a bunch of functionalities, test them, and then deliver them to the users. We
then move on to implementing the next set of functionalities. When it comes to developing
new functionality, the last thing we want to do is to change the existing functionality, which
has been tested and is working. Therefore, we try to add new functionality on top of existing
ones.
This idea is facilitated by the Open-Closed principle. According to it, our functions, classes,
and modules should be designed in such a way that they’re open for extension, but closed for
modification.
Open for Extension: New functionality can be added to classes and modules without
breaking the existing code. Composition and inheritance can be used to accomplish this.
Closed for Modification: It’s ideal not to make changes that break current functionality, as
doing so would require refactoring a lot of existing code and writing several tests to ensure
the changes work.
L – LSP (Liskov Substitution Principle): According to the Liskov Substitution Principle,
all child/derived classes should be replaceable for their parent/base classes without affecting
or breaking the program’s correctness. Thus, objects in your subclass (derived/child class)
should behave similarly to objects in your superclass (parent/base class). Therefore, you
should use inheritance carefully in your projects. While inheritance can be beneficial, it is
advisable to use it moderately and contextually. Before you can perform inheritance, you
have to consider the postconditions and preconditions of the class.
I – ISP (Interface Segregation Principle): According to the Interface Segregation Principle,
clients shouldn’t be forced to depend or rely on methods that they don’t use. How can this be
achieved? Simple: make your interfaces short or small and focused. An interface with a lot of
behaviors is hard to maintain and evolve. Therefore, Separate large interfaces into smaller
ones, each focused on a specific set of functions, so that choose to depend or rely only on the
functionalities that they require
D – DIP (Dependency Inversion Principle): This Principle seeks to eliminate tight
coupling between software modules. According to this principle, high-level modules should
not depend on lower-level modules, but rather on their abstractions. We can break it down
into two parts:
1. A high-level module must be independent of a low-level module. Both should rely on
abstractions
2. The abstraction should be independent of the details, while the details should be
dependent upon the abstractions.
1.KISS (Keep It Simple, Stupid)
Strive for simplicity in design and implementation
Avoid unnecessary complexity that can hinder understanding and maintainability
Focus on creating clean, readable, and concise code
2. DRY (Don’t Repeat Yourself)
Eliminate redundancy in code and processes
Promote code reuse and modular design to improve efficiency and reduce errors
Centralize common functionalities and avoid duplication
3. YAGNI (You Aren’t Gonna Need It)
Implement features that are currently required and avoid over-engineering
Resist the temptation to add unnecessary functionality that may never be used
Focus on delivering value incrementally and iteratively
4. Separation of Concerns
Divide software into distinct, independent modules or components
Each module should have a clear responsibility and minimal overlap with others
Promote loose coupling and high cohesion for maintainability and scalability
5. Modularity
Design software as a collection of interchangeable, reusable modules
Encapsulate related functionalities into self-contained units
Enable easy modification, testing, and replacement of individual modules
6. Single Responsibility Principle (SRP)
Each module, class, or function should have a single, well-defined responsibility
Avoid mixing multiple concerns within a single unit of code
Facilitate understanding, testing, and maintenance of the codebase
7. Open-Closed Principle (OCP)
Software entities should be open for extension but closed for modification
Encourage the use of abstractions and interfaces to enable extensibility
Minimize the impact of changes on existing code
8. Liskov Substitution Principle (LSP)
Subtypes should be substitutable for their base types without affecting correctness
Ensure that derived classes adhere to the contract of their parent classes
Maintain behavioral consistency and avoid unexpected side effects
9. Interface Segregation Principle (ISP)
Clients should not be forced to depend on interfaces they do not use
Split large interfaces into smaller, more specific ones
Promote loose coupling and improve modularity
10. Dependency Inversion Principle (DIP)
High-level modules should depend on abstractions, not concrete implementations
Invert the dependency flow to make code more flexible and testable
Utilize dependency injection and interfaces to decouple modules.

Programming-in-the-Small

This refers to the development of small-scale software components, modules, or programs. It

focuses on individual tasks and is typically the domain of a single developer or a small team.

Characteristics:

 Scope: Limited to small programs or individual modules within a larger system.

 Team Size: Usually involves one or a few developers.
 Focus:
o Writing specific algorithms or functions.
o Ensuring that code is syntactically correct and logically sound.
o Debugging and testing at the unit level.
 Complexity: Lower complexity, as it deals with a smaller portion of the system.
 Example Activities:
o Writing a sorting algorithm.
o Creating a single microservice or API endpoint.
o Implementing a user interface widget.
Challenges:

 Writing efficient and error-free code.

 Ensuring functionality and correctness.
 Understanding local details of the implementation.

Programming-in-the-Large

This refers to the development of large-scale, complex software systems. It focuses on the
collaboration of multiple teams and managing the integration of many components.

Characteristics:

 Scope: Involves designing, implementing, and maintaining large systems composed

of many interacting components or modules.
 Team Size: Often involves multiple teams or organizations working together.
 Focus:
o System architecture and design.
o Coordination between different teams or modules.
o Version control, configuration management, and integration testing.
 Complexity: High complexity, as it involves managing interactions and dependencies
among various parts of the system.
 Example Activities:
o Developing an entire e-commerce platform.
o Creating and maintaining a large-scale enterprise application (e.g., ERP,
CRM).
o Building distributed systems like cloud services or data-processing pipelines.

Challenges:

 Communication and collaboration among team members.

 Managing dependencies and interfaces between modules.
 Ensuring scalability, maintainability, and reliability of the system.
 Handling configuration, deployment, and updates for a large system.

Waterfall model
Winston Royce introduced the Waterfall Model in 1970.This model has five phases:
Requirements analysis and specification, design, implementation, and unit testing, integration
and system testing, and operation and maintenance. The steps always follow in this order and
do not overlap. The developer must complete every phase before the next phase begins. This
model is named "Waterfall Model", because its diagrammatic representation resembles a
cascade of waterfalls.

1. Requirements analysis and specification phase: The aim of this phase is to understand
the exact requirements of the customer and to document them properly. Both the customer
and the software developer work together so as to document all the functions, performance,
and interfacing requirement of the software. It describes the "what" of the system to be
produced and not "how."In this phase, a large document called Software Requirement
Specification (SRS) document is created which contained a detailed description of what the
system will do in the common language.

2. Design Phase: This phase aims to transform the requirements gathered in the SRS into a
suitable form which permits further coding in a programming language. It defines the overall
software architecture together with high level and detailed design. All this work is
documented as a Software Design Document (SDD).

3. Implementation and unit testing: During this phase, design is implemented. If the SDD
is complete, the implementation or coding phase proceeds smoothly, because all the
information needed by software developers is contained in the SDD.

During testing, the code is thoroughly examined and modified. Small modules are tested in
isolation initially. After that these modules are tested by writing some overhead code to check
the interaction between these modules and the flow of intermediate output.

4. Integration and System Testing: This phase is highly crucial as the quality of the end
product is determined by the effectiveness of the testing carried out. The better output will
lead to satisfied customers, lower maintenance costs, and accurate results. Unit testing
determines the efficiency of individual modules. However, in this phase, the modules are
tested for their interactions with each other and with the system.

5. Operation and maintenance phase: Maintenance is the task performed by every user
once the software has been delivered to the customer, installed, and operational.

When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most suited are:

o When the requirements are constant and not changed regularly.

o A project is short
o The situation is calm
 o Where the tools and technology used is consistent and is not changing
o When resources are well prepared and are available to use.

Advantages of Waterfall model

o This model is simple to implement also the number of resources that are required for
it is minimal.
o The requirements are simple and explicitly declared; they remain unchanged during
the entire project development.
o The start and end points for each phase is fixed, which makes it easy to cover
progress.
o The release date for the complete product, as well as its final cost, can be determined
before development.
o It gives easy to control and clarity for the customer due to a strict reporting system.

Disadvantages of Waterfall model

o In this model, the risk factor is higher, so this model is not suitable for more
significant and complex projects.
o This model cannot accept the changes in requirements during development.
o It becomes tough to go back to the phase. For example, if the application has now
shifted to the coding phase, and there is a change in requirement, It becomes tough to
go back and change it.
o Since the testing done at a later stage, it does not allow identifying the challenges and
risks in the earlier phase, so the risk reduction strategy is difficult to prepare.

Prototyping Model

Prototyping is defined as the process of developing a working replication of a product or

system that has to be engineered. It offers a small-scale copy of the end product and is used
for obtaining customer feedback.

The Prototyping Model is one of the most popularly used Software Development Life Cycle
Models (SDLC models). This model is used when the customers do not know the exact
project requirements beforehand. In this model, a prototype of the end product is first
developed, tested, and refined as per customer feedback repeatedly till a final acceptable
prototype is achieved which forms the basis for developing the final product.
In this process model, the system is partially implemented before or during the analysis phase
thereby allowing the customers to see the product early in the life cycle. The process starts by
interviewing the customers and developing the incomplete high-level paper model. This
document is used to build the initial prototype supporting only the basic functionality as
desired by the customer. Once the customer figures out the problems, the prototype is further
refined to eliminate them. The process continues until the user approves the prototype and
finds the working model to be satisfactory.

Steps of Prototyping Model

Step 1: Requirement Gathering and Analysis: This is the initial step in designing a
prototype model. In this phase, users are asked about what they expect or what they want
from the system.

Step 2: Quick Design: This is the second step in the Prototyping Model. This model covers
the basic design of the requirement through which a quick overview can be easily described.

Step 3: Build a Prototype: This step helps in building an actual prototype from the
knowledge gained from prototype design.

Step 4: Initial User Evaluation: This step describes the preliminary testing where the
investigation of the performance model occurs, as the customer will tell the strengths and
weaknesses of the design, which was sent to the developer.

Step 5: Refining Prototype: If any feedback is given by the user, then improving the client’s
response to feedback and suggestions, the final system is approved.

Step 6: Implement Product and Maintain: This is the final step in the phase of the
Prototyping Model where the final system is tested and distributed to production, here the
program is run regularly to prevent failures.
Types of Prototyping Models
There are four types of Prototyping Models, which are described below.
1. Rapid Throwaway Prototyping
 This technique offers a useful method of exploring ideas and getting customer feedback
for each of them.
 In this method, a developed prototype need not necessarily be a part of the accepted
prototype.
 Customer feedback helps prevent unnecessary design faults and hence, the final prototype
developed is of better quality.
2. Evolutionary Prototyping
 In this method, the prototype developed initially is incrementally refined based on
customer feedback till it finally gets accepted.
 In comparison to Rapid Throwaway Prototyping, it offers a better approach that saves
time as well as effort.
 This is because developing a prototype from scratch for every iteration of the process can
sometimes be very frustrating for the developers.
3. Incremental Prototyping
 In this type of incremental prototyping, the final expected product is broken into different
small pieces of prototypes and developed individually.
 In the end, when all individual pieces are properly developed, then the different
prototypes are collectively merged into a single final product in their predefined order.
 It’s a very efficient approach that reduces the complexity of the development process,
where the goal is divided into sub-parts and each sub-part is developed individually.
 The time interval between the project’s beginning and final delivery is substantially
reduced because all parts of the system are prototyped and tested simultaneously.
 Of course, there might be the possibility that the pieces just do not fit together due to
some lack of ness in the development phase – this can only be fixed by careful and
complete plotting of the entire system before prototyping starts.
4. Extreme Prototyping
This method is mainly used for web development. It consists of three sequential independent
phases:
 In this phase, a basic prototype with all the existing static pages is presented in HTML
format.
 In the 2nd phase, Functional screens are made with a simulated data process using a
prototype services layer.
 This is the final step where all the services are implemented and associated with the final
prototype.
This Extreme Prototyping method makes the project cycling and delivery robust and fast and
keeps the entire developer team focused and centralized on product deliveries rather than
discovering all possible needs and specifications and adding necessitated features.

Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final product.

2. Require extensive customer collaboration
o Costs customer money
o Needs committed customer
o Difficult to finish if customer withdraw
o May be too customer specific, no broad market
3. Difficult to know how long the project will last.
4. Easy to fall back into the code and fix without proper requirement analysis, design,
customer evaluation, and feedback.
5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.

Spiral Model
The spiral model, initially proposed by Boehm, is an evolutionary software process model
that couples the iterative feature of prototyping with the controlled and systematic aspects of
the linear sequential model. It implements the potential for rapid development of new
versions of the software. Using the spiral model, the software is developed in a series of
incremental releases. During the early iterations, the additional release may be a paper model
or prototype. During later iterations, more and more complete versions of the engineered
system are produced.
Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of purpose for that
cycle, the various alternatives that are possible for achieving the targets, and the constraints
that exists.

Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is located
on the risk perception for the project.

Development and validation: The next phase is to develop strategies that resolve
uncertainties and risks. This process may include activities such as benchmarking, simulation,
and prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a choice made
whether to continue with a further period of the spiral. If it is determined to keep, plans are
drawn up for the next step of the project.

The development phase depends on the remaining risks. For example, if performance or user-
interface risks are treated more essential than the program development risks, the next phase
may be an evolutionary development that includes developing a more detailed prototype for
solving the risks.

The risk-driven feature of the spiral model allows it to accommodate any mixture of a
specification-oriented, prototype-oriented, simulation-oriented, or another type of approach.
An essential element of the model is that each period of the spiral is completed by a review
that includes all the products developed during that cycle, including plans for the next cycle.
The spiral model works for development as well as enhancement projects.

When to use Spiral Model?

o When deliverance is required to be frequent.

o When the project is large
 o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

Advantages

o High amount of risk analysis

o Useful for large and mission-critical projects.

Disadvantages

o Can be a costly model to use.

o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.

Evolutionary Model
This evolutionary model concept comes into the picture after the user faces the partially
developed system rather than waiting for the fully developed version. The idea of this
evolutionary model comes from developing the core module and then improving the software
product by using iterative and incremental techniques with appropriate feedback.

In this evolutionary process model, the software product is in the sensitive version, which is
made through many iterations, and then the final product is prepared. This evolutionary
approach also suggests breaking down all the models into maintainable smaller chunks. After
that, we can prioritize all the smaller products. After completing all the products, we can
deliver those chunks one at a time to the users.

It plays a vital role in large projects where we can easily search the module for the
implementation of incremental things. It is also an influential model because it collects
customer feedback throughout the development process, and the customer can use the base
feature of the project before the release of the entire working version.

The evolutionary model is also known as successive versions or incremental models. The
main aim of this evolutionary model is to deliver the products in total processes over time. It
also combines the iterative and collective model of the software development life cycle
(SDLC).

Based on the evolutionary model, we can divide the development model into many modules
to help the developer build and transfer incrementally. On the other hand, we can also
develop the skeleton of the initial product. Also, it refines the project to increase levels of
capability by adding new functionalities in successive versions.

Characteristics of the Evolutionary Model

There are so many characteristics of using the evolutionary model in our project. These
characteristics are as follows.
 o We can develop the evolutionary model with the help of an iterative waterfall model
of development.
o There are three types of evolutionary models. These are the Iterative model,
Incremental model and Spiral model.
o Many primary needs and architectural planning must be done
o to implement the evolutionary model.
o When the new product version is released, it includes the new functionality and some
changes in the existing product, which are also released with the latest version.
o This model also permits the developer to change the requirement, and the developer
can divide the process into different manageable work modules.
o The development team also have to respond to customer feedback throughout the
development process by frequently altering the product, strategy, or process.

Iterative Model
In this Model, you can start with some of the software specifications and develop the first
version of the software. After the first version if there is a need to change the software, then a
new version of the software is created with a new iteration. Every release of the Iterative
Model finishes in an exact and fixed period that is called iteration.

The Iterative Model allows the accessing earlier phases, in which the variations made
respectively. The final output of the project renewed at the end of the Software Development
Life Cycle (SDLC) process.

The various phases of Iterative model are as follows:

1. Requirement gathering & analysis: In this phase, requirements are gathered from
customers and check by an analyst whether requirements will fulfil or not. Analyst checks
that need will achieve within budget or not. After all of this, the software team skips to the
next phase.

2. Design: In the design phase, team design the software by the different diagrams like Data
Flow diagram, activity diagram, class diagram, state transition diagram, etc.
3. Implementation: In the implementation, requirements are written in the coding language
and transformed into computer programmes which are called Software.

4. Testing: After completing the coding phase, software testing starts using different test
methods. There are many test methods, but the most common are white box, black box, and
grey box test methods.

5. Deployment: After completing all the phases, software is deployed to its work
environment.

6. Review: In this phase, after the product deployment, review phase is performed to check
the behaviour and validity of the developed product. And if there are any error found then the
process starts again from the requirement gathering.

7. Maintenance: In the maintenance phase, after deployment of the software in the working
environment there may be some bugs, some errors or new updates are required. Maintenance
involves debugging and new addition options.

When to use the Iterative Model?

1. When requirements are defined clearly and easy to understand.

2. When the software application is large.
3. When there is a requirement of changes in future.

Advantage(Pros) of Iterative Model:

1. Testing and debugging during smaller iteration is easy.

2. A Parallel development can plan.
3. It is easily acceptable to ever-changing needs of the project.
4. Risks are identified and resolved during iteration.
5. Limited time spent on documentation and extra time on designing.

Disadvantage(Cons) of Iterative Model:

1. It is not suitable for smaller projects.

2. More Resources may be required.
3. Design can be changed again and again because of imperfect requirements.
4. Requirement changes can cause over budget.
5. Project completion date not confirmed because of changing requirements.

Object-oriented Life Cycle Model

The object-oriented life cycle model considers 'objects' as the basis of the software
engineering process. The development team starts by observing and analyzing the system
they intend to develop before defining the requirements. Once the process is over, they focus
on identifying the objects of the system. Now, an object could be anything; it can have a
physical existence like a customer, car, etc. An object also constitutes intangible elements
like a process or a project.
 Advantages of Object-Oriented Life Cycle Model

 Since it is data-focused and easy to work with problem domains.

 It uses encapsulation and data hiding process that allows a developer to build tamper-proof
systems.
 It enables software modularity, making it easier to manage and maintain complex software.
 It allows developers to create new modules using existing models, saving time and
development cost of organizations.

The primary objectives of the Object-Oriented Model

 Object-oriented Analysis
 Object-oriented Design
 Object-oriented Implementation

Object-Oriented Analysis (OOA)

The object-oriented analysis consists of the process where a development team evaluates the
system and organizes the requirements as objects. Contrary to traditional structural analysis,
the OOA heavily depends on advanced data like Use Cases and Object Models.
Use case

Use Cases are written descriptions about how users will behave when they enter your website
or application. It comprises the goals of each user from the point of their entry to exit.

Object Model

An object model allows the development team to create an architectural software or system
model before implementing or programming. It helps in defining a software/system in objects
and classes. It informs the developers about

 Interaction between different models

 Inheritance
 Encapsulation
 Other types of object-oriented interfaces

The OOA starts with analyzing the problem domain and produce a conceptual model by
thoroughly evaluating the information in the given area. There is an abundance of data
available from various sources like:

 Formal document
 Requirement statements
 Primary data collected through stakeholders
Once the analysis is complete, the development team prepares a conceptual model describing
the system's functionalities and requirements.

Object-oriented Design

It is the next development stage of the object-oriented life cycle model where the analysts
design the desired system's overall architecture. The system is divided into a set of interacting
subsystems. The analyst considers the specifications from the system analysis. It all about
evaluating what the end-users expect from the new system.

As per the object-oriented design, the system is considered a collection of objects, with each
object handling a specific state data. For example, in banking software, each account may
feature some exclusive objects with separate data and functions.

The philosophy behind an object-oriented design is to create a set of interacting objects as

seen in the real world. Instead of process-based structural programming, developers create
objects through data structures.

Each programming language comes with several data types, with each type comprising
various variables. Similarly, objects also feature certain predefined data types.

Useful definitions for Object-oriented design

Class

A class refers to a collection of similar objects. It is created as a blueprint to define variables

and methods that share certain similarities with objects.

Likewise, in object-oriented programming, developers can use many similar objects to create
blueprints. This is called a class.

Abstraction

Abstraction is the essence used by developers to build classes. Developers observe a set of
similar objects and characteristics of importance to define classes. Abstractions are divided
into two parts- global abstractions and local abstractions.

Global abstractions are static, providing one interface to users for a limited time. Meanwhile,
Local abstractions are responsible for providing a view based on user/developer's
requirements.

Inheritance
The concept of inheritance in object-oriented design defines the process of reusing 'objects.'
Developers can define a new class type using a similar existing class.

Object-oriented Implementation

In this phase, developers translate the class objects and the interrelationships of classes and
code them using a programming language. This is the phase to create databases and establish
functionalities for the system.

The object-oriented methodology focuses on identifying objects in the system. Developers

closely observe each object to identify characteristics and behavioral patterns. The developers
ensure that the object recognizes and responds perfectly to an event.

Let's consider a smartphone screen as an object and the touch on a specific icon as an event.
Now, when the user touches an icon, the screen opens up an application. This means the
smartphone screen (object) responds to the event (touch) by opening an application.

The object-oriented implementation methodology supports three basic models

Object Model − It describes the objects and their interrelationships. This model observes
objects as static and discards their dynamicity.
Dynamic Model − This model focuses on the changes in states of various objects related to
specific events.
Functional Model − This describes the changes in the flow of data throughout the system.

What are Functional Requirements?

Functional requirements are the important qualification that every system should have in
various forms. We can describe functional requirements as the behaviour of the system as it
connects to the system’s functionality. Authentication, audit tracking, certification
requirements, etc are examples of functional requirements.

What are Non-Functional Requirements?

Non-functional requirements are the qualifications that are not connected to the software’s
functional characteristics. Some of the basic non-functional requirements are reliability,
security, usability, scalability, maintainability, storage, cost, configuration, performance, etc.

Difference between Functional and Non-Functional Requirements

S.No. Functional Requirements Non-Functional Requirements

1 A functional requirement represents It represents the quality characteristic of a

software and its elements and system.
features.

2 The functional requirements It sets some rules and regulations for a

mentioned the activities a software software system on how it should fulfil the
system should perform. essential need.

3 These requirements are established These requirements are established by

by the user. technical persons, such as e.g. software
developers, architects, and more.

4 These requirements are compulsory. These are not compulsory.

5 These are easy to define. These are hard to define.

6 Functional requirements allow you It allows you to check the performance of

to measure the functionality of the the system.
software.

7 System, Integration, End to End, Performance, Stress, Usability, Security

API testing, etc are functional testing, etc are non-functional testing.
testing.

8 These requirements are vital to These are not always vital requirements.
system operation.

User’s Requirement

A user requirement refers to the needs, goals, and expectations of the end users or
stakeholders regarding the functionality, performance, and usability of a software system.
User requirements are typically expressed in non-technical terms, focusing on what the
software should do rather than how it should be implemented. These requirements are vital
for ensuring that the final product aligns with the users' needs.

Types of User Requirements

1. Functional Requirements
o Describe the specific functions or features the software must have.
o Example: "The system must allow users to log in using their email and
password."
 2. Non-Functional Requirements
o Define the quality attributes or constraints of the system, such as performance,
security, and usability.
o Example: "The system should respond to user inputs within 2 seconds."

3. Usability Requirements
o Focus on the user experience, including interface design and ease of use.
o Example: "The interface should be intuitive and accessible to users with visual
impairments."

4. Business Requirements
o Outline the goals and objectives the software must achieve to meet business
needs.
o Example: "The system should increase customer retention by 15% within the
first year."

5. Environmental Requirements
o Specify the conditions under which the software will operate.
o Example: "The system must support mobile devices running Android and
iOS."

Key Characteristics of Good User Requirements

1. Clear and Unambiguous

o Requirements should be easy to understand and interpret.
o Avoid vague statements like "The system should be fast."

2. Measurable and Testable

o Requirements must be stated in a way that allows for validation.
o Example: "The system must handle 500 concurrent users without performance
degradation."

3. Relevant
o Requirements should align with the needs and goals of the stakeholders.

4. Feasible
o The requirements should be technically and financially achievable within the
project constraints.

5. Traceable
o Each requirement should be linked to a specific business or user need.

Gathering User Requirements

1. Interviews and Surveys

o Engage stakeholders and end-users to understand their needs and expectations.

2. Workshops and Focus Groups

o Collaborative sessions to brainstorm and refine requirements.
 3. Use Cases and Scenarios
o Define specific situations or workflows the software must handle.

4. Prototyping
o Create mockups or prototypes to validate user expectations early in the
development process.

5. Observation
o Study how users interact with existing systems or workflows.

Documentation of User Requirements

User requirements are typically documented in a Software Requirements Specification

(SRS) or similar document. They may include:

 User Stories: Short, simple descriptions of a feature from the user's perspective.
Example: "As a user, I want to reset my password so that I can regain access to my
account."
 Use Case Diagrams: Visual representations of user interactions with the system.
 Acceptance Criteria: Specific conditions under which a requirement is considered
met.

System Requirements

System requirements define what a software system should do, how it should perform, and
under what constraints it should operate. These requirements are critical for ensuring the
system's development meets stakeholder expectations and performs as intended. They are
generally divided into two main categories:

1. Functional Requirements

Functional requirements specify the functions, behaviors, or operations a system must

perform. These define what the system should do.

Examples:

 User Authentication: The system must allow users to log in with a username and
password.
 Data Processing: The system must process customer orders within 5 seconds.
 Reporting: The system must generate monthly sales reports.
 Business Rules: Validate user input to ensure compliance with organizational
standards.

2. Non-Functional Requirements

Non-functional requirements describe how the system performs the tasks defined in
functional requirements. These address quality attributes and constraints.
Categories of Non-Functional Requirements:

 Performance Requirements:
o Response time should be under 2 seconds for 95% of transactions.
o The system must handle 10,000 concurrent users.
 Scalability:
o The system should support the addition of new modules with minimal effort.
 Security:
o All sensitive data must be encrypted.
o The system must prevent unauthorized access using multi-factor
authentication.
 Availability:
o The system should have 99.99% uptime.
 Usability:
o The system must support screen readers for accessibility.
 Maintainability:
o Codebase should allow adding features without disrupting existing
functionality.
 Compliance:
o The system must adhere to GDPR regulations.

3. Domain-Specific Requirements

These depend on the industry or domain the software serves, such as healthcare, finance, or
education. They might include specific regulatory, legal, or operational guidelines.

Examples:

 In healthcare: The system must comply with HIPAA regulations.

 In finance: Transactions must follow anti-money laundering (AML) standards.

Importance of System Requirements

1. Clarity: They establish a clear understanding between stakeholders, developers, and

designers.
2. Foundation for Design: They provide a baseline for system architecture and detailed
design.
3. Quality Assurance: Testing efforts are guided by well-defined requirements.
4. Risk Mitigation: Potential issues can be identified and addressed early in the
development process.

Requirement Engineering

Requirements engineering (RE) refers to the process of defining, documenting, and

maintaining requirements in the engineering design process. Requirement engineering
provides the appropriate mechanism to understand what the customer desires, analyzing the
need, and assessing feasibility, negotiating a reasonable solution, specifying the solution
clearly, validating the specifications and managing the requirements as they are transformed
into a working system. Thus, requirement engineering is the disciplined application of proven
principles, methods, tools, and notation to describe a proposed system's intended behavior
and its associated constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the software
that is acceptable to users, flexible to change and conformable to established standards.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current technologies,

which are needed to accomplish customer requirements within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and customer
requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software
can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are identified with
the help of customers and existing systems processes, if available.
Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of
relationships and also resolve conflicts if any.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software
analyst after the requirements collected from the various sources - the requirement received
by the customer written in ordinary language. It is the job of the analyst to write the
requirement in technical language so that they can be understood and beneficial by the
development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system. The system may be a
company, an organization, a set of procedures, a computer hardware system, a
software system, or any combination of the preceding. The DFD is also known as a
data flow graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store information
about all data items defined in DFDs. At the requirements stage, the data dictionary
should at least define customer data items, to ensure that the customer and developers
use the same definition and terminologies.
 o Entity-Relationship Diagrams: Another tool for requirement specification is the
entity-relationship diagram, often called an "E-R diagram." It is a detailed logical
representation of the data for the organization and uses three main constructs i.e. data
entities, relationships, and their associated attributes.
4. Software Requirement Validation:
After requirement specifications developed, the requirements discussed in this document are
validated. The user might demand illegal, impossible solution or experts may misinterpret the
needs. Requirements can be the check against the following conditions -

o If they can practically implement

o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe
Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the requirements.

o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured
requirements descriptions.
Software Requirement Management:
Requirement management is the process of managing changing requirements during the
requirements engineering process and system development.

New requirements emerge during the process as business needs a change, and a better
understanding of the system is developed.

The priority of requirements from different viewpoints changes during development process.

The business and technical environment of the system changes during the development.

Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software development project.
Hence they should be clear, correct, and well-defined.

A complete Software Requirement Specifications should be:

o Clear
o Correct
o Consistent
o Coherent
o Comprehensible
o Modifiable
o Verifiable
o Prioritized
 o Unambiguous
o Traceable
o Credible source
Software Requirements: Largely software requirements must be categorized into two
categories:

1. Functional Requirements: Functional requirements define a function that a system

or system element must be qualified to perform and must be documented in different
forms. The functional requirements are describing the behavior of the system as it
correlates to the system's functionality.
2. Non-functional Requirements: This can be the necessities that specify the criteria
that can be used to decide the operation instead of specific behaviors of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable at run
time.
o Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software system.

 maintainability, and reliability

of the software
 6. Documentation:
Programming in large
 requires comprehensive
documentation to
 ensure that the software can be
maintained and
 modified by other developers
in the future
 Programming in small may
require less
 documentation.
 7. Tools and frameworks:
Programming in large
 often requires the use of
specific tools and
 frameworks to manage the
complexity of the
 software
 Programming in small may
involve fewer
 tools and frameworks.
 8. Standards and guidelines:
Programming in
 large often requires
adherence to specific
 coding standards and
guidelines to ensure
 consistency and
maintainability
 Programming in small may
involve fewer
 standards and guidelines
 9. Timeframe: Programming
in large often takes
 longer to complete due to the
complexity of the
 software
 Programming in small can
often be completed
 more quickly
 10. Resource requirements:
Programming in
 large often requires more
resources, such as
 hardware, software, and
personnel
 Programming in small
requires lesser
 resources, such as
hardware, software, and
 personnel as compared to
programming in
 large
 Software Project Failure
 Software project failure
refers to the situation where
a software project does not
achieve its
 intended objectives or meet
its success criteria. It can be
due to various factors such
as poor
 planning, lack of resources,
technical issues,
miscommunication,
unrealistic expectations, and
 other factors that prevent the
project from being
completed on time, within
budget, and to the
 required quality standards.
 Software project failure can
have serious consequences,
 including financial losses,
damage to the
 organization's reputation,
and lost opportunities. It can
also lead to increased costs,
delays, and
 reduced productivity. It i