What is Software Engineering?

Software Engineering is the process of designing, developing, testing, and maintaining

software. It is a systematic and disciplined approach to software development that aims to
create high-quality, reliable, and maintainable software.
1.​ Software engineering includes a variety of techniques, tools, and methodologies,
including requirements analysis, design, testing, and maintenance.
2.​ It is a rapidly evolving field, and new tools and technologies are constantly being
developed to improve the software development process.
3.​ By following the principles of software engineering and using the appropriate tools
and methodologies, software developers can create high-quality, reliable, and
maintainable software that meets the needs of its users.
4.​ Software Engineering is mainly used for large projects based on software systems
rather than single programs or applications.
5.​ The main goal of Software Engineering is to develop software applications for
improving quality, budget, and time efficiency.
6.​ Software Engineering ensures that the software that has to be built should be
consistent, correct, also on budget, on time, and within the required requirements.

Software Engineering is a systematic, disciplined, quantifiable study and approach to the

design, development, operation, and maintenance of a software system. There are four
main Attributes of Software Engineering.
1.​ Efficiency: It provides a measure of the resource requirement of a software product
efficiently.
2.​ Reliability: It assures that the product will deliver the same results when used in a
similar working environment.
3.​ Reusability: This attribute makes sure that the module can be used in multiple
applications.
4.​ Maintainability: It is the ability of the software to be modified, repaired, or enhanced
easily with changing requirements.

Characteristics of Software Engineering

1.​ Maintainability: It should be feasible for the software to evolve to meet changing
requirements.
2.​ Efficiency: The software should not make wasteful use of computing devices such as
memory, processor cycles, etc.
3.​ Correctness: A software product is correct if the different requirements specified in
the SRS Document have been correctly implemented.
4.​ Reusability: A software product has good reusability if the different modules of the
product can easily be reused to develop new products.
5.​ Testability: Here software facilitates both the establishment of test criteria and the
evaluation of the software concerning those criteria.
6.​ Reliability: It is an attribute of software quality. The extent to which a program can
be expected to perform its desired function, over an arbitrary time period.
7.​ Portability: In this case, the software can be transferred from one computer system or
environment to another.
8.​ Adaptability: In this case, the software allows differing system constraints and the
user needs to be satisfied by making changes to the software.
9.​ Interoperability: Capability of 2 or more functional units to process data
cooperatively.

Program: A program is a set of instructions that are given to a computer in order to

achieve a specific task.Program is one of the stages involved in the development of the
software.

Software Product: Software is when a program is made available for commercial

business and is properly documented along with its licensing.

Software Product = Program + Documentation + Licensing

Software Development usually follows a life cycle, which involves the feasibility study
of the project, requirement gathering, development of a prototype, system design, coding,
and testing.

Advantages of Software Engineering

There are several advantages to using a systematic and disciplined approach to software
development, such as:

1.​ Improved Quality: By following established software engineering principles and

techniques, the software can be developed with fewer bugs and higher reliability.
2.​ Increased Productivity: Using modern tools and methodologies can streamline the
development process, allowing developers to be more productive and complete
projects faster.
3.​ Better Maintainability: Software that is designed and developed using sound software
engineering practices is easier to maintain and update over time.
4.​ Reduced Costs: By identifying and addressing potential problems early in the
development process, software engineering can help to reduce the cost of fixing bugs
and adding new features later on.
5.​ Increased Customer Satisfaction: By involving customers in the development process
and developing software that meets their needs, software engineering can help to
increase customer satisfaction.
6.​ Better Team Collaboration: By using Agile methodologies and continuous
integration, software engineering allows for better collaboration among development
teams.
7.​ Better Scalability: By designing software with scalability in mind, software
engineering can help to ensure that software can handle an increasing number of
users and transactions.
8.​ Better Security: By following the Software Development Life Cycle (SDLC) and
performing security testing, software engineering can help to prevent security
breaches and protect sensitive data.

Software Evolution - Software Engineering

Software Evolution is a term that refers to the process of developing software initially,
and then timely updating it for various reasons, i.e., to add new features or to remove
obsolete functionalities, etc. This article focuses on discussing Software Evolution in
detail.
What is Software Evolution?
The software evolution process includes fundamental activities of change analysis,
release planning, system implementation, and releasing a system to customers.
1.​ The cost and impact of these changes are accessed to see how much the system is
affected by the change and how much it might cost to implement the change.
2.​ If the proposed changes are accepted, a new release of the software system is
planned.
3.​ During release planning, all the proposed changes (fault repair, adaptation, and new
functionality) are considered.
4.​ A design is then made on which changes to implement in the next version of the
system.
5.​ The process of change implementation is an iteration of the development process
where the revisions to the system are designed, implemented, and tested.

Necessity of Software Evolution

Software evaluation is necessary just because of the following reasons:

1.​ Change in requirement with time: With time, the organization's needs and Modules
working could substantially be changed so in this frequently changing time the
tools(software) that they are using need to change to maximize the performance.
2.​ Environment change: As the working environment changes the things(tools) that
enable us to work in that environment also changes proportionally. The same
happens in the software world as the working environment changes then, the
organizations require reintroduction of old software with updated features and
functionality to adapt to the new environment.
 3.​ Errors and bugs: As the age of the deployed software within an organization
increases, their preciseness or impeccability decrease and the efficiency to bear the
increasing complexity workload also continually degrades. So, in that case, it
becomes necessary to avoid the use of obsolete and aged software. All such obsolete
pieces of software need to undergo the evolution process in order to become robust
as per the workload complexity of the current environment.
4.​ Security risks: Using outdated software within an organization may lead you to be at
the verge of various software-based cyberattacks and could expose your confidential
data illegally associated with the software that is in use. So, it becomes necessary to
avoid such security breaches through regular assessment of the security
patches/modules used within the software. If the software isn't robust enough to bear
the current occurring Cyber attacks so it must be changed (updated).
5.​ For having new functionality and features: In order to increase the performance and
fast data processing and other functionalities, an organization need to continuously
evolute the software throughout its life cycle so that stakeholders & clients of the
product could work efficiently.

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) is a structured process that is used to design,
develop, and test high-quality software. SDLC, or software development life cycle, is a
methodology that defines the entire procedure of software development step-by-step. The
goal of the SDLC life cycle model is to deliver high-quality, maintainable software that
meets the user's requirements.

