Unit 1 Software Engineering Fundamentals

1.1 Software

Software refers to a collection of computer programs, data, and instructions that enable a
computer system to perform specific tasks or functions. It encompasses both the tangible code
and the intangible algorithms that govern how a computer operates. Software can be broadly
categorized into two main types: system software and application software.

System software serves as the foundational layer of a computer's operating environment,

responsible for managing hardware resources, providing essential services, and facilitating
communication between hardware and other software components. This includes the operating
system (such as Windows, macOS, or Linux) and device drivers, which enable peripheral devices
to interact with the computer seamlessly.

Application software, on the other hand, encompasses a wide range of programs designed to
address specific user needs or tasks. These can include word processors, spreadsheet applications,
web browsers, video games, and specialized tools for various industries like graphic design or
scientific research. Application software is created to enhance productivity, creativity,
entertainment, and a myriad of other functions, making it the part of software that most users
interact with directly.

Software development involves a multi-step process that includes design, coding, testing,
debugging, and maintenance. Programmers write code in programming languages like Java, C++,
Python, and many others, translating human-readable instructions into machine code that
computers can execute. The quality of software is crucial, as poorly designed or tested software
can lead to errors, vulnerabilities, and system failures.

The evolution of software has been rapid and transformative, with the advent of cloud computing,
mobile applications, artificial intelligence, and the Internet of Things (IoT) leading to
increasingly sophisticated and interconnected software ecosystems. As technology continues to
advance, software remains at the heart of digital innovation, enabling everything from social
networking platforms to autonomous vehicles and beyond, making it a critical component of our
modern world.
 .

1.2 Problem Domain

In software engineering, the problem domain refers to the specific area or subject matter that a software
system is designed to address or solve. It defines the context in which the software will operate and the
real-world issues or challenges it aims to resolve. Understanding the problem domain is a fundamental
step in the software development process because it informs the requirements, design, and functionality of
the software. Here, we'll delve into the concept of the problem domain in more detail:

Problem Identification: The first step in addressing any problem is identifying it. In software
engineering, this involves working closely with stakeholders, domain experts, and end-users to
understand their needs and the challenges they face. This process often includes conducting interviews,
surveys, and research to gather information about the problem domain.

Problem Abstraction: Once the problem is identified, it needs to be abstracted into a form that can be
translated into software. This abstraction involves defining the key concepts, entities, and relationships
within the problem domain. It may include creating diagrams, models, or documentation to represent the
problem's structure and dynamics.

Domain Knowledge: Developing effective software requires a deep understanding of the problem
domain. Software engineers must become domain experts to make informed decisions about how the
software should behave and what features it should have. This may involve learning about industry-
specific terminology, business processes, regulations, and user preferences.

Requirements Gathering: The problem domain analysis informs the gathering of software requirements.
Requirements are a crucial part of the software development process because they describe what the
software should do and how it should behave in the context of the problem domain. Accurate and
comprehensive requirements are essential for building a system that meets user needs.

Design and Architecture: The problem domain analysis influences the architectural and design decisions
for the software. The structure of the software, the choice of algorithms and data structures, and the user
interface design are all influenced by the characteristics and constraints of the problem domain.

Testing and Validation: To ensure that the software effectively addresses the problem domain, rigorous
testing and validation are necessary. Test cases and scenarios should be designed to cover various aspects
of the problem domain, including different input scenarios and edge cases.
Feedback and Iteration: As the software is developed and deployed, feedback from users and
stakeholders is invaluable. This feedback can reveal whether the software is effectively addressing the
problem domain and whether any adjustments or enhancements are needed. The iterative nature of
software development allows for ongoing refinement to better match the problem domain's evolving
requirements.

Scalability and Adaptability: In some cases, the problem domain may change over time, or the software
may need to scale to handle larger volumes of data or users. Software engineers need to anticipate these
changes and design the system to be adaptable and scalable to accommodate future needs.

1.3 Software Engineering Challenges

Every software engineer faces various challenges when it comes to being an excellent programmer.
Some of these challenges are particular to the person and their developmental stage. However,
regardless of their level of training and expertise, all engineers face similar problems. Let's check the
most common software engineer challenges and discuss their responsibilities. These software
engineering challenges must be addressed immediately to minimize their effect on your final product .

The rapid advancement of technology

For the IT sector, every technological innovation is a blessing. The rapid advancement of technology
puts additional pressure on software development professionals to take advantage of these trends when
creating new software products to stand out from the crowd and obtain a competitive advantage. It is
one of the major software engineering problems.

2. Increasing customer demands in the development stage

The majority of software projects are conceptual in nature and are focused on creating software
solutions that satisfy a range of consumer needs. Even the simplest application or product requires
developers to fully grasp the underlying business concept and incorporate the necessary functionality
to meet the ever-increasing client needs. It is among the software engineer coding challenges faced in
software development.

3. Time limitation

The deadlines set for software engineers are incredibly short and are one of the major challenges of
being a software engineer. After all, it is a game of time. When engineers collaborate with several
clients across various time zones, the process becomes considerably more difficult. These time
restraints frequently cause development teams to work less productively, resulting in subpar-quality
products.

4. Limited infrastructure/ resources

The lack of resources or IT infrastructure to carry out projects successfully is another issue that most
software development companies deal with and is among the major problems of software engineering.
It could be caused by a lack of high-performance programming tools, strong computing platforms,
ineffective data storage structures, or bad networks and connections. These obstacles lower software
engineers' productivity and effectiveness, which affects the end result.

5. Understanding the large and complex system requirements is difficult

We are all aware that engineers do not communicate with clients directly because clients are contacted
through the project manager or bidder procedure. As a result, engineers face challenges when dealing
with customers who have personal ideas about the software they want to use because they rarely have
direct contact with them. It is one of the key challenges in software engineering.
We all know that practically every development project requires pre-production and testing; therefore,
the same problem arises when someone works on an unproven project. When working on a
complicated project, managing your time and focusing on each component might be challenging.

6. Undefined system boundaries

