Software Characteristics – Software Engineering


Software is defined as a collection of computer programs, procedures, rules, and data.
Software Characteristics are classified into six major components. Software
engineering is the process of designing, developing, testing, and maintaining software.
Table of Content
 Components of Software Characteristics
 Characteristics of “Software” in Software Engineering
 Characteristics of the Software
 Questions For Practice
 FAQs on Software Characteristic
Components of Software Characteristics
There are 6 components of Software Characteristics are discussed here. We will
discuss each one of them in detail.
 Software Characteristics

Functionality:
It refers to the degree of performance of the software against its intended purpose.
Functionality refers to the set of features and capabilities that a software
program or system provides to its users. It is one of the most important
characteristics of software, as it determines the usefulness of the software for
the intended purpose. Examples of functionality in software include:
 Data storage and retrieval
 Data processing and manipulation
 User interface and navigation
 Communication and networking
 Security and access control
 Reporting and visualization
 Automation and scripting
The more functionality a software has, the more powerful and versatile it is,
but also the more complex it can be. It is important to balance the need for
functionality with the need for ease of use, maintainability, and scalability.
Required functions are:
Reliability:
A set of attributes that bears on the capability of software to maintain its level
of performance under the given condition for a stated period of time.
Reliability is a characteristic of software that refers to its ability to perform its
intended functions correctly and consistently over time. Reliability is an
important aspect of software quality, as it helps ensure that the software will
work correctly and not fail unexpectedly.
Examples of factors that can affect the reliability of software include:
1. Bugs and errors in the code
2. Lack of testing and validation
3. Poorly designed algorithms and data structures
4. Inadequate error handling and recovery
5. Incompatibilities with other software or hardware
6. To improve the reliability of software, various techniques, and
methodologies can be used, such as testing and validation, formal
verification, and fault tolerance.
7. Software is considered reliable when the probability of it failing is low
and it is able to recover from the failure quickly, if any.
Required functions are:
Efficiency:
It refers to the ability of the software to use system resources in the most
effective and efficient manner. The software should make effective use of
storage space and executive command as per desired timing requirements.
Efficiency is a characteristic of software that refers to its ability to use
resources such as memory, processing power, and network bandwidth in an
optimal way. High efficiency means that a software program can perform its
intended functions quickly and with minimal use of resources, while low
efficiency means that a software program may be slow or consume excessive
resources.
Examples of factors that can affect the efficiency of the software include:
1. Poorly designed algorithms and data structures
2. Inefficient use of memory and processing power
3. High network latency or bandwidth usage
4. Unnecessary processing or computation
5. Unoptimized code
To improve the efficiency of software, various techniques, and methodologies
can be used, such as performance analysis, optimization, and profiling.
Efficiency is important in software systems that are resource-constrained,
high-performance, and real-time systems. It is also important in systems that
need to handle many users or transactions simultaneously.
Required functions are:
 Efficiency

Usability:
It refers to the extent to which the software can be used with ease. the amount
of effort or time required to learn how to use the software.
Required functions are:

Usability
Maintainability:
It refers to the ease with which modifications can be made in a software system
to extend its functionality, improve its performance, or correct errors.
Required functions are:

Maintainability
Characteristics of “Software” in Software Engineering
1. Software is developed or engineered; it is not manufactured in the classical sense:
 Although some similarities exist between software development and
hardware manufacturing, few activities are fundamentally different.
 In both activities, high quality is achieved through good design, but the
manufacturing phase for hardware can introduce quality problems than
software.
2. The software doesn’t “wear out.”:
 Hardware components suffer from the growing effects of many other
environmental factors. Stated simply, the hardware begins to wear out.
 Software is not susceptible to the environmental maladies that cause
hardware to wear out.
 When a hardware component wears out, it is replaced by a spare part.
 There are no software spare parts.
 Every software failure indicates an error in design or in the process
through which the design was translated into machine-executable
code. Therefore, the software maintenance tasks that accommodate
requests for change involve considerably more complexity than
hardware maintenance. However, the implication is clear—the
software doesn’t wear out. But it does deteriorate.
3. The software continues to be custom-built:
 A software part should be planned and carried out with the goal that it
tends to be reused in various projects.
 Current reusable segments encapsulate the two pieces of information
and the preparation that is applied to the information, empowering the
programmer to make new applications from reusable parts.
 In the hardware world, component reuse is a natural part of the
engineering process.
Characteristics of the Software
 It is intangible, meaning it cannot be seen or touched.
 It is non-perishable, meaning it does not degrade over time.
 It is easy to replicate, meaning it can be copied and distributed easily.
 It can be complex, meaning it can have many interrelated parts and
features.
 It can be difficult to understand and modify, especially for large and
complex systems.
 It can be affected by changing requirements, meaning it may need to be
