2.

Software Requirement Specification

2.1 Modules
1. Text Encryption and Decryption
2. Image Encryption and decryption
3. Text request
4. Image request
SERVER SIDE
5. View encrypted data
6. View user request
7. Provide password

1. Text Encryption and Decryption

In this module user encrypted the plain text to encrypted format and uploaded to the
cloud. The encryption is done by using a password. Only using this password only
any one can decrypt the text. The user upload the password also include with
encrypted data. The trusted authority id responsible for passing the password to the
requested user
2. Image Encryption and decryption
Like the same as the image encryption is also done. And the encrypted images and
password will also be uploaded to the cloud. The trusted authority id responsible for
passing the password to the requested user
3. Text request
Any user can view the file uploaded in the server. All the files are in encrypted
format. User cant view the files without know the password. For view the file first
user need to request the password to Trusted Authority The Authority check the user
and provide the password for valid user.
4. Image request
Image request is also same as the Text Request. The list of images can view in the
application. But user can only view the images after getting the password from
trusted authority
5. View Encrypted Data
The user uploaded encrypted data can be view in the server side. The trusted authority
act as server they have the responsibility to provide password for the requested user.
6. View user request
After user view the encrypted data they can request the password for encrypted data.
This user request can be view in the Trusted authority
7. Provide password
After view the request Trusted authority validating the user and if the user is valid the
Trusted authority provide password for the requested file via email. Using this
password user can decrypt the file

2.2 H/W Requirements

 System : Pentium Dual Core.
 Hard Disk : 120 GB.
 Ram : 1GB.

2.3 Software Requirements

Operating System : Windows95/98/2000/XP

Application Server : Tomcat5.0/6.X
Front End : HTML, Java, Jsp
Scripts : JavaScript.
Server side Script : Java Server Pages.
Database (Back End) : Mysql5.5.1

2.4 Non-Functional Requirements

Non-functional requirements describe user-visible aspects of the system that are not
directly related to functionality of the system. Non-functional requirements these are
constraints on the services or functions offered by the System.
Non-functional requirements are often called qualities of a system. Other terms for
non-functional requirements are "constraints", "quality attributes", "quality goals",
"quality of service requirements" and "non-behavioral requirements". Qualities, that
are non-functional requirements, can be divided into two main categories:
 1. Execution qualities, such as security and usability, which are observable at run
time.
2. Evolution qualities, such as testability, maintainability, extensibility and
scalability, which are embodied in the static structure of the software system.

Non-functional requirements

Product
Organizational External
requirements
requirement requirement

Efficiency Reliability Portability Ethical

requirement requirement requirement Interoperability
requirement
requirement

Legislative
Usability Delivery Implementation
Standards requirement
requirement requirement requirement
requirement

Privacy
Safety
requirement
Performance Space requirement
requirement requirement

Fig 2.4.1: Non-Functional Requirements

The non-functional requirements are
Reliability
The packages will pick-up current transactions online. Regarding the old transactions,
user will enter them in to the system.

Security
The web server and database server should be protected from hacking, virus etc.

Portability
The application will be developed using standard open source software (Except
Oracle) like Java, tomcat web server, Internet Explorer Browser etc. these software
will work both on Windows and Linux OS. Hence portability problems will not arise.
Maintainability
The first tier is the GUI, which is said to be front-end and the second tier is the
database, which uses My-Sql, which is the back-end. The front-end can be run on
different systems (clients). The database will be running at the server. Users access
these forms by using the user-ids and the passwords.

Robustness
Time to restart after failure percentage of events causing failure probability of data
corruption on failure

Usability
The system is used by the four persons namely Administrator, Project Manager,
Developer and the customer. Each person is having their own roles and separated by
the security issues.

Performance
System is highly functional and good in performance. The system must use the
minimal set of variables and minimal usage of the control structures will dynamically
increase the performance of the system.

Availability
The system is implemented based on the web browser and server. Using this web
browser the user can access the data and store the data in the server, here we can use
the web browser as Mozilla and server as Tomcat5.5. And windows XP professional
is used as the platform.

Supportability
The system is designed to be the cross platform supportable. The System is supported
on a wide range of hardware and any software platform

Testability
The system software can be tested. Operability is the better it works, the more
efficiency it can be tested. It operates clearly. Observability is what you see is what
you test. The results of each test case are readily observer.
2.5 SDLC
SDLC ( Software Development Life Cycle)
SDLC stands for Software Development Life Cycle. A Software Development
Life Cycle is essentially a series of steps, or phases, that provide a model for the
development and lifecycle management of an application or piece of software. The
methodology within the SDLC process can vary across industries and organizations,
but standards such as ISO/IEC 12207 represent processes that establish a lifecycle for
software, and provide a mode for the development, acquisition, and configuration of
software systems.
SDLC consists of following activities
1. Planning: The most important parts of software development, requirement
gathering or requirement analysis are usually done by the most skilled and
experienced software engineers in the organization. After the requirements are
gathered from the client, a scope document is created in which the scope of the
project is determined and documented.
2. Implementation: The software engineers start writing the code according to
the client's requirements.
3. Testing: This is the process of finding defects or bugs in the created software.
4. Documentation: Every step in the project is documented for future reference
and for the improvement of the software in the development process. The
design documentation may include writing the application programming
interface (API).
5. Deployment and maintenance: The software is deployed after it has been
approved for release.
6. Maintaining: Software maintenance is done for future reference. Software
improvement and new requirements (change requests) can take longer than the
time needed to create the initial development of the software.
The Waterfall Model was first Process Model to be introduced. It is also referred to as
a linear-sequential life cycle model. It is very simple to understand and use. In a
waterfall model, each phase must be completed before the next phase can begin and
there is no overlapping in the phases. Waterfall model is the earliest SDLC approach
that was used for software development .
The waterfall Model illustrates the software development process in a linear
sequential flow; hence it is also referred to as a linear-sequential life cycle model.
This means that any phase in the development process begins only if the previous
phase is complete. In waterfall model phases do not overlap.
Waterfall Model design
Waterfall approach was first SDLC Model to be used widely in Software Engineering
to ensure success of the project. In "The Waterfall" approach, the whole process of
software development is divided into separate phases. In Waterfall model, typically,
the outcome of one phase acts as the input for the next phase sequentially.
Following is a diagrammatic representation of different phases of waterfall model.

The sequential phases in Waterfall model are:

 Requirement Gathering and analysis: All possible requirements of the
system to be developed are captured in this phase and documented in a
requirement specification doc.
 System Design: The requirement specifications from first phase are studied in
this phase and system design is prepared. System Design helps in specifying
hardware and system requirements and also helps in defining overall system
architecture.
 Implementation: With inputs from system design, the system is first
developed in small programs called units, which are integrated in the next
 phase. Each unit is developed and tested for its functionality which is referred
to as Unit Testing.
 Integration and Testing: All the units developed in the implementation phase
are integrated into a system after testing of each unit. Post integration the
entire system is tested for any faults and failures.
 Deployment of system: Once the functional and non functional testing is
done, the product is deployed in the customer environment or released into the
market.
 Maintenance: There are some issues which come up in the client
environment. To fix those issues patches are released. Also to enhance the
product some better versions are released. Maintenance is done to deliver
these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing
steadily downwards (like a waterfall) through the phases. The next phase is started
only after the defined set of goals are achieved for previous phase and it is signed off,
so the name "Waterfall Model". In this model phases do not overlap.
Waterfall Model Application
Every software developed is different and requires a suitable SDLC approach to be
followed based on the internal and external factors. Some situations where the use of
Waterfall model is most appropriate are:
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.