Software Requirements

Specification

for

UTAS Reconnaissance Mission Debrief System

Version 1.9 to be verified

06FEB2013

Prepared by Matthew Alioto, Jason Buoni, Harry Chris, Joshua Gagne

Revision History

Name	Date	Reason For Changes	Version
Joshua Gagne	11/30/2012	Initial Setup
All	12/10/2012	Added Content (S1.4 + S2)	1.1
All	12/18/2012	Add Draft Content	1.2
All	12/19/2012	Add Content (S4 + S5)	1.3
All	1/2/2013	Revise S3	1.4
Jason Buoni	1/10/2013	Added features to S3	1.5
Jason Buoni	1/29/2013	Draft 2	1.6
Matt Alioto	2/3/2013	Draft 2 Revision	1.7
Jason Buoni	2/6/2013	Draft Final Revisions	1.8
Jason Buoni	2/22/2013	Added Requirement Changes resulting from Planning Poker meeting	1.9

Table of Contents

1 Introduction

1.1 Purpose

1.2 Document Conventions

1.3 Intended Audience and Reading Suggestions

2 Overall Description

2.1 Product Perspective

2.2 Product Features

2.3 User Classes and Characteristics

2.4 Operating Environment

2.5 Assumptions and Constraints

3.1.1 Latitude and Longitude

3.1.1.1 Description and Priority

3.1.1.2 Stimulus/Response Sequence

3.1.1.3 Functional Requirements

3.1.2 Temperature

3.1.2.1 Description and Priority

3.1.2.2 Stimulus/Response Sequence

3.1.2.3 Functional Requirements

3.1.3 Location

3.1.3.2 Stimulus/Response Sequence

3.1.3.3 Functional Requirements

3.1.4 Attitude

3.1.4.2 Stimulus/Response Sequence

3.1.4.3 Functional Requirements

3.1.5 Pod Reported Errors

3.1.5.2 Stimulus/Response Sequence

3.1.5.3 Functional Requirements

3.1.6 Speed

3.1.6.2 Stimulus/Response Sequence

3.1.6.3 Functional Requirements

3.2 Timeline

3.2.1 Error Notes Displayed

3.2.1.2 Stimulus/Response Sequence

3.2.1.3 Functional Requirements

3.2.2 Tick Navigation

3.2.2.2 Stimulus/Response Sequence

3.2.2.3 Functional Requirements

3.2.3 Fast Forward Functionality

3.2.3.2 Stimulus/Response Sequence

3.2.3.3 Functional Requirements

3.2.4 Reverse Functionality

3.2.4.2 Stimulus/Response Sequence

3.2.4.3 Functional Requirements

3.2.5.2 Stimulus/Response Sequence

3.2.5.3 Functional Requirements

3.2.6.2 Stimulus/Response Sequence

3.2.6.3 Functional Requirements

3.2.7.2 Stimulus/Response Sequence

3.2.7.3 Functional Requirements

3.3 Briefing / Report Generation

3.3.1 Export Output Report

3.3.1.1 Description and Priority

3.3.1.2 Stimulus/Response Sequence

3.3.1.3 Functional Requirements

3.4 Picture display

3.4.1 Visual

3.4.1.2 Stimulus/Response Sequence

3.4.1.3 Functional Requirements

3.5 Filters

3.5.1 Task Start/End

3.5.1.2 Stimulus/Response Sequence

3.5.1.3 Functional Requirements

3.5.2 Scan Start/End

3.5.2.2 Stimulus/Response Sequence

3.5.2.3 Functional Requirements

3.5.3 Enable / Disable Filters

3.5.3.2 Stimulus/Response Sequence

3.5.3.3 Functional Requirements

3.5.3 Filter Criteria

3.5.3.2 Stimulus/Response Sequence

3.5.3.3 Functional Requirements

3.6 Flight Path Analysis

3.6.1 Graph Flight Data

3.6.1.2 Stimulus/Response Sequence

3.6.1.3 Functional Requirements

3.7.1 Hide and Show Panel

3.7.1.2 Stimulus/Response Sequence

3.7.1.3 Functional Requirements

3.7.2 Organize Panels

3.7.2.2 Stimulus/Response Sequence