There might not be a clear set of prerequisites for implementation. The customer might add additional
unrelated and irrelevant functionalities on top of the crucial ones, which would result in a very high
implementation cost that might go beyond the predetermined budget.

7. Customers are not clear about their needs

The lengthy list of features that clients frequently want in software may not always be clear to them. It
may occur when they have a basic understanding of their requirements but haven't made many
preparations for the execution phase.

8. Conflicting requirements

Two different project stakeholders can make expectations that are incompatible with one another's
execution. A single customer may occasionally articulate two requirements that are incompatible.

9. Partitioning the system suitably to reduce complexity

Occasionally, the projects can be divided into smaller modules or functionalities, which are then
handled by other teams. Larger, more complicated projects frequently call for additional segmentation,
and the partitions must be kept separate from one another and without any overlap.

10. Validating and tracing requirements

Project requirements that are constantly changing make it harder for software engineers to work.
Before beginning the implementation phase, it is crucial to double-check the list of requirements.
Additionally, both forward and backward tracing should be possible.

11. Identifying critical requirements

It's crucial to identify the needs that must be fulfilled at all costs. Prioritizing the requirements will
allow for the most urgent ones to be implemented first.

12. Resolving the "to be determined" requirements

Developers make sincere assumptions in the absence of specified specifications. They frequently
avoid asking the product owners or customers their questions. Using what they know, they carry out
the assignment. Later, they must recode the requirements using the information from the flaws.

13. Proper documentation, proper meetings time, and budget constraints

Confirm your grasp of the requirement by creating a clear requirement document. The aims, scope,
limitations, and functional requirements of a product or software program are made clear to teams and
individual stakeholders through documentation.

These are some of the major software engineer challenges, and approaches to deal with these have
been discussed further. Check out the Best Full-Stack Developer Course online to gain knowledge in
various aspects of full-stack development and be ready for a career in the field.

Solutions to Overcome Challenges in Software Engineering

You may simplify your life as a software engineer with the aid of these basic fixes. Let's check some
of the software engineering solutions for the problems discussed. Make sure you and your team use
these solutions throughout all of the project's phases:

1. Maintaining accurate records

As you work on your project, don't forget to address any unforeseen maintenance needs.

Engineers in charge of maintaining a product have access to software documentation such as software
design, source code, and development methodology.

2. Attempting to understand from the viewpoint of stakeholders

When stakeholders are concerned about the problems and understand that their ideas, opinions, and
contributions are respected, software engineering projects are successful. There is evidence to suggest
that the way in which the project manager incorporates stakeholders in the decision-making process
across the various stages of the project is closely related to the effective execution of software
engineering projects.

3. Establishing proper communication with stakeholders

When stakeholders are concerned about the problems and understand that their ideas, opinions, and
contributions are respected, software engineering projects are successful. There is evidence to suggest
that the way in which the project manager incorporates stakeholders in the decision-making process
across the various stages of the project is closely related to the effective execution of software
engineering projects.

4. Recognizing conflicting requirements from the stakeholder side

It is important to correctly examine and prioritize requirements. Keeping a healthy balance between
the requirements and only accepting those that are valid and for which good solutions can be offered
within the constraints of the project timeline and budget will help to avoid conflicts.

5. Creating informative and well-structured conversations with end consumers

Poor conversations are a major issue for novice engineers. Imagine becoming stuck when coding and
being unable to communicate the problem to your team, which could have an impact on project cost,
time, and productivity. Before a project starts, specify the methods and frequency of conversation.

6. Performing proper market research and competitors' analysis

A target audience has been identified, comprising the people who are or will use your product or
service and their demands. This is one of the key outcomes of the market analysis. A single app cannot
serve the needs of all users. If you attempt, you probably won't have any audience at all. Every
product is designed for a certain audience, and yours should be as well.

Rates and reviews will provide you with a general overview of existing solutions, a clear grasp of the
market you want to target, and assistance in identifying market trends and client demands.
 1.4 Software Process (Processes)

Software process in software engineering refers to a structured set of activities, tasks, and steps that are
followed to design, develop, test, deploy, and maintain software products. These processes are essential
for managing the complexity of software development, ensuring quality, and delivering software on time
and within budget. There are several software development methodologies and processes, and the choice
of which to use depends on the specific project's requirements and constraints. Below are the details of
key software development processes and methodologies:

Waterfall Model:
The Waterfall Model is a linear and sequential approach to software development.
It consists of distinct phases, such as requirements analysis, design, implementation, testing, deployment,
and maintenance.Progression from one phase to the next is typically one-way, and each phase must be
completed before moving on to the next. Well-suited for projects with well-defined and stable
requirements.

Agile Methodology:
Agile is an iterative and incremental approach to software development.
It emphasizes collaboration, customer feedback, and flexibility. Common Agile methodologies include
Scrum, Kanban, and Extreme Programming (XP).Agile teams work in short iterations (usually 2-4 weeks)
called sprints and deliver working increments of software at the end of each sprint.

Scrum:
Scrum is a specific Agile framework that divides work into time-boxed iterations called sprints.
It includes roles like Product Owner, Scrum Master, and Development Team. Daily stand-up meetings,
sprint planning, sprint reviews, and sprint retrospectives are integral parts of Scrum.

Kanban:
Kanban is another Agile framework that visualizes work items on a Kanban board .Work is pulled from a
backlog and moved through various stages of the workflow. It provides a more continuous flow of work
compared to Scrum's time-boxed sprints.

Extreme Programming (XP):

XP is an Agile methodology that emphasizes engineering practices like pair programming, test-driven
development (TDD), and continuous integration.It focuses on rapid iterations, customer feedback, and
small, frequent releases.

DevOps:
DevOps is a set of practices that combines development and IT operations to shorten the software
development lifecycle. It aims to automate and streamline the deployment and maintenance processes,
leading to more frequent and reliable software releases.

Lean Software Development:

Lean principles are borrowed from manufacturing and focus on eliminating waste, improving efficiency,
and delivering value to customers. It emphasizes concepts like minimizing work in progress and
delivering features just-in-time.

