Software Engineering

Software Engineering is a systematic and cost-effective technique for software development. It is

an engineering approach to developing software.
For example: If someone wants to travel from Punjab to Delhi. There are two approaches one
can follow to achieve the same result:
1. The normal approach is to go out and catch the bus/train that is available.
2. A systematic approach is constructed as Firstly check on Google Maps distance and after
analyzing the timing of trains and buses online that, match the user’s preference suppose the
user has some work till 4:00 PM and train slots are: 1:00 PM, 6:00 PM then the user will
choose 6:00 PM time slot and reach Delhi.
From the above situation, one can easily analyze that Creating a systematic Approach is more
optimal, time, and cost-effective than a normal approach. This will occur while designing
Software. So in Software Engineering working on an Engineering or a Systematic approach is
more beneficial.

Evolution of Software Engineering

Software engineering has evolved from being considered an art to becoming a recognized
engineering discipline. In the early days of computing, software development was primarily done
by individuals or small teams who wrote code based on their own experiences and knowledge.
This approach was often referred to as “hacking” or “programming by intuition.” As the field of
computing grew, it became apparent that this approach was not sustainable and that a more
structured and systematic approach was needed.
In the 1960s and 1970s, the field of software engineering began to take shape. Researchers and
practitioners began to develop formal methods for software design and development, such as
structured programming and the use of flowcharts to represent algorithms. In 1968, a conference
on software engineering was held, and the term “software engineering” was officially coined.
In the following decades, software engineering continued to evolve and mature. The introduction
of object-oriented programming in the 1980s led to a shift in how software was designed and
developed. The 1990s saw the emergence of the Agile software development methodologies,
which emphasized flexibility and responsiveness to change. Today, software engineering is a
well-established field with its own set of best practices, methodologies, and tools. It is
considered as a discipline of engineering and follows the same principles like any other
engineering field.
In summary, software engineering has evolved from an art to a discipline with its own set of best
practices, methodologies, and tools. The field has grown and matured over time, with new
technologies and approaches being developed to improve the design and development of
software.

Is Software Engineering A Science Or An Art?

Most people think that writing a good quality program is an Art. So let’s discuss it as an Art or
Science. Like other engineering, branches suppose Mechanical engineering. It is based on
Science where there are specific rules and names for each component, technique, and working
principle related to it and before they are standardized the experience is marked as their thumb
rule and on the basis of it, the rules are standardized by various organizations. Similarly, in
Software Engineering there is heavy use of knowledge which is gathered from the experience of
practitioners. Thus, various Organizations or Researchers’s made systematically organized the
experience of practitioners in the theoretical form. Before these are standardized, the experience
act as Thumb Rule. Thus, like every other Engineering Discipline, Software Engineering is a
Science that is transformed from an Art.

Software Engineering Evolution: From An Art To Engineering Discipline

Software Engineering principles have evolved over the last sixty years with the contributions of
various researchers and software professionals. From the beginning period Software Engineering
acts as an Art after that with time, it transformed into a craft and finally to Engineering
Discipline.
Initially, Programmers used an Ad Hoc programming style. Ad Hoc programming is an
approachable solution in an unplanned or unorganized manner. In this type of Programming
Style, no plan is created on how to create Structure and Steps to complete the programming task
but without having any systematic approach the problem needs to be solved in the required time.
This style is now referred to as exploratory, build and fix, and code and fix styles.
Like in today’s world various researchers and scientists working on those things which are not
even necessary but during the initial period, Programmers worked on those things which are
really needed. But as time fleet the Ad Hoc Programming will cause various problems which
results in less efficiency and another approach i.e. systematic approach is adopted.

Software Engineering As An Art

Software Engineering as an Art means, this can be only learned by specific people and other
people’s are not allowed to work on them.
 Software engineering as an art refers to the creative and intuitive aspect of software
development. It involves the use of creativity, problem-solving skills, and artistic expression
to design and develop software systems that are not only functional but also aesthetically
pleasing and user-friendly.
 In the early days of software development, many programmers considered software
development as an art, as it was more about creativity and intuition than about following a set
 of established processes and methodologies. Programmers would often write code in an ad-
hoc manner, without much structure or planning, and the final product was often the result of
their personal artistic expression.
 However, as software systems have become more complex and important, it has become
clear that the traditional ad-hoc approach to software development is not sufficient. This has
led to the emergence of the field of software engineering, which has focused on bringing
more structure and discipline to the software development process.
 Despite this, the art of software engineering still plays an important role in the development
process. For example, a good software engineer must also have a sense of aesthetics, be able
to think creatively and out of the box and be able to develop software that is easy to use and
understand.
For Example: In ancient times only a few people know Gold Ornaments making. Those who
know Gold Ornaments making kept it as a secret and will reveal to his genetic generation. So at
this time, this is known as Art and during that time accuracy was very less.
The same in Software Development, only a few people know about Software designing and
coding and at that time there is no set of rules or instruction for software designing. And those
who are able to write code efficiently and essentially fix bugs are considered proficient and those
who are not good at programming and didn’t know about that were left wondering that how they
could effortlessly write elegant and correct code each time.
Like Gold Ornaments are not efficiently designed in the same way Program Coding is not
efficiently done due to this various issues cause which degrades the efficiency of Software but at
time efficiency is not considered as an important aspect.