3.7.2.3 Functional Requirements

3.7.4 Save Panel State

3.7.4.2 Stimulus/Response Sequence

3.7.4.3 Functional Requirements

3.7.5 System Menu

3.7.5.2 Stimulus/Response Sequence

3.7.5.3 Functional Requirements

3.8 Panels

3.8.1 Rules Panel

3.8.1.2 Stimulus/Response Sequence

3.8.1.3 Functional Requirements

3.9 Multiple Data Input Support

4 External Interface Requirements

4.1 User Interfaces

4.2 Hardware Interfaces

4.3 Software Interfaces

5 Other Nonfunctional Requirements

5.1 Performance Requirements

5.2 Software Quality Attributes

5.2.1 Correctness

5.2.2 Modifiability

6 Glossary

1 Introduction

1.1 Purpose

The UTC Aerospace Systems ISR Systems division develops and supports a variety of airborne imaging reconnaissance systems. Not all reconnaissance missions are successful and improper data may be gathered due to pod faults, user error, or other factors. Upon an aircraft landing, gathered data is analyzed by a ground exploitation system. However, the only troubleshooting tools available act at a low level, take too much time to use, and require highly trained technical personnel.

The Reconnaissance Mission Debrief System (RMDS) shall support timely post-flight mission deconstruction and analysis by helping the operator determine the cause of task, system, and mission failures. It shall be used as a diagnostic tool both internally and in the field, as a pilot training aid, and for ground support.

RMDS shall be a graphic system which runs on COTS hardware and allows the mission to be browsed chronologically. It shall display information such as avionics, sensor data, engineering data, and operator annotations synchronized to the time record of the mission. Data may be filtered, searched, exported, or summarized into a printable report, and the RMDS as a whole shall be architected to support future expansion of analysis techniques and filters.

1.2 Document Conventions

In this version of the Document, requirements are stated at a fairly high level. This is not the final version of detail.

Incomplete sections marked: to be determined (TBD)

Unverified portions marked: to be verified (TBV)

1.3 Intended Audience and Reading Suggestions

This document is primarily geared towards the software developers, describing what type of software they are expected to build. The document is also intended for the architects, for the same reasons as the developer, as well as the managers of the company that shall be using the software. This document shall facilitate the understanding of how the system runs.

Introduction/Overview - Introduces the project and this document
Overall Description - Information related to the general overview of the product relevant to the requirements. This includes a context diagram.
System Features - This section describes what the features of the system are and how they shall be used.
External Interface Requirements - This section describes the different interfaces the System shall interact with. These interfaces include local, remote, hardware, and user interfaces.
Other Non-Functional Requirements - This section describes the different attributes that the System must have from the perspective of an End User.
Other Requirements - This section shall cover any requirements not mentioned in sections 4 and 5.

Typically a software developer shall want to focus on sections 3, 4, and 6. The software architect on the other hand shall find most useful sections 2, 4, 5, and 6. And lastly the managers in the company that uses the software shall find most useful sections 2, 3, and 5.

2 Overall Description

2.1 Product Perspective

The RMDS is not based off of any previous software. UTAS has created some mock up UI designs, but most of design shall be up to the team. The system is geared to be placed on top of one existing system developed by UTAS however full integration with this component is not expected by the team.

Here is a diagram that depicts the dependencies of the RMDS system. The RMDS system shall rely on the File Output provided by the UTAS STANAG Parser. Multiple examples of File Output are being provided to the team to allow for more real examples and test cases. RMDS shall be designed to allow Alternate Input configurations of data to be added to the system at a later time but the alternate input configurations shall not be developed by the team.

2.2 Product Features

The product will* mainly contain an architected framework that can be used to house independent panels* that shall be used to display data. These panels can be changed out for other panels developed by the team or later by the sponsor in maintenance releases or updates.

Each panel in the system can be removed or added in a later date by the UTAS software engineering team. Panels shall not require information from other panels to function correctly. The framework in which these panels reside shall contain the only pertinent information for each panel.

2.3 User Classes and Characteristics

