22F-3678,22F-3683,22F-3679 SRE pp2

22F-3685
22F-3720
22F-3696
PROJECT OVERVIEW:
Weather Measuring System Through Satellites
Our system is primarily based on the utilization of cosmic satellites, radar
technology, and advanced data processing to deliver a comprehensive and user-
friendly weather forecasting service.
Cosmic Satellites:
Our system relies on cosmic satellites equipped with sensors that measure a wide
range of meteorological parameters. These satellites gather data about temperature,
weather patterns, storms, and various atmospheric conditions. This data is
transmitted to Earth in binary form (0s and 1s).
Data Visualization:
Upon receiving the binary data from the cosmic satellites, we employ advanced
data processing techniques to convert this raw data into interactive maps. These
maps are designed to provide users with a visual representation of the weather
conditions. They feature different colors and patterns, allowing users to identify
storms, cloud formations, and specific cloud types in real-time. In last ,send this
data to communication satellites.
Communication Satellites:
We rely on a network of communication satellites (each communication satellite
serves a specific geographic area, so we use a lot of satellites to cover the whole
earth). The collected weather data is shared across multiple communication
satellites and from different communication satellite data transmitted to a
centralized forecasting office.
Forecasting and Prediction:

At the forecasting office, algorithms are deployed to analyze the incoming data
from various communication satellites. This process enables us to predict future
weather conditions, including storms, cloud cover, temperature changes, and more.
Data Access and Website:
The results of our weather prediction algorithms (which consist of future predicted
weather) are then uploaded to our user-friendly website. This website is designed
to cater to a global audience and offers multiple features. Users can access weather
data based on their geographical location through GPS satellites, ensuring
personalized weather information. Additionally, users have the option to select
specific regions or areas for detailed weather reports.
ELICITATION TECHNIQUE:
Document-Centric (Perspective-Based Reading and Reuse)
What is it?
This technique involves studying and learning from documents and information
related to an existing system.
Why are we using it?
To make our project easier and better.
To reuse the good ideas and methods of an already successful system (National
Weather Service).
The points defined in the project overview are used by the National Weather
Service. We read their documents and decided to reuse their ideas.
Justification of National Weather Service are using project overview points are in
their official Website and You tube channel.
How project overview mechanism work: https://youtu.be/ry34hK3R_yg?

si=UIEP7miX5GUN2cQl
Website link: https://www.weather.gov/
You tube link: https://youtube.com/@noaanationalweatherservice?si=-RO68o-b-

etNlSIn
Some other links (Project overview points or National Weather Service

Mechanism)
Storm Spotting: https://youtu.be/v7f2_YxYPL0?si=vOwDZNJqnK4D1kDI
Radar and analyze weather through map: https://youtu.be/NRFd_5Hiz6g?

si=tYlE0E72UuWw3NRJ
How satellite works: https://youtu.be/ror4P1UAv_g?si=fYqmJyZZMFxn7khB
Hurricane Preparedness: https://youtu.be/Fq_1PwKuRPg?

si=M_yRG5GBSoTmxSax
NWS (visual overview): https://youtu.be/7DgFPgJTxP8?

si=NF4NwtTl9xyuy3YS
Requirements for Weather Measuring System in Natural