updated or modified as the needs of users change.
 It can be impacted by bugs and other issues, meaning it may need to be
tested and debugged to ensure it works as intended.
Layered Technology in Software Engineering

Software engineering is a fully layered technology, to develop software we

need to go from one layer to another. All the layers are connected and each
layer demands the fulfillment of the previous layer
Layered technology is divided into four parts:
1. A quality focus: It defines the continuous process improvement principles
of software. It provides integrity that means providing security to the software
so that data can be accessed by only an authorized person, no outsider can
access the data. It also focuses on maintainability and usability.
2. Process: It is the foundation or base layer of software engineering. It is key
that binds all the layers together which enables the development of software
before the deadline or on time. Process defines a framework that must be
established for the effective delivery of software engineering technology. The
software process covers all the activities, actions, and tasks required to be
carried out for software development.

Process activities are listed below:-

 Communication: It is the first and foremost thing for the development of
software. Communication is necessary to know the actual demand of the
client.
 Planning: It basically means drawing a map for reduced the complication
of development.
 Modeling: In this process, a model is created according to the client for
better understanding.
 Construction: It includes the coding and testing of the problem.
 Deployment:- It includes the delivery of software to the client for
evaluation and feedback.

3. Method: During the process of software development the answers to all

“how-to-do” questions are given by method. It has the information of all the
tasks which includes communication, requirement analysis, design modeling,
program construction, testing, and support.
4. Tools: Software engineering tools provide a self-operating system for
processes and methods. Tools are integrated which means information
created by one tool can be used by another.
 Software Process Framework – Software
Engineering

A Software Process Framework is a structured approach that defines the steps,
tasks, and activities involved in software development. This framework serves as
a foundation for software engineering, guiding the development team through
various stages to ensure a systematic and efficient process. A Software Process
Framework helps in project planning, risk management, and quality assurance by
detailing the chronological order of actions.
Table of Content
 What is a Software Process Framework?
 What Is a Software Development Framework?
 Advantages of Software Development Framework
 Dis-advantages of Software Development Framework
 How to Choose a Suitable Development Framework
 Software Process Framework Activities
 Popular Software Development Frameworks
 Umbrella Activities
 Conclusion
 Frequently Asked Questions Related on Software Process Framework
It includes task sets, umbrella activities, and process framework activities, all essential
for a successful software development lifecycle. Utilizing a well-defined Software
Process Framework enhances productivity, consistency, and the overall quality of the
software product
What is a Software Process Framework?
Software Process Framework details the steps and chronological order of a process.
Since it serves as a foundation for them, it is utilized in most applications. Task sets,
umbrella activities, and process framework activities all define the characteristics of
the software development process. Software Process includes:
1. Tasks: They focus on a small, specific objective.
2. Action: It is a set of tasks that produce a major work product.
3. Activities: Activities are groups of related tasks and actions for a major objective.
 Software Process Framework

What Is a Software Development Framework?

A software development framework is a structured set of tools, libraries, best
practices, and guidelines that help developers build software applications. Think of it
as a template or foundation that provides the basic structure and components needed
for a software project.
Key Points
1. Foundation: It gives a basic structure or template for developing software, so
developers don’t have to start from scratch.
2. Components and Tools: It includes pre-built components and tools that make
development faster and easier.
3. Best Practices and Guidelines: It offers best practices and guidelines to ensure
the software is built in an organized and efficient way.
4. Customization: Developers can modify and add new functions to customize the
framework to their specific needs.
Advantages of Software Development Framework
A Software Development Framework offers numerous benefits that streamline
the software development process and enhance the quality and efficiency of the final
product. Here are some key advantages:
1. Increased Productivity: Frameworks provide pre-built components and tools,
allowing developers to focus on specific application logic rather than reinventing
the wheel.
2. Consistent Quality: By following best practices and standardized processes,
frameworks help ensure consistent code quality and structure across the project.
3. Reduced Development Time: With ready-to-use templates and libraries,
developers can significantly cut down on the time needed to build applications
from scratch.
4. Better Maintainability: A structured framework makes the codebase more
organized and easier to understand, which simplifies maintenance and updates.
5. Enhanced Security: Frameworks often include built-in security features and
follow industry best practices, reducing the risk of vulnerabilities.
6. Scalability: Frameworks are designed to handle growth, making it easier to scale
applications as user demand increases.
Dis-advantages of Software Development Framework
While Software Development Frameworks offer several advantages, they also come
with certain drawbacks that developers and organizations should consider:
1. Learning Curve: Frameworks often have a steep learning curve, requiring
developers to invest time and effort in understanding the framework’s architecture,
conventions, and best practices.
2. Restrictions: Some frameworks impose constraints and limitations on how
developers can design and implement certain features, potentially limiting
flexibility and creativity.
3. Complexity Overhead: In some cases, frameworks introduce unnecessary
complexity, especially for smaller or simpler projects, which can lead to over-
engineering.
4. Performance Overhead: Using a framework may introduce additional layers of
abstraction and overhead, which can impact the performance of the application,
particularly in resource-intensive environments.
5. Vendor Lock-in: Depending heavily on a specific framework can lead to vendor
lock-in, making it challenging to switch to alternative technologies or frameworks
in the future.
How to Choose a Suitable Development Framework
Choosing a suitable development framework is crucial for the success of a software
project. Here are key steps to help you make an informed decision. Here is a simple
and effective strategy to help you select the most suitable framework for your project
1. Consider the Framework’s Language
 Popular Languages: Start with frameworks in popular programming languages