Field Service Representatives (FSR) - FSRs shall be responsible for using the software when training the customer. These will be the primary points of contact for UTAS and shall handle all malfunctions in hardware and software. The FSR shall be knowledgeable about the software.
UTAS Software Engineer - The UTAS Software Engineer shall be responsible for all post release maintenance and updates associated with the software. The software engineer shall have a large amount of skill operating and using computer software.

Pilot - The pilot shall be able to view his/her mission results for training purposes. The pilot may or may not have a large amount of skill dealing with computer software.

2.4 Operating Environment

The software will be operated by the FSR associated with UTAS. The software will be used in an office setting.

2.5 Assumptions and Constraints

2.5.1 Constraints

RMDS-144: The software shall be able to run as a standalone system on both a Windows 7/XP operating systems and a Linux 2.6, along with subsequent releases.
RMDS-145: The software shall not require the installation or configuration of a database.
RMDS-146: The software and its rules shall be configurable via text file.

The text file shall be of human readable ASCII file of type .txt.

RMDS-147: The software shall be able to work on a commodity laptop with a higher end graphics card.

The laptop will have at least a 1.7 GHz processor and a high end NVIDIA graphics card.

RMDS-148: The panels in the program shall be interchangeable.

The software shall be able to run regardless of what panels are set to be loaded into the project.

2.5.2 Assumptions

The STANAG data shall be parsed by an intermediate program that UTAS shall provide the team with. The program shall call this parser program to get all parsed STANAG data required.

The team shall not need handle any other data separate from the STANAG data.

WorldWind stock geographical data shall be used for any maps.
No locale functionality shall be required.

2.5.3 Dependencies

The system shall primarily be dependent on table output format from an extractor program provided by UTAS. The extractor program will parse the STANAG data so that it will be readable to the program.
Panels shall be independent of each other, but shall be dependent upon the framework to run, i.e. no panel can run as a standalone system.

3 System Features

The RMDS shall be split up into two main components, the RMDS Framework, and independent RMDS Panels. Goodship Aces shall develop the RMDS Framework as well as some RMDS Panels, while the UTAS Software Engineering staff shall be responsible for developing additional panels in the future. Goodship Aces will be responsible for providing UTAS with an API needed to implement new panels along with documentation on how to do so. Many Panels are out of scope for this project. The Temperature, Altitude, Rules, Timeline, and World Wind panels will be released with the final team deliverable.

3.1 Error Analysis

The system shall contain multiple rules that will be used to help validate a mission and point out where errors were encountered.

3.1.1 Latitude and Longitude

3.1.1.1 Description and Priority

The system shall check for errors resulting from the pilot straying outside of accepted bounds of latitude and longitude during the mission. This feature has a priority* of Major.

3.1.1.2 Stimulus/Response Sequence

User loads mission data extract.
System loads Latitude and Longitude rule data.
Deviations are logged and saved to rule data file.
(Optional) User displays Panel containing data.

3.1.1.3 Functional Requirements

REQ-EA-1 Check for Errors - The system shall check for errors for all relevant rules.

REQ-EA-2 Read Latitude and Longitude - The system shall read position data from the provided data sheets.

REQ-EA-3 Report Errors - The system shall report all found errors to the user.

3.1.2 Temperature

3.1.2.1 Description and Priority

The system shall check for errors resulting from excess temperature in the Sensor Bay or Avionics Bay. The system shall track temperature changes over time. This feature has priority of Major.

3.1.2.2 Stimulus/Response Sequence

User loads mission data extract.
System loads temperature rule data.
Deviations are logged and saved to rule data file.
User displays Panel showing changes in temperature over time.
(Optional) User displays Panel showing temperature deviations.

3.1.2.3 Functional Requirements

RMDS-151 Check for Errors - The system shall check for errors for all relevant rules.

RMDS-152 Read Temperature - The system shall read in all temperature data from the provided data sheets.

RMDS-153 Report Errors - The system shall report all found errors to the user.

RMDS-20 Report Temperature Changes - The system shall report all temperature changes observed in the data.

3.1.3 Location

3.1.3.2 Description and Priority

The system shall track the aircraft's location throughout the mission. The system shall report any errors in aircraft location. The rules shall determine what is and what is not a location error. This feature has a priority of Major.

3.1.3.2 Stimulus/Response Sequence

