Digital Audio Forensics Using Artificial Intelligence

Software Requirements Specification

Version 1.0

Group Id: F23027F9D6 (BC200414187)

Supervisor Name: Sonia Salman

 Revision History
Date Version Description Author
(dd/mm/yyyy)
07/12/2023 1.0 The project commenced BC200414187
with an exploration of the
interdisciplinary field of
digital audio forensics,
aiming to leverage the
synergies of audio
engineering, signal
processing, and artificial
intelligence. The initial
focus centered on
understanding the
theoretical foundations of
audio authentication and
delineating the objectives
for applying AI
methodologies to
discriminate between
authentic and modified
audio samples. During this
phase, the project team
conducted an extensive
literature review,
identifying key concepts
and existing frameworks in
the realm of digital audio
forensics.

i
 Table of Contents

1. Scope (of the project) 1

2. Functional Requirements Non Functional requirements 2

3. Use Case Diagram 4

4. Usage Scenarios 5

5. Adopted Methodology 11

6. Work Plan (Use MS Project to create Schedule/Work Plan) 18

ii
 SRS Document
Scope of Project:
Digital audio forensics, an interdisciplinary domain encompassing audio engineering,
signal processing, and artificial intelligence, focuses on the analysis and authentication of
audio recordings. This project aims to provide students with a comprehensive exploration
of digital audio forensics by incorporating advanced AI methodologies. The primary
objective is to develop and implement machine learning algorithms capable of
discriminating between authentic and modified audio samples.

Throughout the project, students will engage in practical tasks involving the manipulation
and analysis of audio data. The scope includes hands-on experience in recognizing
speech features, understanding the nuances of audio signals, and employing AI
techniques to enhance the accuracy of audio authentication. By immersing themselves in
this project, students will gain a profound understanding of the complexities involved in
verifying the authenticity of audio recordings.

Additionally, the scope extends to the exploration of various AI approaches such as deep
learning and pattern recognition to discern subtle alterations in audio files. Through this
interdisciplinary endeavor, students will not only acquire technical expertise but also
develop critical thinking skills as they navigate the intricate landscape of digital audio
forensics. The project's scope aligns with the broader goal of equipping students with
practical insights into AI applications within the context of audio analysis and forensic
investigation.

1
Functional and non-Functional Requirements:

Functional Requirements:

1. User (App User):

 Upload Audio Clips:

o Requirement: Users should be able to upload audio clips (real or
suspected fake) to the application interface.
 Initiate Detection:
o Requirement: Users can initiate the detection process for uploaded audio
clips by triggering the neural network model.
 View Results:
o Requirement: Users should receive clear and understandable results
indicating whether the audio clip is real or fake.
 Provide Feedback:
o Requirement: Users may have the option to provide feedback on the
accuracy of the detection results to improve the system's performance.

2. Admin/System (Neural Network Model):

 Receive Audio Clips:

o Requirement: The neural network model should be able to receive audio
clips uploaded by users for analysis.
 Process Audio Clips:
o Requirement: The model should process audio clips using appropriate
feature extraction methods and machine learning algorithms to
differentiate between real and fake audio.
 Generate Detection Results:
o Requirement: The model should generate accurate detection results,
indicating whether the provided audio clip is real or fake.

Non-functional requirements

o Performance: The system should process audio clips within an average

response time of 5 seconds and a maximum response time of 10 seconds
under normal operating conditions. During peak usage periods, the system
should maintain acceptable performance, with no degradation in response
times for users.
o Scalability: The system should be designed to handle a scalable user base,
accommodating at least a 50% increase in user activity within the next
year without a significant decrease in performance. The architecture
should support easy scalability by adding computational resources as the
user base grows.
o Reliability: The system should have a mean time between failures
(MTBF) of at least 30 days, ensuring high availability for users. In the

2
 event of a system failure, the recovery time objective (RTO) should be
less than 1 hour to minimize downtime.
o Security: User data, including uploaded audio clips and detection results,
should be stored securely with encryption and access controls to prevent
unauthorized access. Regular security audits and vulnerability assessments
should be conducted to identify and address potential security risks.
o Usability: The user interface should adhere to accessibility standards,
ensuring that it is usable by individuals with disabilities. User interface
elements should be responsive and optimized for various devices and
screen sizes.
o Maintainability: Code should be well-documented, and the system should
include version control to facilitate maintenance and updates. Routine
maintenance tasks, such as database backups and software updates, should
be automated to minimize downtime.
o Compatibility: The system should be compatible with major web
browsers (Chrome, Firefox, Safari, and Edge) and support the latest
versions. The application interface should be responsive and compatible
with various operating systems, including Windows, macOS, and Linux.
o Scalability: The neural network model should be designed to handle an
increasing volume of uploaded audio clips by efficiently utilizing
available computational resources. The model training process should be
scalable, allowing for the incorporation of additional training data to
improve detection accuracy over time.
o Legal and Ethical Considerations: The system should comply with
international and local laws regarding user privacy, data protection, and
the ethical use of machine learning algorithms. Ethical guidelines should
be established to mitigate biases in the detection process and ensure fair
and unbiased results.
o Training and Support: Comprehensive training materials should be
provided for system administrators and support staff to ensure effective
management and troubleshooting. A dedicated support channel should be
available for users to report issues and seek assistance, with a response
time target of 24 hours for non-critical issues.