like Java, Python, or Ruby if you have no preference. These languages often have
robust frameworks with strong community support.
2. Open-Source vs. Paid Frameworks
 Open-Source: Generally have a large user base, frequent updates, and community
contributions.
 Paid: Often more reliable with better support but may lack customization and
timely updates.
3. Community and Support
 Community Size: A large, active community means better support, more tutorials,
and a more mature framework. Look for frameworks with extensive community
resources and engagement.
4. Review Case Studies and Example Applications
 Practical Insights: Check the framework’s website or repositories for case studies
or example applications. These can provide insights into development processes
and methods that work well with the framework.
5. Test the Framework Yourself
 Hands-On Experience: Try out the framework in your own project to see how it
fits your needs. Testing helps you understand the framework’s functionality and
whether it suits your development scenario.
Software Process Framework Activities
The Software process framework is required for representing common process
activities. Five framework activities are described in a process framework for software
engineering. Communication, planning, modeling, construction, and deployment are all
examples of framework activities. Each engineering action defined by a framework
activity comprises a list of needed work outputs, project milestones, and software
quality assurance (SQA) points. Let’s explain each:

Software Process Framework Activities

1. Communication
Definition: Communication involves gathering requirements from customers and
stakeholders to determine the system’s objectives and the software’s requirements.
Activities:
 Requirement Gathering: Engaging with consumers and stakeholders through
meetings, interviews, and surveys to understand their needs and expectations.
 Objective Setting: Clearly defining what the system should achieve based on the
gathered requirements.
Explanation: Effective communication is essential to understand what the users need
from the software. This phase ensures that all stakeholders are on the same page
regarding the goals and requirements of the system.
2. Planning
Definition: Planning involves establishing an engineering work plan, describing
technical risks, listing resource requirements, and defining a work schedule.
Activities:
 Work Plan: Creating a detailed plan that outlines the tasks and activities needed to
develop the software.
 Risk Assessment: Identifying potential technical risks and planning how to
mitigate them.
 Resource Allocation: Determining the resources (time, personnel, tools) required
for the project.
 Schedule Definition: Setting a timeline for completing different phases of the
project.
Explanation: Planning helps in organizing the project and setting clear expectations.
It ensures that the development team has a roadmap to follow and that potential
challenges are anticipated and managed.
3. Modeling
Definition: Modeling involves creating architectural models and designs to better
understand the problem and work towards the best solution.
Activities:
 Analysis of Requirements: Breaking down the gathered requirements to
understand what the system needs to do.
 Design: Creating architectural and detailed designs that outline how the software
will be structured and how it will function.
Explanation: Modeling translates requirements into a visual and structured
representation of the system. It helps in identifying the best design approach and
serves as a blueprint for development.
4. Construction
Definition: Construction involves creating code, testing the system, fixing bugs, and
confirming that all criteria are met.
Activities:
 Code Generation: Writing the actual code based on the design models.
 Testing: Running tests to ensure the software works as intended, identifying and
fixing bugs.
Explanation: This phase is where the actual software is built. Testing is crucial to
ensure that the code is error-free and that the software meets all specified
requirements.
5. Deployment
Definition: Deployment involves presenting the completed or partially completed
product to customers for evaluation and feedback, then making necessary
modifications based on their input.
Activities:
 Product Release: Delivering the software to users, either as a full release or in
stages.
 Feedback Collection: Gathering feedback from users about their experience with
the software.
 Product Improvement: Making changes and improvements based on user
feedback to enhance the product.
Popular Software Development Frameworks
 Angular
 React
 Vue.js
 Django
 Flask
 Ruby on Rails
 Spring
 Express
 Laravel
 ASP.NET Core