User loads mission data extract.
System loads location rules data.
Deviations are logged and saved to rule data file.
(Optional) User displays Panel showing position violations.

3.1.3.3 Functional Requirements

RMDS-154 Check for Errors - The system shall check for errors for all relevant rules.

RMDS-155 Report Errors - The system shall report all found errors to the user.

RMDS-156 Report Location Changes - The system shall report the current location to the user.

3.1.4 Attitude

3.1.4.1 Description and Priority

The system shall check the direction in which the plane is facing to ensure that it matches the mission plan. This feature has a priority of Minor.

3.1.4.2 Stimulus/Response Sequence

User loads mission data extract.
System loads Attitude rule data.
Deviations are logged and saved to rule data file.
Keeps checking for more errors.
(Optional) User displays Panel showing attitude violations.

3.1.4.3 Functional Requirements

RMDS-157 Check for Errors - The system shall check for errors for all relevant rules.

RMDS-158 Read Attitude - The system shall read in plane attitude from the provided data sheets.

RMDS-159 Report Errors - The system shall report all found errors to the user.

3.1.5 Pod Reported Errors

3.1.5.1 Description and Priority

The system shall check for errors in the plane or hardware returned by the pod. This feature has a priority of Critical.

3.1.5.2 Stimulus/Response Sequence

User loads mission data extract.
Errors are logged and saved to rule data file.
User displays Panel showing errors.

3.1.5.3 Functional Requirements

RMDS-22 Find Reported Pod Errors - The system shall find all errors reported by the pod that are contained within the parsed STANAG data.

RMDS-159 Report Errors - The system shall report all found errors to the user.

RMDS-160 Determine Error Criticality - Each pod error shall have a level of severity. The system shall be able to determine the level of severity of this error.

3.1.6 Speed

3.1.6.1 Description and Priority

3.1.6.2 Stimulus/Response Sequence

User loads mission data extract.
System loads speed rules data.

Deviations are logged and saved to rule data file.
(Optional) User displays Panel showing speed data.

3.1.6.3 Functional Requirements

RMDS-161 Check for Errors - The system shall check for errors for all relevant rules.

RMDS-162 Report Errors - The system shall report all found errors to the user.

3.2 Timeline

A timeline shall be displayed to the user. The timeline shall allow a playback of the mission in simulated wall and accelerated time. The timeline shall allow a user to jump to sections with errors. The timeline shall display errors to the user. The timeline features have the highest priority, and therefore the highest Prioritys.

3.2.1 Error Notes Displayed

3.2.1.1 Description and Priority

The system shall display all pod errors as ticks on the timeline. The system shall display all violated rule data as ticks on the timeline. This feature has a priority of Major.

3.2.1.2 Stimulus/Response Sequence

User loads mission extract data.
System loads rules data.
(Optional) User filters displayed rules.
Timeline is populated with rules passing filter.

3.2.1.3 Functional Requirements

RMDS-27 Timeline Displayed In Panel - The system shall display the Timeline data in a panel. This panel will always be visible to the user while a mission is loaded.

RMDS-34 Display Ticks - The system shall add ticks on the timeline for reported errors.

RMDS-163 Recognize Errors - The system has to recognize mission errors generated by other parts of the system. These errors must be annotated as ticks on the timeline.

3.2.2 Tick Navigation

3.2.2.1 Description and Priority

The system shall allow the user to navigate the timeline between different ticks. This feature has a priority of Minor.

3.2.2.2 Stimulus/Response Sequence

User loads mission extract data.
System loads rules data.
Timeline is populated with rule tick marks.
User selects a tick on the timeline.
System loads data at the time of the selected tick and displays it to the user.

3.2.2.3 Functional Requirements

RMDS-27 Timeline Displayed In Panel - The system shall display the Timeline data in a panel. This panel will always be visible to the user while a mission is loaded.

RMDS-164 Synchronized Data Display - All data displayed to the user shall be synchronized with the current mission time unless the user chooses otherwise.

RMDS-165 Data Navigation - The system has to be able to cycle back and forth through the data provided depending on the user’s tick navigation.

3.2.3 Fast Forward Functionality

3.2.3.1 Description and Priority