Spiral Model:
The Spiral Model is a risk-driven approach that combines elements of both the Waterfall and iterative
development. It involves multiple cycles (spirals), where each cycle includes planning, risk analysis,
engineering, and evaluation phases.

Incremental and Iterative Development:

These approaches involve building and delivering a software product in small, incremental steps.
Each iteration adds new functionality or refines existing features based on feedback.

V-Model (Verification and Validation Model):

This model is an extension of the Waterfall Model and emphasizes the relationship between each
development phase and its corresponding testing phase.
It ensures that each development phase is followed by a testing phase to validate the work done.
Selecting the right software development process depends on the project's goals, requirements, team, and
constraints. Many organizations also adapt and customize these processes to fit their specific needs,
leading to hybrid or tailored approaches. The software development process should evolve and improve
over time to adapt to changing project dynamics and technologies.
1.5 Software Development Processes (Projects)
Software Development Processes (Projects):
Software development processes are applied when creating a new software application or system. These
processes are focused on designing, coding, testing, and delivering the initial software product. Here are
the key phases and activities involved:
a. Requirements Gathering and Analysis:
 Identify and document the software requirements by understanding user needs and
expectations.
  Create a requirements specification document that serves as the foundation for
development.
b. System Design:
 Develop a high-level architectural design of the software system, outlining its
components, modules, and their interactions.
 Create detailed designs for each module, including data structures, algorithms, and
interfaces.
c. Implementation (Coding):
 Write the actual source code based on the design specifications.
 Developers collaborate to build the software components and ensure code quality.
d. Testing and Quality Assurance:
 Conduct various testing phases, such as unit testing, integration testing, and system
testing, to detect and fix defects.
 Ensure that the software meets functional and non-functional requirements, including
performance, security, and usability.
e. Deployment:
 Deploy the software to a production environment, making it available to end-users.
 Plan and execute data migration, if applicable.
f. Maintenance and Support:
 Address post-deployment issues and provide ongoing support to resolve user-reported
problems and make necessary updates.
 Monitor and improve software performance, security, and reliability.
2. Software Maintenance Processes (Products):
Once software is deployed and in active use, it enters a maintenance phase. This phase involves
sustaining and enhancing the software product over its lifecycle. The software maintenance process can
be categorized into four types:
a. Corrective Maintenance:
 This involves fixing defects, bugs, and issues reported by users.
 The goal is to ensure the software continues to operate correctly and reliably.
b. Adaptive Maintenance:
 Adaptive maintenance focuses on adapting the software to changes in the environment,
such as operating system updates or hardware changes.
 It may also include making the software compatible with new regulatory requirements.
c. Perfective Maintenance:
 Perfective maintenance involves making enhancements to the software to improve its
functionality or performance.
 These enhancements can include adding new features or optimizing existing ones.
d. Preventive Maintenance:
 Preventive maintenance aims to proactively identify and address potential issues or
vulnerabilities before they become critical problems.
 This helps in minimizing downtime and reducing the risk of software failures.
 1.6 Software Process (Components)

Software processes consist of various components and activities that work together to manage and guide
the development and maintenance of software products. These components ensure that the software is
created efficiently, meets quality standards, and aligns with project objectives. Here are the key
components of a software process:
1. Process Framework:
 The process framework provides the overarching structure and guidelines for how
software development and maintenance activities should be organized and executed. It
defines the stages, phases, and workflows of the process.
2. Roles and Responsibilities:
 Clear roles and responsibilities are assigned to individuals or teams involved in the
software development process. Common roles include project manager, software
developer, tester, business analyst, and quality assurance engineer.
3. Artifacts and Deliverables:
 Artifacts are documents, diagrams, or models that capture information about the software,
its design, requirements, and other aspects. Examples include software requirements
specifications, design documents, and test plans.
 Deliverables are tangible outputs produced during the development process, such as code
modules, executable software, and user manuals.
4. Activities and Tasks:
 Activities represent high-level processes or phases within the software development
lifecycle (e.g., requirements analysis, design, coding, testing).
 Tasks are specific, granular actions performed within each activity (e.g., writing code,
running tests, documenting features).
5. Methods and Techniques:
 Methods are systematic approaches and methodologies used to carry out specific
activities and tasks. For example, the software design method may involve object-
oriented modeling.
 Techniques are practical tools or practices employed within methods. For instance,
version control is a technique used in software configuration management.
6. Standards and Guidelines:
 Software processes often rely on industry standards and guidelines to ensure quality,
consistency, and compatibility. These can include coding standards, software architecture
patterns, and regulatory compliance standards (e.g., ISO 9001, HIPAA).
7. Quality Assurance and Testing:
 Quality assurance activities are integrated into the software process to monitor and
improve product quality throughout development.
  Testing involves various techniques, such as unit testing, integration testing, and user
acceptance testing, to identify and fix defects.
8. Configuration Management:
 Configuration management involves managing and controlling changes to software and
its associated artifacts. It includes version control, release management, and change
tracking.
9. Project Management:
 Effective project management components include project planning, scheduling, resource
allocation, risk management, and progress monitoring. Project managers ensure that the
software development process stays on track.
10. Feedback and Continuous Improvement:
 Continuous improvement is a fundamental aspect of software processes. Feedback
mechanisms, such as reviews, inspections, and retrospectives, help identify areas for
improvement and guide process enhancements.
11. Documentation:
 Comprehensive documentation is maintained throughout the software development
process to capture requirements, designs, decisions, and testing results. It serves as a
reference and ensures knowledge transfer.
12. Tools and Technology:
 Software development and maintenance often rely on various tools and technologies,
such as integrated development environments (IDEs), issue tracking systems, and
automated testing frameworks.
13. Change Management:
 Change management processes are in place to handle changes to project scope,
requirements, or priorities. These processes help minimize scope creep and ensure that
changes are properly evaluated and incorporated.
14. Training and Skill Development:
 To ensure that team members are proficient in the chosen technologies and