Software Engineering Transition from Art to Craft

Software Engineering transformed from Art to Craft when the area of people who know
Software Designing and Coding will increase.
The transition of software engineering from an art to a craft can be seen as a gradual process that
has occurred over time.
 In the early days of software development, software engineering was primarily considered an
art form. Programmers would often write code in an ad-hoc manner, without much structure
or planning, and the final product was often the result of their personal artistic expression.
 As software systems have become more complex and important, it has become clear that the
traditional ad-hoc approach to software development is not sufficient. This led to the
emergence of the field of software engineering, which focused on bringing more structure
and discipline to the software development process.
 With the emergence of software engineering as a discipline, the focus shifted from the artistic
expression of individual programmers to the use of established processes and methodologies
to ensure the quality and reliability of software systems. This led to the development of new
methodologies and techniques such as the Waterfall and Agile methodologies, as well as the
development of new tools and technologies to support software development.
 As a result, software engineering has transitioned from an art form to a craft. Instead of
relying on the creativity and intuition of individual programmers, software development has
become more structured and disciplined, with a focus on using established processes and
methodologies to ensure the quality and reliability of software systems.
For Example: When the secret of Gold Ornaments making is revealed to the only generation
after generation which will increase the number of people in that Art and will convert art into a
craft where accuracy is increased.
The same in Software Engineering, the Specific Degree and P.H.D were introduced in the
Universities and some specific people will go further to learn and there is a certain rule which
must be fulfilled to take that degree. So the number of people which increases in that area, and
they start researching about it and create Standards and Styles for Coding and Software
Development which must be followed and these Standards will help to create a less error-free
software.

Like gold, ornaments are taking decent shapes and become efficient. In the same way, Program
Writing has also become efficient in terms of Code reusability and efficiency but still, it is at
times, efficiency is not considered an important aspect.

Software Engineering Transition From Craft To Engineering Discipline

The transition of software engineering from a craft to an engineering discipline can be seen as a
gradual process that has occurred over time as the field has matured.
 In the early days of software development, software engineering was considered a craft, with
a focus on using established processes and methodologies to ensure the quality and reliability
of software systems. However, as the field has grown and matured, software engineering has
become more formalized and structured, with the development of new methodologies,
techniques and tools to support software development.
 One of the key milestones in the transition of software engineering from a craft to an
engineering discipline was the publication of the book “Software Engineering: A
 Practitioner’s Approach” by Pressman in 1975. This book provided a comprehensive
overview of the field and defined software engineering as an engineering discipline.
 With the growing recognition of software engineering as an engineering discipline, the focus
has shifted from the use of established processes and methodologies to ensure the quality and
reliability of software systems, to a more scientific and systematic approach to software
development.
 This has led to the development of new techniques and methodologies such as formal
methods, model-driven development, and software architecture, which are based on sound
scientific principles and are designed to ensure the quality and reliability of software systems.
 In conclusion, software engineering has transitioned from being considered a craft to being
considered an engineering discipline as the field has matured and grown more formalized and
structured. The field has shifted its focus from relying on established processes and method
In today’s world Software Engineering acts as an Engineering Discipline when everyone can
learn Software designing and coding irrespective of that they are pursuing a degree or not.
For example: In today’s world everyone can learn Gold Ornament making and accuracy has
much more increased with the help of various machines. Also, it is converted into a
Professional study where people will learn about how? Why? The science behind it etc.
The same in software engineering occur where everyone can learn about Software
Development with or without pursuing any Professional Studies and accuracy of Software
Development increased with the help of Standards and improved rules created by
researchers.
Software engineering principles are now widely used in industry and new principles are still
continuing to emerge at a very rapid rate.

Benefits to treating software development as an engineering discipline

There are many benefits to treating software development as an engineering discipline. Some of
the key benefits include:
1. Improved quality: By following established best practices and methodologies, software
engineers are able to produce higher quality software that is more reliable and less prone to
errors.
2. Increased productivity: Formal methods and tools can help software engineers work more
efficiently and effectively, leading to increased productivity.
3. Greater predictability: By following a structured and systematic approach, software
engineers can make more accurate predictions about the time and resources required to
complete a project.
4. Better communication: Software engineering practices can help ensure that all stakeholders,
including developers, managers, and clients, have a clear understanding of the project’s goals
and requirements.
5. Greater maintainability: Software engineering practices can help ensure that the software is
designed in a way that makes it easy to maintain and update over time.
6. Better cost management: By following established best practices and methodologies,
software engineers can reduce the cost of development, testing and maintenance of software.
7. Better Scalability: Software engineering provides the process and methodologies to design
the software in a way that it is easy to scale up or down as per the requirement.
Important Points to software Engineering Evolution: From An Art To Engineering
Discipline
Following are some important points:
1. Software engineering has evolved from being considered an art form to being considered an
engineering discipline.
2. The transition from art to craft involved bringing more structure and discipline to the
software development process.
3. The transition from craft to engineering discipline involved a more formalized and structured
approach, with a focus on using established
4. processes and methodologies to ensure the quality and reliability of software systems.
5. Key milestones in this transition include the publication of the book “Software Engineering:
A Practitioner’s Approach” and the development of new methodologies, techniques, and
tools to support software development.
6. The goal of software engineering is to deliver a functional, reliable, maintainable, and
efficient software.

