Essay: Team Software Requirements Specification Report

CE201 Team Software Requirements Specification Report
Team: 35
1 Introduction
Purpose (Bradley)
The purpose of this SRS is to provide an unambiguous guide that indicates exactly what our software product is and what it does. It will feature sub-sections such as functional requirements, which will define exactly what our product must do in order to be considered a success.
It will also contain details of the non-functional requirements, which will be crucial during the testing of the product to ensure the product meets the expectations of the client. It will also feature a constraints sub-section to indicate any restrictions that may be crucial to consider during the design phase of the products development.
Overall, this SRS should provide clarity of the products requirements, both for the client to sign off and agree to and for the development team to ensure the product they deliver satisfies the client’s requests. It is also useful for the testers in the testing phase to be able to correctly check if an aspect of the product satisfies a requirement.
Scope (Joe)
The UK Power-Generation Viewer is a software package, which will provide the department for energy and climate change (DECC) with a tool to view and perform analysis about the United Kingdom’s power generation sources. The client intends on using the software for not only viewing the country’s energy supply but to help with the planning of the UK’s future power plants.
As the client desires the program to be able to output a report which shows current power sources and consumption over different time periods. This highlights the importance for the program to be functional (providing reports for future projects) and be able to display the current energy supply in an easy to ready format.
The software will be available to different members of staff at the DECC thus the software needs to be easy to navigate and responsive (most actions must take less than two seconds). Users are able to upload a Comma Separated Values (CSV) from their local machine to provide the data, which the software will read. This data will be displayed using a variety of graphs, which will give users a visual overview of the inputted data. Moreover, this data is able to be viewed in a report, which can be exported in a Portable Document Format (PDF) file.
The software will also provide DECC staff with an estimate on the countries future usage which will be based on the current data source. Furthermore, the software should be able to highlight outliers in the data sort such a drop-in demand or a spike in energy usage.
Definitions, acronyms, and abbreviations (Everyone)
Term Definition
Product The software deliverable as requested by the Client
User Someone who interacts with the software application.
DECC Department for Energy and Climate Change
CSV file Series of data where each line represents a ‘record’ and each record of data is made up of a number of elements separated by commas or another specified delimiter such as a pipe character ‘|’
PDF Portable Document Format
Client, (See DECC) Employee from the DECC
Java A high-level Object Orientated Programming language
GUI Graphical User Interface
SVN Subversion source control system.
JAR file Java Archive format.
SMART criteria Acronym for Specific, Measurable, Achievable, Relevant and Time-bound.
SPECIFIC Must unambiguously define the requirement.
MEASURABLE The requirement must be able to be determined to meet the SPECIFIC requirement(s).
ACHIEVABLE Possible to complete within the given constraints.
REALISTIC Can be done with the available resources.
TIME-BOUND The requirement must be attainable within a given time frame or by a specific date.
Local Machine The computer the user is currently using
FR Function requirement
NFR Non-functional requirement.
Overview (Adam-Ryan)
The remaining sections of the Software Requirement Specification are split into 2 sections: the ‘Overall Description’ of the product and the ‘Specific Requirements’, the product needs to fulfil. The Overall Description of the product is categorized into 6 sub-sections: Product Perspective; Product Functions; User Characteristics; Constraints, Assumptions and Dependencies; Requirements Gathering Methodology and Requirements Modelling. The Specific Requirements are split into 3 sub-sections: User Interface & GUI Requirements; Functional Requirements and Non-Functional Requirements.
2 Overall description
Product Perspective (Sai)
This software is to provide the information for users to review the data on different types of energy. This software is coded using the Java programming language and a CSV file. The purpose of this software is to help users to analyse the type of energy usage data which selected by them, by providing a summary report with some graphs and charts.
An important aspect of the product being developed is its ability to be used by an unskilled employee of the DECC. To make this achievable the product will provide a graphical user interface (GUI), so that the user may use the system without prior knowledge of programming or use of a command line. Due to this, only some minimal training will be before the user can comfortably use the software.
The software will operate on a reasonably powerful computer. This is required as the CSV files will contain a large amount of data which needs to be loaded and analysed. In order for the data in the CSV to be used, it must first be imported into the program and stored in a suitable data structure. This will therefore require a substantial amount of memory (RAM) as these variables/objects will be stored on the heap.
One optional requirement of the system is the ability to load a CSV file that must first be retrieved from a file server which the user will provide the URL for. Therefore, for this requirement to operate, the user’s device (PC) must be connected to the internet or at least be on the same local network as the file server in order to locate the file.
Product Functions (Joe)
The main function of the software is to maximise staff utility at the DECC. This is implemented by producing an independent self-contained software package which will provide the staff firstly with a platform to perform analysis on UK’s power generation sources.
One of the core features of the software is the ability to visualise power generation data which can provided by the CSV file. The user is able to change the CSV file from which the data is read to another one on user’s local machine. This gives the software package a longer life span as the DECC is able to change the data file to the most recent version.
The software package is also able to provide staff with an easy-to-view overview of the data provided rather than having to read raw data in table form such as the CSV file. When data is visualised using a graph its more accessible for the user. Moreover, they are able to spot outliers in the data via a visual inspection rather than having to sift through the data in its raw format.
Furthermore, the software will be able to perform analysis on the data. The software will be able to highlight any outliers in the data and alert the user’s attention to this. As well as this, the software is able to calculate a prediction of the country’s energy demand and supply based on the current data input.
Finally, the client has specified the need for the software to output a report. This report will be available in a PDF format which allows the user to be able to select which data to include in the report and which type of graph is used to visualise the data. The program will supply the user with three graph types to choose from:
• Scatter Graph
• Bar Chart
• Pie Chart
The software is able to generate a graph type of the users choosing based on which type they select. This provides the user with many different ways to visualise the data and thus many reports can be generated from one data source.
User Characteristics (Sai)
There is only one type of user for this software which means everyone will have a same user interface. All users should have standard English language skills and computing skills. They would be trained how to use this software. Also, there will be a user guideline which is provided for them to check back for some certain skills in anytime. On the other hand, users will be able to use this software in any physical environment such as factory, home or office, etc providing the device used is in compliance with the memory constraints of the product.
Constraints, Assumptions and Dependencies (Myles)
The product is constrained by the language requirements requested by the client, the product must be implemented using Java and if at all possible refrain from using external Java libraries and attempt to implement as much as feasibly possible using the Java standard library. Use of third-party libraries for PDF export has been considered appropriate to use. The final product must compile to an executable JAR file. The source code must be stored in an SVN source control system.
Another constraint of the system is the amount of RAM available to the program. In order for the program to function as desired, the data in the CSV file will need to be stored as objects in an appropriate data structure. This will consume a large amount of computer memory as these objects will be stored on the heap.
One of the optional functional requirements of the system is the ability to retrieve a CSV file from a file server using a URL that is provided by the user. This hence, makes the assumption that the device the user is running the software product on has access to the internet, or at the very least the device is connected to the same local network.
It is also assumed that any file that the user attempts to load will be a CSV file structured the same as the previous energy data files. This structure requirement will be elaborated on further into the SRS, under the functional requirements section.
Assumptions will be made that the employee of the DECC using the software will be trained to correctly use the software. The product will depend on the use of a third-party library for PDF export functionality.
Requirements Gathering Methodology (Myles)
Considerations with gathering requirements has many strategies but the predominate strategies used to ascertain the specific requirements of the client. The core requirements were extracted by means of an informal interview with a representative of the DECC and questions in the document are included in appendix 2. Discussions regarding the answers to these questions form the basis for the requirements listed in section 3.
Building on the information provided by the interview, analysis of the provided CSV file and the data this makes available we can use this information to
 