Umbrella Activities
Umbrella Activities that take place during a software development process for improved
project management and tracking.
1. Software project tracking and control: This is an activity in which the team can
assess progress and take corrective action to maintain the schedule. Take action to
keep the project on time by comparing the project’s progress against the plan.
2. Risk management: The risks that may affect project outcomes or quality can be
analyzed. Analyze potential risks that may have an impact on the software
product’s quality and outcome.
3. Software quality assurance: These are activities required to maintain software
quality. Perform actions to ensure the product’s quality.
4. Formal technical reviews: It is required to assess engineering work products to
uncover and remove errors before they propagate to the next activity. At each level
of the process, errors are evaluated and fixed.
5. Software configuration management: Managing of configuration process when
any change in the software occurs.
6. Work product preparation and production: The activities to create models,
documents, logs, forms, and lists are carried out.
7. Reusability management: It defines criteria for work product reuse. Reusable
work items should be backed up, and reusable software components should be
achieved.
8. Measurement: In this activity, the process can be defined and collected. Also,
project and product measures are used to assist the software team in delivering the
required software.
Conclusion
The Software Process Framework outlines a structured approach to software
development, detailing key activities like communication, planning, modeling,
construction, and deployment. It ensures systematic progress from gathering
requirements to delivering the final product. Supporting activities like quality
assurance and risk management enhance project efficiency and product quality. This
framework helps teams build reliable, high-quality software efficiently.
PROCESS MODEL:
PROCESS FLOW:
Components of Software
There are three main components of the software:
1. Program: A computer program is a list of instructions that tell a computer
what to do.
2. Documentation: Source information about the product contained in
design documents, detailed code comments, etc.
3. Operating Procedures: Set of step-by-step instructions compiled by an
organization to help workers carry out complex routine operations.
Other Software Components
Other Software Components are:
1. Code: the instructions that a computer executes in order to perform a
specific task or set of tasks.
2. Data: the information that the software uses or manipulates.
3. User interface: the means by which the user interacts with the software,
such as buttons, menus, and text fields.
4. Libraries: pre-written code that can be reused by the software to perform
common tasks.
5. Documentation: information that explains how to use and maintain the
software, such as user manuals and technical guides.
6. Test cases: a set of inputs, execution conditions, and expected outputs
that are used to test the software for correctness and reliability.
7. Configuration files: files that contain settings and parameters that are
used to configure the software to run in a specific environment.
8. Build and deployment scripts: scripts or tools that are used to build,
package, and deploy the software to different environments.
9. Metadata: information about the software, such as version numbers,
authors, and copyright information.

Key Process Activities

There four basic key process activities are:
1. Software Specifications: In this process, detailed description of a
software system to be developed with its functional and non-functional
requirements.
2. Software Development: In this process, designing, programming,
documenting, testing, and bug fixing is done.
3. Software Validation: In this process, evaluation software product is done
to ensure that the software meets the business requirements as well as
the end users needs.
4. Software Evolution: It is a process of developing software initially, then
timely updating it for various reasons.
1. Requirements analysis and specification phase: The aim of this phase is to
understand the exact requirements of the customer and to document them
properly. Both the customer and the software developer work together so as to
document all the functions, performance, and interfacing requirement of the
software. It describes the "what" of the system to be produced and not "how."In
this phase, a large document called Software Requirement Specification
(SRS) document is created which contained a detailed description of what the
system will do in the common language.
 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.

here 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?s 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.

when to use V-Model?

o When the requirement is well defined and not ambiguous.

o The V-shaped model should be used for small to medium-sized projects where
requirements are clearly defined and fixed.
o The V-shaped model should be chosen when sample technical resources are available with
essential technical expertise.

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.

Incremental Model is a process of software development where requirements divided into

multiple standalone modules of the software development cycle. In this model, each module
goes through the requirements, design, implementation and testing phases. Every subsequent
release of the module adds function to the previous release. The process continues until the
complete system achieved.

when we use the Incremental Model?

o When the requirements are superior.
o A project has a lengthy development schedule.
o When Software team are not very well skilled or trained.
o When the customer demands a quick release of the product.
 o You can develop prioritized requirements first.

Advantage of Incremental Model

o Errors are easy to be recognized.
o Easier to test and debug
o More flexible.
o Simple to manage risk because it handled during its iteration.
o The Client gets important functionality early.

Disadvantage of Incremental Model

o Need for good planning
o Total Cost is high.
o Well defined module interfaces are needed.

advantage of Prototype Model

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

Disadvantage of Prototype Model

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

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

Evolutionary Process Model

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

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

Benefits of Evolutionary Process Model

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

EVO can reduce costs by providing a structured, disciplined avenue for experimentation.

EVO allows the marketing department access to early deliveries, facilitating the
development of documentation and demonstration.

Better fit the product to user needs and market requirements.

Manage project risk with the definition of early cycle content.

Uncover key issues early and focus attention appropriately.

Increase the opportunity to hit market windows.

Accelerate sales cycles with early customer exposure.

Increase management visibility of project progress.

Increase product team productivity and motivations.

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

The Spiral Model is shown in fig:

Each cycle in the spiral is divided into four parts:

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

Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is
located on the risk perception for the project.
Development and validation: The next phase is to develop strategies that resolve
uncertainties and risks. This process may include activities such as benchmarking,
simulation, and prototyping.

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

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

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