The system shall allow the user to fast forward the mission display time. The fast forwarding speed can be adjusted. This feature has a priority of Critical.

3.2.3.2 Stimulus/Response Sequence

User is viewing displayed data
User chooses to fast forward mission.
Mission data is displayed at a quicker rate in all Panels.
User chooses to increase forwarding speed.
Mission data is displayed at an even quicker rate in all Panels.

3.2.3.3 Functional Requirements

RMDS-27 Timeline Displayed In Panel - The system shall display the Timeline data in a panel. This panel will always be visible to the user while a mission is loaded.

RMDS-166 Increased Data Navigation Speed - The system shall support increased data navigation speeds when fast forwarding.

RMDS-38 Multiple Navigation Speeds - The system shall support multiple mission navigation speeds.

RMDS-167 Increased Data Display Speed - All data shall be displayed to the user when fast forwarding and remain synchronized with the current mission time.

3.2.4 Reverse Functionality

3.2.4.1 Description and Priority

The system shall allow the user to rewind the mission display time. The rewinding speed can be adjusted. This feature has a priority of Critical. .

3.2.4.2 Stimulus/Response Sequence

User is viewing displayed data.
User chooses to rewind mission.
Mission data is displayed in reverse in all Panels.
User chooses to increase rewind speed.
Mission data is displayed in reverse at an even quicker rate in all Panels.

3.2.4.3 Functional Requirements

RMDS-27 Timeline Displayed In Panel - The system shall display the Timeline data in a panel. This panel will always be visible to the user while a mission is loaded.

RMDS-168 Reversed Data Navigation - The system shall support displaying data in reverse.

RMDS-38 Multiple Navigation Speeds - The system shall support multiple mission navigation speeds.

RMDS-169 Reversed Data Display - All data shall be displayed to the user when rewinding and remain synchronized with the current mission time.

3.2.5 Next / Previous Tick Navigation

3.2.5.1 Description and Priority

The system shall be able to navigate to the next tick or the previous tick on the timeline. The system shall “jump” to that spot on the timeline. All required panels shall navigate to that mission time. This feature has a priority of Minor.

3.2.5.2 Stimulus/Response Sequence

User wants to view mission at the next tick.
User selects to navigate to the next tick.
System jumps to next tick.
Data updated to current mission time is displayed in all Panels.
User wants to view mission at previous tick.
User selects to navigate to previous tick.
System jumps to previous tick.
Data updated to current mission time is displayed in all Panels.

3.2.5.3 Functional Requirements

RMDS-27 Timeline Displayed In Panel - The system shall display the Timeline data in a panel. This panel will always be visible to the user while a mission is loaded.

RMDS-170 Navigation of Data to Current Mission Time - The system shall be able to jump back and forth to different mission times and display that data as the current mission time data.

3.2.6 Zoom Timeline

3.2.6.1 Description and Priority

The user shall be able to zoom in and out when viewing the timeline. This feature has a priority of Minor..

3.2.6.2 Stimulus/Response Sequence

User chooses to zoom in on timeline.
User selects to zoom in timeline.
System zooms in on timeline.
User chooses to zoom out on timeline.
User selects to zoom out timeline.
System zooms out on timeline.

3.2.6.3 Functional Requirements

RMDS-27 Timeline Displayed In Panel - The system shall display the Timeline data in a panel. This panel will always be visible to the user while a mission is loaded.

RMDS-171 Increase / Decrease Displayed Time Intervals - The system shall increase and decrease the displayed time intervals when zooming.

3.2.7 Play Mission

3.2.7.1 Description and Priority.

The user shall be able to play the mission. Mission will play a normal rate. This feature has a priority of Critical.

3.2.7.2 Stimulus/Response Sequence

User is viewing displayed data.
User selects the play button.
Mission plays at normal rate.

3.2.7.3 Functional Requirements

RMDS-37 Play mission at set rate - Time advances automatically

3.3 Briefing / Report Generation

3.3.1 Export Output Report

3.3.1.1 Description and Priority

The user shall be able to generate an output report in text format consisting of all time stamped rule violations, pod reported errors, and custom notes. Times stamps shall use an epoch time type. This file will be exported to a location outside of the system. This feature has a priority of Major.

