SRS

Project Plan
Schedule Date Project Activity

1st Week 08/07/2019 Project Topic Selection

2nd Week 15/07/2019 Synopsis Submission
August 1st Week 05/08/2019 Presentation On Project Ideas
2nd Week 12/08/2019 Submission Of Literature Survey
3rd Week 19/08/2019 Feasibility Assessment
September 1st Week 02/09/2019 Mid Sem Presentation
3rd Week 16/09/2019 Design Of Mathematical Model
4th Week 23/09/2019 End Sem Presentation.
October 1st Week 07/10/2019 Report Preparation And Submission
December 3rd Week 19/12/2019 1st module presentation
4th Week 26/12/2019 Discussion and implementation of 2nd module
January 1st Week 02/01/2020 Preparation for ANEC conference
2nd Week 09/01/2020 Study of porter stemmer and tf algorithm.
3rd Week 16/01/2020 Discussion about modification
4th Week 23/01/2020 1st and 2nd module presentation
5th Week 30/01/2020 Discussion on flow of project and designing new
module
February 1st Week 06/02/2020 Modification of modules.
2nd Week 13/02/2020 Designed test cases for our module.
3rd Week 20/02/2020 Worked on user interface.
March 1st Week 06/03/2020 Integration of all modules.
3rd Week 20/03/2020 Final Report and presentation.

Use Case Diagram

Class Diagram

Sequence Diagram
Activity Diagram
Data Flow Diagram
Component Diagram

Deployment Diagram
Required Tools
Software Requirements

Operating System : Windows7

Coding language : Python

Hardware Requirements

Processor - Intel i3 core

Speed - 1.1 GHz
RAM - 256MB (min)
Hard Disk - 20 GB
Floppy Drive - 1.44 MB
Key Board - Standard Windows Keyboard
Mouse - Two or Three Button Mouse
Monitor - SVGA
Testing -Test Case ex. Login Page
1. Unit Testing

Unit testing concentrates verification on the smallest element of the program – the
module. Using the detailed design description important control paths are tested to establish
errors within the bounds of the module.

In this system each sub module is tested individually as per the unit testing such as
campaign, lead, contact etc are tested individually. Their input field validations are tested.

2. Integration testing

Once all the individual units have been tested there is a need to test how they were put
together to ensure no data is lost across interface, one module does not have an adverse impact
on another and a function is not performed correctly.

After unit testing each and every sub module is tested with integrating each other.

System testing for the current system:

In this level of testing we are testing the system as a whole after integrating all the main
modules of the project. We are testing whether system is giving correct output or not. All the
modules were integrated and the flow of information among different modules was checked. It
was also checked that whether the flow of data is as per the requirements or not. It was also
checked that whether any particular module is non-functioning or not i.e. once the integration
is over each and every module is functioning in its entirety or not.

In this level of testing we tested the following: -

 Whether all the forms are properly working or not.

 Whether all the forms are properly linked or not.
 Whether all the images are properly displayed or not.
 Whether data retrieval is proper or not.
Specific knowledge of the application's code/internal structure and programming knowledge in
general is not required. The tester is aware of what the software is supposed to do but is not
aware of how it does it. For instance, the tester is aware that a particular input returns a certain,
invariable output but is not aware of how the software produces the output in the first place.

Test Cases

Test cases are built around specifications and requirements, i.e., what the application is supposed
to do. Test cases are generally derived from external descriptions of the software, including
specifications, requirements and design parameters. Although the tests used are primarily
functional in nature, non-functional tests may also be used. The test designer selects both valid
and invalid inputs and determines the correct output without any knowledge of the test object's
internal structure.

Test Design Techniques

Typical black-box test design techniques include:

 Decision table testing

 All-pairs testing
 State transition Analysis
 Equivalence partitioning
 Boundary value analysis
 Cause–effect graph
 Error guessing

Advantages

 Efficient when used on large systems.

 Since the tester and developer are independent of each other, testing is balanced and
unprejudiced.
 Tester can be non-technical.
 There is no need for the tester to have detailed functional knowledge of system.
  Tests will be done from an end user's point of view, because the end user should accept
the system. (This testing technique is sometimes also called Acceptance testing.)
 Testing helps to identify vagueness and contradictions in functional specifications.
 Test cases can be designed as soon as the functional specifications are complete.

Disadvantages

 Test cases are challenging to design without having clear functional specifications.
 It is difficult to identify tricky inputs if the test cases are not developed based on
specifications.
 It is difficult to identify all possible inputs in limited testing time. As a result, writing test
cases may be slow and difficult.
 There are chances of having unidentified paths during the testing process.
 There is a high probability of repeating tests already performed by the programmer.

1] Test case For Admin Login Page:

Project Name: NLP.

Prepared Date:-18-11-2019. Prepared By:

Module Name: Login. Reviewed Date:-22-11-2019

Project Code: - NLP. Reviewed By:- :

Total no of test Cases:-04

Total no of test Cases Passed:-04

Total no of test Cases failed:-00

Total no of test Cases executed:-04

Total no of test Cases pending:-00

 Test Test Case Input Expected Actual Test
Case Procedure Output
Data Output Status
ID

FCRM- Checking the 1.Enter valid Admin Admin Pass