SDLC Models
Software Development life cycle (SDLC) is a spiritual model used in project
management that defines the stages include in an information system development
project, from an initial feasibility study to the maintenance of the completed
application.

There are different software development life cycle models specify and design,
which are followed during the software development phase. These models are also
called "Software Development Process Models." Each process model follows a
series of phase unique to its type to ensure success in the step of software
development.

Here, are some important phases of SDLC life cycle:

Waterfall Model
The waterfall is a universally accepted SDLC model. In this method, the whole
process of software development is divided into various phases.

The waterfall model is a continuous software development model in which

development is seen as flowing steadily downwards (like a waterfall) through the
steps of requirements analysis, design, implementation, testing (validation),
integration, and maintenance.

Linear ordering of activities has some significant consequences. First, to identify the
end of a phase and the beginning of the next, some certification techniques have to
be employed at the end of each step. Some verification and validation usually do this
mean that will ensure that the output of the stage is consistent with its input (which
is the output of the previous step), and that the output of the stage is consistent with
the overall requirements of the system.

RAD Model
RAD or Rapid Application Development process is an adoption of the waterfall
model; it targets developing software in a short period. The RAD model is based on
the concept that a better system can be developed in lesser time by using focus
groups to gather system requirements.

o Business Modeling
o Data Modeling
o Process Modeling
o Application Generation
o Testing and Turnover

Spiral Model
The spiral model is a risk-driven process model. This SDLC model helps the group
to adopt elements of one or more process models like a waterfall, incremental,
waterfall, etc. The spiral technique is a combination of rapid prototyping and
concurrency in design and development activities.

Each cycle in the spiral begins with the identification of objectives for that cycle, the
different alternatives that are possible for achieving the goals, and the constraints
that exist. This is the first quadrant of the cycle (upper-left quadrant).

The next step in the cycle is to evaluate these different alternatives based on the
objectives and constraints. The focus of evaluation in this step is based on the risk
perception for the project.

The next step is to develop strategies that solve uncertainties and risks. This step
may involve activities such as benchmarking, simulation, and prototyping.

V-Model
In this type of SDLC model testing and the development, the step is planned in
parallel. So, there are verification phases on the side and the validation phase on the
other side. V-Model joins by Coding phase.
Incremental Model
The incremental model is not a separate model. It is necessarily a series of waterfall
cycles. The requirements are divided into groups at the start of the project. For each
group, the SDLC model is followed to develop software. The SDLC process is
repeated, with each release adding more functionality until all requirements are met.
In this method, each cycle act as the maintenance phase for the previous software
release. Modification to the incremental model allows development cycles to
overlap. After that subsequent cycle may begin before the previous cycle is
complete.

Agile Model
Agile methodology is a practice which promotes continues interaction of
development and testing during the SDLC process of any project. In the Agile
method, the entire project is divided into small incremental builds. All of these builds
are provided in iterations, and each iteration lasts from one to three weeks.

Any agile software phase is characterized in a manner that addresses several key
assumptions about the bulk of software projects:

1. It is difficult to think in advance which software requirements will persist and

which will change. It is equally difficult to predict how user priorities will
change as the project proceeds.
2. For many types of software, design and development are interleaved. That is,
both activities should be performed in tandem so that design models are
proven as they are created. It is difficult to think about how much design is
necessary before construction is used to test the configuration.
3. Analysis, design, development, and testing are not as predictable (from a
planning point of view) as we might like.

Iterative Model
It is a particular implementation of a software development life cycle that focuses
on an initial, simplified implementation, which then progressively gains more
complexity and a broader feature set until the final system is complete. In short,
iterative development is a way of breaking down the software development of a large
application into smaller pieces.
Big bang model
Big bang model is focusing on all types of resources in software development and
coding, with no or very little planning. The requirements are understood and
implemented when they come.

This model works best for small projects with smaller size development team which
are working together. It is also useful for academic software development projects.
It is an ideal model where requirements are either unknown or final release date is
not given.

Prototype Model
The prototyping model starts with the requirements gathering. The developer and
the user meet and define the purpose of the software, identify the needs, etc.

A 'quick design' is then created. This design focuses on those aspects of the software
that will be visible to the user. It then leads to the development of a prototype. The
customer then checks the prototype, and any modifications or changes that are
needed are made to the prototype. Looping takes place in this step, and better
versions of the prototype are created. These are continuously shown to the user so
that any new changes can be updated in the prototype. This process continue until
the customer is satisfied with the system. Once a user is satisfied, the prototype is
converted to the actual system with all considerations for quality and security.

Waterfall model
Winston Royce introduced the Waterfall Model in [Link] 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.

Prototype Model
The prototype model requires that before carrying out the development of actual
software, a working prototype of the system should be built. A prototype is a toy
implementation of the system. A prototype usually turns out to be a very crude
version of the actual system, possible exhibiting limited functional capabilities, low
reliability, and inefficient performance as compared to actual software. In many
instances, the client only has a general view of what is expected from the software
product. In such a scenario where there is an absence of detailed information
regarding the input to the system, the processing needs, and the output requirement,
the prototyping model may be employed.
Steps of Prototype Model

