4.

SYSTEM REQUIREMENT SPECIFICATIONS

A. FUNCTIONAL REQUIREMENTS
a. SOFTWARE REQUIREMENTS
Operating System : Windows XP/2003 or Linux
User Interface : HTML, CSS
Client-side Scripting : JavaScript
Programming Language : Java
Web Applications: Jdbc, Servlets, jsp
IDE/Workbench : My Eclipse 8.6
Database : Oracle 10g
Server Deployment : Tomcat 6.x

b. HARDWARE REQUIREMENTS

Processor : core 2 duo

Hard Disk : 160GB
RAM : 1GB or more

B.NON-FUNCTIONAL REQUIREMENTS
Performance Requirements
Some Performance requirements identified is listed below:
The database shall be able to accommodate a minimum of 10,000 records of students.
The software shall support use of multiple users at a time. There are no other specific
performance requirements that will affect development.

Security Requirements
Some of the factors that are identified to protect the software from accidental or malicious
access, use, modification, destruction, or disclosure are described below. Specific
requirements in this area could include the need to:
 Utilize certain cryptographic techniques
 Keep specific log or history data sets
 Assign certain functions to different modules
 Restrict communications between some areas of the program
  Check data integrity for critical variables
 Later version of the software will incorporate encryption techniques in the
user/license authentication process.
 The software will include an error tracking log that will help the user understand what
error occurred when the application crashed along with suggestions on how to prevent
the error from occurring again.
 Communication needs to be restricted when the application is validating the user or
license. (i.e., using https)

Portability Requirements
Some of the attributes of software that relate to the ease of porting the software to other host
machines and/or operating systems.
This may include:
Java is used to develop the product. So, it is easiest to port the software in any environment.
Maintainability
The user will be able to reset all options and all stored user variables to default settings.
Reliability
Some of the attributes identified for the reliability is listed below:
 All data storage for user variables will be committed to the database at the time of
entry.
 Data corruption is prevented by applying the possible backup procedures and
techniques.
Usability requirements
Some of the usability requirements identified for this system are listed below:
 A logical interface is essential to an easy-to-use system, speeding up common tasks.
 Error prevention is integral to the system and is provided in a number of formats from
sanity hacks to limiting free-text input.
Availability
All cached data will be rebuilt during every startup. There is no recovery of user data if it is
lost. Default values of system data will be assigned when necessary
Software System Attributes
 There are a number of attributes of software that can serve as requirements. It is
important that required attributes by specified so that their achievement can be
objectively verified. The following items provide a partial list of examples.
  The input system will allow for inputting numbers, operands, special symbols and
letters of the alphabet.

C.SDLC METHODOLOGIES

This document plays a vital role in the development of life cycle (SDLC) as it describes
the complete requirement of the system. It means for use by developers and will be the
basic during testing phase. Any changes made to the requirements in the future will have
to go through formal change approval process.
SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model
of Software Development and Enhancement. This model was not the first model to
discuss iterative development, but it was the first model to explain why the iteration
models.
As originally envisioned, the iterations were typically 6 months to 2 years long. Each
phase starts with a design goal and ends with a client reviewing the progress thus far.
Analysis and engineering efforts are applied at each phase of the project, with an eye
toward the end goal of the project.
The steps for Spiral Model can be generalized as follows:
 The new system requirements are defined in as much details as possible. This
usually involves interviewing a number of users representing all the external or
internal users and other aspects of the existing system.

 A preliminary design is created for the new system.

 A first prototype of the new system is constructed from the preliminary design.
This is usually a scaled-down system, and represents an approximation of the
characteristics of the final product.

 A second prototype is evolved by a fourfold procedure:

1. Evaluating the first prototype in terms of its strengths, weakness, and risks.

2. Defining the requirements of the second prototype.

3. Planning an designing the second prototype.

4. Constructing and testing the second prototype.

 At the customer option, the entire project can be aborted if the risk is deemed too
great. Risk factors might involve development cost overruns, operating-cost
miscalculation, or any other factor that could, in the customer’s judgment, result
in a less-than-satisfactory final product.

 The existing prototype is evaluated in the same manner as was the previous
prototype, and if necessary, another prototype is developed from it according to
the fourfold procedure outlined above.

 The preceding steps are iterated until the customer is satisfied that the refined
prototype represents the final product desired.

 The final system is constructed, based on the refined prototype.

 The final system is thoroughly evaluated and tested. Routine maintenance is

carried on a continuing basis to prevent large scale failures and to minimize down
time.

The following diagram shows how a spiral model acts like:

 Fig 1.0-Spiral Model
ADVANTAGES
 Estimates(i.e. budget, schedule etc .) become more relistic as work progresses,
because important issues discoved earlier.

 It is more able to cope with the changes that are software development generally
entails.

 Software engineers can get their hands in and start woring on the core of a project
earlier.

D.SYSTEM ARCHITECTURE
1. THE PRESENTATION LAYER

Also called as the client layer comprises of components that are dedicated to
presenting the data to the user. For example: Windows/Web Forms and buttons, edit
boxes, Text boxes, labels, grids, etc.
2. THE BUSINESS RULES LAYER

This layer encapsulates the Business rules or the business logic of the encapsulations.
To have a separate layer for business logic is of a great advantage. This is because any
changes in Business Rules can be easily handled in this layer. As long as the interface
between the layers remains the same, any changes to the functionality/processing
logic in this layer can be made without impacting the others. A lot of client-server
apps failed to implement successfully as changing the business logic was a painful
process

3. THE DATA ACCESS LAYER

This layer comprises of components that help in accessing the Database. If used in the
right way, this layer provides a level of abstraction for the database structures. Simply
put changes made to the database, tables, etc., do not affect the rest of the application
because of the Data Access layer. The different application layers send the data
requests to this layer and receive the response from this layer.

4. THE DATABASE LAYER

This layer comprises of the Database Components such as DB Files, Tables, Views,
etc. The Actual database could be created using SQL Server, Oracle, Flat files, etc.
In an n-tier application, the entire application can be implemented in such a way that
it is independent of the actual Database. For instance, you could change the Database
Location with minimal changes to Data Access Layer. The rest of the Application
should remain unaffected.