methodologies, training and skill development plans are essential components of the
software process.
15. Security and Compliance:
 Security measures and compliance requirements, depending on the application domain
(e.g., healthcare, finance), are integrated into the software process to protect sensitive
data and ensure legal and regulatory compliance.
16. Risk Management:
 Risk management involves identifying, assessing, and mitigating risks that can impact the
project's success, including schedule delays, budget overruns, and technical challenges.

2. Software Development Process Models

 2.1 Waterfall Model

The classical waterfall model is the basic software development life cycle model. It is very
simple but idealistic. Earlier this model was very popular but nowadays it is not used. But it is
very important because all the other software development life cycle models are based on the
classical waterfall model.

Features of the Waterfall Model

Sequential Approach: The waterfall model involves a sequential approach to software

development, where each phase of the project is completed before moving on to the next one.

Document-Driven: The waterfall model relies heavily on documentation to ensure that the
project is well-defined and the project team is working towards a clear set of goals.

Quality Control: The waterfall model places a high emphasis on quality control and testing at
each phase of the project, to ensure that the final product meets the requirements and
expectations of the stakeholders.

Rigorous Planning: The waterfall model involves a rigorous planning process, where the
project scope, timelines, and deliverables are carefully defined and monitored throughout the
project lifecycle.

Phases of Classical Waterfall Model

1. Requirements Gathering and Analysis: The first phase involves gathering

requirements from stakeholders and analyzing them to understand the scope and
objectives of the project.
2. Design: Once the requirements are understood, the design phase begins. This
involves creating a detailed design document that outlines the software architecture,
user interface, and system components.
3. Implementation: The implementation phase involves coding the software based on
the design specifications. This phase also includes unit testing to ensure that each
component of the software is working as expected.
4. Testing: In the testing phase, the software is tested as a whole to ensure that it
meets the requirements and is free from defects.
5. Deployment: Once the software has been tested and approved, it is deployed to the
production environment.
6. Maintenance: The final phase of the Waterfall Model is maintenance, which
involves fixing any issues that arise after the software has been deployed and
ensuring that it continues to meet the requirements over time.
 Waterfall Model

Let us now learn about each of these phases in detail.

1. Feasibility Study
The main goal of this phase is to determine whether it would be financially and technically
feasible to develop the software.
The feasibility study involves understanding the problem and then determining the various
possible strategies to solve the problem. These different identified solutions are analyzed based
on their benefits and drawbacks, The best solution is chosen and all the other phases are carried
out as per this solution strategy.
2. Requirements Analysis and Specification
The aim of the requirement analysis and specification phase is to understand the exact
requirements of the customer and document them properly. This phase consists of two different
activities.
 Requirement gathering and analysis: Firstly all the requirements regarding the
software are gathered from the customer and then the gathered requirements are
analyzed. The goal of the analysis part is to remove incompleteness (an incomplete
requirement is one in which some parts of the actual requirements have been
omitted) and inconsistencies (an inconsistent requirement is one in which some part
of the requirement contradicts some other part).
 Requirement specification: These analyzed requirements are documented in a
software requirement specification (SRS) document. SRS document serves as a
 contract between the development team and customers. Any future dispute between
the customers and the developers can be settled by examining the SRS document.
3. Design
The goal of this phase is to convert the requirements acquired in the SRS into a format that can
be coded in a programming language. It includes high-level and detailed design as well as the
overall software architecture. A Software Design Document is used to document all of this
effort (SDD)
4. Coding and Unit Testing
In the coding phase software design is translated into source code using any suitable
programming language. Thus each designed module is coded. The aim of the unit testing phase
is to check whether each module is working properly or not.
5. Integration and System testing
Integration of different modules is undertaken soon after they have been coded and unit tested.
Integration of various modules is carried out incrementally over a number of steps. During
each integration step, previously planned modules are added to the partially integrated system
and the resultant system is tested. Finally, after all the modules have been successfully
integrated and tested, the full working system is obtained and system testing is carried out on
this.
System testing consists of three different kinds of testing activities as described below.
 Alpha testing: Alpha testing is the system testing performed by the development
team.
 Beta testing: Beta testing is the system testing performed by a friendly set of
customers.
 Acceptance testing: After the software has been delivered, the customer performed
acceptance testing to determine whether to accept the delivered software or reject it.
6. Maintenance
Maintenance is the most important phase of a software life cycle. The effort spent on
maintenance is 60% of the total effort spent to develop a full software. There are basically
three types of maintenance.
 Corrective Maintenance: This type of maintenance is carried out to correct errors
that were not discovered during the product development phase.
 Perfective Maintenance: This type of maintenance is carried out to enhance the
functionalities of the system based on the customer’s request.
 Adaptive Maintenance: Adaptive maintenance is usually required for porting the
software to work in a new environment such as working on a new computer
platform or with a new operating system.
Advantages of the Classical Waterfall Model
The classical waterfall model is an idealistic model for software development. It is very
simple, so it can be considered the basis for other software development life cycle models.
Below are some of the major advantages of this SDLC model.
 Easy to Understand: Classical Waterfall Model is very simple and easy to
understand.
 Individual Processing: Phases in the Classical Waterfall model are processed one
at a time.
  Properly Defined: In the classical waterfall model, each stage in the model is
clearly defined.
 Clear Milestones: Classical Waterfall model has very clear and well-understood
milestones.
 Properly Documented: Processes, actions, and results are very well documented.
 Reinforces Good Habits: Classical Waterfall Model reinforces good habits like
define-before-design and design-before-code.
 Working: Classical Waterfall Model works well for smaller projects and projects
where requirements are well understood.
Disadvantages of the Classical Waterfall Model
The Classical Waterfall Model suffers from various shortcomings, basically, we can’t use it in
real projects, but we use other software development lifecycle models which are based on the
classical waterfall model. Below are some major drawbacks of this model.
 No Feedback Path: In the classical waterfall model evolution of software from one
phase to another phase is like a waterfall. It assumes that no error is ever committed
by developers during any phase. Therefore, it does not incorporate any mechanism
for error correction.
 Difficult to accommodate Change Requests: This model assumes that all the