1. Requirement Gathering and Analyst

2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product
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.

Evolutionary Process Model

Evolutionary process model resembles the iterative enhancement model. The same
phases are defined for the waterfall model occurs here in a cyclical fashion. This
model differs from the iterative enhancement model in the sense that this does not
require a useful product at the end of each cycle. In evolutionary development,
requirements are implemented by category rather than by priority.

For example, in a simple database application, one cycle might implement the
graphical user Interface (GUI), another file manipulation, another queries and
another updates. All four cycles must complete before there is a working product
available. GUI allows the users to interact with the system, file manipulation allow
the data to be saved and retrieved, queries allow user to get out of the system, and
updates allows users to put data into the system.

Benefits of Evolutionary Process Model

 Use of EVO brings a significant reduction in risk for software projects.

 EVO can reduce costs by providing a structured, disciplined avenue for
experimentation.
 EVO allows the marketing department access to early deliveries, facilitating
the development of documentation and demonstration.
 Better fit the product to user needs and market requirements.
 Manage project risk with the definition of early cycle content.
 Uncover key issues early and focus attention appropriately.
 Increase the opportunity to hit market windows.
 Accelerate sales cycles with early customer exposure.
 Increase management visibility of project progress.
 Increase product team productivity and motivations

Evolutionary Model
The evolutionary model is a combination of the Iterative and Incremental
models of the software development life cycle. Delivering your system in a big
bang release, delivering it in incremental process over time is the action done in
this model. Some initial requirements and architecture envisioning need to be done.
It is better for software products that have their feature sets redefined during
development because of user feedback and other factors.

What is the Evolutionary Model?

The Evolutionary development model divides the development cycle into smaller,
incremental waterfall models in which users can get access to the product at the
end of each cycle.
1. Feedback is provided by the users on the product for the planning stage of the
next cycle and the development team responds, often by changing the product,
plan, or process.
2. Therefore, the software product evolves with time.
3. All the models have the disadvantage that the duration of time from the start of
the project to the delivery time of a solution is very high.
4. The evolutionary model solves this problem with a different approach.
5. The evolutionary model suggests breaking down work into smaller chunks,
prioritizing them, and then delivering those chunks to the customer one by one.
6. The number of chunks is huge and is the number of deliveries made to the
customer.
7. The main advantage is that the customer’s confidence increases as he constantly
gets quantifiable goods or services from the beginning of the project to verify
and validate his requirements.
8. The model allows for changing requirements as well as all work is broken down
into maintainable work chunks.

Application of Evolutionary Model

1. It is used in large projects where you can easily find modules for incremental
implementation. Evolutionary model is commonly used when the customer
wants to start using the core features instead of waiting for the full software.
2. Evolutionary model is also used in object oriented software development
because the system can be easily portioned into units in terms of objects.
Necessary Conditions for Implementing this Model
1. Customer needs are clear and been explained in deep to the developer team.
2. There might be small changes required in separate parts but not a major change.
3. As it requires time, so there must be some time left for the market constraints.
4. Risk is high and continuous targets to achieve and report to customer repeatedly.
5. It is used when working on a technology is new and requires time to learn.

Advantages Evolutionary Model

1. Adaptability to Changing Requirements: Evolutionary models work
effectively in projects when the requirements are ambiguous or change often.
They support adjustments and flexibility along the course of development.
2. Early and Gradual Distribution: Functional components or prototypes can be
delivered early thanks to incremental development. Faster user satisfaction and
feedback may result from this.
3. User Commentary and Involvement: Evolutionary models place a strong
emphasis on ongoing user input and participation. This guarantees that the
software offered closely matches the needs and expectations of the user.
4. Improved Handling of Difficult Projects: Big, complex tasks can be
effectively managed with the help of evolutionary models. The development
process is made simpler by segmenting the project into smaller, easier-to-
manage portions.

Disadvantages Evolutionary Model

1. Communication Difficulties: Evolutionary models require constant
cooperation and communication. The strategy may be less effective if there are
gaps in communication or if team members are spread out geographically.
2. Dependence on an Expert Group: A knowledgeable and experienced group
that can quickly adjust to changes is needed for evolutionary models. Teams
lacking experience may find it difficult to handle these model’s dynamic nature.
3. Increasing Management Complexity: Complexity can be introduced by
organizing and managing several increments or iterations, particularly in large
projects. In order to guarantee integration and synchronization, good project
management is needed.
4. Greater Initial Expenditure: As evolutionary models necessitate continual
testing, user feedback and prototyping, they may come with a greater starting
cost. This may be a problem for projects that have limited funding.
 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.

The Spiral Model is shown in fig:

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.

Feasibility Study
A feasibility study analyzes the viability of a proposed project or venture. It is used to evaluate a
project's potential, including the technical, financial, and economic aspects, and to determine
whether it should proceed. A feasibility study aims to identify and assess a proposed project's
strengths, weaknesses, opportunities, and threats to determine its potential for success.

Feasibility Study Process