What is the need for SDLC?

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

Stage 1: Planning and Requirement Analysis

Planning is a crucial step in everything, just as in software development. In this same

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

Stage 2: Defining Requirements

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

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

Stage 4: Developing Product

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

Stage 5: Product Testing and Integration

After the development of the product, testing of the software is necessary to ensure its
smooth execution. Although, minimal testing is conducted at every stage of SDLC.
Therefore, at this stage, all the probable flaws are tracked, fixed, and retested. This
ensures that the product confronts the quality requirements of SRS.
Documentation, Training, and Support: Software documentation is an essential part of the
software development life cycle. A well-written document acts as a tool and means to the
information repository necessary to know about software processes, functions, and
maintenance. Documentation also provides information about how to use the product.
Training in an attempt to improve the current or future employee performance by
increasing an employee's ability to work through learning, usually by changing his
attitude and developing his skills and understanding.

Stage 6: Deployment and Maintenance of Products

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

Software Development Life Cycle Models

Software Development Models are structured frameworks that guide the planning,
execution, and delivery of software projects. They define the sequence of development
stages, such as requirements, design, coding, testing, and deployment.
SDLC Waterfall Model?
The waterfall model is a Software Development Model used in the context of large,
complex projects, typically in the field of information technology. It is characterized by a
structured, sequential approach to Project Management and Software Development.
The Waterfall Model is useful in situations where the project requirements are
well-defined and the project goals are clear. It is often used for large-scale projects with
long timelines, where there is little room for error and the project stakeholders need to
have a high level of confidence in the outcome.
The Classical Waterfall Model divides the life cycle into a set of phases. The
development process can be considered as a sequential flow in the waterfall. The
different sequential phases of the classical waterfall model are follow:

1. Requirements Analysis and Specification

The aim is to clearly understand what the customer needs and record it properly.

●​ Requirement Gathering & Analysis: Collect all requirements from the customer,
then check them for missing details (incompleteness) or contradictions.​

●​ Requirement Specification: Write the analyzed requirements in a Software

Requirements Specification (SRS) document. This acts as a contract between the
customer and developers.

2. Design

Turn the requirements in the SRS into a plan that can be coded.

●​ High-Level Design (HLD): Shows the overall structure of the system and how its
main parts work together.​

●​ Low-Level Design (LLD): Breaks down each part in detail, explaining exactly
how it will work.​

The plan is recorded in a Software Design Document (SDD).

3. Development

Write the actual program code based on the design.

●​ Each module (part) is coded separately.​

●​ Unit testing is done to check that each module works properly.

4. Testing and Deployment

Testing:

●​ Integration testing: Combine modules step-by-step and test them together.​

●​ System testing: Test the full system.​

○​ Alpha testing – by developers.​

○​ Beta testing – by selected users.​

○​ Acceptance testing – by the customer to decide whether to accept the

software.​

Deployment:

●​ Deliver the software to users.​

●​ Set it up in the real environment, train users, and make sure it works as expected.

5. Maintenance

After release, the software is updated and improved. This takes about 60% of the total
work in a software’s life.

●​ Corrective – Fix errors found after release.​

●​ Perfective – Add or improve features as requested by the customer.​

●​ Adaptive – Make the software work in new environments (e.g., new OS or

hardware).
Features of the Waterfall Model

1.​ Step-by-Step Process – Work is done in order, finishing one phase before starting the
next.​

2.​ Focus on Documentation – Detailed documents are made so everyone knows the goals
and plan.​

3.​ Quality Checks – Testing is done at every stage to make sure the software meets the
requirements.​

4.​ Careful Planning – Project scope, time, and deliverables are clearly planned and
tracked.

Advantages of the Waterfall Model

1.​ Easy to Understand – Simple to learn and follow.​

2.​ Step-by-Step Work – Each phase is done one after the other.​

3.​ Clear Structure – Every stage is well-defined.​

4.​ Clear Goals – Milestones are easy to understand.​

5.​ Good Documentation – Everything is well recorded.​

6.​ Encourages Good Practice – Plan before designing, and design before coding.​

7.​ Good for Small Projects – Works well when requirements are clear from the start.​

Disadvantages of the Waterfall Model

1.​ No Feedback Path – Assumes no mistakes are made, so it’s hard to go back and fix
errors from earlier stages.​

2.​ Hard to Handle Changes – Difficult to add or change requirements once the project
has started.​
3.​ No Overlapping Phases – Each phase must finish before the next starts, which can
slow down work.​

4.​ Rigid and Inflexible – Not suitable for projects where requirements are unclear or
may change.​

5.​ Limited Client Involvement – Clients are mostly involved at the start and not much
during later stages.​

6.​ Late Problem Detection – Testing happens at the end, so errors are found late and cost
more to fix.​

7.​ Slow Development – The step-by-step process can make projects take longer and cost
more.

Mobile Banking App Development (Waterfall Model)

1. Requirements​
The bank lists all features needed, like checking balance, transferring funds, and paying
bills, along with security needs. These are clearly documented.

2. Design​
Designers plan the app screens, user navigation, database structure, and how security
features will work.

3. Development​
Developers write code to build each feature, such as login, balance display, and fund
transfer, testing each part individually.

4. Testing​
The complete app is tested for functionality and security by developers, selected users,
and the bank itself before release.

5. Deployment​
The app is published on app stores and made available to customers.

6. Maintenance​
Developers fix bugs, update security, and add new features like QR payments to keep the
app reliable and secure.

What is a Prototyping Model?

The Prototyping Model is one of the most popularly used Software Development Life
Cycle Models (SDLC models). This model is used when the customers do not know the
exact project requirements beforehand.
In this model, a prototype of the end product is first developed, tested, and refined as per
customer feedback repeatedly till a final acceptable prototype is achieved which forms
the basis for developing the final product.

Phases of Prototyping Model

Prototyping Model has six phases as follows:
1. Requirements gathering and analysis