Requirements Modelling: Use-case Diagram and Descriptions (Bradley)
Figure 1: System Use-case Diagram
 
Use-case Title Use-case Description
Open a new CSV file using a URL (OPTIONAL). 1. User: enters a URL into the provided text field.
2. User: presses ‘Apply’.
3. System: Searches for file.
4. System: Reports success or failure back to the user.
Open a new local CSV file using a file name. 1. User: enters a file name into the provided text field.
2. User: presses ‘Apply’.
3. System: Searches for file.
4. System: Reports success or failure back to the user.
Select current page view for export. 1. User: Presses ‘Export current page’.
2. System: Requests a file name.
3. User: Enters file name in text field or similar (e.g. JInputPane).
4. System: Exports data on current page as a PDF with the specified name to the local directory.
5. System: Reports success or failure back to the user.
Select all data included in the report for export. 1. User: Presses ‘Export entire current report’.
2. System: Requests a file name.
3. User: Enters file name in text field or similar (e.g. JInputPane).
4. System: Exports the all data currently included in the report as a PDF with the specified file name to the local directory.
5. System: Reports success or failure back to the user.
Select what data is included in the report. 1. User: Ticks a tick box labelled ‘include in report’ or similar.
2. System: Notes that this data is to be included in the report.
3. System: Box becomes ticked, highlighted, etc.
Select the graphical display of data. 1. User: Ticks boxes of the graphs/charts/diagrams that they wish to include in the report.
2. System: Notes the graphs/charts/diagrams to be used in the report.
3. System: Box becomes ticked, highlighted, etc.
Select type of analysis. (OPTIONAL) 1. User: Selects analysis type from a menu.
2. System: Changes analysis type preference.
Select to include future predictions in report. 1. User: Presses ‘Add Predictions’.
2. System: Generates and adds basic future prediction(s) to the report.
3. System: Reports success or failure back to the user.
View report on screen. 1. User: Navigates to ‘Report’ tab.
2. System: Shows report tab, hence, displaying the current report.
 