The feasibility study process typically includes a variety of tasks, such as market research,
technical analysis, financial analysis, and risk assessment. Market research is used to identify the
demand for the proposed product or service and the competition and potential customers.
Technical analysis is used to evaluate the technical aspects of the project, such as the design and
production methods, and to determine whether the project is technically feasible. Financial
analysis is used to evaluate the project's financial viability, including the costs and revenues, and
to determine whether the project is financially feasible. Risk assessment is used to identify and
evaluate the project's potential risks, such as regulatory, market, and financial risks, and to
determine the project's overall risk profile. The outcome of a feasibility study is a report that
summarizes the study's findings and provides recommendations for proceeding with the project. If
the study finds the project feasible, the report will recommend proceeding with the project and
may include a detailed project plan and budget. If the study finds that the project is not feasible,
the report will recommend not proceeding with the project and may include suggestions for
alternative projects.

It's important to note that feasibility studies are not always required for all projects, but they are
particularly useful for larger, more complex projects that require significant investment. A simple
cost-benefit analysis may be sufficient for smaller or less complex projects. Additionally,
feasibility studies are often used to secure funding from investors, banks, or other sources, as they
provide a detailed analysis of the project's potential for success. In short, a feasibility study is a
tool that helps to evaluate the potential of a proposed project or venture by analyzing the technical,
financial, and economic aspects.

Domains of Feasible Study

Feasibility studies typically cover several domains, including market, technical, financial, and
organizational. Each domain provides information and analysis that helps to evaluate the potential
of the proposed project or venture.

The market domain assesses the demand for the proposed product or service, competition, and
potential customers. This includes research on the market size, growth, trends, and segmentation,
as well as analyzing the target market and their needs, preferences and buying habits. The market
research also includes a competitive analysis, which provides information on the competitors, their
market share, strengths and weaknesses, and how the proposed project or venture will compare
and compete in the market. The technical domain evaluates the technical aspects of the project,
such as the design and production methods, and determines whether the project is technically
feasible. This includes a detailed engineering and design analysis and a review of the equipment,
materials, and technology required for the project. It also includes an assessment of the project's
scalability and adaptability and an analysis of the feasibility of any new or innovative technologies
that may be required.
The financial domain assesses the project's financial viability, including the costs and revenues,
and determines whether the project is financially feasible. This includes a detailed financial
analysis, such as a cost-benefit analysis, a break-even analysis, and a cash flow analysis. It also
includes an assessment of the project's funding requirements, including the funding sources and
the terms and conditions of any financing arrangements. The financial analysis also includes an
assessment of the project's Return on Investment (ROI) and Net Present Value (NPV). The
organizational domain assesses the project's feasibility, including the project's human resources,
management, and administrative aspects. This includes an analysis of the project's organizational
structure, roles, and responsibilities and an assessment of the project's management and
administrative systems.

Benefits of Feasibility
o Feasibility studies provide several advantages, including aiding project directors in
understanding the benefits and drawbacks of performing work before investing significant
time and money into it.
o Feasibility studies may also provide critical information to an organization's management
team, preventing them from embarking on a risky project.
o Such studies help firms decide how they will grow. They will learn how they will function,
what potential roadblocks exist, who their competitors are, and what the market is like.
Feasibility studies can aid in convincing financial backers and brokers that investing in a
given project or firm is a sensible move.

How to Conduct a Feasible Study

The structure of a feasibility study will be determined by the type of organization that requires it.
Regardless, comparable factors will be engaged, regardless of how their weighting alters. Even
though each assignment has unique objectives and needs, there are a few standard techniques for
conducting each feasibility study:

o Conduct a preliminary evaluation, which involves gathering feedback on the new proposal
from appropriate partners.
o To guarantee that the information obtained in the early stages of the study is robust, break
it down and pose questions about it.
o Conduct market research or statistical survey to identify market interest and opportunities
for pursuing the activity or business.
o Create a traditional, functional, or field-tested approach that determines how much labour
is necessary, how much it will cost, and how long it will take.
 o Create a predicted pay announcement that includes income, working expenditures, and
benefits.
o Create an accounting report for the first day of the season.
o Recognize barriers and potential vulnerabilities and how to deal with them.
o Make a fundamental "go" or "off limits" decision regarding moving forward with the
arrangement.

Recommended Components
The real work begins once the reasonable underlying degree of effort has been completed. Parts of
a feasibility study that are commonly encountered include the following:

o Outline of the Leader: Create a tale that depicts the nuances of the project, item,
administration, plan, or business.
o Thoughts on Mechanics: What will it take? How much will it cost? Have you got it?
Could you ever acquire it if you didn't have it?
o Existing Commercial Centre: Look for the item, administration, strategy, or firm in
adjacent and larger business sectors.
o Advertising Technique: Extensively depict it.
 o Personnel Required: What are the human resource requirements for this project? Make a
hierarchical graph.
o Timetable and Sequence of Events: Include large interval markers for the project's
completion date.

Example of a Feasibility study

The following are two examples of feasibility studies. The first involves college development
plans. The second is a genuine model headed by the Washington State Department of
Transportation and backed by Microsoft Inc.

A Science Building at a College

Authorities at a college were concerned that the science building, which had been in use since the
1970s, was antiquated. Taking into account the most recent 20 years of creative and logical
advancements, they needed to explore the cost and benefits of revamping and expanding the
structure. A feasibility study was conducted.