Requirement analysis is the first step in developing a prototyping model. During this
phase, the system’s desires are precisely defined. During the method, system users are
interviewed to determine what they expect from the system.

2. Quick design

The second phase could consist of a preliminary design or a quick design. During this
stage, the system’s basic design is formed. However, it is not a complete design. It
provides the user with a quick overview of the system. The rapid design aids in the
development of the prototype.

3. Build a Prototype

During this stage, an actual prototype is intended to support the knowledge gained from
quick design. It is a small low-level working model of the desired system.

4. Initial user evaluation

The proposed system is presented to the client for preliminary testing at this stage. It is
beneficial to investigate the performance model’s strengths and weaknesses. Customer
feedback and suggestions are gathered and forwarded to the developer.

5. Refining prototype

If the user is dissatisfied with the current model, you may want to improve the type that
responds to user feedback and suggestions. When the user is satisfied with the upgraded
model, a final system based on the approved final type is created.

6. Implement Product and Maintain

The final system was fully tested and distributed to production after it was developed to
support the original version. To reduce downtime and prevent major failures, the
programmer is run on a regular basis.
Advantages of the Prototyping Model

●​ Customers see an early version of the product, increasing their satisfaction.​

●​ New or changed requirements can be added easily.​

●​ Missing features and errors are found early, saving time and cost.​

●​ Prototypes can be reused for future projects.​

●​ Design is flexible and can be improved based on feedback.​

●​ Early feedback helps guide development to meet customer needs.​

●​ Helps test design ideas before full development.​

●​ Reduces the risk of failure by spotting issues early.​

●​ Improves communication between developers and customers.​

●​ Provides a clear, visual product for both technical and non-technical stakeholders.​

Disadvantages of the Prototyping Model

●​ Can be costly and time-consuming.​

●​ Frequent changes in requirements may cause confusion.​

●​ Documentation may be poor due to constant changes.​

●​ Difficult to implement all customer changes.​

●​ Hard to know how many iterations will be needed.​

●​ Customers may expect the final product too soon.​

●​ Quick prototypes might lead to poor-quality solutions.​

●​ Customers might lose interest if the prototype isn’t good.​

●​ Prototypes may not scale or fully represent the final product.​

 ●​ Focus on prototypes can delay final development.​

●​ May give a false impression that the product is finished.​

●​ Technical challenges like scalability may be overlooked.​

●​ Different tools for prototyping may increase training and maintenance costs.​

●​ Prototype might not match actual business needs, causing dissatisfaction.

Applications of Prototyping Model

●​ The Prototyping Model should be used when the requirements of the product
are not clearly understood or are unstable.
●​ The prototyping model can also be used if requirements are changing quickly.
●​ This model can be successfully used for developing user interfaces,
high-technology software-intensive systems, and systems with complex
algorithms and interfaces.
●​ The prototyping Model is also a very good choice to demonstrate the technical
feasibility of the product.

Example: Online Food Delivery App

1.​ Initial Prototype​

The development team creates a simple version of the app showing the main
screens: restaurant list, menu, and order page. This prototype doesn’t have full
functionality but lets the customer see how the app will look and work.
2.​ Customer Feedback​
The customer reviews the prototype and suggests adding features like user
reviews, order tracking, and payment options.
3.​ Refinement​
Developers update the prototype by adding these features and improving the user
interface based on the feedback.
4.​ More Feedback and Changes​
The prototype is shared again with the customer for further suggestions and
corrections.
5.​ Final Product Development​
Once the customer approves the prototype, the full app is developed with all
features working properly.
6.​ Deployment and Maintenance​
The app is launched, and developers continue to fix bugs and add new features
based on user feedback.​
Incremental Model

The Incremental Model develops a software system in small, manageable parts called
increments. Instead of building the whole system at once, the project is divided into
pieces, and each piece adds some functionality to the system.

How It Works:

●​ The project is split into multiple increments, where each increment delivers a
working part of the software.​

●​ The first increment contains the core or most important features.​

●​ Each subsequent increment adds new features or improves existing ones.​

●​ After each increment, the software is tested and delivered to the user.​

●​ This continues until all increments are completed and the full system is ready.​

Process Steps:

1.​ Planning – Decide which features to include in each increment based on priority.​

2.​ Design & Development – Design and develop the features planned for the current
increment.​

3.​ Testing – Test the new features and how they integrate with the existing system.​

4.​ Delivery – Deliver the increment to the user for feedback and use.​

5.​ Repeat – Plan and develop the next increment until the complete system is
finished.​

Advantages of Incremental Model:

●​ Early Working Product: Users get a working version quickly, even if it’s basic at
first.​

●​ Flexibility: It’s easier to add or change features in later increments.​

●​ Risk Management: Problems can be found and fixed early in smaller increments.​
 ●​ User Feedback: Users can provide feedback after each increment, improving
satisfaction.​

●​ Better Resource Management: Work can be divided and prioritized effectively.​

Example:

Developing a Weather Forecast App incrementally:

●​ Increment 1: Show current weather for one location.​

●​ Increment 2: Add a 5-day weather forecast.​

●​ Increment 3: Add weather alerts and notifications.​

●​ Each increment is tested and delivered before moving to the next.

Iterative Model

The Iterative Model focuses on developing software through repeated cycles called
iterations. Instead of building the entire system at once, the software is developed and
improved step-by-step by repeatedly going through phases like planning, design, coding,
and testing.

How It Works:

●​ Start with a basic version of the software, containing only the most important
features.​

●​ After each iteration, the software is reviewed and tested.​

●​ Feedback and test results are used to improve the software in the next iteration.​

●​ Each new iteration adds more features or improves existing ones.​

●​ This cycle repeats until the software meets all requirements and is complete.​
Process Steps:

1.​ Planning: Define goals and features for the current iteration.​

2.​ Analysis and Design: Analyze requirements and design the system parts to be
developed in this iteration.​

3.​ Implementation: Write the code and build the features planned.​

4.​ Testing: Test the new features and the whole system for errors.​

5.​ Evaluation: Review the iteration outcome and gather feedback.​

6.​ Repeat: Plan the next iteration with improvements or new features.

Advantages of the Iterative Model:

●​ Early Feedback: Users can test early versions and suggest changes.​