3
Use Case Diagram(s):

Figure 1/Use Case Diagram

4
 Usage Scenarios:

1. Use Case: User Upload Real Audio Clip (UC-01)

Use Case ID UC-01
Use Case Title User Upload Real Audio Clip
Actions Upload Real Audio Clip
Description User upload the genuine audio clip for analysis.

Alternative Paths User can link the genuine audio clip.

Pre-Conditions User has the genuine audio clip.

Post-Conditions User uploaded the genuine audio clip for analysis.

Exceptions Incorrect Audio clip.

Author BC200414187

2. Use Case: User Upload Suspected Fake Audio Clip (UC-02)

Use Case ID UC-02
Use Case Title User upload suspected fake audio clip
Actions User suspect the fake audio clip and verify it.
Description User upload the suspected fake audio
clip through the application interface
Alternative Paths Trigger the neural network for detection.
Pre-Conditions Real audio clip has been uploaded
Post-Conditions Suspected fake audio clip has been uploaded.
Exceptions Incorrect Audio.
Author BC200414187

5
 3. Use Case: Initiates Detection Process (UC-03)

Use Case ID UC-03

Use Case Title Initiates Detection Process
Actions Initiate the detection process for multiple audio clips.
Description User has uploaded multiple audio clips and wants to initiate
the detection process for each of them.
Alternative Paths Use single Audio clip to initiate
Pre-Conditions Real audio clip has been uploaded
Post-Conditions Multiple audio clips should available for detection process.
Exceptions Invalid audio
Author BC200414187

4. Use Case: View Detection Results for Real Audio Clip (UC-04)

Use Case ID UC-04

Use Case Title View Detection Results for Real Audio Clip
Actions User view detection results for real audio clip
Description After initiating the detection process for a real audio clip,
the user receives clear and understandable results
indicating that the audio clip is indeed real.
Alternative Paths User can move back to the detection process
Pre-Conditions User has initiated the detection process for real audio clip.
Post-Conditions View detection process result for real audio clip.
Exceptions Invalid results
Author BC200414187

6
 5. Use Case: Detection Results for Suspected Fake Audio (UC-05)

Use Case ID UC-05

Use Case Title Views Detection Results for Suspected Fake Audio
Actions User views detection results for Suspected Fake Audio
Description After initiating the detection process for a suspected fake
audio clip, the user receives results indicating that the audio
clip is flagged as potentially fake.
Alternative Paths User can cancel or reverse the action.
Pre-Conditions User has initiated detection process for suspected fake audio.
Post-Conditions Recommendations are displayed to the user.
Exceptions Invalid results
Author BC200414187

6. Use Case: User Provides Feedback on Real Audio Detection (UC-06)

Use Case ID UC-06

Use Case Title Provides Feedback on Real Audio Detection
Actions User provide feedback on real audio detection
Description User who has received accurate results for a real audio
clip decides to provide positive feedback on the accuracy
of the detection.
Alternative Paths User can’t provide feedback.
Pre-Conditions User has received accurate results for a real audio clip.
Post-Conditions User has posted the feedback.
Exceptions Option not available.
Author BC200414187
7. Use Case: User Provides Feedback on Suspected Fake Audio
Detection (UC-07)

7
Use Case ID UC-07
Use Case Title Provides Feedback on Suspected Fake Audio Detection
Actions User provides feedback on suspected fake audio
detection
Description User who has received results for a suspected fake
audio clip decides to provide feedback regarding the
accuracy of the detection.
Alternative Paths User can’t provide feedback.
Pre-Conditions User has received results for a suspected fake audio
clip
Post-Conditions User has posted the feedback.
Exceptions Option not available.
Author BC200414187

Use Case ID UC-08

Use Case Title Admin Receives Real Audio Clip for Analysis
Actions Admin receives real audio clip for analysis
Description The neural network model administrator receives a
genuine audio clip uploaded by a user for analysis.
Alternative Paths Admin can redirect.
Pre-Conditions A genuine audio clip uploaded by a user for analysis.
Post-Conditions Administrator receives a genuine audio clip.
Exceptions Admin had not received the real audio clip.
Author BC200414187
8. Use Case: Admin Receives Real Audio Clip for Analysis (UC-08)
9. Use Case: Admin Processes Real Audio Clip (UC-09)
Use Case ID UC-09
Use Case Title Admin Processes Real Audio Clip