When to use Spiral Model?

ADVERTISEMENT

ADVERTISEMENT

o When deliverance is required to be frequent.

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

Advantages

o High amount of risk analysis

o Useful for large and mission-critical projects.

Disadvantages

o Can be a costly model to use.

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

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

Each cycle in the spiral is divided into four parts:

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

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

Development and validation: The next phase is to develop strategies that resolve
uncertainties and risks. This process may include activities such as benchmarking,
simulation, and prototyping.
Planning: Finally, the next step is planned. The project is reviewed, and a choice made
whether to continue with a further period of the spiral. If it is determined to keep, plans
are drawn up for the next step of the project.

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

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

When to use Spiral Model?

o When deliverance is required to be frequent.

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

Advantages

o High amount of risk analysis

o Useful for large and mission-critical projects.

Disadvantages

o Can be a costly model to use.

o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.
https://www.scribd.com/document/603639071/1-3-Perspective-and-Specialized-Process

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.

Agile Testing Methods:

ADVERTISEMENT

o Scrum
o Crystal
o Dynamic Software Development Method(DSDM)
o Feature Driven Development(FDD)
o Lean Software Development
o eXtreme Programming(XP)

Scrum
SCRUM is an agile development process focused primarily on ways to manage tasks in
team-based development conditions.

There are three roles in it, and their responsibilities are:

o Scrum Master: The scrum can set up the master team, arrange the meeting and remove
obstacles for the process
 o Product owner: The product owner makes the product backlog, prioritizes the delay and
is responsible for the distribution of functionality on each repetition.
o Scrum Team: The team manages its work and organizes the work to complete the sprint
or cycle.

eXtreme Programming(XP)
This type of methodology is used when customers are constantly changing demands or
requirements, or when they are not sure about the system's performance.

Crystal:
There are three concepts of this method-

1. Chartering: Multi activities are involved in this phase such as making a development team,
performing feasibility analysis, developing plans, etc.
2. Cyclic delivery: under this, two more cycles consist, these are:
A. Team updates the release plan.
B. Integrated product delivers to the users.
3. Wrap up: According to the user environment, this phase performs deployment, post-
deployment.

Dynamic Software Development Method(DSDM):

DSDM is a rapid application development strategy for software development and gives
an agile project distribution structure. The essential features of DSDM are that users must
be actively connected, and teams have been given the right to make decisions. The
techniques used in DSDM are:

1. Time Boxing
2. MoSCoW Rules
3. Prototyping

The DSDM project contains seven stages:

1. Pre-project
2. Feasibility Study
 3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
6. Implementation
7. Post-project

Feature Driven Development(FDD):

This method focuses on "Designing and Building" features. In contrast to other smart
methods, FDD describes the small steps of the work that should be obtained separately
per function.

Lean Software Development:

Lean software development methodology follows the principle "just in time production."
The lean method indicates the increasing speed of software development and reducing
costs. Lean development can be summarized in seven phases.

1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole

When to use the Agile Model?

o When frequent changes are required.
o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
o When project size is small.

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.
objectives of CMMI :
1. Fulfilling customer needs and expectations.
2. Value creation for investors/stockholders.
3. Market growth is increased.
4. Improved quality of products and services.
5. Enhanced reputation in Industry.

SOFTWARE PROCESS IMPROVEMENT:

Software Process Improvement is the application of a systematic approach
to the identification, evaluation, and improvement of software processes which
is critical for computational science and engineering projects. The overall
goals of software process improvement in scientific computing are to enhance
the quality, efficiency, reliability, and sustainability of software development in
scientific research.

The goal of Software Process Improvement is a systematic methodology to

improve the quality, efficiency, and effectiveness of software development and
 maintenance. Improvement efforts can implemented in a variety of ways, but it
typically involve the following steps:

1. Identify the need for improvement: This can be done by conducting a

process assessment, which involves gathering data on the current state of the
software development process.
2. Establish goals and objectives: These goals should be specific,
measurable, achievable, relevant, and time-boxed.
3. Develop a plan: This plan should include a timeline, resources, and
responsibilities.
4. Implement the plan: This involves implementing the changes (often couched
as experiments) that have been identified and putting the collection of metrics
in place to see if they are effective.
5. Monitor and evaluate the improvement effort: This involves collecting
metrics data on the effectiveness of the changes (i.e. the experiments) that
have been implemented and making adjustments as needed based on
feedback.
There are various ways to implement improvement efforts, but they generally
involve the following steps:

 Improve the quality of software products

 Reduce development costs
 Increase productivity
 Improve customer satisfaction
 Enhance organizational reputation
 Increase market share

There exists a range of software process improvement techniques in scientific