●​ Flexibility: Easy to adapt to changing requirements.​

●​ Risk Reduction: Problems are identified and fixed early.​

●​ Continuous Improvement: Software quality improves with each iteration.​

●​ Better Resource Use: Work is divided into manageable cycles.​

Example:

Developing a Social Media App:

●​ Iteration 1: Build a basic profile and posting feature.​

●​ Iteration 2: Add friend requests and messaging.​

●​ Iteration 3: Add notifications and photo uploads.​

●​ After each iteration, the app is tested and improved based on user feedback.
Iterative Model Incremental Model Prototyping Model

Repeatedly improving and Building the software in Quickly creating a working model
refining the software in small parts (increments), (prototype) to understand
cycles (iterations). each adding functionality. requirements.

Each iteration includes Each increment delivers a Build a simple version early, get
planning, designing, coding, working piece of software feedback, then refine or build final
and testing. that builds on previous parts. product.

Improve software Deliver parts of the software Explore and clarify requirements
step-by-step through gradually, adding features through early visual models.
repeated cycles. over time.

Customers review and give Customers see working parts Customers interact with
feedback after each after each increment. prototypes early and often.
iteration.

Flexible — changes can be Flexible — changes can be Very flexible — prototypes change
made after each iteration. planned in future increments. frequently based on feedback.

Risks are reduced by early Risks are lowered by Helps identify risks early by
testing and refinement in delivering smaller, clarifying requirements with
each iteration. manageable parts. prototypes.

Projects where requirements Projects that can be divided When requirements are unclear
may evolve but a working into smaller parts for and need clarification.
product is needed early. stepwise delivery.

Usually more detailed and Documentation increases Documentation can be limited due
updated through iterations. with each increment. to frequent changes.
A working version is Working versions of the Prototype delivered early; final
improved repeatedly until software are delivered product after refinements.
complete. incrementally.

Evolutionary Model - Software Engineering

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. This article focuses on discussing the Evolutionary Model in
detail.
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.
 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 SDLC Models

The Spiral Model is a Software Development Life Cycle (SDLC) model that provides a
systematic and iterative approach to software development. In its diagrammatic
representation, looks like a spiral with many loops. The exact number of loops of the
spiral is unknown and can vary from project to project. Each loop of the spiral is called a
phase of the software development process.
Some Key Points regarding the Stages of a Spiral Model:
1.​ The exact number of phases needed to develop the product can be varied by the
project manager depending upon the project risks.
2.​ As the project manager dynamically determines the number of phases, the project
manager has an important role in developing a product using the spiral model.
3.​ It is based on the idea of a spiral, with each iteration of the spiral representing a
complete software development cycle, from requirements gathering and analysis to
design, implementation, testing, and maintenance.

The Spiral Model is a risk-driven model, meaning that the focus is on managing risk
through multiple iterations of the software development process. Each phase of the Spiral
Model is divided into four Quadrants:
1. Objectives Defined

In first phase of the spiral model we clarify what the project aims to achieve, including
functional and non-functional requirements.
Requirements are gathered from the customers and the objectives are identified,
elaborated, and analyzed at the start of every phase. Then alternative solutions possible
for the phase are proposed in this quadrant.

2. Risk Analysis and Resolving

In the risk analysis phase, the risks associated with the project are identified and
evaluated.
During the second quadrant, all the possible solutions are evaluated to select the best
possible solution. Then the risks associated with that solution are identified and the risks
are resolved using the best possible strategy. At the end of this quadrant, the Prototype is
built for the best possible solution.

3. Develop the next version of the Product

During the third quadrant, the identified features are developed and verified through
testing. At the end of the third quadrant, the next version of the software is available.
In the evaluation phase, the software is evaluated to determine if it meets the customer's
requirements and if it is of high quality.

4. Review and plan for the next Phase

In the fourth quadrant, the Customers evaluate the so-far developed version of the
software. In the end, planning for the next phase is started.
The next iteration of the spiral begins with a new planning phase, based on the results of
the evaluation.
The Spiral Model is often used for complex and large software development projects, as
it allows for a more flexible and adaptable approach to Software development. It is also
well-suited to projects with significant uncertainty or high levels of risk.
The Radius of the spiral at any point represents the expenses (cost) of the project so far,
and the angular dimension represents the progress made so far in the current phase.

Risk Handling in Spiral Model

A risk is any adverse situation that might affect the successful completion of a software
project. The most important feature of the spiral model is handling these unknown risks
after the project has started. Such risk resolutions are easier done by developing a
prototype.
1.​ The spiral model supports coping with risks by providing the scope to build a
prototype at every phase of software development.
2.​ The Prototyping Model also supports risk handling, but the risks must be identified
completely before the start of the development work of the project.
3.​ But in real life, project risk may occur after the development work starts, in that case,
we cannot use the Prototyping Model.
4.​ In each phase of the Spiral Model, the features of the product dated and analyzed, and
the risks at that point in time are identified and are resolved through prototyping.
5.​ Thus, this model is much more flexible compared to other SDLC models.

Why Spiral Model is called Meta Model?

The Spiral model is called a Meta-Model because it subsumes all the other SDLC
models. For example, a single loop spiral actually represents the Iterative Waterfall
Model.

1.​ The spiral model incorporates the stepwise approach of the Classical Waterfall
Model.
2.​ The spiral model uses the approach of the Prototyping Model by building a
prototype at the start of each phase as a risk-handling technique.
3.​ Also, the spiral model can be considered as supporting the Evolutionary model - the
iterations along the spiral can be considered as evolutionary levels through which
the complete system is built.

Advantages of the Spiral Model

Below are some advantages of the Spiral Model.