3.3.1.2 Stimulus/Response Sequence

User loads mission data extract.
Rules data is loaded and saved to rule data file(s).
User reviews mission and adds notes.
User selects to generate an output report.
System generates output report.
System exports output file.

3.3.1.3 Functional Requirements

RMDS-24 Write System Data to Output File - The system shall write all system data to a data output file. The data output file shall be of a type .txt format.

RMDS-172 Timestamps are in epoch time type

3.4 Picture display

An aircraft mounting the DB-110 pod may capture many images during a single mission. Images are in either the infrared or visual spectrum, and have either a wide or narrow field of view. The aircraft can capture both infrared and regular images at the same time. The system will be responsible for differentiating between regular and infrared. The system will not be responsible for differentiating between images with narrow or wide fields of view.

3.4.1 Visual

3.4.1.1 Description and Priority

The system shall contain a panel that displays the pictures taken at that point in time. The images displayed shall be determined by the STANAG data given to the system. Visual image files shall contain scans taken by the aircraft. Image files will be contained within the parsed STANAG data. This feature has a priority of Minor.

3.4.1.2 Stimulus/Response Sequence

User loads mission data extract.
System determines location and format of image data.
Ticks are added to Timeline denoting the start and end of the image scan.
User navigates to beginning of image scan.
Image scan is displayed.
User reaches end of image scan.
Image data is no longer displayed.

3.4.1.3 Functional Requirements

RMDS-40 Display Images from STANAG Data - The system shall be able to determine the locations of and load the image files contained within the parsed STANAG data.

3.5 Filters

Filters allow the user to control the volume or priority of rules to be displayed in various Panels, including the Timeline.

3.5.1 Task Start/End

3.5.1.1 Description and Priority

The system shall track the start and end time of configured aircraft tasks recorded in the data. These points shall be annotated with ticks on the timeline. This feature has a priority of Major.

3.5.1.2 Stimulus/Response Sequence

User loads mission extract data.
System loads filter configuration.
User enables “Tasks” filter.
System annotates task start and end with ticks on the timeline.

3.5.1.3 Functional Requirements

RMDS-43 Record Task Start Time - The system shall record the start time of every task it is configured to do.

RMDS-43 Record Task End Time - The system shall record the end time of every task it is configured to do.

3.5.2 Scan Start/End

3.5.2.1 Description and Priority

The system shall note when a scan has started and ended.These points shall be annotated with ticks on the timeline. This feature has a priority of Major.

3.5.2.2 Stimulus/Response Sequence

User loads mission extract data.
System loads filter configuration.
User enables “Scans” filter.
System annotates start and end of the scan with ticks on the timeline.

3.5.2.3 Functional Requirements

RMDS-44 Record Scan Start Time - The system shall record the start time of every scan it is configured to do.

RMDS-44 Record Scan End Time - The system shall record the end time of every scan it is configured to do.

3.5.3 Enable / Disable Filters

3.5.3.1 Description and Priority

The system shall allow for a user to enable or disable filters that are set by the rules and the pod. This feature has a priority of Minor.

3.5.3.2 Stimulus/Response Sequence

User loads mission extract data.
Rules data is loaded and saved to rule data file(s).
System marks rules on the timeline.
User chooses to filter all data but high priority errors.
System hides all ticks on timeline that are not high priority errors.

3.5.3.3 Functional Requirements

RMDS-35 FIlter on Criticality - The system shall allow the user to filter data based on criticality. The filter system will have a low - medium - high scale.

RMDS-173 - Filter by Rule - The system shall allow the user to filter data based on a rule. Rules can have multiple filters associated with them. The system shall allow a one to many filter to rule association.

3.5.3 Filter Criteria

3.5.3.1 Description and Priority

The system shall be able to filter errors generated based on their severity or regex. The severity of each error shall be determined by the rules. This feature has a priority of Minor.

3.5.3.2 Stimulus/Response Sequence

User loads mission extract data.
Rules data is loaded and saved to rule data file(s).
System marks rules on the timeline.
User selects to filter out minimal and moderate errors.
System only displays data for errors marked as high.

3.5.3.3 Functional Requirements

RMDS-45: Rule Filtering - The system shall allow the user to filter rules based on the severity or regex.