In the preliminary investigation, school officials considered several options, weighing the benefits
and costs of expanding and renovating the science building. Some school officials were concerned
about the project, particularly the cost and potential community opposition. The new scientific
building would be far larger, and the local area board had already rejected a related proposal. The
feasibility study must address these concerns and potential legal or drafting issues.

The feasibility study also looked at the mechanical needs of the new scientific office, the benefits
to students, and the school's long-term suitability. An updated scientific office would broaden the
school's logical investigation capacities, work on its teaching programme, and attract new students.

Monetary forecasts demonstrated the cost and scope of the project, as well as how the school
expected to obtain the necessary assets, which included appealing to financial backers and
leveraging the institution's approval. The predictions also demonstrated how the expanded office
would enable more understudies to enrol in science programmes, increasing money from
educational costs and expenses.

The feasibility analysis demonstrated that moving forward with the scientific building's
refurbishment and expansion plans was reasonable. The school's administrators would never have
been able to determine if their extension plans were feasible without conducting a feasibility
assessment.

A High-Speed Railway Project

The Washington State Division of Transportation decided to focus its feasibility study on
constructing a high-speed rail connecting Portland, Oregon, Seattle, Washington, and Vancouver,
British Columbia. The goal was to build a stable natural transportation system to increase the
Pacific Northwest's importance and future prosperity.

An administrative framework for future direction was shown in the initial inquiry. The evaluation
involved talking to experts and partners to determine the optimal administrative system, assessing
administrative designs, and learning from already completed fast rail projects in North America.
As a result, managing and organizing components were developed to oversee and carry out the
project, assuming the state assembly would approve it.

An important commitment strategy includes an objective technique with the general public,
selected authorities, government agencies, corporate visionaries, promotion events, and local
networks. The commitment plan was designed to be flexible, considering the scope, size, and
number of cities and towns that seemed to be involved. A group of leadership council members
was established, and they gathered to discuss policies, provide examples from previous jobs, and
consult with experts to create a system.

The financial portion of the feasibility focus outlined the task's funding process, which also looked
into obtaining assets from state, federal, and private ventures. The estimated cost of the enterprise
ranged from $24 billion to $42 billion. It was estimated that the high-speed rail framework would
generate between $160 million and $250 million in revenue.

The study divided the financing and subsidizing sources of money. The term "funding" refers to
government-issued securities, loans from financial institutions, and value speculations, which are
advances against future revenue that must be repaid with interest. The term "subsidizing" was used
to refer to grants, distributions from the local or state government, and revenue.

As the task advanced, different areas would need different amounts of cash. The majority of the
subsidizing would come from the public authority in the early stages, and as the initiative
developed, money and promises from the private sector would take over. Microsoft Inc. was one
of the project's secret donors, contributing more than $570,000.

The benefits outlined in the achievability report indicate that the region will see improved
interconnectivity, taking better population management and boosting regional monetary
development by $355 billion into consideration. The improved transportation system would allow
them access to better jobs and more affordable housing. The quick rail system also frees up areas
where car traffic is backed up.

The review's timeline began in 2016 when an agreement was made with English Columbia to work
together on another innovation hall that would feature high-speed rail transit. The Washington
State Land Council received the potential report in December 2020.

What is the Main Objective of a Feasibility Study?

Feasibility analysis is meant to help managers determine if a new business or speculative idea has
a good chance of succeeding. It makes a distinction between general costs and typical benefits.
"Fruitful" in business refers to a situation where the financial gain outweighs the cost.
Achievement in a charity might be measured in several ways. The benefit of an enterprise to the
community it serves could be worth the cost.

What are the Steps in a Feasibility Study?

A basic examination comes before a feasibility study. A marketable plan is ready when partners
have been assessed, and statistical surveying has been conducted. The breakdown of this
information enables a fundamental "go" or "off limits" decision to be made.

The real examination may begin if everything is okay. This involves presenting the original ideas,
focusing on the commercial area, displaying the advertising strategy, and highlighting the crucial
human resources, project timeline, and financial requirements.

Functional and non-functional requirements

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 describe the
behavior of the system as it correlates to the system's functionality.

Functional requirements should be written in a simple language, so that it is easily understandable.

The examples of functional requirements are authentication, business rules, audit tracking,
certification requirements, transaction corrections, etc.
These requirements allow us to verify whether the application provides all functionalities
mentioned in the application's functional requirements. They support tasks, activities, user goals
for easier project management.

There are a number of ways to prepare functional requirements. The most common way is that
they are documented in the text form. Other formats of preparing the functional requirements are
use cases, models, prototypes, user stories, and diagrams.

Non-functional requirements
Non-functional requirements are not related to the software's functional aspect. They can be the
necessities that specify the criteria that can be used to decide the operation instead of specific
behaviors of the system. Basic non-functional requirements are - usability, reliability, security,
storage, cost, flexibility, configuration, performance, legal or regulatory requirements, etc.

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.

Non-functional requirements specify the software's quality attribute. These requirements define
the general characteristics, behavior of the system, and features that affect the experience of the
user. They ensure a better user experience, minimizes the cost factor. Non-functional requirements
ensure that the software system must follow the legal and adherence rules. The impact of the non-
functional requirements is not on the functionality of the system, but they impact how it will
perform. For a well-performing product, atleast some of the non-functional requirements should
be met.