1.​ Risk Handling: The projects with many unknown risks that occur as the development
proceeds, in that case, Spiral Model is the best development model to follow due to
the risk analysis and risk handling at every phase.
2.​ Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.
3.​ Flexibility in Requirements: Change requests in the Requirements at a later phase can
be incorporated accurately by using this model.
4.​ Customer Satisfaction: Customers can see the development of the product at the early
phase of the software development and thus, they habituated with the system by
using it before completion of the total product.
5.​ Iterative and Incremental Approach: The Spiral Model provides an iterative and
incremental approach to software development, allowing for flexibility and
adaptability in response to changing requirements or unexpected events.
6.​ Emphasis on Risk Management: The Spiral Model places a strong emphasis on risk
management, which helps to minimize the impact of uncertainty and risk on the
software development process.
7.​ Improved Communication: The Spiral Model provides for regular evaluations and
reviews, which can improve communication between the customer and the
development team.
8.​ Improved Quality: The Spiral Model allows for multiple iterations of the software
development process, which can result in improved software quality and reliability.

Disadvantages of the Spiral Model

Below are some main disadvantages of the spiral model.

1.​ Complex: The Spiral Model is much more complex than other SDLC models.
2.​ Expensive: Spiral Model is not suitable for small projects as it is expensive.
3.​ Too much dependability on Risk Analysis: The successful completion of the project
is very much dependent on Risk Analysis. Without very highly experienced experts,
it is going to be a failure to develop a project using this model.
4.​ Difficulty in time management: As the number of phases is unknown at the start of
the project, time estimation is very difficult.
5.​ Complexity: The Spiral Model can be complex, as it involves multiple iterations of
the software development process.
6.​ Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple
evaluations and reviews.
7.​ Resource Intensive: The Spiral Model can be resource-intensive, as it requires a
significant investment in planning, risk analysis, and evaluations.

The most serious issue we face in the cascade model is that taking a long length to finish
the item, and the product became obsolete. To tackle this issue, we have another
methodology, which is known as the Winding model or spiral model. The winding model
is otherwise called the cyclic model.
When To Use the Spiral Model?
Here are the reasons where the Spiral Model is used:

1.​ When a project is vast in Software Engineering, a spiral model is utilized.

2.​ A spiral approach is utilized when frequent releases are necessary.
3.​ When it is appropriate to create a prototype
4.​ When evaluating risks and costs is crucial
5.​ The spiral approach is beneficial for projects with moderate to high risk.
6.​ The SDLC's spiral model is helpful when requirements are complicated and
ambiguous.
7.​ If modifications are possible at any moment
8.​ Committing to a long-term project is impractical owing to shifting economic
priorities.

Example: Building a Music Player App

1.​ First Round:​

○​ Understand basic needs like play, pause, and stop music.​

○​ Identify risks such as app crashing or poor sound quality.​

○​ Create a simple prototype with play and pause buttons.​

2.​ Second Round:​

○​ Improve the design based on feedback.​

○​ Add features like playlist creation and shuffle.​

○​ Test the app for crashes and bugs.​

3.​ Third Round:​

○​ Add more features such as equalizer and song search.​

○​ Perform performance testing and fix issues.​

4.​ Final Round:​

○​ Complete the app with all features.​

○​ Do full testing and release the app.

What is a Feasibility Study?

A Feasibility Study is a detailed investigation and evaluation of a proposed project or

system to determine if it is practical, achievable, and likely to succeed within the given
constraints. It helps decision-makers understand the viability of the project before
committing significant time, money, and resources.

The study examines multiple dimensions—technical, economic, operational, social, legal,

and scheduling—to identify potential risks, costs, benefits, and challenges. The goal is to
provide a clear picture of whether the project should proceed, be modified, or abandoned.
Importance of a Feasibility Study

●​ Reduces Risk: By identifying potential problems early, the study minimizes project
failure chances.​

●​ Improves Planning: It provides essential data that guides detailed project planning and
resource allocation.​

●​ Supports Decision-Making: Stakeholders can make informed choices based on

thorough analysis rather than guesswork.​

●​ Saves Resources: Avoids investing in projects that are unlikely to succeed or

profitable.​

●​ Builds Stakeholder Confidence: Shows due diligence and commitment to thorough

evaluation.​

Types of Feasibility Studies

1. Technical Feasibility

This evaluates whether the project can be successfully completed with the available
technology, tools, equipment, and technical skills. It asks questions like:

●​ Are the required hardware and software resources available?​

●​ Does the team have the technical expertise needed?​

●​ Can the technology meet project requirements and performance standards?​

●​ Is the current IT infrastructure sufficient?​

●​ Can the project be completed within the technical constraints and timeline?​

Example: Assessing if a new software system can run on the company’s existing servers.
2. Economic Feasibility (Financial Feasibility)

This focuses on analyzing the financial aspects of the project to ensure it is cost-effective
and profitable. Key points include:

●​ Estimating total project costs (development, operation, maintenance).​

●​ Forecasting potential revenue or cost savings.​

●​ Performing cost-benefit analysis and Return on Investment (ROI) calculations.​

●​ Evaluating funding sources and budget availability.​

●​ Considering long-term financial sustainability.​

Example: Determining if the expected sales from a new product justify the investment
costs.

3. Operational Feasibility

This assesses how well the proposed project fits into the current operational processes
and organizational structure. It checks:

●​ Whether the organization can support the new system or process.​

●​ Impact on existing workflows and employee roles.​

●​ Ease of integrating the project with current operations.​

●​ Availability of trained personnel to operate and maintain the system.​

●​ User acceptance and willingness to adapt to the change.​

Example: Checking if a new customer management system will be easily adopted by the
sales team.

4. Social Feasibility (Social and Cultural Feasibility)

This looks at the impact of the project on people, communities, and society, considering:

●​ Social acceptance by stakeholders and the public.​

 ●​ Ethical implications and cultural sensitivities.​

●​ Effects on local communities, environment, and social norms.​

●​ Corporate social responsibility and alignment with social goals.​

●​ Potential opposition or support from social groups.​

Example: Evaluating if building a factory will affect local communities’ environment or

livelihood.

5. Legal Feasibility

Legal feasibility studies examine the regulatory and legal requirements relevant to the
project. They ensure that:

●​ The project complies with laws and regulations (e.g., data protection, labor laws).​

●​ Necessary permits and licenses can be obtained.​

●​ There are no legal obstacles or potential lawsuits that could stop or delay the
project.​

●​ Intellectual property rights are respected.​

Example: Ensuring a healthcare software complies with patient privacy laws like HIPAA.

6. Schedule Feasibility

This type assesses whether the project can be completed within the desired timeline. It
evaluates:

●​ Estimated project duration versus deadlines.​

●​ Availability of resources and personnel within the schedule.​

●​ Potential bottlenecks or delays.​

●​ The impact of any schedule overruns.​

Example: Analyzing if a website redesign can be completed before a major product

launch date.
7. Environmental Feasibility (Optional but Increasingly Important)

This looks at the environmental impact of the project and whether it aligns with
sustainability goals. It covers:

●​ Effects on natural resources, pollution, waste management.​

●​ Compliance with environmental laws.​

●​ Opportunities to use green technologies or reduce carbon footprint.​

Example: Assessing if a construction project follows environmental regulations and

minimizes ecological damage.

Steps to Conduct a Feasibility Study

1.​ Preliminary Analysis: Understand the basic idea of the project and its objectives.​

2.​ Define Scope and Criteria: Decide what aspects will be studied and success criteria.​

3.​ Data Collection: Gather information on technical, financial, operational, and legal
factors.​

4.​ Analysis: Evaluate collected data to identify risks, costs, benefits, and challenges.​

5.​ Report Preparation: Document findings, conclusions, and recommendations.​

6.​ Decision Making: Stakeholders review the study and decide whether to proceed,
modify, or stop the project.

Functional Requirements

Functional requirements describe what the system should do. They define the specific
behavior or functions of the software — essentially the tasks, features, or services the
system must provide.

●​ They explain the actions, inputs, outputs, and processes the system must perform.​

●​ Functional requirements answer questions like:​

○​ What features does the system have?​

 ○​ How should the system respond to inputs?​

○​ What data will the system handle?​

Examples of Functional Requirements:

●​ The system must allow users to register and log in.​

●​ The application shall send an email confirmation after successful registration.​

●​ The software should allow users to add, edit, and delete items from a shopping
cart.​

●​ The system must generate monthly sales reports.​

Non-Functional Requirements

Non-functional requirements define how the system performs its functions. They describe
the system’s quality attributes, constraints, and overall behavior rather than specific
behaviors.

●​ These requirements focus on performance, usability, reliability, security, and

scalability.​

●​ They answer questions like:​

○​ How fast should the system respond?​

○​ How secure should it be?​

○​ What are the system’s availability and reliability targets?​

Examples of Non-Functional Requirements:

●​ The system should respond to user requests within 2 seconds.​

●​ The application must be available 99.9% of the time.​

●​ User passwords must be encrypted and stored securely.​

 ●​ The system should support 10,000 concurrent users without degradation.​

●​ The interface should be easy to navigate for users with no technical background.​

Functional Requirements Non-Functional Requirements

Describe what the system should do Describe how the system performs its
(functions and features). functions (qualities and constraints)

Specify the actions the system must take. Specify the system’s quality and operational
attributes.

Examples: user login, data input, report Examples: response time, availability, security
generation. levels.

Verified by functional testing (does it do Verified by performance testing, security

what it should?). audits, etc.

Directly affects what users can do with the Affects user experience and system
system. effectiveness.

Project Report Feasibility Report

It mainly focuses on determining feasibility

It mainly focuses on determining whether
of project i.e. possible to do easily and
project is viable or not.
conveniently or not.
It does not have a specific format. It have a specific format.

Factors affecting feasibility report includes

Factors affecting project report include time
scope of project, volume vs quality,
complexity, improper communication, lack of
complexity and scale, constraints such as
understanding, cost related issues, etc.
funding, etc.

Its benefits include identifying risks, cost

Its benefits include improve team focus,
management, control of project, increase
identify new opportunities, provide
project success manage budget effectively,
important information regarding feasibility,
improve communication, increase team
etc.
performance, etc.

Its main objective is to provide status of Its main objectives is to help decision
scope, time, and budget of project and makers to choose among options that are
manage expectations of stakeholders available.

It include information such executive

It includes manufacturing process, project
summary, marketing strategy,
description, marketing plan, capture structure
organizational structure, description of
and operating cost, etc.
project, etc.

It is generally submitted to company that

It is generally submitted to bankers.
requested to solve a particular problem.
It is more difficult to understand and handle It is less difficult to understand and handle
than feasibility report. than project report.

What is Requirements Gathering?

Requirements gathering is a crucial phase in the software development life cycle (SDLC)
and project management. It involves collecting, documenting, and managing the
requirements that define the features and functionalities of a system or application. The
success of a project often depends on the accuracy and completeness of the gathered
requirements in software.
Processes of Requirements Gathering in Software Development:
There are 6 steps crucial for requirement gathering processes

Step 1 – Assign Roles

First, identify and involve all important people related to the project. This includes users,
clients, project managers, experts, and anyone interested in the software. Understanding
their views helps gather a wide range of requirements.

Step 2 – Define Project Scope

Clearly explain what the project will do, its goals, and limits. This helps everyone agree
on what the software should achieve and which features it will have.
Step 3 – Talk to Stakeholders

Arrange meetings with key people to learn about their needs and expectations. Ask open
questions to discover both obvious and hidden requirements. These talks give useful
information for a better overall understanding.

Step 4 – Write Down Requirements

Carefully record all gathered requirements. Use formats like user stories, use cases, or
formal documents. Clearly describe what the system must do (functional requirements)
and qualities it should have like speed or security (non-functional requirements).

Step 5 – Check and Confirm Requirements

Review the documented requirements with stakeholders to make sure they reflect what
they want (verification) and will help meet project goals (validation). This may need
multiple feedback sessions to improve and clarify the details.

Step 6 – Prioritize Requirements

Rank the requirements by how important they are to the project and based on available
time and resources. This helps decide what to build first and plan the development work
effectively.

Requirement Gathering Techniques:

Effective requirement gathering is essential for the success of a software development
project. Various techniques are employed to collect, analyze, and document requirements.

Interviews

Talk one-on-one or in groups with people involved, like users, clients, and experts. This
helps gather detailed information about what they need, want, and worry about.
Surveys and Questionnaires

Send out surveys or questionnaires to many people to collect feedback from a larger
group. This works well for big projects with many stakeholders.

Workshops

Hold group meetings where everyone discusses and defines the requirements together.
Workshops help share ideas, solve disagreements, and get everyone on the same page.