customer requirements can be completely and correctly defined at the beginning of
the project, but actually customer’s requirements keep on changing with time. It is
difficult to accommodate any change requests after the requirements specification
phase is complete.
 No Overlapping of Phases: This model recommends that a new phase can start
only after the completion of the previous phase. But in real projects, this can’t be
maintained. To increase efficiency and reduce cost, phases may overlap.
 Limited Flexibility: The Waterfall Model is a rigid and linear approach to software
development, which means that it is not well-suited for projects with changing or
uncertain requirements. Once a phase has been completed, it is difficult to make
changes or go back to a previous phase.
 Limited Stakeholder Involvement: The Waterfall Model is a structured and
sequential approach, which means that stakeholders are typically involved in the
early phases of the project (requirements gathering and analysis) but may not be
involved in the later phases (implementation, testing, and deployment).
 Late Defect Detection: In the Waterfall Model, testing is typically done toward the
end of the development process. This means that defects may not be discovered
until late in the development process, which can be expensive and time-consuming
to fix.
 Lengthy Development Cycle: The Waterfall Model can result in a lengthy
development cycle, as each phase must be completed before moving on to the next.
This can result in delays and increased costs if requirements change or new issues
arise.
 Not Suitable for Complex Projects: The Waterfall Model is not well-suited for
complex projects, as the linear and sequential nature of the model can make it
difficult to manage multiple dependencies and interrelated components.
 2.2 Prototyping Model

The most significant disadvantage of previous models (waterfall and spiral) is

that there were lots of customer rejection that happens after the application
was developed, and there was no involvement of the customers in between
the project.

Hence, they started the new approach, which is known as the prototype
model. In this, we will collect the requirements from the customer and
prepare a prototype (sample), and get it reviewed and approved by the
customer. And only when they satisfied, we will start working on the original
projects so that there won't be any customer rejection.

The prototype is just the sample or a dummy of the required software

product. If all the mentioned modules are present, then only the developer
and tester will perform prototype testing.

Prototyping Model has different phases, which are as follows:

o Requirement analysis
o feasibility study
o Create a prototype
o Prototype testing
o Customer review and approval
o Design
o Coding
o Testing
o Installation and maintenance
Step-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.
Step-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.
Step-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.
Step-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.
Step-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.
Step-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 Software Prototyping :

 Users help to shape the future. As a result, errors can be discovered during the first
stage of the software development process.
  Prototyping is also considered a risk reduction function because it allows non-
existent performance to be seen, lowering the risk of failure.
 Assists team members in effectively communicating.
 Customer satisfaction exists, and he can feel the product from the start.
 There will be no risk of software loss.
 Quick user feedback aids in the development of better software solutions.
Disadvantages of Software Prototyping :
 Prototyping is a time-consuming and labor-intensive process.
 The cost of creating a specific type of waste is completely wasted because the
prototype is eventually discarded.
 Prototyping may result in an overabundance of change requests.
 Customers may be unwilling to commit to the iteration cycle for an extended period
of time.
 During each customer test, there may be too many variations in software
requirements.
 Poor documentation as a result of changing customer needs.

2.2 Spiral Model

The Spiral Model is one of the most important Software Development Life Cycle models,
which provides support for Risk Handling. In its diagrammatic representation, it 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.

The exact number of phases needed to develop the product can be varied by the project
manager depending upon the project risks. As the project manager dynamically determines the
number of phases, the project manager has an important role to develop a product using the
spiral model.

The Spiral Model is a Software Development Life Cycle (SDLC) model that provides a
systematic and iterative approach to software development. It is based on the idea of a spiral,
with each iteration of the spiral representing a complete software development cycle, from
requirements gathering and analysis to design, implementation, testing, and maintenance.
  Objectives determination and identify alternative solutions: Requirements are
gathered from the customers and the objectives are identified, elaborated, and
analysed at the start of every phase. Then alternative solutions possible for the
phase are proposed in this quadrant.
 Identify and resolve Risks: During the second quadrant, all the possible solutions
are evaluated to select the best possible solution. Then the risks associated with that
solution are identified and the risks are resolved using the best possible strategy. At
the end of this quadrant, the Prototype is built for the best possible solution.
 Develop the next version of the Product: During the third quadrant, the identified
features are developed and verified through testing. At the end of the third quadrant,
the next version of the software is available.
 Review and plan for the next Phase: In the fourth quadrant, the Customers
evaluate the so-far developed version of the software. In the end, planning for the
next phase is started.
Advantages of the Spiral Model
 Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development model to
follow due to the risk analysis and risk handling at every phase.
 Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.
 Flexibility in Requirements: Change requests in the Requirements at a later phase
can be incorporated accurately by using this model.
  Customer Satisfaction: Customers can see the development of the product at the
early phase of the software development and thus, they habituated with the system
by using it before completion of the total product.
 Iterative and Incremental Approach: The Spiral Model provides an iterative and
incremental approach to software development, allowing for flexibility and
adaptability in response to changing requirements or unexpected events.
 Emphasis on Risk Management: The Spiral Model places a strong emphasis on
risk management, which helps to minimize the impact of uncertainty and risk on the
software development process.
 Improved Communication: The Spiral Model provides for regular evaluations and
reviews, which can improve communication between the customer and the
development team.
 Improved Quality: The Spiral Model allows for multiple iterations of the software
development process, which can result in improved software quality and reliability.
Disadvantages of the Spiral Model
 Complex: The Spiral Model is much more complex than other SDLC models.
 Expensive: Spiral Model is not suitable for small projects as it is expensive.
 Too much dependability on Risk Analysis: The successful completion of the
project is very much dependent on Risk Analysis. Without very highly experienced
experts, it is going to be a failure to develop a project using this model.
 Difficulty in time management: As the number of phases is unknown at the start
of the project, time estimation is very difficult.
 Complexity: The Spiral Model can be complex, as it involves multiple iterations of