3 Specific Requirements
3.1 User Interface & GUI Requirements
The following section provides mock ups of the GUI. However, these are not reflective of the final product. They are only to show a very basic overview of the GUI and features that are similar to what will be included in the final product.
Choose File Pane Mock-up: (Bradley)
Figure 2: Choosing file mock-up
Choosing Graph Type Mock-up: (Joe)
The following diagrams are simple mock ups of the GUI which allows the user to select the type of graph to represent the data. This diagram shows radio buttons which generate its corresponding graph. These controls are only for example and the final software may include a different type of control, however the premise is the same.
Figure 3.1: User selecting pie chart
Figure 3.2: User selecting bar chart
 
Figure 3.3: User selecting scatter graph
Functional Requirements (Everyone)
This section will highlight the functional requirements of the software. These requirements are main functions of the system that must be included to produce a product which fulfils the requirements of the client.
ID: Functional Requirement 1 – Local File Change. (FR1) (Bradley)
Title: User must be able to change the local file being used.
Description:
• Specific: This feature will allow the user to update the csv file that they wish to analyse by providing the name of a file in the local directory. This will prolong the life of the program as more recent versions of the energy report can be used.
• Measurable: An option will appear on the main GUI frame which will take the file name of the file to be opened. If the current file was changed, a success or failure message will be displayed i.e. through a JOptionPane.
• Achievable: This requirement of the system will require exception handling if the file cannot be found. It will also be required to validate the file being opened if a file is found. This is because the file is assumed to be structured like the previous files being used, therefore if the file structure is different an error message will be displayed. This type of exception handling is easily achieved in java, hence achievable within the constraints.
• Realistic: This function of the system will be relatively easy to implement and only the standard java API will be required for implementation.
• Time-bound: This aspect of the system will be one of the first features to be implemented. This forms the base for all further data processing, such as: data analysis and data reporting. It will be implemented within the first week.
ID: (OPTIONAL) Functional Requirement 1.1 – File Change Via URL. (FR1.1) (Bradley)
Title: Users can change the file being used using a URL to indicate the file location.
Description:
• Specific: This feature will allow the user to update the csv file that they wish to analyse by providing a URL to indicate the file location i.e. on a file server.
• Measurable: If this feature is implemented then FR1 will be extended to take a URL from the user, download the file and process it as usual. The user will see a label that indicates a URL can be used, such as “Enter a local file name OR URL:”.
• Achievable: Providing the file can be downloaded and is structured as expected then the processing of the file will be the same as that performed in FR1.
• Realistic: The retrieval of the file via URL will be similar to retrieving a local file. Once the file is retrieved, all further processing will be the same as FR1 and will hence, only require the standard java API.
• Time-bound: As this is an optional feature, it may not be implemented at all in the final product. However, if this feature is implemented then it will be done either at the beginning alongside FR1 or at the end if time permits.
ID: Functional Requirement 2 – Import CSV file data. (FR2) (Myles)
Title: The software must be able to open a CSV file specified by the user, load the data and parse it into a data format that can be manipulated by Java and by the extension software.
Description:
• Specific: The software must be able to load data from a CSV file and parse this data into the system. The CSV file must follow the correct format defined below with example data and data types. The CSV file must use a comma as a delimiter.
Field Data Type Example Data Notes
id Integer 520760
timestamp DateTime 2016-05-13 22:30:02 Format is YYYY-MM-DD HH:mm:ss
demand Integer 25837 The total demand of the entire country including an estimate for solar and excluding unmetered wind generation.
frequency Double 49.987999 UK power grid is controlled to be at 50Hz alternating current (AC) but varies depending on demand. By lowering the frequency and voltage the demand can be reduced slightly.
coal Integer 0
nuclear Integer 6745 Currently the UK has seven Advanced Gas-cooled Reactor (AGR) designs and one relatively modern Pressurized water reactor (PWR). Nuclear power stations are run flat-out to maximise income. Since the cost of fuel is almost insignificant, it pays them to sell at any price they can get.
ccgt Integer 11522 Combined cycle gas turbines
wind Integer 2819 Only metered wind generation is included.
french_ict Integer 1998 2GW bi-directional French interconnector link between the UK and France.
dutch_ict Integer 502 1GW bi-directional BritNed interconnector link between the UK and the Netherlands.
irish_ict Integer 162 0.5GW bi-directional Moyle interconnector link between Scotland and Norther Ireland.
ew_ict Integer -126 0.5GW bi-directional East-West interconnector from Wales to Southern Ireland.
pumped Integer 155 Hydro-electric power where excess power usage is used to pump water back up into the reservoir. Quickly runs out but only used to cover peak demand usage & sudden spikes.
hydro Integer 135 The UK only generates minor hydroelectric power due a limited number of small power stations.
oil Integer 0 Oil power stations
ocgt Integer 0 Open Cycle Gas Turbines (OCGT), are gas turbines without steam plant to maximise their efficiency.
other Integer 2053 Any other power generation not covered by other fields.
solar Double 0 This is an Estimated value as no solar power in the UK is metered centrally to provide accurate real-time figures.
biomass Number 2065 Power generated by natural bio-matter based fuels or stations that qualify as renewable, such as Drax 2.
*ICT power is a bi-directional link importing when power is positive & negative power is exported.
**All energy usage is in Giga Watts unless other units are explicitly stated
• Measurable: The file format must be met otherwise the data parsing process will fail, only valid file formats will be successfully parsed. A suitable error will otherwise be provided.
• Achievable: Parsing CSV data from a file into a Java data structure is an achievable goal using the Java standard libraries.
• Realistic: Given the constraints, parsing CSV data is a realistic and necessary requirement of the system and without the ability to import data into the system no data processing is possible.
• Time-Bound: This feature will be implemented very early in the development cycle as parsing the data into a format where Java can manipulate the data is necessary for a large majority of the remaining requirements.
ID: Functional Requirement 3 – Export Report as PDF (FR3) (Leo)
Title: Users will be able to export the report generated by the program as a PDF file.
Description:
• Specific: This will enable the user to save the report generated by the program as a PDF at the click of a JButton or similar. This feature will be available once the data analysis process has finished and the report has been presented in the GUI.
• Measurable: The feature should not take too long to accomplish, as there are multiple existing resources / information on exporting PDFs. When completed, this is easily testable as a successful PDF export would be a simple “screenshot” of the report. A message indicating success or failure will also be presented to the user.
• Achievable: As mentioned earlier, the feature should not require a large amount of time. There are multiple libraries for java which enable the use of exporting PDFs. Although a third-party library is to be used, this feature is still to be implemented in java.
• Realistic: As this function is only available once the report is generated (which is another function that is only available once other tasks are completed), this should be fairly simple to implement.
• Time-Bound: The export PDF function will be one of the final features to be implemented. It requires the majority or at the very least the core features to have already been completed. As such, time restrictions are not a necessity for this but will likely be towards the end of the development lifecycle.
ID: (OPTIONAL) Functional Requirement 3.1 – Export Current Window as PDF (FR3.1) (Leo)
Title: Users will be able to export the current screen as a PDF:
Description:
• Specific: This will enable the user to save the current screen as a PDF at the click of a J Button. This feature will be available on every page.
• Measurable: If the Export Report as PDF (FR2) is completed, this activity will be finished very fast. There will be a need for code on each button, but most of the code will be duplicated and the majority of the code will be very similar to the Export Report as PDF (FR2) button.
• Achievable: Although this feature will require multiple buttons, the code will be reused in most of them. This makes quantity a non-issue and testing should be extremely simple similarly to FR2.
• Realistic: With so much resemblance to the Export Report as PDF (FR2), exporting the current window should not cause any problems if FR2 has no issues.
• Time-Bound: The Export Current Window as PDF will be one of the final features to be implemented. However, unlike FR2, these buttons do not require the majority of the project to be completed and could be made alongside FR2 or as tests before implementing FR2.
ID: Functional Requirement 4 – Select Data for Report. (FR4) (Joe)
Title: User has the ability to select what data to include in the report:
Description:
• Specific: The user will be able to select which data to include in the report. For user can select by source region or by power source category.
• Measurable: The options to select data source will be available during execution of the software. The data show on the group will be consistent with the options selected by the user.
• Achievable: Once the ability to draw graphs from the data has been implemented it this feature will be implemented without any constraints.
• Realistic: Java Swing has classes and methods which provide radio buttons, menus and, tabs which can be used to select the data.
• Time-Bound: This feature should be implemented around halfway through development as the ability to draw graphs from the data needs to be implemented beforehand.
ID: Functional Requirement 5 – Multiple Types of Graphs. (FR5) (Joe)
Title: User is able to select in which type of graph the data is shown
Description:
• Specific: The user should be able to select which type of graph they would like the data is be displayed as.
• Measurable: The user will be presented with three default graphic options. Scatter Graph, Pie Chart and Bar Chart.
• Achievable: This requirement is possible to implement into the system as it do not clash with any of the constraints highlighted in section 2.4.
• Realistic: This requirement is able to be implemented using the standard Java API libraries. For example, Java Swing has a JRadioButton class which could be used to select which graph the user wishes to use.
• Time-Bound: This feature will be implemented once the software is able to draw the graphs and the data is able to be analysed.
ID: (OPTIONAL) Functional Requirement 6 – Type of analysis from selected data types (FR6) (SAI)
Title: User can select a certain the type of analysis which is based on selected data types.
Description:
• Specific: Once the user selected the data types which they want to include in the report. They might be also able to select the type of data analysis, such as check trends of usage on target or predictions for data usage in the future.
• Measurable: There will be a selecting button for the user to select the type of analysis which they want it. If they wish to add more types of analysis provided by the software, there will be a button for them to add more to be processed.
• Achievable: By calculating the trend which increases or decreases in the past, the software will be able be to use it to predict the data trend in the future. This is only maths based and is achievable within the constraint on implementation; using Java.
• Realistic: Java Swing will provide all the button for this feature. Trend analysis can be done by implementing a trend formula to calculate the trend line which can be displayed on the bar graph or scatter diagram. Based on the trend line, a general analysis can be produced.
• Time-bound: as this function is based on selected data types which is FR3, therefore, this can be implement with FR3 together or after it.
(There could be some optional advance predictions which relate to the actual society, for example, compare the energy usage trend with the population of UK. This means that it will be required some extra information from a third party).
ID: Functional Requirement 7 – Future Predictions (FR7) (Bradley)
Title: [One of our products Unique Selling Points (USPs)] The user is able to view a BASIC prediction of the state of energy generation-to-usage in the future using previous trends.
Description:
• Specific: The user will be able to request a basic prediction of the demand-supply amount in 1 years’ time. This prediction will use previous data to calculate an average increase in energy consumption and then predicts the demand-supply amount at the end of the following year. The prediction will be displayed to the user on the current pane. It will also provide recommendations based on the result, such as: 3 more wind turbines will satisfy the energy deficit.
• Measurable: A JButton or similar will be provided on one of the system’s data reporting tabs. This button will allow the user to request this functionality of the system.
• Achievable: The most complex aspect with implementing this feature is the mathematics required to calculate the predictions. This is however, independent of the programming language being used and is compliant with the identified constraints of the system i.e. must be programmed in Java.
• Realistic: The ‘Math’ Java package can be used to provide additional tools for calculating the prediction. This package is part of the Java SE API.
• Time-bound: These predictions can only be made once the data has been loaded into the program and analysed. Therefore, this feature will have to be implemented after the data loading and analysis stages. This will be approximately the end of week 3 of implementation.
Non-Functional Requirements (Everyone)
ID: Non-Functional Requirement 1 – Local File Change in Under 2 Seconds. (NFR1) (Bradley)
Title: When a user requests the use of a different local file, the file should be located, opened, imported and closed within 2 seconds of the button being pressed.
Description:
• Specific: Once the user presses the button to apply the file change, the system should locate the file, open the file, transfer the data from the file into the chosen data structure and then close the file.
• Measurable: The process described above will be completed and a success or failure message displayed to the user within 2 seconds of the apply button being pressed.
• Achievable: Given the processing power of modern machines, as long as efficiency is considered while implementing FR1 the whole process could be completed in under 1 second, should be completed in under 1.5 seconds and must be completed in under 2 seconds.
• Realistic: 2 second is more than reasonable for the machine to process the file given the power of modern machines.
• Time-bound: Given that efficiency is considered when implementing FR1, which is at the beginning of the implementation, this requirement will in turn be satisfied. Hence, being completed in the first week of implementation.
ID: (OPTIONAL) Non-Functional Requirement 1.1 –File Change Via URL in Under 5 Seconds. (NFR1.1) (Bradley)
Title: When a user requests the use of a different file via URL, the file should be located, downloaded, opened, imported and closed within 5 seconds of the button being pressed.
Description:
• Specific: Once the user presses the button to apply the file change, the system should locate, download, and open the file. It should then transfer the data from the file into the chosen data structure and then close the file.
• Measurable: The process described above will be completed and a success or failure message displayed to the user within 5 seconds of the apply button being pressed (time can be expected to vary depending on the user’s internet speed).
• Achievable: As this extends NFR1, the time increase of 3 second (from 2 to 5) is to compensate for the time to connect to the server and download the file. Given the expected size of the csv file and the current average internet speed, the file retrieval could take less than 2 seconds, should take less than 2.5 seconds and must take less than 3 seconds.
• Realistic: 3 seconds, given the size of the file and expected internet speed, is reasonable for the file to be downloaded.
• Time-bound: As this is an optional non-functional requirement that coincides with FR1.1, this feature may not be implemented. However, if this feature is implemented then it will be implemented as part of FR1.1 which, if implemented, will be completed at the very beginning or after all other features.
ID: Non-Functional Requirements 2 – Generating/Displaying Graphical items within 2 seconds (NFR2) (Adam-Ryan)
Title: Any graphics should be displayed to the user within a maximum time of 2 seconds
Description:
• Specific: The graphical items (graphs, charts, etc.) should be displayed onto the screen, to the user within 2 seconds.
• Measurable: The graphical items will be displayed on the GUI once the graphical item is selected.
• Achievable: The standard library within Java offers notable tools to implement this feature.
• Realistic: Considering the computation power of current computer systems and applying good programming practices and mindfulness/awareness of the Space/Time complexity of the algorithms used.
• Time Bound: This can only be achieved once the data storage and analysis parts are completed. This feature should be finished by week 3.
ID: Non-Functional Requirement 3 – Produce Predictions Within 2 seconds (NFR3) (Bradley)
Title: If the user requests a basic prediction using FR6, then the prediction should be calculated and displayed to the user on the current pane within 2 seconds.
Description:
• Specific: the process of calculating the prediction and displaying the result on the current pane will be completed in 2 seconds or less.
• Measurable: Once the button for requesting a prediction is pressed, the details of the result will be displayed on the current tab for the user to see.
• Achievable: Java is an efficient programming language and is capable of processing simple equations and algorithms quickly. Therefore, the constraint of using java is not an issue.
• Realistic: 2 seconds is a reasonable time for a program to calculate a result using basic equations.
• Time-bound: This will be achieved indirectly from the efficient implementation of the predictions requirement, FR6. Therefore, this will be achieved at the same time as FR6; the end of week 3.
ID: Non-Functional Requirement 4- The system will take no longer than 2 seconds to generate and export a PDF report (NFR4) (Adam-Ryan)
Title: The system should produce and export the PDF reports within 2 seconds
Description:
• Specific: The PDF of the report should be compiled by the data obtained through data analysis and reporting stages. The PDF will then be uploaded to the user’s local directory. This process should be completed within 2 seconds.
• Measurable: A button (or something similar) to “Export to PDF” will be shown on the Graphical User Interface (GUI) tab.
• Achievable: Java’s third-party libraries can be used to achieve this, which is not affected by any of the identified constraints
• Realistic: Java’s basic API does not provide the relevant tools/aids to implement this feature, but free, open sourced packages are available to provide these tools.
• Time-bound: The feature will be added once all the data analysis and reporting is finished, therefore this feature will be included during week 5.
ID:  Non-Functional Requirement 5 – Accurate Data Conversion (NFR5) (Leo)
Title: When the CSV is uploaded and data is gathered, there will be no added data and no missing data.
Description:
• Specific: During the conversion of the raw CSV data to readable information, there could be erroneous code which might return wrong information. This would spell disaster for the program as information accuracy is extremely vital for our product.
• Measurable: The accuracy of the data must be 100%, a single percent of wrong data could potentially cost an enormous amount of time / resources to the customer.  Testing will be vigorous and constant through all stages of the project.
• Achievable: The project’s team consists of 6 skilled programmers and as such resources are abundant for this requirement. Once the information has been converted, the only potential issue is time invested. However, it is very unlikely that this activity would be time expensive.
• Realistic: Referring to the previous point – importance, the completion of this functional requirement is critical. Regardless of this possibly taking a long time and work-power to accomplish or not, it is necessary to be completed by the end.
• Time-Bound: Although the program’s finalization demands the completion of this requirement, it does not necessarily need to be implemented until the end. Most of the features could be tested and functional with inaccurate data, and the accuracy of the data conversion could possibly be easier to test towards the end (compare data with charts / graphs). However, this requirement will most likely be successful when the data conversion is implemented.