3.6 Flight Path Analysis

3.6.1 Graph Flight Data

3.6.1.1 Description and Priority

The system shall present the user with the mission flight analysis data. The data will be presented in a graphical display generated through NASA’s WorldWind software. The user shall be able to rotate the graphical representation. This feature has a priority of Critical.

3.6.1.2 Stimulus/Response Sequence

User loads mission extract data.
Rules data is loaded and saved to rule data file(s).
User displays Worldwind Panel.
System displays graphical representation of flight data.

3.6.1.3 Functional Requirements

RMDS-174 - Graphical Representation of Flight Data - The system shall interpret all gathered flight data and display it in a graphical representation created by WorldWind.

RMDS-175- Overhead Graphical Display- The system shall allow the user to view an overhead interpretation of the flight data.

RMDS-49 Graphical Display Manipulation - The system shall allow the user to manipulate the displayed flight data. User shall be able to view flight data from different angles. User shall be able to rotate the flight data display.

3.7 Panel Display

3.7.1 Hide and Show Panel

3.7.1.1 Description and Priority

The system shall allow the user to hide or show panels. Panels that are hidden shall still continue with required calculations. This feature has a priority of Critical.

3.7.1.2 Stimulus/Response Sequence

User loads mission extract data.
Rules data is loaded and saved to rule data file(s).
User choses to hide a Panel.
System hides Panel UI from user.
User choses to show Panel.
System makes Panel UI visible to user.

3.7.1.3 Functional Requirements

RMDS-176 Store Panel Dimensions - Hidden panels that are made visible to the user shall have the same dimensions as they did when they were hidden.

RMDS-177 Update Required Hidden UI - Some hidden panels will have data that will have to be updated continuously throughout the mission playback. Hidden panels that are made visible shall contain up to date mission data.

3.7.2 Organize Panels

3.7.2.1 Description and Priority

The system shall allow the user to organize the displayed panels in some coherent fashion. Panels shall be resizable and movable. This feature has a priority of Critical.

3.7.2.2 Stimulus/Response Sequence

User loads mission extract data.
Rules data is loaded and saved to rule data file(s).
User moves a Panel to left corner of screen.
System guides Panel to top left corner of screen.
User shrinks the Panel’s width by 50%.
System shrinks Panel display by 50%.

3.7.2.3 Functional Requirements

RMDS-178 Panel Movement - Panels will have a drag and drop interface. The user shall be able to drag any panel into a position on the screen.

RMDS-179 Multiple Panel Overlap - The system shall allow for multiple panels to overlap.

RMDS-180 Panel Sizing - The system shall allow the user to edit the height and width of each panel.

3.7.4 Save Panel State

3.7.4.1 Description and Priority

The system shall allow the user to save its state. The system shall save all panel data and display information. The user can then exit the program, restart it, and reload the mission at the saved state. This feature has a priority of Minor.

3.7.4.2 Stimulus/Response Sequence

User loads mission extract data.
Rules data is loaded and saved to rule data file(s).
User navigates chronologically through mission.
(Optional) User makes annotations at a given mission time.
System saves mission time, state, and notes.
User exits mission and reloads the saved state.
System reloads mission data and panel orientation and displays the mission playback to the user starting at the saved state.

3.7.4.3 Functional Requirements

RMDS-181 Save Panel Data State- The system shall store the state of all panel data. When the mission is reopened the panel data will be displayed at the saved state.

RMDS-176 Store Panel Dimensions - Dimensions of the panels of the reloaded mission will the the same as those of the saved state. Hidden panels will remain hidden.

RMDS-182 Store Panel Locations - Locations of the panels of the reloaded mission will the the same as those of the saved state.

RMDS-33 Save Current Mission Time - The system shall store the state of all panel data. When the mission is reopened the panel data will be displayed at the saved state.

3.7.5 System Menu

3.7.5.1 Description and Priority

The system shall have a system menu which allows users to perform system tasks, such as exiting or minimizing the system or non-panel mission related tasks. This feature has a priority of Critical.

3.7.5.2 Stimulus/Response Sequence

User starts application.
System starts.
System displays system menu.
User interacts with system menu.