the software development process.
 Time-Consuming: The Spiral Model can be time-consuming, as it requires
multiple evaluations and reviews.
 Resource Intensive: The Spiral Model can be resource-intensive, as it requires a
significant investment in planning, risk analysis, and evaluations.

2.3 Iterative Enhancement Model

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

The Iterative Model allows the accessing earlier phases, in which the variations made
respectively. The final output of the project renewed at the end of the Software Development
Life Cycle (SDLC) process.
The various phases of Iterative model are as follows:
1. Requirement gathering & analysis: In this phase, requirements are gathered from
customers and check by an analyst whether requirements will fulfil or not. Analyst checks that
need will achieve within budget or not. After all of this, the software team skips to the next
phase.

2. Design: In the design phase, team design the software by the different diagrams like Data
Flow diagram, activity diagram, class diagram, state transition diagram, etc.

3. Implementation: In the implementation, requirements are written in the coding language and
transformed into computer programmes which are called Software.

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

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

6. Review: In this phase, after the product deployment, review phase is performed to check the
behaviour and validity of the developed product. And if there are any error found then the
process starts again from the requirement gathering.
7. Maintenance: In the maintenance phase, after deployment of the software in the working
environment there may be some bugs, some errors or new updates are required. Maintenance
involves debugging and new addition options.

Advantage(Pros) of Iterative Model:

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

Disadvantage(Cons) of Iterative Model:

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

2.4 Iterative Waterfall Model

In a practical software development project, the classical waterfall model is hard to use. So, the
Iterative waterfall model can be thought of as incorporating the necessary changes to the
classical waterfall model to make it usable in practical software development projects. It is
almost the same as the classical waterfall model except some changes are made to increase the
efficiency of the software development.
The iterative waterfall model provides feedback paths from every phase to its preceding
phases, which is the main difference from the classical waterfall model.
Feedback paths introduced by the iterative waterfall model are shown in the figure below.
 Re
quirements gathering: This is the first stage where the business owners and developers meet
to discuss the goals and requirements of the website.
Design: In this stage, the developers create a preliminary design of the website based on the
requirements gathered in stage 1.
Implementation: In this stage, the developers begin to build the website based on the design
created in stage 2.
Testing: Once the website has been built, it is tested to ensure that it meets the requirements
and functions properly.
Deployment: The website is then deployed and made live to the public.
Review and improvement: After the website has been live for a while, the business owners
and developers review its performance and make any necessary improvements.
This process is repeated until the website meets the needs and goals of the business. Each
iteration builds upon the previous one, allowing for continuous improvement and iteration until
the final product is complete.
Phase Containment of Errors: The principle of detecting errors as close to their points of
commitment as possible is known as Phase containment of errors.
Collaboration: Throughout each stage of the process, there is collaboration between the
business owners and developers. This ensures that the website meets the needs of the business
and that any issues or concerns are addressed in a timely manner.
Flexibility: The iterative waterfall model allows for flexibility in the development process. If
changes or new requirements arise, they can be incorporated into the next iteration of the
website.
Testing and feedback: The testing stage of the process is important for identifying any issues
or bugs that need to be addressed before the website is deployed. Additionally, feedback from
users or customers can be gathered and used to improve the website in subsequent iterations.
Scalability: The iterative waterfall model is scalable, meaning it can be used for projects of
various sizes and complexities. For example, a larger business may require more iterations or
more complex requirements, but the same process can still be followed.
Maintenance: Once the website is live, ongoing maintenance is necessary to ensure it
continues to meet the needs of the business and its users. The iterative waterfall model can be
used for maintenance and improvement cycles, allowing the website to evolve and stay up-to-
date.

Advantages of Iterative Waterfall Model :

 Feedback Path –
In the classical waterfall model, there are no feedback paths, so there is no
mechanism for error correction. But in the iterative waterfall model feedback path
from one phase to its preceding phase allows correcting the errors that are
committed and these changes are reflected in the later phases.
 Simple –
Iterative waterfall model is very simple to understand and use. That’s why it is one
of the most widely used software development models.
 Cost-Effective –
It is highly cost-effective to change the plan or requirements in the model.
Moreover, it is best suited for agile organizations.
 Well-organized –
In this model, less time is consumed on documenting and the team can spend more
time on development and designing.
 Risk Reduction: The iterative approach allows for early identification and
mitigation of risks, reducing the likelihood of costly errors later in the development
process.
 Quality Assurance: The iterative approach promotes quality assurance by
providing opportunities for testing and feedback throughout the development
process. This results in a higher-quality end product.
 Improved Customer Satisfaction: The iterative approach allows for customer
involvement and feedback throughout the development process, resulting in a final
product that better meets the needs and expectations of the customer.
 Predictable Outcomes: The phased approach of the iterative waterfall model
allows for more predictable outcomes and greater control over the development
process, ensuring that the project stays on track and within budget.
 Faster Time to Market: The iterative approach allows for faster time to market as
small and incremental improvements are made over time, rather than waiting for a
complete product to be developed.
 Easy to Manage: The iterative waterfall model is easy to manage as each phase is
well-defined and has a clear set of deliverables. This makes it easier to track
progress, identify issues, and manage resources.

Drawbacks of Iterative Waterfall Model :

 Difficult to incorporate change requests –

The major drawback of the iterative waterfall model is that all the requirements
 must be clearly stated before starting the development phase. Customers may
change requirements after some time but the iterative waterfall model does not
leave any scope to incorporate change requests that are made after the development
phase starts.

 Incremental delivery not supported –

In the iterative waterfall model, the full software is completely developed and tested
before delivery to the customer. There is no scope for any intermediate delivery. So,
customers have to wait a long for getting the software.

 Overlapping of phases not supported –

Iterative waterfall model assumes that one phase can start after completion of the
previous phase, But in real projects, phases may overlap to reduce the effort and
time needed to complete the project.

 Risk handling not supported –

Projects may suffer from various types of risks. But, the Iterative waterfall model
has no mechanism for risk handling.

 Limited customer interactions –