LG-01 functionality Usernames in Welcome Welcome
of Admin textbox page page
LOGIN should be displayed
2. Enter valid
Button displayed
Password in
textbox

3. Click on
Admin
LOGIN
Button
FCRM Checking the 1.Enter Admin Admin Pass
-LG-02 functionality invalid User Welcome Welcome
of Admin Name in text page page is
LOGIN box should not not
Button be displayed
2. Enter valid
displayed
Password in
password
textbox

3. Click on
Admin
LOGIN
Button

FCRM Checking the 1.Enter valid Admin Admin Pass

-LG-03 functionality User name in Welcome Welcome
of Admin User name page page is
LOGIN textbox should not not
Button be displayed
2. Enter
displayed
invalid
Password in
password
textbox

3. Click on
Admin
LOGIN
Button

FCRM - Checking the 1.Enter Admin Admin Pass

LG-04 functionality invalid User Welcome Welcome
of Admin name in User page page is
 LOGIN name textbox should not not
Button be displayed
2. Enter
displayed
invalid
Password in
password
textbox

3. Click on
Admin
LOGIN
Button

Functional Requirement

Registration and Authentication

The user should be able to create an account and login on the system using it. While
logging in, the system should authenticate that it’s the right user details.

Taking user’s inputs

After logging in, users have to Search query. The user also gets the particular result.
System
- Apply NLP
- Generate excel sheet Particular Result

Non-Functional Requirement

Performance Requirements
The performance of the system lies in the way it is handled. Every user must be given proper
guidance regarding how to use the system. The other factor which affects the performance is the
absence of any of the suggested requirements.

Safety Requirements

To ensure the safety of the system, perform regular monitoring of the system so as to trace the
proper working of the system. An internal staff has to be trained to ensure the safety of the
system. He has to be trained to handle extreme error cases.

Security Requirements

There are four security requirements: -

 Secure Functional Requirements- This is a security related description that is

integrated into each functional requirement. Typically, this also says what shall not
happen. This requirement artifact can for example be derived from misuse cases.
 Functional Security Requirements- These are security services that need to be
achieved by the system under inspection. Examples could be authentication,
authorization, backup, server clustering, etc. This requirement artifact can be derived
from best practices, policies, and regulations.
 Non-Functional Security Requirements- These are security related architectural
requirements, like robustness, minimal performance and scalability". This
requirement type is typically derived from architectural principals and good practice
standards.
 Secure Development Requirements- These requirements describe required activities
during system development which assure that the outcome is not subject to
vulnerabilities. Examples could be data classification coding guidelines or test
methodology
Software Quality Attributes

 Planned approach towards working: -

 The working in the organization will be well planned and organized. The data will be
stored properly in database, which will help in retrieval of information as well as its
storage.
 Accuracy: -
The level of accuracy in the proposed system will be higher. All operation would be done
correctly and it ensures that whatever information is coming from the center is accurate.
 Reliability: -

The reliability of the proposed system will be high due to the above stated reasons. The
reason for the increased reliability of the system is that now there would be proper
storage of information.
 No Redundancy: -
The main objective of proposed system is to classify the exact soil type from image and
crop recommendation. This would assure economic use of storage space and consistency
in the data stored.
 Immediate storage of information: -
In manual system there are many problems to store the largest amount of information.
 Easy to Operate: -
The system should be easy to operate and should be such that it can be developed within
a short period of time and fit in the limited budget of the user

Modules Description
User Model

In User model user can login when he is already registered.

After that the user can Search query the excel data and then process to get the NLP classification
result that is the type of particular Results.

Algorithm used

NLP
Uses of natural language processing

Most of the research being done on natural language processing revolves around search,
especially enterprise search. This involves allowing users to query data sets in the form of a
question that they might pose to another person. The machine interprets the important elements
of the human language sentence, such as those that might correspond to specific features in a
data set, and returns an answer.

NLP can be used to interpret free query and make it analyzable. There is a tremendous amount of
information stored in free excel files, like patients' medical records, for example. Prior to deep
learning-based NLP models, this information was inaccessible to computer-assisted analysis and
could not be analyzed in any kind of systematic way. But NLP allows analysts to sift through
massive troves of free text to find relevant information in the files.
This video explains how to use deep learning to build NLP models. Sentiment analysis is another
primary use case for NLP. Using sentiment analysis, data scientists can assess comments on
social media to see how their business's brand is performing, for example, or review notes from
customer service teams to identify areas where people want the business to perform better.

Google and other search engines base their machine translation technology on NLP deep
learning models. This allows algorithms to read text on a webpage, interpret its meaning and
translate it to another language.

High Level Design

Low Level Design

How its used by industrial perspective?

SDLC Model

The proposed system will be implemented using Iterative Model. The iterative model is a
particular implementation of a software development life cycle (SDLC) that focuses on an initial,
simplified implementation, which then progressively gains more complexity and a broader
feature set until the final system is complete.
 Figure: Iterative Model

In the Iterative model, an iterative process starts with a simple implementation of a small
set of the software requirements and iteratively enhances the evolving versions until the
complete system is implemented and ready to be deployed. An iterative lifecycle model does not
attempt to start with a full specification of requirements. Instead, development begins by
specifying and implementing just part of the software, which is then reviewed to identify further
requirements. This process is then repeated, producing a new version of the software at the end
of each iteration of the model.

Implementation perspective