3.7.5.3 Functional Requirements

RMDS-25 Menu & Context displayed in GUI: The system shall display the system menu and context within the GUI.This menu will allow users to exit the application, minimize the application, load new applications, and generate error reports.

3.8 Panels

3.8.1 Rules Panel

3.8.1.1 Description and Priority

The system shall have a panel which displays the rules data associated with the current mission. This feature has a priority of Critical.

3.8.1.2 Stimulus/Response Sequence

User loads mission extract data.
Rules data is loaded and saved to rule data file(s).
User displays Rules Panel
System displays Rules Panel UI to the user.

3.8.1.3 Functional Requirements

RMDS-26 Rules Displayed in Panel - The system shall display a list of rules in the rules panel.

3.9 Multiple Data Input Support

The system shall be designed to accept input from multiple data formats. The system shall be delivered with one input method implemented using the provided STANAG mission data extractor output format. The UTAS team is responsible for implementing any additional functionality.

4 External Interface Requirements

4.1 User Interfaces

All users

Users shall select a mission data file to load at system start. The system shall be designed to support modification by UTAS to load a file without forcing a user prompt.

The user interface shall be modular and display data in separate panels.

The user shall be able to select which panels they want to be displayed.

The user shall be able to choose the location to attach their panels to.

The user shall be able to playback a mission and view selected panels as time progresses.

The user shall be able to save an analysis session and reload it at the exact point of saving.

4.2 Hardware Interfaces

The system shall not interface directly with any mission hardware component. The system may interact with files on the filesystem created by mission hardware but shall not be required to initiate a connection with the hardware.

4.3 Software Interfaces

The system shall parse mission data from a specific file format containing a hierarchy of text files and folders. The team will be given a parser by the UTAS Software Development team. This tool will parse each mission’s STANAG data, and place it in a local folder. The team will be given documentation through Andy via phone and email concerning the files, data columns, and what they represent.The system shall support future modification to parse other data input formats but actual implementation is not required.

5 Other Nonfunctional Requirements

5.1 Performance Requirements

Performance guidelines are flexible, and performance may vary based on the contents and size of the mission data file. The time to parse a mission data file from the launch of the system shall not exceed 15 minutes with a goal of 5 minutes. The time it takes for win_extract.exe to be completed will not be added in this time contingency.The time is takes to reopen a saved state shall not exceed 5 minutes with a goal of about 2 minutes.

5.2 Software Quality Attributes

5.2.1 Correctness

As RMDS shall be used to support military operations, any information it provides shall be accurate. To measure the correctness of the program, the team will note the number of violations and errors generated / number of caught violations. This metric will be harder to calculate, as it may be difficult to determine the accuracy of the test results. The team will also collect pod generated error / number of pod generated errors detected data.

5.2.2 Modifiability

Modifiability shall be critical for UTC Aerospace and other operators to adapt the software to changing needs and requirements. The architecture of the RMDS shall be designed as to allow the program to have a moderately high level of modifiability. The panels shall each be interchangeable allowing for new panels displaying different data to be developed by the UTAS development team. The framework shall be designed to be modifiable.

6 Glossary

Term	Definition
DB-110	A dual-band high and low to medium altitude day/night capable airborne reconnaissance system.
Field Service Representative (FSR)	In-country point of contact; on-location techs who perform onboard repair or otherwise provide support
Mission	The series of events in which data is STANAG data is collected. Missions have a defined start and end time.
Mission Hardware	The DB-110 reconnaissance pod, or any other hardware which provides mission data.
Mission Time	The timestamp of the current mission which is being viewed in the system.
Output Report	Report generated by the system. Report shall consist of system and STANAG data.
RMDS	Reconnaissance Mission Debrief System
Software/Systems/Chief Engineer	Support flight tests and/or in-country operations.
Tick	An error note displayed on the timeline of the system.
Shall	A statement that can be verified and trackable.
Will	A statement of fact.
Panel	A Panel is a single window in the program that will be used to display important mission related data, filters/user selectable tasks regarding mission data, or other features which will be used to determine the flow and display of mission data. .
Priority	Priority values are the same as those in Jira. Scale is as follows: Blocker -> Critical -> Major -> Minor -> Trivial