Customer interaction occurs at the start of the project at the time of requirement
gathering and at project completion at the time of software delivery. These fewer
interactions with the customers may lead to many problems as the finally developed
software may differ from the customers’ actual requirements.

2.5 Agile Model

The meaning of Agile is swift or versatile ."Agile process model" refers to a software
development approach based on iterative development. Agile methods break tasks into smaller
iterations, or parts do not directly involve long term planning. The project scope and
requirements are laid down at the beginning of the development process. Plans regarding the
number of iterations, the duration and the scope of each iteration are clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process model, which typically
lasts from one to four weeks. The division of the entire project into smaller parts helps to
minimize the project risk and to reduce the overall project delivery time requirements. Each
iteration involves a team working through a full software development life cycle including
planning, requirements analysis, design, coding, and testing before a working product is
demonstrated to the client.

Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

1. Requirements gathering: In this phase, you must define the requirements. You should
explain business opportunities and plan the time and effort needed to build the project. Based on
this information, you can evaluate technical and economic feasibility.
2. Design the requirements: When you have identified the project, work with stakeholders to
define requirements. You can use the user flow diagram or the high-level UML diagram to show
the work of new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins. Designers
and developers start working on their project, which aims to deploy a working product. The
product will undergo various stages of improvement, so it includes simple, minimal
functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's performance and
looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.

Advantage(Pros) of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.

Disadvantages(Cons) of Agile Model:

1. Due to the shortage of formal documents, it creates confusion and crucial decisions taken
throughout various phases can be misinterpreted at any time by different team members.
2. Due to the lack of proper documentation, once the project completes and the developers
allotted to another project, maintenance of the finished project can become a difficulty.

2.6 V Model

V-Model also referred to as the Verification and Validation Model. In this, each phase of SDLC
must complete before the next phase starts. It follows a sequential design process same as the
waterfall model. Testing of the device is planned in parallel with a corresponding stage of
development.
Verification: It involves a static analysis method (review) done without executing code. It is the
process of evaluation of the product development process to find whether specified requirements
meet.

Validation: It involves dynamic analysis method (functional, non-functional), testing is done by

executing code. Validation is the process to classify the software after the completion of the
development process to determine whether the software meets the customer expectations and
requirements.

So V-Model contains Verification phases on one side of the Validation phases on the other side.
Verification and Validation process is joined by coding phase in V-shape. Thus it is known as V-
Model.

There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where product requirements
understood from the customer's side. This phase contains detailed communication to
understand customer's expectations and exact requirements.
2. System Design: In this stage system engineers analyze and interpret the business of the
proposed system by studying the user requirements document.
 3. Architecture Design: The baseline in selecting the architecture is that it should
understand all which typically consists of the list of modules, brief functionality of each
module, their interface relationships, dependencies, database tables, architecture
diagrams, technology detail, etc. The integration testing model is carried out in a
particular phase.
4. Module Design: In the module design phase, the system breaks down into small
modules. The detailed design of the modules is specified, which is known as Low-Level
Design
5. Coding Phase: After designing, the coding phase is started. Based on the requirements, a
suitable programming language is decided. There are some guidelines and standards for
coding. Before checking in the repository, the final build is optimized for better
performance, and the code goes through many code reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module
design phase. These UTPs are executed to eliminate errors at code level or unit level. A
unit is the smallest entity which can independently exist, e.g., a program module. Unit
testing verifies that the smallest entity can function correctly when isolated from the rest
of the codes/ units.
2. Integration Testing: Integration Test Plans are developed during the Architectural
Design Phase. These tests verify that groups created and tested independently can coexist
and communicate among themselves.
3. System Testing: System Tests Plans are developed during System Design Phase. Unlike
Unit and Integration Test Plans, System Tests Plans are composed by the client? business
team. System Test ensures that expectations from an application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business requirement analysis
part. It includes testing the software product in user atmosphere. Acceptance tests reveal
the compatibility problems with the different systems, which is available within the user
atmosphere. It conjointly discovers the non-functional problems like load and
performance defects within the real user atmosphere.

Advantage (Pros) of V-Model:

1. Easy to Understand.
 2. Testing Methods like planning, test designing happens well before coding.
3. This saves a lot of time. Hence a higher chance of success over the waterfall model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily understood.

Disadvantage (Cons) of V-Model:

1. Very rigid and least flexible.

2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no early prototypes of the
software are produced.
4. If any changes happen in the midway, then the test documents along with the required
documents, has to be updated.

2.7 RAD(Rapid Application Development) Model

The Rapid Application Development Model was first proposed by IBM in the 1980s. The RAD
model is a type of incremental process model in which there is extremely short development
cycle. When the requirements are fully understood and the component-based construction
approach is adopted then the RAD model is used. Various phases in RAD are Requirements
Gathering, Analysis and Planning, Design, Build or Construction, and finally Deployment.

The critical feature of this model is the use of powerful development tools and techniques. A
software project can be implemented using this model if the project can be broken down into
small modules wherein each module can be assigned independently to separate teams. These
modules can finally be combined to form the final product. Development of each module
involves the various basic steps as in the waterfall model i.e. analysing, designing, coding, and
then testing, etc. as shown in the figure. Another striking feature of this model is a short time
span i.e. the time frame for delivery(time-box) is generally 60-90 days.
1. Requirements Planning – It involves the use of various techniques used in requirements
elicitation like brainstorming, task analysis, form analysis, user scenarios, FAST
(Facilitated Application Development Technique), etc. It also consists of the entire
structured plan describing the critical data, methods to obtain it, and then processing it to
form a final refined model.
2. User Description – This phase consists of taking user feedback and building the
prototype using developer tools. In other words, it includes re-examination and validation
of the data collected in the first phase. The dataset attributes are also identified and
elucidated in this phase.
3. Construction – In this phase, refinement of the prototype and delivery takes place. It
includes the actual use of powerful automated tools to transform processes and data
models into the final working product. All the required modifications and enhancements
are too done in this phase.
4. Cutover – All the interfaces between the independent modules developed by separate
teams have to be tested properly. The use of powerfully automated tools and subparts
makes testing easier. This is followed by acceptance testing by the user.
Advantages:
 The use of reusable components helps to reduce the cycle time of the project.
 Feedback from the customer is available at the initial stages.
 Reduced costs as fewer developers are required.
 The use of powerful development tools results in better quality products in comparatively