computing that can be applied in a lightweight manner for small and large
teams with the objective of improving the quality, efficiency, reliability, and
sustainability of software development in scientific research.

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

maintaining requirements in the engineering design process. Requirement engineering provides
the appropriate mechanism to understand what the customer desires, analyzing the need, and
assessing feasibility, negotiating a reasonable solution, specifying the solution clearly, validating
the specifications and managing the requirements as they are transformed into a working
system.

Requirement Engineering Process

It is a four-step process, which includes -

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

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

Types of Feasibility:

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

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

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are identified
with the help of customers and existing systems processes, if available.

Analysis of requirements starts with requirement elicitation. The requirements are

analyzed to identify inconsistencies, defects, omission, etc. We describe requirements in
terms of relationships and also resolve conflicts if any.

Problems of Elicitation and Analysis

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

o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.
3. Software Requirement Specification:
Software requirement specification is a kind of document which is created by a software
analyst after the requirements collected from the various sources - the requirement
received by the customer written in ordinary language. It is the job of the analyst to write
the requirement in technical language so that they can be understood and beneficial by
the development team.

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

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

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document
are validated. The user might demand illegal, impossible solution or experts may
misinterpret the needs. Requirements can be the check against the following conditions
-

o If they can practically implement

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

Requirements Validation Techniques

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

o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured
requirements descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements during the
requirements engineering process and system development.

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

The priority of requirements from different viewpoints changes during development

process.

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

Prerequisite of Software requirements

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

A complete Software Requirement Specifications should be:

o Clear
o Correct
o Consistent
o Coherent
o Comprehensible
o Modifiable
o Verifiable
 o Prioritized
o Unambiguous
o Traceable
o Credible source

Software Requirements: Largely software requirements must be categorized into two

categories:

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

system element must be qualified to perform and must be documented in different forms.
The functional requirements are describing the behavior of the system as it correlates to
the system's functionality.
2. Non-functional Requirements: This can be the necessities that specify the criteria that
can be used to decide the operation instead of specific behaviors of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable at run time.
o Evolution qualities like testability, maintainability, extensibility, and scalability that
embodied in the static structure of the software system.
 Requirements Elicitation – Software
Engineering

Requirements elicitation is the process of gathering and defining the requirements for
a software system.
What is Requirement Elicitation?
The process of investigating and learning about a system’s requirements from users,
clients, and other stakeholders is known as requirements elicitation. Requirements
elicitation in software engineering is perhaps the most difficult, most error-prone, and
most communication-intensive software development.
1. Requirement Elicitation can be successful only through an effective customer-
developer partnership. It is needed to know what the users require.
2. Requirements elicitation involves the identification, collection, analysis, and
refinement of the requirements for a software system.
3. Requirement Elicitation is a critical part of the software development life cycle and
is typically performed at the beginning of the project.
4. Requirements elicitation involves stakeholders from different areas of the
organization, including business owners, end-users, and technical experts.
5. The output of the requirements elicitation process is a set of clear, concise, and
well-defined requirements that serve as the basis for the design and development
of the software system.
6. Requirements elicitation is difficult because just questioning users and customers
about system needs may not collect all relevant requirements, particularly for
safety and dependability.
7. Interviews, surveys, user observation, workshops, brainstorming, use cases, role-
playing, and prototyping are all methods for eliciting requirements.
Importance of Requirements Elicitation
1. Compliance with Business Objectives: The process of elicitation guarantees that
the software development endeavors are in harmony with the wider company aims
and objectives. Comprehending the business context facilitates the development of
a solution that adds value for the company.
2. User Satisfaction: It is easier to create software that fulfills end users’ needs and
expectations when they are involved in the requirements elicitation process.
Higher user pleasure and acceptance of the finished product are the results of this.
3. Time and Money Savings: Having precise and well-defined specifications aids in
preventing miscommunication and rework during the development phase. As a
result, there will be cost savings and the project will be completed on time.
4. Compliance and Regulation Requirements: Requirements elicitation is crucial
for projects in regulated industries to guarantee that the software conforms with
 applicable laws and norms. In industries like healthcare, finance, and aerospace,
this is crucial.
5. Traceability and Documentation: Throughout the software development process,
traceability is based on well-documented requirements. Traceability helps with
testing, validation, and maintenance by ensuring that every part of the software can
be linked to a particular requirement.
Requirements Elicitation Activities
Requirements elicitation includes the subsequent activities. A few of them are listed
below:
1. Knowledge of the overall area where the systems are applied.
2. The details of the precise customer problem where the system is going to be
applied must be understood.
3. Interaction of system with external requirements.
4. Detailed investigation of user needs.
5. Define the constraints for system development.
Requirements Elicitation Methods
There are several requirement elicitation methods. A few of them are listed below:
1. Interviews
The objective of conducting an interview is to understand the customer’s expectations
of the software.
It is impossible to interview every stakeholder hence representatives from groups
are selected based on their expertise and credibility. Interviews may be open-ended
or structured.
1. In open-ended interviews, there is no pre-set agenda. Context-free questions
may be asked to understand the problem.
2. In a structured interview, an agenda of fairly open questions is prepared.
Sometimes a proper questionnaire is designed for the interview.
2. Brainstorming Sessions
 Brainstorming Sessions is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share