Functional requirements v/s Non-functional requirements

Now, let's see the comparison chart between the functional and non-functional requirements.

Functional Requirements Non-functional requirements

Functional requirements help to understand the functions of They help to understand the system's
the system. performance.

Functional requirements are mandatory. While non-functional requirements are not

mandatory.

They are easy to define. They are hard to define.

They describe what the product does. They describe the working of product.

It concentrates on the user's requirement. It concentrates on the expectation and

experience of the user.

It helps us to verify the software's functionality. It helps us to verify the software's performance.

These requirements are specified by the user. These requirements are specified by the
software developers, architects, and technical
persons.
 There is functional testing such as API testing, system, There is non-functional testing such as
integration, etc. usability, performance, stress, security, etc.

Examples of the functional requirements are - Examples of the non-functional requirements

Authentication of a user on trying to log in to the system. are -
The background color of the screens should be
light blue.

These requirements are important to system operation. These are not always the important
requirements, they may be desirable.

Completion of Functional requirements allows the system While system will not work only with non-
to perform, irrespective of meeting the non-functional functional requirements.
requirements.

Requirement Gathering
The following are some of the well-known requirements gathering techniques −

Brainstorming
Brainstorming is used in requirement gathering to get as many ideas as possible from group of people.
Generally used to identify possible solutions to problems, and clarify details of opportunities.

Document Analysis
Reviewing the documentation of an existing system can help when creating AS–IS process document,
as well as driving gap analysis for scoping of migration projects. In an ideal world, we would even be
reviewing the requirements that drove creation of the existing system – a starting point for documenting
current requirements. Nuggets of information are often buried in existing documents that help us ask
questions as part of validating requirement completeness.

Focus Group
A focus group is a gathering of people who are representative of the users or customers of a product to
get feedback. The feedback can be gathered about needs/opportunities/ problems to identify
requirements, or can be gathered to validate and refine already elicited requirements. This form of
market research is distinct from brainstorming in that it is a managed process with specific participants.
Interface analysis
Interfaces for a software product can be human or machine. Integration with external systems and
devices is just another interface. User centric design approaches are very effective at making sure that
we create usable software. Interface analysis – reviewing the touch points with other external systems
is important to make sure we don’t overlook requirements that aren’t immediately visible to users.

Interview
Interviews of stakeholders and users are critical to creating the great software. Without understanding
the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. We also
have to recognize the perspective of each interviewee, so that, we can properly weigh and address their
inputs. Listening is the skill that helps a great analyst to get more value from an interview than an
average analyst.

Observation
By observing users, an analyst can identify a process flow, steps, pain points and opportunities for
improvement. Observations can be passive or active (asking questions while observing). Passive
observation is better for getting feedback on a prototype (to refine requirements), where active
observation is more effective at getting an understanding of an existing business process. Either
approach can be used.

Prototyping
Prototyping is a relatively modern technique for gathering requirements. In this approach, you gather
preliminary requirements that you use to build an initial version of the solution - a prototype. You show
this to the client, who then gives you additional requirements. You change the application and cycle
around with the client again. This repetitive process continues until the product meets the critical mass
of business needs or for an agreed number of iterations.

Requirement Workshops
Workshops can be very effective for gathering requirements. More structured than a brainstorming
session, involved parties collaborate to document requirements. One way to capture the collaboration
is with creation of domain-model artifacts (like static diagrams, activity diagrams). A workshop will
be more effective with two analysts than with one.

Reverse Engineering
When a migration project does not have access to sufficient documentation of the existing system,
reverse engineering will identify what the system does. It will not identify what the system should do,
and will not identify when the system does the wrong thing.

Survey/Questionnaire
When collecting information from many people – too many to interview with budget and time
constraints – a survey or questionnaire can be used. The survey can force users to select from choices,
rate something (“Agree Strongly, agree…”), or have open ended questions allowing free-form
responses. Survey design is hard – questions can bias the respondents.

Requirements Analysis
Requirement analysis is significant and essential activity after elicitation. We analyze, refine, and
scrutinize the gathered requirements to make consistent and unambiguous requirements. This
activity reviews all requirements and may provide a graphical view of the entire system. After the
completion of the analysis, it is expected that the understandability of the project may improve
significantly. Here, we may also use the interaction with the customer to clarify points of confusion
and to understand which requirements are more important than others.

The various steps of requirement analysis are shown in fig:

(i) Draw the context diagram: The context diagram is a simple model that defines the boundaries
and interfaces of the proposed systems with the external world. It identifies the entities outside the
proposed system that interact with the system. The context diagram of student result management
system is given below:

(ii) Development of a Prototype (optional): One effective way to find out what the customer
wants is to construct a prototype, something that looks and preferably acts as part of the system
they say they want.

We can use their feedback to modify the prototype until the customer is satisfied continuously.
Hence, the prototype helps the client to visualize the proposed system and increase the
understanding of the requirements. When developers and users are not sure about some of the
elements, a prototype may help both the parties to take a final decision.

Some projects are developed for the general market. In such cases, the prototype should be shown
to some representative sample of the population of potential purchasers. Even though a person who
tries out a prototype may not buy the final system, but their feedback may allow us to make the
product more attractive to others.