Language
Requirement Requirement Descriptions
ID
Functional Requirements
FR001 The system shall provide the capability to manage personalized alerts for
specific weather conditions.
FR002 The system shall provide the User ability to select various channels for alert
delivery including email, SMS, and in-system notifications.
FR003 The system shall provide the User ability to see filtered display weather data
for specific geographical regions.
FR004 The system shall provide the User ability to select different interactive and
clear data visualization tools, i.e., maps, charts, and graphs.
FR005 The system shall provide the User ability to access historical atmospheric data
with customized options for selecting time frames.
FR006 The system shall provide the user ability to watch access historical analysis
(User Optional).
FR007 The system will be able to provide a well-documented API for seamless
integration into external applications or systems used by stakeholders,
ensuring ease of integration.
FR008 The system shall provide the user ability to access a wide range of
atmospheric data, including but not limited to temperature, humidity,
pressure, air quality (CO2, CO, PM levels), wind speed and direction,
precipitation, solar radiation, UV radiation, ozone levels, radiation levels,
lightning detection, earthquake, volcanic eruptions, pollen count, severe
weather alerts, lightning intensity, tropical storm tracking, flood monitoring,
avalanche risk assessment, wildfire risk assessment, tsunami warnings, air
quality during disasters, and nuclear fallout monitoring, smog, visibility.
FR009 The system will deliver this updated data to stakeholders.
FR010 The system will employ advanced algorithms for weather prediction based on
received data.
FR011 The system shall provide User ability to customize forecasts for specified
time intervals i.e., custom (mins, hours), weekly, monthly, annually.
FR012 The system will use an integrated system [Communication Satellite] for real-
time data networking.
FR013 The system will use an integrated system [GPS (31 satellites’)] for real-time
user navigation.
FR014 The system shall implement robust error handling mechanisms to address
anomalies or connection interruption in received data of for integrated
systems i.e., GPS (31 satellites’, Communication Satellite, COSMIC-2
Satellite.
FR015 The System will be able to make future predictions for all measurements
(Data Range)
NON – Functional Requirements

NFR001 The system will provide accurate Measurements
NFR002 The system will be able to maintain data accuracy within predefined MAE
“a” factor tolerance level.
NFR003 The system will be able to conform to accessibility standards: simplicity

(KISS P), and clarity (SR P), ensuring that it is usable by web interface
individuals with disabilities in compliance with relevant accessibility laws
i.e., section 508, ADA, WAI-ARIA.
NFR005 The system will give high performance in processing and transmitting data in
terms of page response (0.000001sec).
NFR006 At its peak usage, the system must support up to 690 million concurrent
users.
QUARS EXPRESS Comprehensive

Evaluation Report
Document Analysis and Metrics
I. Defect Identification Metrics:

Defect metrics analyze the linguistic quality of requirements, detecting various types of linguistic defects.
Optionality: Measures the presence of optional elements in requirements. This is evaluated by

identifying elements that are not mandatory for the fulfillment of the requirement but may enhance it.
Subjectivity: Evaluates the level of subjectivity in the requirements. It identifies elements that may
introduce subjectivity or personal bias into the requirement, potentially leading to ambiguity.
Vagueness: Assesses the extent of vagueness in the requirements. It detects requirements that lack
clarity or specificity, making them open to multiple interpretations.
Weakness: Detects weaknesses in the requirements, such as ambiguities, inconsistencies, or unclear

dependencies that may hinder the development process.
Implicitly: Identifies implicit elements in the requirements. Implicit elements are those that are not
explicitly stated but can be inferred from the context.
Multiplicity: Measures the presence of multiple instances of requirements. This evaluates the potential
duplication or redundancy in the requirements, which can lead to confusion.
Under specification: Identifies under-specification in the requirements, indicating areas where the
requirements are not detailed enough for proper implementation.
II. Execution Time Metrics:

Execution time metrics provide insights into the efficiency of the analysis process.
Document Count (Doc. N.): The number of documents analyzed. This metric helps track the scale of the
analysis.
Requirement Count (Req.): The total number of requirements within the documents. This metric is
crucial for understanding the workload.
Analysis Time (Time min): Time taken for the analysis of each document. This metric measures the
efficiency of the analysis process and highlights potential bottlenecks.
Speed (Req/min): The rate at which requirements are processed per minute. This metric shows the
efficiency of requirement analysis and provides an indication of the tool's performance.
III. Readability Metrics:

Readability metrics evaluate the ease of understanding and comprehending the requirements
documents.
Kincaid Index: The Kincaid readability index measures the readability of the text based on the length of
words and sentences. Lower Kincaid scores indicate easier-to-read text.
ARI (Automated Readability Index): ARI evaluates text complexity based on word length and sentence
structure. Lower ARI scores indicate more accessible text.
Coleman-Liau Index: The Coleman-Liau Index assesses text readability and comprehension based on
characters per word and words per sentence. Lower scores indicate easier-to-read text.
Flesch Index: The Flesch Index determines the ease of reading based on the number of syllables per
word and words per sentence. Higher scores indicate more readable text.
Fog Index: The Fog Index measures text complexity based on the average sentence length and the
percentage of complex words. Lower scores indicate more accessible text.
LIX (Läsbarhetsindex): LIX provides a readability index based on the number of words, sentences, and
long words. Lower scores indicate easier-to-read text.
SMOG-Grading: The SMOG-Grading index assesses the reading grade level required to understand a
text, based on the number of complex words. Lower SMOG-Grading scores indicate more readable text.
summary
This comprehensive report provides a detailed overview of the metrics used in QUARS EXPRESS for
evaluating natural l
REQUIREMENT THROUGH QuARS Analysis:

The requirements I'm going to write have gone through a detailed analysis by a
tool called QuARS. This analysis ensures that the requirements are in line with the
metrics I mentioned earlier.
Requirement Requirement Descriptions

ID
Functional Requirements
FR001 The system shall provide the capability to manage personalized alerts for
FR002 The system shall provide the User ability to select various channels for alert
delivery including email, SMS, and in-system notifications.
FR003 The system shall provide the User ability to see filtered display weather data
for specific geographical regions.
FR004 The system shall provide the User ability to select different interactive and
clear data visualization tools, i.e., maps, charts, and graphs.
FR005 The system shall provide the User ability to access historical atmospheric data
with customized options for selecting time frames.
FR006 The system shall provide the user ability to watch access historical analysis
(User Optional).
FR007 The system will be able to provide a well-documented API for seamless
integration into external applications or systems used by stakeholders,
ensuring ease of integration.
FR008 The system shall provide the user ability to access a wide range of
atmospheric data, including but not limited to temperature, humidity,
pressure, air quality (CO2, CO, PM levels), wind speed and direction,
precipitation, solar radiation, UV radiation, ozone levels, radiation levels,
lightning detection, earthquake, volcanic eruptions, pollen count, severe
weather alerts, lightning intensity, tropical storm tracking, flood monitoring,
avalanche risk assessment, wildfire risk assessment, tsunami warnings, air
quality during disasters, and nuclear fallout monitoring, smog, visibility.
FR009 The system will deliver this updated data to stakeholders.
FR010 The system will employ advanced algorithms for weather prediction based on
received data.
FR011 The system shall provide User ability to customize forecasts for specified
time intervals i.e., custom (mins, hours), weekly, monthly, annually.
FR012 The system will use an integrated system [Communication Satellite] for real-
FR013 The system will use an integrated system [GPS (31 satellites’)] for real-time
user navigation.
FR014 The system shall implement robust error handling mechanisms to address
anomalies or connection interruption in received data of for integrated
systems i.e., GPS (31 satellites’, Communication Satellite, COSMIC-2
Satellite.
FR015 The System will be able to make future predictions for all measurements
(Data Range)
NON – Functional Requirements

NFR001 The system will provide accurate Measurements
NFR002 The system will be able to maintain data accuracy within predefined MAE
“a” factor tolerance level.
NFR003 The system will be able to conform to accessibility standards: simplicity
(KISS P), and clarity (SR P), ensuring that it is usable by web interface
individuals with disabilities in compliance with relevant accessibility laws
i.e., section 508, ADA, WAI-ARIA.
NFR005 The system will give high performance in processing and transmitting data in
terms of page response (0.000001sec).
NFR006 At its peak usage, the system must support up to 690 million concurrent
users.
Use Case Diagram:

Use Case Specification:
QVscribe Analysis:
Scoring Criteria:
0 0% Very Low Risk
Includes clear and unambiguous terminology to
express the requirements.
Quality Criteria:
REQUIREMENT ANALYSIS
R 1: The web interface will conform to accessibility standards: simplicity (KISS P),
and clarity (SR P), ensuring that it is usable by individuals with disabilities in
compliance with relevant accessibility laws i.e., section 508, ADA, WAI-ARIA.
Quality analysis:
Clear: 100% (leaves no room for ambiguity or misinterpretation)
Testable: 100% (provides specific criteria or conditions that can be used to verify whether it has
been successfully implemented)
Imperative: Yes
Complete: 100% (contains all the necessary information for implementation without any
missing or implied details)
Verifiable: 100%
Consistency:
Controlled term: 100% (uses terminology in a standardized and defined manner, preventing
confusion or misinterpretation)
Proper units: 100% (specifies measurements in appropriate units, ensuring accuracy and
consistency in implementation)
R 2: The system shall maintain data accuracy within predefined MAE “a” factor
tolerance level.
Quality analysis:
Clear: 100% (leaves no room for ambiguity or misinterpretation) It specifies a measurable

accuracy level ("MAE 'a' factor tolerance level") that the system must maintain
Testable: 100% The requirement provides a specific criterion ("maintain data accuracy within
predefined MAE 'a' factor tolerance level") that can be objectively evaluated to determine
whether the system meets this requirement. This can be achieved through testing and
validation processes.
Imperative: Yes
Complete: 100% (contains all the necessary information for implementation without any
missing or implied details)
Verifiable: 100%
Consistency:
Controlled term: 100% (The terminology used in the requirement is standardized and well-
defined. "MAE" (Mean Absolute Error) is a commonly used term in data accuracy assessments,
ensuring clarity and precision.)
Proper units: 100% (specifies measurements in appropriate units, ensuring accuracy and
consistency in implementation)
R3: Stakeholders shall possess the capability to manage personalized alerts for
Quality analysis:
Clear: The requirement is clear because it specifies that stakeholders should have the ability to
manage personalized alerts for specific weather conditions. It indicates a clear functionality that
needs to be implemented.
Testable: This requirement is testable because it provides a specific capability that can be
objectively evaluated. Testing can verify whether stakeholders can successfully manage
personalized alerts.
Imperative: The requirement is stated in an imperative form, indicating a directive or command

that specifies what capability should be provided to stakeholders.
Complete: It contains all the necessary information for implementation. It specifies what needs
to be achieved (capability to manage personalized alerts) without missing any key details.
Verifiable: This requirement can be objectively confirmed or validated through testing. The
system can be assessed to determine if stakeholders are able to manage personalized alerts.
Consistency:
Consistent: It aligns seamlessly with other requirements and does not introduce conflicts or
contradictions. It complements other requirements related to stakeholder capabilities and
weather alerts.
Controlled Term: The terminology used in the requirement is clear and standard.
"Stakeholders," "manage," "personalized alerts," and "specific weather conditions" are well-
defined terms in the context of the requirement.
R4: The system will employ various channels for alert delivery such as email, SMS,
and in-system notifications.
Quality analysis:
Clear: The requirement is clear because it specifies that the system will use different channels
for delivering alerts, listing email, SMS, and in-system notifications as examples. This provides a
straightforward indication of the intended functionality.
Testable: This requirement is testable because it provides specific deliverables that can be
objectively evaluated. Testing can confirm whether the system can deliver alerts through email,
SMS, and in-system notifications.
Imperative: The requirement is not stated as a directive or command. Instead, it presents a

factual statement about what the system will do in terms of employing various channels for
alert delivery.
Continuity: The requirement maintains continuity with the previous requirements by addressing
a different aspect of alert management. It builds upon the previous requirement (R 3) which
focused on stakeholders' capability to manage personalized alerts.
Complete: The requirement is complete because it provides clear information about what the
system is expected to do. It states that the system will use various channels (email, SMS, and in-
system notifications) for alert delivery. There are no missing or implied details.
Verifiable: This requirement is verifiable because it provides specific deliverables (email, SMS,
and in-system notifications) that can be objectively evaluated. Testing can confirm whether the
system is capable of delivering alerts through these specified channels.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "Email,"
"SMS," and "in-system notifications" are well-defined terms commonly understood in the
context of alert delivery methods. These terms are commonly accepted in the field and do not
introduce any ambiguity or confusion.
R 5: Users can see filtered display weather data for specific geographical regions.
Quality analysis:
Clear: The requirement is clear because it specifies that users should have the capability to view
filtered weather data for specific geographical regions. It outlines a straightforward
functionality.
Testable: This requirement is testable because it provides specific functionality that can be
objectively evaluated. Testing can verify whether users are able to view filtered weather data for
specific regions.
Imperative: The requirement is not stated as a directive or command. Instead, it presents a

factual statement about what users can do in terms of viewing filtered weather data.
to be achieved (users viewing filtered weather data for specific regions) without missing any key
details.
system can be assessed to determine if users are able to view filtered weather data for specific
regions.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "Users,"
"filtered display weather data," and "specific geographical regions" are well-defined terms in
the context of the requirement.
R 6: The system shall provide interactive and clear data visualization tools i.e.,
maps, charts, and graphs.
Quality analysis:
Clear: The requirement is clear because it specifies that the system should offer interactive and
clear data visualization tools, providing examples such as maps, charts, and graphs.
objectively evaluated. Testing can confirm whether the system provides interactive and clear
data visualization tools, including maps, charts, and graphs.
that specifies what capability the system should have.
Directive: The requirement contains a directive, indicated by the use of "i.e." meaning "that is."
This signals that the examples provided (maps, charts, and graphs) are specific illustrations of
the data visualization tools that the system should provide.
to be achieved (providing interactive and clear data visualization tools including maps, charts,
and graphs) without any missing or implied details.
system can be assessed to determine if it indeed provides interactive and clear data
visualization tools, including maps, charts, and graphs.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "Interactive
and clear data visualization tools," "maps," "charts," and "graphs" are well-defined terms in the
context of the requirement.
R 7: Users shall have the ability to access historical atmospheric data with customized options
for selecting time frames.
Quality analysis:
Clear: The requirement is clear because it specifies that users should have the capability to
access historical atmospheric data with the option to customize time frames for selection. It
outlines a straightforward functionality.
objectively evaluated. Testing can confirm whether users are able to access historical
atmospheric data and customize time frames.

that specifies what capability users should have.
to be achieved (users accessing historical atmospheric data with customized time frame
options) without any missing or implied details.
system can be assessed to determine if users are indeed able to access historical atmospheric
data with customized time frame options.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "Users,"
"access historical atmospheric data," "customized options," and "selecting time frames" are
well-defined terms in the context of the requirement.
R 8: The system shall enable historical analysis (User Optional).
Quality analysis:
Clear: The requirement is clear because it specifies that the system should have the capability to
enable historical analysis, and it explicitly notes that this feature is optional for the user.
Testable: This requirement is testable because it provides specific functionality (enabling

historical analysis) that can be objectively evaluated. Testing can confirm whether the system
has this capability.

to be achieved (enabling historical analysis) without any missing or implied details.
system can be assessed to determine if it indeed enables historical analysis.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "System,"
"enable historical analysis," and "User Optional" are well-defined terms in the context of the
requirement.
R 9: The system will implement robust user authentication and access control
mechanisms to safeguard sensitive data, ensuring authorized access only.
Quality analysis:
Clear: The requirement is clear because it specifies that the system should have robust
mechanisms for user authentication and access control to protect sensitive data, and it
emphasizes that only authorized users should have access.
Testable: This requirement is testable because it provides specific functionality (implementing

user authentication and access control mechanisms) that can be objectively evaluated. Testing
can confirm whether the system effectively safeguards sensitive data.

to be achieved (implementing user authentication and access control mechanisms to safeguard
sensitive data) without any missing or implied details.
system can be assessed to determine if it effectively implements user authentication and access
control mechanisms.
Consistency:
"implement robust user authentication and access control mechanisms," "safeguard sensitive
data," and "authorized access only" are well-defined terms in the context of the requirement.
R 10: The system shall provide a well-documented API for seamless integration
into external applications or systems used by stakeholders, ensuring ease of
integration.
Quality analysis:
Clear: The requirement is clear because it specifies that the system should offer a well-
documented API for easy integration into external applications or systems used by stakeholders.
Testable: This requirement is testable because it provides specific functionality (providing a
well-documented API) that can be objectively evaluated. Testing can confirm whether the
system offers an API that allows seamless integration.

to be achieved (providing a well-documented API for seamless integration) without any missing
or implied details.
system can be assessed to determine if it indeed offers a well-documented API for seamless
integration.
Consistency:
"provide a well-documented API," "seamless integration," "external applications," "systems
used by stakeholders," and "ease of integration" are well-defined terms in the context of the
requirement.
R 11: Regular security audits will be conducted, following a predefined schedule

and reporting mechanisms, to maintain the system's security and compliance.
Quality analysis:
Clear: The requirement is clear because it specifies that regular security audits should be
conducted, providing details about the schedule and reporting mechanisms. It outlines a
straightforward process for maintaining the system's security and compliance.
Testable: This requirement is testable because it provides specific activities (conducting regular
security audits, following a predefined schedule, and using reporting mechanisms) that can be
objectively evaluated. Testing can confirm whether the system adheres to this process.

that specifies what activities should be performed.
Continuance: the use of the word 'following' signifies an ongoing commitment to a structured
process. This requirement extends the established framework by articulating a methodical
approach to sustaining the system's security and compliance.
to be achieved (conducting regular security audits with predefined schedule and reporting
mechanisms) without any missing or implied details.
Verifiable: This requirement can be objectively confirmed or validated through testing and
inspection of the conducted security audits.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "Regular
security audits," "predefined schedule," "reporting mechanisms," "system's security," and
"compliance" are well-defined terms in the context of the requirement.
R 12: The system will provide a wide range of atmospheric data, including but not
limited to temperature, humidity, pressure, air quality (CO2, CO, PM levels), wind
speed and direction, precipitation, solar radiation, UV radiation, ozone levels,
radiation levels, lightning detection, earthquake, volcanic eruptions, pollen count,
severe weather alerts, lightning intensity, tropical storm tracking, flood
monitoring, avalanche risk assessment, wildfire risk assessment, tsunami
warnings, air quality during disasters, and nuclear fallout monitoring, smog,
visibility.
Quality analysis:
Comprehensive: This requirement is comprehensive in nature, as it covers a wide range of

atmospheric data elements. It addresses various aspects of weather and environmental
monitoring, ensuring that the system provides a thorough and inclusive dataset.
Clear: The requirement is clear as it specifies a comprehensive list of atmospheric data

elements that the system is expected to provide. It leaves no room for ambiguity regarding the
scope of data to be included.
Testable: This requirement is testable because it provides a specific list of data elements that
can be objectively evaluated. Testing can confirm whether the system provides the stated
atmospheric data.

Complete: It contains all the necessary information for implementation. It provides an

exhaustive list of atmospheric data elements, leaving no major gaps or omissions.
system can be assessed to determine if it indeed provides the specified atmospheric data.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. Each specified
data element is well-defined and commonly used in the context of atmospheric monitoring.
R 13: The system will continuously update this comprehensive atmospheric data
in real-time.
Quality analysis:
Clear: The requirement is clear because it specifies that the system should provide continuous
real-time updates for comprehensive atmospheric data.
Testable: This requirement is testable because it provides specific functionality (continuous real-
time updates) that can be objectively evaluated. Testing can confirm whether the system
adheres to this process.

to be achieved (continuous real-time updates for comprehensive atmospheric data) without any
missing or implied details.
monitoring of the real-time updates provided by the system.
Timeliness: This requirement emphasizes the importance of real-time updates, ensuring that
the data provided is current and up-to-date. It underscores the system's commitment to
delivering timely information for effective decision-making.
Consistency:
"continuously update," "comprehensive atmospheric data," and "real-time" are well-defined
terms in the context of the requirement.
R 14: The system will deliver this updated data to stakeholders.
Quality analysis:
Clear: The requirement is clear because it specifies that the system should deliver the updated
data to stakeholders. It leaves no room for ambiguity regarding the intended action.
Testable: This requirement is testable because it provides specific functionality (delivering

updated data to stakeholders) that can be objectively evaluated. Testing can confirm whether
the system fulfills this requirement.

to be achieved (delivering updated data to stakeholders) without any missing or implied details.
monitoring of the data delivery process to stakeholders.
Timeliness: This requirement also incorporates the attribute of timeliness, as delivering updated
data to stakeholders implies that the data should be provided in a timely manner to be relevant
and useful.
Consistency:
"deliver," "updated data," and "stakeholders" are well-defined terms in the context of the
requirement.
R 15: The system shall employ advanced algorithms for weather prediction based
on received data.
Quality analysis:
Clear: This requirement is clear and concise. It states that the system must utilize advanced
algorithms for weather prediction based on received data. There is no ambiguity in the
statement.
Testable: This requirement is testable because it outlines a specific functionality that can be
objectively evaluated. The system's use of advanced algorithms for weather prediction can be
assessed through testing and validation against actual weather data.
Imperative: The requirement is stated as a directive or command. It specifies a necessary action

for the system: to employ advanced algorithms for weather prediction. It's not presented as a
suggestion or option.
Complete: The requirement is complete as it provides all necessary information for

implementation. It specifies that the system must use advanced algorithms for weather
prediction based on received data. There are no missing or implied details.
assessment of the system's use of advanced algorithms for weather prediction. The
effectiveness of the algorithms can be assessed against actual weather data.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "Advanced
algorithms," "weather prediction," "received data" are all well-defined terms in the context of
the requirement. Each term has a specific meaning within the domain of weather forecasting.
R 16: It shall generate forecasts for specified time intervals i.e., custom (mins,
hours), weekly, monthly, annually.
Quality analysis:
Clear: This requirement is clear and straightforward. It states that the system shall generate
forecasts for specified time intervals, including custom intervals (in minutes and hours), weekly,
monthly, and annually. There is no ambiguity in the statement.
Testable: This requirement is testable as it defines specific functionality that can be objectively
evaluated. The system's ability to generate forecasts for the specified time intervals can be
assessed through testing and validation.
Imperative: The requirement is stated as a directive or command. It instructs the system to

generate forecasts for specified time intervals, emphasizing the necessary action.

implementation. It specifies the time intervals for which forecasts must be generated, including
custom intervals, weekly, monthly, and annually. There are no missing or implied details.
assessment of the system's ability to generate forecasts for the specified time intervals. The
effectiveness of the forecasting process can be assessed against the defined intervals.
Continuance: The requirement introduces a range of specified time intervals, including custom
intervals (in minutes and hours), weekly, monthly, and annually. This showcases a continuum of
forecast granularity, allowing stakeholders to access forecasts tailored to their specific planning
needs.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "Generate
forecasts," "specified time intervals," "custom (mins, hours)," "weekly," "monthly," and
"annually" are all well-defined terms in the context of the requirement. Each term has a specific
meaning within the domain of weather forecasting.
Proper Units: This requirement involves specifying time intervals, including custom intervals in
minutes and hours, as well as weekly, monthly, and annually. The units for time intervals are
appropriately defined, ensuring that each interval is expressed in a clear and standardized
manner.
R 17: The system will use an integrated system [Communication Satellite] for real-
Quality analysis:
Clear: This requirement is clear and concise. It states that the system will use an integrated
system, specifically a "Communication Satellite," for real-time data networking. There is no
ambiguity in the statement.
Testable: This requirement is testable as it defines a specific functionality that can be objectively
evaluated. The system's utilization of a Communication Satellite for real-time data networking
can be assessed through testing and validation.
Imperative: The requirement is stated as a directive or command. It instructs the system to use
a Communication Satellite for real-time data networking.

implementation. It specifies that the system will utilize an integrated system, namely a
Communication Satellite, for real-time data networking. There are no missing or implied details.
assessment of the system's utilization of a Communication Satellite for real-time data
networking.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "Integrated
system," "Communication Satellite," and "real-time data networking" are all well-defined terms
in the context of the requirement. Each term has a specific meaning within the domain of data
networking.
R 18: The system will use an integrated system [GPS (31 satellites’)] for real-time
user navigation.
Quality analysis:
Clear: This requirement is clear and concise. It states that the system will use an integrated
system, specifically "GPS (31 satellites)," for real-time user navigation. There is no ambiguity in
the statement.
evaluated. The system's utilization of GPS (31 satellites) for real-time user navigation can be
assessed through testing and validation.
Imperative: The requirement is stated as a directive or command. It instructs the system to use
GPS (31 satellites) for real-time user navigation.

implementation. It specifies that the system will utilize an integrated system, namely GPS (31
satellites), for real-time user navigation. There are no missing or implied details.
assessment of the system's utilization of GPS (31 satellites) for real-time user navigatio
Consistency:
system," "GPS (31 satellites)," and "real-time user navigation" are all well-defined terms in the
context of the requirement. Each term has a specific meaning within the domain of user
navigation.
R 19: The system will provide accurate Measurements.
Quality analysis:
Incomplete: This requirement lacks specificity. It states that the system will provide accurate
measurements, but it does not specify what kind of measurements (e.g., temperature,
humidity, pressure) or under what circumstances (e.g., in real-time, at specific intervals)
accuracy is required. Additional details are needed to make this requirement actionable and
testable.
Untestable: This requirement is not directly testable. While the overall functionality of utilizing
advanced algorithms can be tested, the specific implementation of the algorithms may require
more detailed testing through code inspection and validation.

employ advanced algorithms for weather prediction.
Unclear: This requirement lacks specificity. It states that the system will provide accurate
measurements, but it does not specify what kind of measurements (e.g., temperature,
humidity, pressure) or under what circumstances (e.g., in real-time, at specific intervals)
accuracy is required. Additional details are needed to make this requirement actionable and
testable.
Unverifiable: Without specific details regarding the type of measurements and the criteria for
accuracy, it becomes challenging to objectively verify whether the system has indeed provided
accurate measurements. Clarity and specific criteria for accuracy are essential for verifiability.
Consistency:
system," "GPS (31 satellites)," and "real-time user navigation" are all well-defined
R 20: The system shall implement robust error handling mechanisms to address
anomalies or connection interruption in received data of for integrated systems
i.e., GPS (31 satellites’, Communication Satellite, COSMIC-2 Satellite.
Quality analysis:
Clear: This requirement is clear and comprehensive. It specifies that the system shall implement
robust error handling mechanisms to address anomalies or connection interruptions in received
data for integrated systems, including GPS (31 satellites), Communication Satellite, and COSMIC-
2 Satellite. It provides a specific directive without ambiguity.
evaluated. The system's error handling mechanisms can be assessed through testing and
validation against scenarios involving anomalies or connection interruptions.

implement robust error handling mechanisms to address anomalies or connection interruptions
in received data.

implementation. It specifies the need for robust error handling mechanisms for integrated
systems, including GPS (31 satellites), Communication Satellite, and COSMIC-2 Satellite. There
are no missing or implied details.
assessment of the system's error handling mechanisms in scenarios involving anomalies or
connection interruptions in received data.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "Robust error
handling mechanisms," "anomalies," "connection interruptions," "received data," "integrated
systems," "GPS (31 satellites)," "Communication Satellite," and "COSMIC-2 Satellite" are all well-
defined terms in the context of the requirement. Each term has a specific meaning within the
domain of error handling.
R 21: The System will make future predictions for all measurements (Data Range)
Quality analysis:
Unclear: This requirement lacks specificity. It states that the system will make future predictions
for all measurements, but it does not specify what kind of measurements (e.g., temperature,
humidity, pressure) or provide details on how these predictions should be made. Additional
details are needed to make this requirement actionable and testable.
Incomplete: The requirement lacks specific details about the data range for which future
predictions are to be made. It should define the range (e.g., days, weeks, months) within which
the predictions are expected.
Untestable: This requirement is not directly testable. While the overall functionality of making
future predictions can be tested, the specific implementation of predicting all measurements
within an unspecified data range may require more detailed testing through code inspection
and validation.
Unverifiable: Without specific details regarding the type of measurements and the criteria for
making accurate predictions, it becomes challenging to objectively verify whether the system
has provided accurate predictions. Clarity and specific criteria for prediction accuracy are
essential for verifiability.
R 22: It shall demonstrate high performance in processing and transmitting data

in terms of page response (0.000001sec).
Quality analysis:
Clear: This requirement is clear and specific. It states that the system shall demonstrate high
performance in processing and transmitting data, particularly in terms of page response time,
which is specified as 0.000001 seconds. There is no ambiguity in the statement.
Testable: This requirement is testable as it defines a specific performance metric (page response
time) with a precise value (0.000001 seconds). The system's performance in processing and
transmitting data can be objectively evaluated against this benchmark.

demonstrate high performance in processing and transmitting data within the specified
response time.

implementation. It specifies the performance expectation in terms of page response time
(0.000001 seconds). There are no missing or implied details.
assessment of the system's performance in processing and transmitting data, particularly in
terms of page response time.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "High
performance," "processing and transmitting data," and "page response time" are all well-
defined terms in the context of the requirement. Each term has a specific meaning within the
domain of system performance.
Proper Units: The requirement specifies the page response time in seconds, expressed in
scientific notation as 0.000001 seconds. This is an appropriate unit for measuring response
time.
R 23: At its peak usage, the system must support up to 690 million concurrent
users.
Quality analysis:
Clear: This requirement is clear and specific. It states that at its peak usage, the system must
support up to 690 million concurrent users. There is no ambiguity in the statement.
Testable: This requirement is testable as it defines a specific performance metric (concurrent

users) with a precise value (690 million). The system's ability to support this number of
concurrent users can be objectively evaluated.

support up to 690 million concurrent users at its peak usage.

implementation. It specifies the performance expectation in terms of the maximum number of
concurrent users (690 million). There are no missing or implied details.
assessment of the system's ability to support up to 690 million concurrent users at its peak
usage.
Consistency:
Controlled Term: The terminology used in the requirement is clear and standard. "Concurrent
users" and "690 million" are well-defined terms in the context of the requirement. Each term
has a specific meaning within the domain of system performance.
Proper Units: The requirement specifies the number of concurrent users, expressed as 690
million. This is an appropriate unit for measuring system capacity.
SIMILARITY
Requirement 1 and Requirement 2:
Similarity: Both requirements pertain to system standards and accuracy.
Explanation: Requirement 1 focuses on conforming to accessibility standards and ensuring

usability for individuals with disabilities. Requirement 2 addresses the need for data accuracy
within a predefined tolerance level (MAE "a" factor).

Similarity: Both requirements involve stakeholder interaction with the system for alerts.
Explanation: Requirement 3 grants stakeholders the capability to manage personalized alerts

for specific weather conditions. Requirement 4 outlines various channels (email, SMS, in-system
notifications) for delivering alerts.
Similarity: Both requirements relate to accessing weather data.
Explanation: Requirement 5 allows users to view filtered weather data for specific geographical
regions. Requirement 7 enables users to access historical atmospheric data with customizable
time frames.
Similarity: Both requirements concern data visualization and delivery.
Explanation: Requirement 6 mandates the provision of interactive and clear data visualization
tools (maps, charts, graphs). Requirement 14 focuses on delivering updated data to
stakeholders.
Similarity: Both requirements involve generating forecasts.
Explanation: Requirement 8 addresses the use of various channels for alert delivery, including
in-system notifications. Requirement 16 emphasizes the generation of forecasts for specified
time intervals.
Similarity: Both requirements relate to system security and integration.
Explanation: Requirement 9 emphasizes implementing robust user authentication and access

control mechanisms. Requirement 10 focuses on providing a well-documented API for seamless
integration with external applications.
Similarity: Both requirements concern system performance and advanced algorithms.
Explanation: Requirement 11 emphasizes regular security audits for system security and
compliance. Requirement 15 mandates the use of advanced algorithms for weather prediction
based on received data.

22F-3678,22F-3683,22F-3679 SRE pp2

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

22F-3678,22F-3683,22F-3679 SRE pp2

Uploaded by

Copyright:

Available Formats

22F-3685

Forecasting and Prediction:

Why are we using it?

To make our project easier and better.

How project overview mechanism work: https://youtu.be/ry34hK3R_yg?

Website link: https://www.weather.gov/

You tube link: https://youtube.com/@noaanationalweatherservice?si=-RO68o-b-

Some other links (Project overview points or National Weather Service

Radar and analyze weather through map: https://youtu.be/NRFd_5Hiz6g?

How satellite works: https://youtu.be/ror4P1UAv_g?si=fYqmJyZZMFxn7khB

Hurricane Preparedness: https://youtu.be/Fq_1PwKuRPg?

NWS (visual overview): https://youtu.be/7DgFPgJTxP8?

Requirements for Weather Measuring System in Natural

FR009 The system will deliver this updated data to stakeholders.

NON – Functional Requirements

NFR003 The system will be able to conform to accessibility standards: simplicity

QUARS EXPRESS Comprehensive

I. Defect Identification Metrics:

Optionality: Measures the presence of optional elements in requirements. This is evaluated by

Weakness: Detects weaknesses in the requirements, such as ambiguities, inconsistencies, or unclear

II. Execution Time Metrics:

III. Readability Metrics:

REQUIREMENT THROUGH QuARS Analysis:

Requirement Requirement Descriptions

FR009 The system will deliver this updated data to stakeholders.

NON – Functional Requirements

Use Case Diagram:

Clear: 100% (leaves no room for ambiguity or misinterpretation)

Clear: 100% (leaves no room for ambiguity or misinterpretation) It specifies a measurable

Imperative: The requirement is stated in an imperative form, indicating a directive or command

Imperative: The requirement is not stated as a directive or command. Instead, it presents a

Imperative: The requirement is not stated as a directive or command. Instead, it presents a

Imperative: The requirement is stated in an imperative form, indicating a directive or command

R 8: The system shall enable historical analysis (User Optional).

Testable: This requirement is testable because it provides specific functionality (enabling

Imperative: The requirement is stated in an imperative form, indicating a directive or command

Testable: This requirement is testable because it provides specific functionality (implementing

Imperative: The requirement is stated in an imperative form, indicating a directive or command

Imperative: The requirement is stated in an imperative form, indicating a directive or command

R 11: Regular security audits will be conducted, following a predefined schedule

Imperative: The requirement is stated in an imperative form, indicating a directive or command

Comprehensive: This requirement is comprehensive in nature, as it covers a wide range of

Clear: The requirement is clear as it specifies a comprehensive list of atmospheric data

Imperative: The requirement is stated in an imperative form, indicating a directive or command

Complete: It contains all the necessary information for implementation. It provides an

Imperative: The requirement is stated in an imperative form, indicating a directive or command

R 14: The system will deliver this updated data to stakeholders.

Testable: This requirement is testable because it provides specific functionality (delivering

Imperative: The requirement is stated in an imperative form, indicating a directive or command

Imperative: The requirement is stated as a directive or command. It specifies a necessary action

Complete: The requirement is complete as it provides all necessary information for

Imperative: The requirement is stated as a directive or command. It instructs the system to

Complete: The requirement is complete as it provides all necessary information for

Complete: The requirement is complete as it provides all necessary information for

Complete: The requirement is complete as it provides all necessary information for

R 19: The system will provide accurate Measurements.

Imperative: The requirement is stated as a directive or command. It instructs the system to

Imperative: The requirement is stated as a directive or command. It instructs the system to

Complete: The requirement is complete as it provides all necessary information for

R 22: It shall demonstrate high performance in processing and transmitting data

Imperative: The requirement is stated as a directive or command. It instructs the system to

Complete: The requirement is complete as it provides all necessary information for

Testable: This requirement is testable as it defines a specific performance metric (concurrent