Observation

Watch how users do their work in real life to understand their routines, problems, and
preferences. This helps find needs they might not say directly.

Prototyping

Make simple models or mockups of the software to show stakeholders what it might look
like. This helps get early feedback and improve the design.

Use Cases and Scenarios

Create stories or examples showing how users will use the system in different situations.
This helps understand user actions and define system functions.

Document Analysis

Look at existing documents like manuals, reports, and forms to find useful information.
This helps understand current processes and find areas to improve.

Requirement Analysis

Requirement Analysis is a crucial phase in the software development process where the
project team works closely with stakeholders—such as clients, end-users, and business
experts—to clearly understand, organize, and define what the software system must
achieve. This phase ensures that everyone involved has a shared understanding of the
project goals and expected functionalities before actual development begins.

Importance of Requirement Analysis

●​ Clarity and Understanding: It helps clarify what the users truly need, avoiding
vague or ambiguous ideas about the software’s purpose.​

●​ Early Problem Detection: Identifies missing, incomplete, or conflicting

requirements early, reducing costly changes later.​
 ●​ Project Planning: Provides a solid foundation for planning design, development,
testing, and deployment activities.​

●​ Risk Reduction: By knowing the exact requirements, risks related to scope creep
or miscommunication are minimized.​

●​ Stakeholder Satisfaction: Ensures the final product meets user expectations and
business goals, improving satisfaction.​

Key Activities in Requirement Analysis

1.​ Requirement Gathering:​

This involves collecting information from all relevant stakeholders through various
techniques like interviews, questionnaires, workshops, observations, and prototyping.
The goal is to gather all the functional (what the system should do) and non-functional
(how the system should perform) requirements.​

2.​ Requirement Classification and Prioritization:​

Once gathered, requirements are grouped into categories such as functional,
non-functional, business, user, and system requirements. Prioritization helps focus on
the most important features first, especially when there are constraints like time and
budget.​

3.​ Requirement Modeling:​

This involves creating models or diagrams (like use case diagrams, data flow
diagrams, or entity-relationship diagrams) to visually represent requirements and
system interactions. Modeling helps stakeholders better understand and validate
requirements.​

4.​ Requirement Analysis and Negotiation:​

During this phase, analysts check for conflicts, inconsistencies, or unrealistic demands
within the requirements. They work with stakeholders to resolve disagreements and
negotiate feasible solutions.​

5.​ Documentation:​
All requirements are clearly documented, typically in a Software Requirement
Specification (SRS) document. This document should be precise, unambiguous, and
easy to understand for both technical teams and stakeholders.​

6.​ Verification and Validation:​

The documented requirements are reviewed and validated with stakeholders to ensure
 they accurately reflect their needs and expectations. This step may involve
walkthroughs, reviews, and formal approval processes.​

Types of Requirements Analyzed

●​ Functional Requirements: Define specific behaviors or functions of the system (e.g.,

user authentication, report generation).​

●​ Non-Functional Requirements: Define system qualities such as performance, security,

usability, and reliability.​

●​ Business Requirements: High-level business goals or policies the software must

support.​

●​ User Requirements: Needs and preferences of the end-users interacting with the
system.​

●​ System Requirements: Technical and environmental constraints like hardware,

software, and network conditions.​

Challenges in Requirement Analysis

●​ Unclear or Changing Requirements: Users may not know exactly what they want or
change their minds frequently.​

●​ Communication Gaps: Misunderstandings between technical teams and stakeholders

can cause incorrect requirements.​

●​ Incomplete Information: Missing details can lead to gaps in the requirements.​

●​ Conflicting Requirements: Different stakeholders may have opposing needs.​

●​ Scope Creep: Uncontrolled changes or additions to requirements can derail the

project.

What is Software Requirements Specification (SRS)?

A Software Requirements Specification (SRS) is a detailed and formal document that

clearly explains what a software system should do and the limits it must follow. It
describes both the features the software must have (called functional requirements) and
the qualities it must meet, like performance and security (called non-functional
requirements). The SRS acts like a blueprint or guide for building the software.
 It is an essential document in software development that everyone involved—such as
customers, developers, testers, and project managers—can use as a common reference to
make sure they all understand the project goals clearly.

Usually, the SRS includes detailed explanations, examples of how users will interact with
the system, and different scenarios that help illustrate these interactions. This way,
everyone can agree on what the software is supposed to do.

Why is an SRS Important?

The SRS document serves several important purposes:

●​ Set Clear Expectations: It clearly defines exactly what the software will do and the
conditions it needs to work under.​

●​ Improve Communication: It acts as a communication tool among customers, users, and

developers so everyone understands the requirements the same way.​

●​ Guide Development and Testing: Developers use the SRS as a reference to build the
software, and testers use it to create test cases to check if the software works as
expected.​

●​ Control Project Scope: It helps manage what features are included or excluded,
preventing unplanned additions that could delay the project.​

●​ Legal and Contract Use: It acts as an agreement or contract between customers and
developers. If there are disagreements later, the SRS can be checked to settle issues.​

Who Writes the SRS?

Usually, the SRS is created in two steps by different groups of people:

1.​ Customer Version: In the beginning, the customer or a business analyst writes a
simple version that explains their needs and goals for the software in
easy-to-understand language.​

2.​ Developer Version: Next, the developers take that information and create a more
detailed and technical version. This version explains how the software will be
designed, built, and work internally.​

Both versions should match and be approved by all stakeholders before the project moves
forward.
What Does an SRS Usually Include?

An SRS document generally contains these main parts:

●​ Introduction: Explains the purpose of the document, what the software will cover,
important terms, and references.​

●​ Overall Description: Gives an overview of the software’s place in the larger system,
its main functions, the users who will use it, any assumptions or constraints, and
dependencies on other systems.​

●​ Specific Requirements:​

○​ Functional Requirements: Detailed description of what the software must do.​

○​ Non-Functional Requirements: Quality standards like performance, security,

usability, and reliability.​

○​ Interface Requirements: How users, hardware, or other software will interact

with the system.​

○​ Design Constraints: Any limitations such as technologies or standards that must

be followed.​