views
 A highly trained facilitator is required to handle group bias and conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements and their
priority if possible.
3. Facilitated Application Specification Technique
Its objective is to bridge the expectation gap – the difference between what the
developers think they are supposed to build and what customers think they are going
to get. A team-oriented approach is developed for requirements gathering. Each
attendee is asked to make a list of objects that are:
1. Part of the environment that surrounds the system.
2. Produced by the system.
3. Used by the system.
Each participant prepares his/her list, different lists are then combined, redundant
entries are eliminated, the team is divided into smaller sub-teams to develop mini-
specifications and finally, a draft of specifications is written down using all the inputs
from the meeting.
4. Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it emphasizes the
requirements that are valuable to the customer.
3 types of requirements are identified:
 Normal requirements: In this the objective and goals of the proposed software
are discussed with the customer. For example – normal requirements for a result
management system may be entry of marks, calculation of results, etc.
 Expected requirements: These requirements are so obvious that the customer
need not explicitly state them. Example – protection from unauthorized access.
 Exciting requirements: It includes features that are beyond customer’s
expectations and prove to be very satisfying when present. For example – when
unauthorized access is detected, it should back up and shut down all processes.
5. Use Case Approach
Use Case technique combines text and pictures to provide a better understanding of
the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a
functional view of the system.
The components of the use case design include three major things – Actor, use cases,
and use case diagram.
1. Actor: It is the external agent that lies outside the system but interacts with it in
some way. An actor may be a person, machine, etc. It is represented as a stick
figure. Actors can be primary actors or secondary actors.
 Primary actors: It requires assistance from the system to achieve a goal.
 Secondary actor: It is an actor from which the system needs assistance.
2. Use cases: They describe the sequence of interactions between actors and the
system. They capture who(actors) do what(interaction) with the system. A
complete set of use cases specifies all possible ways to use the system.
3. Use case diagram: A use case diagram graphically represents what happens when
an actor interacts with a system. It captures the functional aspect of the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users, and the customer involved.
Steps of Requirements Elicitation
Following are the Steps of Requirement Elicitation

Steps of Requirement Elicitation

1. Identify all the stakeholders, e.g., Users, developers, customers, etc.

2. List out all requirements from the customer.
3. A value indicating the degree of importance is assigned to each requirement.
4. In the end, the final list of requirements is categorized as:
 It is possible to achieve.
 It should be deferred and the reason for it.
 It is impossible to achieve and should be dropped off.

Features of Requirements Elicitation

1. Stakeholder engagement: Requirements elicitation involves engaging with
stakeholders such as customers, end-users, project sponsors, and subject-matter
experts to understand their needs and requirements.
2. Gathering information: Requirements elicitation involves gathering information
about the system to be developed, the business processes it will support, and the
end-users who will be using it.
3. Requirement prioritization: Requirements elicitation involves prioritizing
requirements based on their importance to the project’s success.
4. Requirements documentation: Requirements elicitation involves documenting
the requirements clearly and concisely so that they can be easily understood and
communicated to the development team.
5. Validation and verification: Requirements elicitation involves validating and
verifying the requirements with the stakeholders to ensure they accurately
represent their needs and requirements.
6. Iterative process: Requirements elicitation is an iterative process that involves
continuously refining and updating the requirements based on feedback from
stakeholders.
7. Communication and collaboration: Requirements elicitation involves effective
communication and collaboration with stakeholders, project team members, and
other relevant parties to ensure that the requirements are clearly understood and
implemented.
8. Flexibility: Requirements elicitation requires flexibility to adapt to changing
requirements, stakeholder needs, and project constraints.
Advantages of Requirements Elicitation
1. Clear requirements: Helps to clarify and refine customer requirements.
2. Improves communication: Improves communication and collaboration between
stakeholders.
 3. Results in good quality software: Increases the chances of developing a software