The prototype should be built quickly and at a relatively low cost. Hence it will always have
limitations and would not be acceptable in the final system. This is an optional activity.

(iii) Model the requirements: This process usually consists of various graphical representations
of the functions, data entities, external entities, and the relationships between them. The graphical
view may help to find incorrect, inconsistent, missing, and superfluous requirements. Such models
include the Data Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-transition
diagrams, etc.
(iv) Finalise the requirements: After modeling the requirements, we will have a better
understanding of the system behavior. The inconsistencies and ambiguities have been identified
and corrected. The flow of data amongst various modules has been analyzed. Elicitation and
analyze activities have provided better insight into the system. Now we finalize the analyzed
requirements, and the next step is to document these requirements in a prescribed format.

Software Requirement Specifications

The production of the requirements stage of the software development process is Software
Requirements Specifications (SRS) (also called a requirements document). This report lays a
foundation for software engineering activities and is constructing when entire requirements are
elicited and analyzed. SRS is a formal report, which acts as a representation of software that
enables the customers to review whether it (SRS) is according to their requirements. Also, it
comprises user requirements for a system as well as detailed specifications of the system
requirements.

The SRS is a specification for a specific software product, program, or set of applications that
perform particular functions in a specific environment. It serves several goals depending on who
is writing it. First, the SRS could be written by the client of a system. Second, the SRS could be
written by a developer of the system. The two methods create entirely various situations and
establish different purposes for the document altogether. The first case, SRS, is used to define the
needs and expectation of the users. The second case, SRS, is written for various purposes and
serves as a contract document between customer and developer.

Characteristics of good SRS

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS.
SRS is said to be perfect if it covers all the needs that are truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following elements:

(1). All essential requirements, whether relating to functionality, performance, design, constraints,
attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input data in all
available categories of situations.

(3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of all
terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict. There are three types of possible conflict in the SRS:

(1). The specified characteristics of real-world objects may conflicts. For example,

(a) The format of an output report may be described in one requirement as tabular but in another
as textual.
(b) One condition may state that all lights shall be green while another states that all lights shall
be blue.

(2). There may be a reasonable or temporal conflict between the two specified actions. For
example,

(a) One requirement may determine that the program will add two inputs, and another may
determine that the program will multiply them.

(b) One condition may state that "A" must always follow "B," while other requires that "A and B"
co-occurs.

(3). Two or more requirements may define the same real-world object but use different terms for
that object. For example, a program's request for user input may be called a "prompt" in one
requirement's and a "cue" in another. The use of standard terminology and descriptions promotes
consistency.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a method
used with multiple definitions, the requirements report should determine the implications in the
SRS so that it is clear and simple to understand.

5. Ranking for importance and stability: The SRS is ranked for importance and stability if each
requirement in it has an identifier to indicate either the significance or stability of that particular
requirement.

Typically, all requirements are not equally important. Some prerequisites may be essential,
especially for life-critical applications, while others may be desirable. Each element should be
identified to make these differences clear and explicit. Another way to rank requirements is to
distinguish classes of items as essential, conditional, and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly
obtain changes to the system to some extent. Modifications should be perfectly indexed and cross-
referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements. The requirements
are verified with the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it
facilitates the referencing of each condition in future development or enhancement documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly referencing its source
in earlier documents.
2. Forward Traceability: This depends upon each element in the SRS having a unique name or
reference number.

The forward traceability of the SRS is especially crucial when the software product enters the
operation and maintenance phase. As code and design document is modified, it is necessary to be
able to ascertain the complete set of requirements that may be concerned by those modifications.

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

10. Testability: An SRS should be written in such a method that it is simple to generate test cases
and test plans from the report.

11. Understandable by the customer: An end user may be an expert in his/her explicit domain
but might not be trained in computer science. Hence, the purpose of formal notations and symbols
should be avoided too as much extent as possible. The language should be kept simple and clear.

12. The right level of abstraction: If the SRS is written for the requirements stage, the details
should be explained explicitly. Whereas,for a feasibility study, fewer analysis can be used. Hence,
the level of abstraction modifies according to the objective of the SRS.

Properties of a good SRS document

The essential properties of a good SRS document are the following:

Concise: The SRS report should be concise and at the same time, unambiguous, consistent, and
complete. Verbose and irrelevant descriptions decrease readability and also increase error
possibilities.

Structured: It should be well-structured. A well-structured document is simple to understand and

modify. In practice, the SRS document undergoes several revisions to cope up with the user
requirements. Often, user requirements evolve over a period of time. Therefore, to make the
modifications to the SRS document easy, it is vital to make the report well-structured.

Black-box view: It should only define what the system should do and refrain from stating how to
do these. This means that the SRS document should define the external behavior of the system and
not discuss the implementation issues. The SRS report should view the system to be developed as
a black box and should define the externally visible behavior of the system. For this reason, the
SRS report is also known as the black-box specification of a system.

Conceptual integrity: It should show conceptual integrity so that the reader can merely
understand it. Response to undesired events: It should characterize acceptable responses to
unwanted events. These are called system response to exceptional conditions.
Verifiable: All requirements of the system, as documented in the SRS document, should be
correct. This means that it should be possible to decide whether or not requirements have been
met in an implementation.