8
Actions Admin process the real audio clip received from user.
Description Admin processes a real audio clip using appropriate feature
extraction methods and machine learning algorithms to differentiat
between real and fake audio.
Alternative Paths Admin can cancel the action.
Pre-Conditions Admin received the real audio clip.
Post-Conditions Admin processed the real audio clip.
Author BC200414187

10.Use Case: Admin Generates Detection Results - Real Audio (UC-10)

Use Case ID UC-10
Use Case Title Admin Generates Detection Results - Real Audio
Actions Admin generates the detection results for real audio
Description After processing a real audio clip, the neural network model
admin generates accurate detection results, indicating that the
provided audio clip is real.
Alternative Paths Admin can cancel or reverse the action of generating results.
Pre-Conditions Admin processes the real audio clip.
Post-Conditions Admin generated the results for real audio clip.
Exceptions Incorrect audio clip.
Author BC200414187

9
 11.Use Case: Admin Processes Suspected Fake Audio Clip (UC-11)

Use Case ID UC-11

Use Case Title Admin Processes Suspected Fake Audio Clip
Actions Admin process the suspected fake audio clip.
Description The neural network model admin receives a suspected fake audio clip for
analysis using feature extraction methods and machine learning
algorithms.
Alternative Paths Admin can cancel/reverse the action of processing.
Pre-Conditions Admin receives the suspected fake audio clip.
Post-Conditions Admin has processed the suspected audio clip.
Exceptions Missing or incorrect suspected fake audio clip.
Author BC200414187

12.Use Case: Admin Generates Detection Results - Suspected Fake

Audio (UC-12)

Use Case ID UC-12

Use Case Title Admin Generates Detection Results - Suspected Fake Audio
Actions Admin generates the result for suspected fake audio clip.
Description Admin generates detection results. The results indicate whether
the provided audio clip is flagged as potentially fake.
Alternative Paths Admin can reverse the action.
Pre-Conditions Admin processed the suspected fake audio clip.
Post-Conditions Admin generates the results for suspected fake audio clip.
Exceptions Missing or incorrect suspected fake audio clip.
Author BC200414187

10
 Adopted Methodology

Exploring Software Development Methodologies:

In the world of software development, choosing the right methodology is
crucial to ensure project success. Different software methodologies offer
unique approaches and frameworks to guide the development process. There
are four popular software development methodologies: Waterfall, Spiral,
Agile, and Incremental models. Following are the key steps involved in each
methodology, highlighting their strengths and weaknesses.

I. Waterfall Model:
The Waterfall model is a linear and sequential approach to software
development. It follows a structured process with distinct phases, where
each phase must be completed before moving to the next. The steps involved
in the Waterfall model are as follows:

1. Requirements Gathering: Gathering and documenting detailed

requirements from stakeholders.
2. System Design: Creating a high-level design that outlines the system
architecture and components.
3. Implementation: Writing code and developing the software based on
the design specifications.
4. Testing: Conducting comprehensive testing to identify and fix defects.
5. Deployment: Releasing the software to the end-users or customers.
6. Maintenance: Providing ongoing support, bug fixes, and updates.

Figure 2. Waterfall Model

11
 Strengths of the Waterfall model include its straightforward and easy-to-
understand nature, as well as the ability to plan and estimate the project
upfront. However, its rigid structure may not accommodate changes well,
and any mistakes in earlier phases can be costly to rectify in later stages.

II. Spiral Model:

The Spiral model combines the iterative nature of prototyping with the
systematic and controlled aspects of the Waterfall model. It emphasizes risk
management and continual evaluation. The steps involved in the Spiral
model are as follows:

1. Planning: Determining objectives, constraints, and alternatives.

2. Risk Analysis: Identifying and assessing potential risks.
3. Engineering: Developing the software incrementally, starting with a
small prototype.
4. Evaluation: Reviewing the prototype and collecting feedback.
5. Iteration: Repeating the steps to refine and enhance the software in
subsequent cycles.

Figure 3. Spiral Model

The Spiral model is well-suited for projects with high risk and evolving
requirements. It allows for early identification and mitigation of risks.
However, it can be complex to manage and may require experienced
personnel.

12
III. Agile Methodology:
Agile is an iterative and collaborative approach that emphasizes
adaptability and customer satisfaction. It promotes cross-functional teams
and regular customer involvement. The steps involved in Agile methodology
(specifically Scrum, a popular Agile framework) are as follows:

1. Product Backlog Creation: Defining and prioritizing a list of features

and user stories.
2. Sprint Planning: Selecting a subset of items from the product backlog
for development in a sprint.
3. Sprint Execution: Developing and testing the selected features in short
iterations (sprints).
4. Daily Stand-up Meetings: Brief, daily meetings to discuss progress
and address any issues.
5. Sprint Review: Demonstrating the completed work to stakeholders
and gathering feedback.
6. Sprint Retrospective: Reflecting on the sprint, identifying areas of
improvement, and making adjustments for the next sprint.

Figure 4. Agile Methodology

Agile methodologies are flexible, allowing for changing requirements and

continuous improvement. They foster collaboration and customer
13
 satisfaction. However, they may require active customer involvement, and
the lack of upfront planning can lead to scope creep if not managed properly.

IV. Incremental Model:

The Incremental model breaks down the software development process
into smaller increments or iterations. Each increment builds upon the
previous one, delivering a working version of the software after each
iteration. The steps involved in the Incremental model are as follows:

1. Requirements Analysis: Gathering and analyzing the initial

requirements.
2. Design and Development: Developing the software in small
increments, focusing on high-priority features.
3. Testing and Integration: Testing each increment and integrating it into
the overall system.
4. Deployment and Feedback: Releasing each increment to the end-users
and collecting feedback.
5. Incremental Enhancement: Incorporating feedback, refining features,
and adding new functionality in subsequent increments.

Figure 5. Incremental Model

14
The Incremental model provides early delivery of usable software and
allows for flexibility in adjusting requirements. It enables continuous
feedback and improvements. However, managing dependencies between
increments can be challenging, and inadequate planning may result in
difficulties integrating the increments effectively.

Selecting the most suitable software development methodology depends on

various factors such as project complexity, requirements volatility, and
stakeholder collaboration. The Waterfall, Spiral, Agile, and Incremental
models offer distinct approaches, each with its own strengths and
weaknesses. Understanding these methodologies and their respective steps
can help software development teams make informed decisions and tailor
their approach to the unique needs of their projects. Ultimately, the choice of
methodology should align with the project's goals, team dynamics, and
customer expectations to ensure successful software development.

15
Adopted Methodology:

The VU process model is the adopted methodology for this project,

which combines elements of the Waterfall and Spiral models, offers a
structured and iterative approach to software development. In this model, the
project progresses through distinct phases following the sequential steps of
the Waterfall model, while incorporating the risk management and iterative
aspects of the Spiral model. Here is a brief explanation of how things would
work in the VU process model:

1. Requirements Gathering: The project begins with a thorough

gathering and documentation of requirements from stakeholders,
similar to the Waterfall model. This phase focuses on
understanding the project objectives, user needs, and functional
requirements.

2. System Design: Once the requirements are defined, a high-level

system design is created, outlining the system architecture and
major components. This phase also includes identifying potential
risks and devising strategies to manage them, as per the Spiral
model's risk analysis phase.

3. Iterative Development: The VU process model incorporates

iterative development cycles within each major phase. Instead of
waiting until the entire system is developed, small increments or
prototypes are created and evaluated throughout the development
process. This allows for early feedback and enables potential
adjustments and refinements based on stakeholder input.

4. Risk Assessment and Planning: In each iteration, the risks

associated with the specific increment are assessed and addressed.
The project team conducts risk analysis and takes appropriate
measures to mitigate risks. This step is similar to the Spiral model's
risk analysis phase, where risks are identified, analyzed, and
managed throughout the project.

5. Evaluation and Feedback: After completing each iteration or

increment, the system is evaluated, and feedback is collected from
stakeholders. This feedback helps identify any necessary

16
 modifications or improvements to be made in subsequent
iterations, ensuring continuous refinement and enhancement.

6. Integration and Deployment: Once all the iterations are completed,

the final product is integrated, tested thoroughly, and prepared for
deployment. The traditional Waterfall model's emphasis on testing
and deployment is followed in this phase.

7. Maintenance: After deployment, ongoing maintenance and support

are provided to address any issues, fix bugs, and incorporate
updates or enhancements as needed. This ensures that the system
remains functional and meets the evolving needs of users.

Figure 6. VU Process Model

The VU process model provides the structure and predictability of the

Waterfall model while incorporating the flexibility and risk management of
the Spiral model. It allows for iterative development, risk analysis, and early
stakeholder involvement, reducing the chances of major risks going
unnoticed and enabling timely adjustments. This combination aims to strike
a balance between planning and adaptability, ultimately leading to
successful project outcomes.

17
Work Plan (Use MS Project to create Schedule/Work Plan)

Figure 7/Gantt Chart

18