system that meets customer needs.
4. Avoids misunderstandings: Avoids misunderstandings and helps to manage
expectations.
5. Supports the identification of potential risks: Supports the identification of
potential risks and problems early in the development cycle.
6. Facilitates development of accurate plan: Facilitates the development of a
comprehensive and accurate project plan.
7. Increases user confidence: Increases user and stakeholder confidence in the
software development process.
8. Supports identification of new business opportunities: Supports the
identification of new business opportunities and revenue streams.
Disadvantages of Requirements Elicitation
1. Time-consuming: It can be time-consuming and expensive.
2. Skills required: Requires specialized skills and expertise.
3. Impacted by changing requirements: This may be impacted by changing
business needs and requirements.
4. Impacted by other factors: Can be impacted by political and organizational
factors.
5. Lack of commitment from stakeholders: This can result in a lack of buy-in and
commitment from stakeholders.
6. Impacted by conflicting priorities: Can be impacted by conflicting priorities and
competing interests.
7. Sometimes inaccurate requirements: This may result in incomplete or inaccurate
requirements if not properly managed.
8. Increased development cost: This can lead to increased development costs and
decreased efficiency if requirements are not well-defined.

Analysis principles – Analysis Modelling in

Software Engineering

Analysis Model is a technical representation of the system. It acts as a link between the
system description and the design model. In Analysis Modelling, information, behavior,
and functions of the system are defined and translated into the architecture, component,
and interface level design in the design modeling.
Objectives of Analysis Modelling
 Understanding Needs: The process of analysis modelling helps in the
understanding and extraction of user needs for the software system.
 Communication: Analysis models facilitate communication between users,
clients, developers, and testers, among other stakeholders.
 Clarifying Ambiguities: Analysis models assist in resolving requirements
disputes and providing clarification on unclear areas.
 Finding the Data Requirements: Analysis modelling assists in determining the
relationships, entities, and qualities of the data that the system needs.
 Defining Behavior: Analysis modelling aids in the definition of the system’s
dynamic behavior, including workflows, processes, and inter-component
interactions.
 System Boundary Identification: It is made easier by analysis modelling, which
helps in defining the parameters of the software system and its interactions with
users, other systems, and hardware components.
Elements of Analysis Model

Elements of Analysis Model

1. Data Dictionary:
It is a repository that consists of a description of all data objects used or produced
by the software. It stores the collection of data present in the software. It is a very
crucial element of the analysis model. It acts as a centralized repository and also
helps in modeling data objects defined during software requirements.

2. Entity Relationship Diagram (ERD):

It depicts the relationship between data objects and is used in conducting data
modeling activities. The attributes of each object in the Entity-Relationship
Diagram can be described using Data object description. It provides the basis for
activity related to data design.
3. Data Flow Diagram (DFD):
It depicts the functions that transform data flow, and it also shows how data is
transformed when moving from input to output. It provides the additional
information that is used during the analysis of the information domain and serves
as a basis for the modeling of function. It also enables the engineer to develop
models of functional and information domains at the same time.

4. State Transition Diagram:

It shows various modes of behavior (states) of the system and also shows the
transitions from one state to another state in the system. It also provides the details
of how the system behaves due to the consequences of external events. It
represents the behavior of a system by presenting its states and the events that
cause the system to change state. It also describes what actions are taken due to the
occurrence of a particular event.

5. Process Specification:
It stores the description of each function present in the data flow diagram. It
describes the input to a function, the algorithm that is applied for the
transformation of input, and the output that is produced. It also shows regulations
and barriers imposed on the performance characteristics that apply to the process
and layout constraints that could influence how the process will be implemented.

6. Control Specification:
It stores additional information about the control aspects of the software. It is used
to indicate how the software behaves when an event occurs and which processes
are invoked due to the occurrence of the event. It also provides the details of the
processes which are executed to manage events.

7. Data Object Description:

It stores and provides complete knowledge about a data object present and used in
the software. It also gives us the details of attributes of the data object present in
the Entity Relationship Diagram. Hence, it incorporates all the data objects and
their attributes.
Key Principles of Analysis Modelling
1. Abstraction: Analysis modelling involves separating important system
components from unneeded specifics. While leaving out unnecessary or low-level
information, it concentrates on capturing the essential ideas, behaviors, and
relationships relevant to the system’s requirements.
2. Modularity: Analysis models ought to be able to break down a system into
smaller, more manageable parts. It is simpler to understand, assess, and alter the
 system when each module or component reflects a different part of its
functionality.
3. Consistency: Internally and with other project artifacts, including requirements
documents, design specifications, and implementation code, analysis models
should be consistent. By preventing opposing or conflicting representations of the
system, consistency promotes greater stakeholder comprehension and alignment.
4. Traceability: Analysis models ought to be able to be linked to other project
components so that interested parties may follow requirements from their inception
to their execution. Throughout the software development lifecycle, it helps with
impact analysis, change management, and requirements coverage verification.
5. Precision: To provide an unambiguous picture of the needs and behaviors of the
system, analysis models must be accurate and exact. Accuracy lowers the chance
of miscommunication and misunderstanding among stakeholders as well as
implementation problems.
6. Separation of Concerns: Analysis modeling divides various system components
or concerns into discrete representations. For instance, behavioral modeling aims
to capture the dynamic behavior of the system, whereas data modeling
concentrates on expressing the relationships and structure of data items.