From 51ed99e59e83f6bba4aac308817a47905b9fa332 Mon Sep 17 00:00:00 2001
From: Harsh Raj <harshraj22aug@gmail.com>
Date: Mon, 12 Oct 2020 16:21:58 +0530
Subject: [PATCH] added srs doc

---
 SRS_Template.md | 68 -------------------------------------------------
 SRS_document.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 66 insertions(+), 68 deletions(-)
 delete mode 100644 SRS_Template.md
 create mode 100644 SRS_document.md

diff --git a/SRS_Template.md b/SRS_Template.md
deleted file mode 100644
index 64b5c6d..0000000
--- a/SRS_Template.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# Requirements Specification # 
-<b>for</b>
-## Project Name ##
-<b>prepared by:</b>
-## 
-* Author 1
-##
-
-<b> Date: <b>
-
-### Table of Contents ###
-- [Introduction](#Introduction)
-  - [Purpose](#Purpose)
-  - [Scope](#Scope)
-- [User Requirements](#user-requirements)
-  - [Software Interfaces](#software-interfaces)
-  - [User Interfaces](#user-interfaces)
-  - [User Characteristics](#user-characteristics)
-- [System Requirements](#system-requirements)
-  - [Functional Requirements](#functional-requirements)
-  - [Non-Functional Requirements](#non-functional-requirements)
-  
-### Introduction ###
-#### Purpose ####
-  Describe the purpose of the product, whose software requirements are specified in this document. Specify the intended audience and mention the overall scope of the product if this product is part of a bigger system.
-#### Scope ####
-  <Identify the product by its name e.g. Video Player. Explain the applications of this product. Be specific while doing so. As part of this, write goals and benefits of this product, relate the product to overall goals, and summarize the features. >
-
-### User Requirements ###
-#### Software Interfaces ####
-  <Describe the connections between this product and other specific software components (name and version), including databases, operating systems, tools, libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Refer to documents that describe detailed application programming interface protocols. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way (for example, use of a global data area in a multitasking operating system), specify this as an implementation constraint. See section 6.3.1.5.3 of the reference doc. for further reading.>
-#### User Interfaces ####
-  <Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification. See section 6.3.1.5.1 of the reference doc. for further reading.>
-#### User Characteristics ####
-  <Identify the various user categories that you anticipate will use this product. Some of these are users, operators, and maintenance personnel. Identify constraints that pose (based on expertise level / role of the user). E.g. user categories may be differentiated based on frequency of use, subset of product functions / features used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user category. Certain requirements may pertain only to certain user categories. Distinguish the most important user categories for this product from those who are less important to satisfy. See section 6.2. 3 of the reference doc. for further reading.>
-  
- ### System Requirements ###
- #### Functional Requirements ####
- <Tabulate system features. For each feature, provide the details of:
-     * Description and Priority	
-	     <Provide a short description of the feature and indicate whether it is of High, Medium, or Low priority. You may optionally include specific priority component ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).>
-     * Stimulus and Response Sequences
-	     <List the sequences of user actions and system responses that stimulate the behavior defined for this feature. These will correspond to the dialog elements associated with use cases.>
-     * Feature Requirements
-	     <Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary information is not yet available. See section 6.3.1.1 of the reference doc. for further reading.>
-	  	 <Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind.>
-        E.g.
- 
-| Req#  				| Requirement		| Comment						| Priority |
-| --------------------- |:---------------------:|:-----------------------------:|:-----:| 
-| REQ_1 | detailed requirement of feature1 | some comment | high
-| REQ_2 | detailed requirement of feature2 | some comment | low
-
-#### Non-Functional Requirements ####
-  <Identify Performance, Safety, Security, Quality, and Other requirements, See section 6.3.1.5.3 of the reference doc. for further reading.>:
-
-  <If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features.>
-
-  <Specify those requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define any safeguards or actions that must be taken, as well as actions that must be prevented. Refer to any external policies or regulations that state safety issues that affect the product’s design or use. Define any safety certifications that must be satisfied.>
-
-  <Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication requirements. Refer to any external policies or regulations containing security issues that affect the product. Define any security or privacy certifications that must be satisfied.>
-
-  <Specify any additional quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning.>
-
-  <List any operating principles about the product, such as which individuals or roles can perform which functions under specific circumstances. These are not functional requirements in themselves, but they may imply certain functional requirements to enforce the rules.>
-
-
-
diff --git a/SRS_document.md b/SRS_document.md
new file mode 100644
index 0000000..a069c03
--- /dev/null
+++ b/SRS_document.md
@@ -0,0 +1,66 @@
+# Requirements Specification # 
+<b>for</b>
+## Project Name ##
+<b>prepared by:</b>
+## 
+* Manjeet Kapil (180010021)
+* Harsh Raj (180010017)
+* Shriram Ghadge (180010015)
+* Rupesh Kalantre (180010029)
+##
+
+<b> Date: <b>
+
+### Table of Contents ###
+- [Introduction](#Introduction)
+  - [Purpose](#Purpose)
+  - [Scope](#Scope)
+- [User Requirements](#user-requirements)
+  - [Software Interfaces](#software-interfaces)
+  - [User Interfaces](#user-interfaces)
+  - [User Characteristics](#user-characteristics)
+- [System Requirements](#system-requirements)
+  - [Functional Requirements](#functional-requirements)
+  - [Non-Functional Requirements](#non-functional-requirements)
+
+
+### Introduction ###
+#### Purpose ####
+  The product (or say tool) to be developed is meant for the students of the nearby university. The instructor wants to help the students in the essays they write by improving their writing style.
+#### Scope ####
+  The product would be identified by `Command Line Java based tool`. The students would use this tool to cross check the essays they write. This would make them aware of the long sentences and improve their writing style.
+
+### User Requirements ###
+#### Software Interfaces ####
+  The tool would be a tool written in Java, similar to `ping` utility, that comes pre-installed in Ubuntu operating system, and can be accessed via terminal. It would use the java libraries (and JDK will be a software requirement) and the user would be expected to have java installed on their system (the details to install would be provided in the documentation). We would also need a terminal (or its alternative) to talk with the operating system. <br>
+  OS, Java SDK (JDK and JRE), Command Prompt, File System,  <br>
+  Constraints: requires libraries that read files containing textual data <br>
+#### User Interfaces #### 
+  The product will be used via command line. Students will have to run the tool via command line, providing the path to text file that contains their essays, as a command line argument. The script will evaluate the essay and print the required messages/ errors on the screen. So, say for example, if the user provides faulty path (i.e. no text file exists), some error message will be displayed, stating there doesn't exists any such file. Similar messages will be displayed in case the writing standards dont match the expected standards. <br>
+  User will provide file path as input <br>
+  User will provide various arguments as input (optional) <br>
+   &nbsp;delimiter <br>
+   &nbsp;default word length <br>
+  User should see the output on the console <br>
+
+#### User Characteristics ####
+  The students of the university will be its users. It will be made such that large audience (ranging from students having no computer knowledge, to proficient ones) can use it.
+  
+ ### System Requirements ###
+ #### Functional Requirements ####
+  * Description and Priority:          
+    It would help students improve their essay writing by keeping track of the length of sentences they write. The tool would take path to their essay text file as a command line argument, and output the required messages that could improve their writing. This would be the highest proirity of the tool. 
+  * Stimulus and Response Sequences:              
+    The user would check the essays by providing the path to the text files containing essays, as command line argument to the tool. The tool would then try to read the text file (if exists) and evaluate the sentences lenght. If the file doesn't exists, the tool will terminate printing message on screen about non availability of file, else the tool will print the details of evaluation of the essay.
+  * Feature Requirements:         
+    If the user inputs wrong file path (ie. no text file exists at the provided path), the tool would exit, printing message on user screen about non-availability of such file. 
+ 
+| Req#  				| Requirement		| Comment						| Priority |
+| --------------------- |:---------------------:|:-----------------------------:|:-----:| 
+| REQ1 | To be able to find the long words from the essay and notify user via prompt on terminal screen. | User knows how many sentences are too long | high |
+| REQ2 | To be able to adjust number of words instructor allows as an acceptable sentence. | NA | high |
+| REQ3 | To be able to adjust instructors preferences as what symbol should be considered as end of sentences. | From a given set of options, instructor selects as what is favourable. | high |
+| REQ4 | Output the appropriate messages (error message in case of faults) | User will understand what went wrong | high |
+
+#### Non-Functional Requirements ####
+  User should not edit/ alter the code base of command line tool. Changing the code, without understanding might have hazardous consequences when run, ranging from displaying faulty messages to completely erasing files from the machine.