○​ Quality Attributes: Expected levels of quality, such as response time or

availability.​

●​ Use Cases or User Stories: Examples of how users will interact with the software to
complete tasks.​

●​ Appendices and Glossary: Additional helpful information and definitions of technical

terms.​

Characteristics of a Good SRS

A well-written SRS should have these qualities:

●​ Correct: It must correctly reflect the real needs and expectations of all stakeholders
without mistakes.​

●​ Clear and Unambiguous: The language should be simple and precise so there is no
confusion or multiple interpretations.​
●​ Complete: It should cover all necessary requirements without missing anything
important.​

●​ Consistent: There should be no conflicting or contradictory statements.​

●​ Prioritized: Requirements should be ranked by importance to help plan development.​

●​ Verifiable: It must be possible to test or check whether the requirements are met.​

●​ Modifiable: The document should be organized so changes can be made easily as the
project progresses.​

●​ Traceable: Each requirement should be linked back to its origin, such as a stakeholder
or business need, to track its history throughout the project.​

Benefits of Having an SRS

Creating an SRS provides many advantages:

●​ Saves Time and Money: Clear requirements reduce errors and rework.​

●​ Enhances Communication: Everyone on the team understands the goals and

expectations clearly.​

●​ Helps Plan the Project: Supports scheduling, resource allocation, and budgeting.​

●​ Improves Software Quality: Helps ensure the final product meets user needs.​

●​ Supports Maintenance: Acts as a reference for fixing bugs and adding features in the
future.​

Challenges in Preparing an SRS

While writing an SRS is very helpful, it can also face some difficulties:

●​ Customers might change their requirements during the project.​

●​ Some requirements might be vague or incomplete.​

●​ Misunderstandings can occur between customers and developers.​

 ●​ Providing either too many details or too few can cause problems.​

●​ The SRS needs to be updated regularly as the project evolves.

Various Dimensions in Requirement Gathering (Detailed Explanation)

Requirement gathering is the process of collecting all the necessary information to

understand what a software system must do. To do this effectively, it is important to look
at the project from different dimensions or perspectives. Each dimension focuses on a
specific area, helping to gather comprehensive requirements and avoid missing key
points.

1. Stakeholder Dimension

This dimension focuses on identifying all individuals and groups who have an interest or
stake in the software project. Stakeholders can include:

●​ End-users: The people who will actually use the software daily. Their input helps
define usability and practical needs.​

●​ Customers or Clients: Those who fund the project or have requested the software.
They define business objectives and expectations.​

●​ Project Managers: Oversee the project’s progress, schedule, and budget. Their
concerns involve resource allocation and timelines.​

●​ Developers and Testers: Technical team members who build and validate the software.
Their feedback ensures technical feasibility.​

●​ Support and Maintenance Teams: Those responsible for the software

post-deployment, focusing on maintainability and user support.​

Understanding the needs and priorities of all stakeholders is critical because different
groups may have conflicting requirements. Effective communication and negotiation help
balance these.

2. Functional Dimension

This dimension describes what the software must do — the tasks, actions, and features it
should provide. It defines the system’s behavior and functionalities. Examples include:

●​ User Authentication: Login, logout, password reset.​

●​ Data Management: Creating, reading, updating, and deleting records.​

●​ Reporting: Generating reports or exporting data.​

●​ Notifications: Alerts via email or SMS.​

●​ Business Rules: Automated calculations, validations, or workflows.​

Capturing functional requirements is essential because they form the foundation for
software design and development.

3. Non-Functional Dimension

While functional requirements describe what the system does, non-functional

requirements describe how the system performs those functions and the quality standards
it must meet. Important non-functional aspects include:

●​ Performance: Response time, throughput, latency, and scalability (how well the
system performs under different loads).​

●​ Security: Measures like authentication, authorization, data encryption, and audit trails.​

●​ Usability: Ease of use, accessibility, user interface standards.​

●​ Reliability: System uptime, error rates, fault tolerance.​

●​ Maintainability: How easy it is to update or fix the software.​

●​ Portability: Ability to operate on different platforms or environments.​

These requirements often influence the architecture, technology choices, and testing
approaches.

4. Business Dimension

This dimension connects the software to the organization’s goals, strategies, and policies.
Requirements here focus on:

●​ Business Goals: For example, increasing customer satisfaction, reducing costs, or

expanding market reach.​
●​ Regulatory Compliance: Ensuring the software follows laws, industry standards, or
certifications (e.g., GDPR, HIPAA).​

●​ Business Processes: Software should align with existing workflows or help automate
new ones.​

●​ Constraints: Budgets, deadlines, or organizational policies that restrict project scope

or design.​

Understanding business context ensures the software delivers real value and supports
strategic objectives.

5. Technical Dimension

This dimension involves technical details and constraints that affect how the software
will be built and run:

●​ Platforms: Target operating systems, devices, and browsers.​

●​ Technologies: Programming languages, frameworks, databases, and tools preferred or

mandated.​

●​ Integration: How the software will connect with existing systems, APIs, or hardware.​

●​ Infrastructure: Network bandwidth, servers, cloud services, or hardware limitations.​

●​ Standards: Compliance with technical standards or protocols (e.g., ISO, IEEE).​

Technical requirements ensure the software fits into the organization’s technology
environment and can be supported.

6. User Dimension

Different users interact with the software in different ways. This dimension studies:

●​ User Roles: Admins, regular users, guests, or external partners.​

●​ User Skills: Novice users versus expert users, affecting design complexity and training
needs.​

●​ Access Levels: What information or functions each user group can access.​
●​ User Expectations: Preferences related to look and feel, workflows, or response times.​

Identifying user diversity helps tailor the software’s interface, security, and support
accordingly.

7. Environmental Dimension

This dimension examines the external environment where the software will be used or
maintained, including:

●​ Physical Environment: Office, factory floor, outdoors, or mobile contexts, affecting

usability and design.​

●​ Organizational Culture: Formal or informal procedures, communication styles, and

decision-making processes.​

●​ Support Environment: Availability of IT support, user training programs, and

maintenance teams.​

●​ Legal and Ethical Factors: Local laws, privacy concerns, and ethical considerations.​