shorter time spans.
 The progress and development of the project can be measured through the various stages.
 It is easier to accommodate changing requirements due to the short iteration time spans.
 Productivity may be quickly boosted with a lower number of employees.

Disadvantages:
 The use of powerful and efficient tools requires highly skilled professionals.
 The absence of reusable components can lead to the failure of the project.
 The team leader must work closely with the developers and customers to close the project
on time.
 The systems which cannot be modularized suitably cannot use this model.
 Customer involvement is required throughout the life cycle.
 It is not meant for small-scale projects as in such cases, the cost of using automated tools
and techniques may exceed the entire budget of the project.
 Not every application can be used with RAD.

3. Software Requirement Analysis & Specification

3.1 Need , Characteristics Of Requirement 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.
(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

(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.

3.2 Components of Requirement Analysis

Requirements Elicitation:
It is related to the various ways used to gain knowledge about the project domain and
requirements. The various sources of domain knowledge include customers, business manuals,
the existing software of same type, standards and other stakeholders of the project. The
techniques used for requirements elicitation include interviews, brainstorming, task analysis,
Delphi technique, prototyping, etc. Some of these are discussed here. Elicitation does not
produce formal models of the requirements understood. Instead, it widens the domain knowledge
of the analyst and thus helps in providing input to the next stage.

 Interviews: These are one-on-one conversations with stakeholders to gather

information about their needs and expectations.
 Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.
  Focus Groups: These are small groups of stakeholders who are brought together to
discuss their needs and expectations for the software system.
 Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
 Prototyping: This technique involves creating a working model of the software
system, which can be used to gather feedback from stakeholders and to validate
requirements.
Requirements specification:
This activity is used to produce formal software requirement models. All the requirements
including the functional as well as the non-functional requirements and the constraints are
specified by these models in totality. During specification, more knowledge about the problem
may be required which can again trigger the elicitation process. The models used at this stage
include ER diagrams, data flow diagrams(DFDs), function decomposition diagrams(FDDs),
data dictionaries, etc.
 Functional Requirements: These describe what the software system should do.
They specify the functionality that the system must provide, such as input
validation, data storage, and user interface.
 Non-Functional Requirements: These describe how well the software system
should do it. They specify the quality attributes of the system, such as performance,
reliability, usability, and security.
 Constraints: These describe any limitations or restrictions that must be considered
when developing the software system.
 Acceptance Criteria: These describe the conditions that must be met for the
software system to be considered complete and ready for release.

Requirements management:
Requirement management is the process of analysing, documenting, tracking, prioritizing and
agreeing on the requirement and controlling the communication to relevant stakeholders. This
stage takes care of the changing nature of requirements. It should be ensured that the SRS is as
modifiable as possible so as to incorporate changes in requirements specified by the end users
at later stages too. Being able to modify the software as per requirements in a systematic and
controlled manner is an extremely important part of the requirements engineering process.
 Tracking and controlling changes: This involves monitoring and controlling
changes to the requirements throughout the development process, including
identifying the source of the change, assessing the impact of the change, and
approving or rejecting the change.
 Version control: This involves keeping track of different versions of the
requirements document and other related artifacts.
 Traceability: This involves linking the requirements to other elements of the
development process, such as design, testing, and validation.
 Communication: This involves ensuring that the requirements are communicated
effectively to all stakeholders and that any changes or issues are addressed in a
timely manner.
 Monitoring and reporting: This involves monitoring the progress of the
development process and reporting on the status of the requirements.
 3.3 Data Flow Diagram

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system requirement
graphically. It can be manual, automated, or a combination of both.
It shows how data enters and leaves the system, what changes the information, and where data is
stored.
The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be
used as a communication tool between a system analyst and any person who plays a part in the
order that acts as a starting point for redesigning a system. The DFD is also called as a data flow
graph or bubble chart.

Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.

Data Flow: A curved line shows the flow of data into or out of a process or data store.
Data Store: A set of parallel lines shows a place for the collection of data items. A data store
indicates that the data is stored which can be used at a later stage or by the other processes in a
different order. The data store can have an element or group of elements.

Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or sink
of system outputs.

Levels in Data Flow Diagrams (DFD)

The DFD may be used to perform a system or software at any level of abstraction. Infact, DFDs
may be partitioned into levels that represent increasing information flow and functional detail.
Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see primarily three levels in the
data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level DFD.

0-level DFDM

It is also known as fundamental system model, or context diagram represents the entire software
requirement as a single bubble with input and output data denoted by incoming and outgoing
arrows. Then the system is decomposed and described as a DFD with multiple bubbles. Parts of
the system represented by each of these bubbles are then decomposed and documented as more
and more detailed DFDs. This process may be repeated at as many levels as necessary until the
program at hand is well understood. It is essential to preserve the number of inputs and outputs
between levels, this concept is called leveling by DeMacro. Thus, if bubble "A" has two inputs
x1 and x2 and one output y, then the expanded DFD, that represents "A" should have exactly two
external inputs and one external output as shown in fig:

The Level-0 DFD, also called context diagram of the result management system is shown in fig.
As the bubbles are decomposed into less and less abstract bubbles, the corresponding data flow
may also be needed to be decomposed.
1-level DFD

In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this level,
we highlight the main objectives of the system and breakdown the high-level process of 0-level
DFD into subprocesses.
2-Level DFD

2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project or
record the specific/necessary detail about the system's functioning.

AD
 3.4 Use Case Model

Before we start working on any project, it is very important that we are very clear on what we
want to do and how do we want to do. In my last Blog, I discussed on how to write a good SRS
for your project and what is the advantage we get out of that. In this Blog, I’ll discuss Use
Cases and their advantage in our projects.