Shri Vaishnav Institute of Technology and Science

Indore
Department of Computer Science and Engineering
STUDENT RESULT MANAGEMENT SYSTEM
ASSIGNMENT 3
Submitted To:- Sub
mitted By:-
Mr. Rajeev G. Vishwakarma Arpit Jain(1010)
Mayank Apte(1
025)
Mayank Bandi(1
026)
Piyush Agarwal (1034)

1. VISION:-
To view performance of required faculty on the basis of results of last 3 years,
compare performance of two faculties, view performance of faculty in different
class, compare branch-wise result, view result variation of a batch, view result
variation of a student, calculate aggregate for student, calculate the marks re
quired by student in next exam to obtain the desired result & compare result of
two batches, view comparison graphically by using the information about students
record.
2. GLOSSARY:-
Profile: Details of administrator, operators, students & faculties associated wi
th the result analysis.
Admin: Administrator is the primary user of the system. He can view & compare Re
sults of students & faculties.
Operator: Operator maintains the database. Operator inserts , delete & maintain
records of students & faculties.
Student: Student uses this software for his evaluation by viewing & comparing re
sults. He can calculate his aggregate & marks required in next semester to get d
esired overall aggregate.
Faculty: Faculty uses this software for evaluating the students by viewing & com
paring results.
HTML: Hypertext Markup Language is a markup language used to design static web p
ages.
J2EE: Java 2 Enterprise Edition is a programming platform— part of the Java Platfo
rm for developing and running distributed multitier architecture Java applicatio
ns, based largely on modular software components running on an application serve
r.
SQL: SQL Oracle is the database management system that delivers a flexible and c
ost effective database platform to build robust on demand business applications.
WAS: Web sphere application server is an application server that runs business a
pplications and supports the J2EE and web services standards.
WSAD: Web sphere studio application developer is a toolkit which is designed for
the creation of more complex projects, providing fully dynamic web application
utilizing EJB’s. This consist of EJB tools , CMP ,data mapping tools & a universal
test client that is designed to aid testing of EJB’s.
HTTP: Hypertext Transfer Protocol is a transaction oriented client/server protoc
ol between web browser & a Web Server.
HTTPS: Secure Hypertext Transfer Protocol is a HTTP over SSL (secure socket laye
r).
TCP/IP: Transmission Control Protocol/Internet Protocol, the suite of communicat
ion protocols used to connect hosts on the Internet. TCP/IP uses several protoco
ls, the two main ones being TCP and IP.
JAVA: Java is a programming language expressly designed for use in the distribut
ed environment of the Internet. It was designed to have the "look and feel" of t
he C++ language, but it is simpler to use than C++ and enforces an object-orient
ed programming model. Java can be used to create complete applications that may
run on a single computer or be distributed among servers and clients in a networ
k. It can also be used to build a small application module or applet for use as
part of a Web page. Applets make it possible for a Web page user to interact wit
h the page.
ORACLE: The Oracle Database also known as Oracle RDBMS or simply Oracle is a rel
ational database management system (RDBMS) produced and marketed by Oracle Corpo
ration. The Oracle RDBMS stores data logically in the form of tablespaces and ph
ysically in the form of data files ("datafiles").
Rational: Rational Rose is a tool set produced and marketed by Rational Software
Corporation (now owned by IBM). Rose is an operational tool set that uses the
Unified Modeling Language (UML) as its means for facilitating the capture of dom
ain semantics and architecture/design intent.
3. Requirement Management Plan:-
The five levels of maturity for our RMM are: 1) written 2) organized 3)structure
d 4) traced, and 5) integrated. We will use these categories to partition requir
ements management practices, starting at the lowest level (One) and moving up th
rough Level Five.
Actually, there is one other level on the requirements maturity scale: Level Zer
o -- no requirements. At Level Zero,they make broad assumptions that they know w
hat to build;and the time in which the software can be build. Sometimes this gam
ble works, but more often than not, a product is released that is missing functi
onality, has functions that are not needed,
or is of poor quality.
Level One --Written Requirements
The first step up is simply to write the requirements. Once you write requiremen
ts, several benefits become obvious.First, you have a real basis for a contract
with your customer. If you write them well, the requirements can clearly state y
our understanding of what the customer wants you to build, and they can read the
requirements and agree (or disagree).Second, everyone on your development team
has a basis for doing his or her work. Third, as you staff up the project, new
members, too, will have a source for figuring out what the application or system
is supposed to do. Our project meets this level as we have written all the requ
irements in a well organized manner which states all the objectives clearly. The
customer is agreed with all requirements. Also,it helped us a lot while assigni
ng the tasks to the members of the team based on the different objectives classi
fied. Everyone on our development team has a basis for doing his or her work.
Level Two -- Organized
At this level an organization deals with things like the quality of the requirem
ents, their format, their security, where they are stored, and how to keep track
of different versions.The goal of a requirement is to clearly communicate the p
roposed behavior of the software to a diverse set of constituents: users, custom
ers and other stakeholders, as well as the development team. A good set of requi
rements does this job well; a bad one does not. Good requirements are understand
able by stakeholders who specify them.
Formatting
Requirements must also be formatted effectively. Consistent numbering schemes, h
eaders, fonts, and a good table of contents make your documents easier to read,
understand, and use. We have used better fonts, headers and classified all the r
eq. uniquely & effectively.
Accessibility, Security, and Version Control
At Level Two, you need a central, well known location for the requirements, one
that is accessible by all users. Limiting the ability to modify requirements to
authorized persons only can help ensure the requirements integrity.Costs associ
ated with getting to Level Two relate mostly to training and review.
In our project we have given authentication levels to each user accordin
g to the need. When your requirements are more readable and easier to understand
(and more trustworthy), you will have a better basis for a contract with the cu
stomer,the development team will find the requirements easier to use, and new st
aff will be able to come up to speed more quickly. Writing quality requirements
is not a simple task. Getting to, and staying at, a given maturity level will r
equire consistent review of requirements documents and some level of "process en
forcement".

Level Three -- Structured

Getting to Level Three involves being more specific about the "types" of requir
ements you gather. Are they functional or nonfunctional.Making these distinction
s helps you get a better understanding of the requirements and manage them bette
r.
Getting Your Types Straight
The first issue arises if you do not distinguish among different types of requir
ements. If your current requirements specification simply contains a big list of
requirements with no indication of their type, it is likely that the list conta
ins a mix of different types.
Attributes
All requirements are not created equal: Some are more important than others; som
e are more stable than others.These are important things to keep track of, and a
dding attributes for requirements can help you do so. Attributes include informa
tion that supplements the requirement text and helps you better understand and m
anage your requirements.Benefits of getting to Level Three revolve around better
understanding and easier management.
In our project we have used well-structured requirements clearly identify differ
ent requirement types, and attributes provide the ability to query and filter gr
oups of requirements. Better typing of requirements also provides greater assura
nce that the team has identified all important requirements. The main cost of ge
tting to Level Three is in planning and maintenance. Determining appropriate req
uirement types and attributes is not a trivial task.
Usually this information is captured in a Requirements Management Plan (RMP). Th
en, requirements attributes are of little use if they are not kept up-to-date, s
o there is a maintenance burden that goes beyond the one for Level Two. There is
an increased cost too, because
determining the correct attribute values takes time. Often, when organizations g
et to Level Three, they institute the use of a requirements management tool like
Rational RequisitePro. This has large benefits that often outweigh the cost of
purchasing, updating, and administering the
software.
Level Four -- Traced
Most systems of any significant complexity will have a hierarchy of requirement
s. In a systems engineering environment, this hierarchy starts with system requi
rements and moves down to subsystem requirements, program requirements, and elem
ent requirements. In the Rational Unified Process, the hierarchy starts with use
r needs, proceeds to features, and then goes on to use cases. The
ability to keep track of these relationships is commonly called traceability,and
it entails identifying and documenting the derivation path (upward) and allocat
ion/flowdown path (downward) of requirements in the hierarchy. Traceability prov
ides the ability to understand how changes to
one requirement might affect others (impact analysis) and can also help determin
e if your requirements are complete (coverage analysis).Usually, an organization
at Level Four will develop an explicit traceability strategy prior to starting
a project and then document it in the requirements management plan. The strategy
will define the requirements levels and how they fit in the hierarchy. In addit
ion, it will lay down some "rules" for requirements relationships.
Level Five -- Integrated
It is often the case that requirements are used up front to get agreement from t
he customer on what the software is supposed to do, but then those requirements
are not really tied in to the way the software is developed. This results in sta
le requirements and software that doesn t meet its
objectives. Reaching Level Five means integrating the requirements management pr
ocess with the rest of your software development environment. Software that does
what the customer expects is built to comply with the requirements -- that is,
the team s software development process uses the
requirements as a key input. Integrating requirements into your change managemen
t process helps
ensure that no changes are made to requirements without review and approval. A
comprehensive, requirements-based software development process as described here
takes significant planning, training, and process enforcement.
Requirements Management Tool Support
Until Level Five, it is theoretically possible to do everything that we have tal
ked about either "manually" or with general-purpose tools like a word processor
and spreadsheet. However, starting at Level Two, an RM tool can help you be far
more efficient and consistent. Table 1 shows how the
important features of Rational RequisitePro support key characteristics of the f
ive RM maturity levels.

Table 1: How Rational RequisitePro Supports RMM Levels

Rational RequisitePro Feature Maturity Level
Dynamic integration between Microsoft Word ® One -- Written
and requirements database Two --Organi
zed

Secure central requirements repository Two -- Organized

User security Tw
o -- Organized
Requirements revision history Two -- Organi
zed
Web interface Two
-- Organized
Requirements project templates Three -- Struc
tured
User-defined requirement types, requirements
attributes, and document types Three -- Stru
ctured
Requirements attributes and query capability Three -- Structured
Requirements traceability and coverage analysis Four -- Traced
Impact of requirement change Four -- Traced
Integrations with other software development tools Five -- Integrated

4 Software Requirements:-
Client on Internet: Web Browser
Client on Intranet: Web Browser
Web Server: WAS, Operating System
Data Base Server: ORACLE 9i
Documentation: Rational Rose
Development End: RAD (Java, Java Beans, Servlets, HTML, Dreamweaver), OS (Window
s XP and UNIX), Web Server (WAS)

5. SRS:-
1) Introduction:-
1.1) Purpose: In today’s world of growing technologies the need for an improved an
d untenable system to cope with world is at most important. In competitive envir
onment of today’s world it is not sufficient to have knowledge about own result bu
t it is necessary to compare performance with others as well. Thus, this online
project is for the similar requirements. Using this project we can easily compar
e results along with display of results.
This project is for displaying results of students of a college. It also provide
s comparison of results of students from previous years & also students of diffe
rent branches. This project gives graphical comparison so that it becomes easy t
o analyze the variation in results. Performance of faculty in different class &
for different years can be viewed. Student can obtain the required result in nex
t year to get the desired final result. Branch with best result will be highligh
ted. Branch-toppers list is also displayed. Result of student can be viewed by p
roviding the roll number.
1.2) Scope:
View performance of required faculty on the basis of results of last 3 y
ears.
Compare performance of two faculties.
View performance of faculty in different class.
Compare branch-wise result.
View result variation of a batch.
View result variation of a student.
Calculate aggregate for student.
Calculate the marks required by student in next exam to obtain the desir
ed result.
Compare result of two batches.
View comparison graphically.
1.3) References:
• IEEE SRS Format (Std 830-1993).
• Project specification requirement (provided by TGMC).
1.4) Technologies:
JAVA: Application Architecture
ORACLE: Database
WSAD: Development Tool
WAS: Web Server
Rational: Design Tool
2.01) Product prospective:
The web pages (XHTML/JSP) are present to provide the user interface on customer
client side. Communication between customer and server is provided through HTTP/
HTTPS protocols.
The Client Software is to provide the user interface on system user client side
and for this TCP/IP protocols are used.
On the server side web server is for EJB and database server is for storing the
information.
2.02) Software Interface:
Client on Internet: Web Browser (internet explorer and Chrome)
Client on Intranet: Web Browser
Web Server: WAS, Operating System (any)
Data Base Server: ORACLE 9i
Development End: RAD (J2EE, Java, Java Beans, Servlets, HTML), DB2, OS (Windows
XP and UNIX), Web Server (WAS).
 2.03) Hardware Interface:
Client side -
Processor RAM Disk Space
Internet Explorer 6.0
Pentium 4 2.0 2 GHz 128 MB 1 GB
Server side
Processor RAM Disk Space
Web sphere application server
V5.0 Pentium IV at 1 GHz 512 MB 2 GB
ORACLE 9i Pentium IV at 1 GHz 512 MB 1GB (Excluding
data size)
2.04) Communication Interface:
Client on Internet will be using HTTP/HTTPS protocol.
2.05) Product Functions:
1. Performance of required faculty can be viewed on basis of results of las
t 3 years.
2. Performance of two faculties can be compared.
3. Performance of faculty in different class can be viewed.
4. Branch-wise result can be compared.
5. Result variation of a batch can be viewed.
6. Result variation of a student can be viewed.
7. Result of two batches can be compared.
8. Comparison can be viewed graphically.
2.06) User Characteristics: The users of this system are:
• Admin
• Operator
• Student
• Faculty
Every user should be comfortable of working with computer and net browsing.
2.07) Constraints:
• GUI is only in English.
• Login and password is used for identification of users.
• This system is working for single server.
• There is no maintainability of back up so availability will get affected.
• Limited to HTTP/HTTPS.

2.08) Use-Case Model Survey:

2.09) Architecture Design:

Application Layer
Business Layer
Data Layer

2.10) Assumptions and Dependencies:

• Administrator is created in the system already.
• Roles and tasks are predefined.
• Results are already fed into the database taken from University.
3) Specific Requirements:
3.1) Use-Case Reports:
USE CASE MODEL SURVEY & VIEW DIAGRAMS
USE CASE SPECIFICATION:-
ACTOR: ADMIN

Name of use case: View result.

Description: Admin can view Results of students & faculties.
Preconditions:
Administrator is already logged in.
Results have already been inserted.
Normal flow of events:
ADMIN will Login.
Admin will enter roll no.
Results are displayed.

Alternate flow of events:

Admin will login.
Admin will enter roll no.
Invalid roll no is displayed.
Post Condition: Results will be viewed.

Name of use case: Compare Results.

Description: Admin can compare any desired set of results.
Preconditions:
Administrator is already logged in.
Results have already been inserted.
Normal flow of events:
ADMIN will Login.
Admin will enter roll no.
Results are displayed.
Results comparison is visible.
Alternate flow of events: None.
Post Condition: Suitable decisions will be made.

ACTOR: STUDENT
USE CASE SPECIFICATION:-
Name of use case: View result.
Description: Student can view results of his own.
Preconditions:
Student is already logged in.
Results have already been inserted.
Normal flow of events:
Student will Login.
Student will enter roll no.
Results are displayed.
Alternate flow of events:
Student will login.
Student will enter roll no.
Invalid roll no is displayed.
Post Condition: Results will be viewed.
Name of use case: Compare Results.
Description: Student can compare any desired set of results.
Preconditions:
Student is already logged in.
Results have already been inserted.
Normal flow of events:
Student will Login.
Student will enter roll no.
Results are displayed.
Results comparison is visible.
Alternate flow of events: None.
Post Condition: None.

Name of use case: Calculate aggregate.

Description: Student can calculate his aggregate.
Preconditions:
Student is already logged in.
Results have already been inserted.
Normal flow of events:
Student will Login.
Student will enter roll no.
Student will choose criterion.
Aggregate will be displayed.
Alternate flow of events: None.
Post Condition: None.
Name of use case: Calculate Required Marks.
Description: Student can calculate marks required in next exam to obtain desired
result.
Preconditions:
Student is already logged in.
Results have already been inserted.
Normal flow of events:
Student will Login.
Student will enter roll no.
Student will choose option.
Required marks will be displayed.
Alternate flow of events: None.
Post Condition: None.

ACTOR: FACULTY

USE CASE SPECIFICATION:-

Name of use case: View result.
Description: Student can view results of his own.
Preconditions:
Student is already logged in.
Results have already been inserted.
Normal flow of events:
Student will Login.
Student will enter roll no.
Results are displayed.
Alternate flow of events:
Student will login.
Student will enter roll no.
Invalid roll no is displayed.
Post Condition: Results will be viewed.

Name of use case: Compare Results.

Description: Student can compare any desired set of results.
Preconditions:
Student is already logged in.
Results have already been inserted.
Normal flow of events:
Student will Login.
Student will enter roll no.
Results are displayed.
Results comparison is visible.
Alternate flow of events: None.

ACTOR: OPERATOR

USE CASE SPECIFICATION:-

Name of use case: Feed Result.
Description: Operator will feed result.
Preconditions:
Operator is already logged in.
Results are provided to operator.
Normal flow of events:
Operator will login.
Operator will enter roll no.
Operator will feed result.
Alternate flow of events: None.
Post Condition: None.

Name of use case: Update Result.

Description: Operator will update result.
Preconditions:
Operator is already logged in.
Results are provided to operator.
Normal flow of events:
Operator will login.
Operator will enter roll no.
Operator will feed result.
Alternate flow of events: None.
Post Condition: None

3.2) Supplementary Requirements:

i. Secure access of confidential data (user’s details). SSL can be used.
ii. 24 X 7 availability
iii. Better component design to get better performance at peak time
iv. Flexible service based architecture will be highly desirable for future exte
nsion.
6 Stakeholder’s request:-
An individual who is materially affected by the outcome of the system. End users
are often
thought of as the primary stakeholders, but other stakeholders, such as sharehol
ders and
executive management, among others, also have a stake in the project.
A requirement describes a condition or capability to which a system must conform
; it can be
either derived directly from user needs, or stated in a contract, standard, spec
ification, or
other formally imposed document. A desired feature, property, or behavior of a s
ystem.
1 General Requirements:-
These requirements describes the system objectives. In our project, the general
requirements are to view & compare results, view performance of required facult
y on the basis of results of last 3 years, compare performance of two faculties,
view performance of faculty in different class, compare branch-wise result, vie
w result variation of a batch, view result variation of a student, calculate agg
regate for student, calculate the marks required by student in next exam to obta
in the desired result, compare result of two batches.
2. Expected Requirements:-
These are implicit to software as users consider them to be fundamental requirem
ents which are accomplished in the software & hence do not express them. For exa
mple ease of software installation, ease of software & user interaction, user fr
iendly software etc.
3. Unexpected Requirements:-
These requirements specify the requirements that are beyond users expectations.
These requirements are not requested by the user but if added to the software th
ey become an additional feature. In this project the graphical comparison provid
ed for comparison of results is the unexpected requirement, which is an addition
al feature.
7. STORYBOARD:-
A Storyboard is a logical and conceptual description of system functionality for
a specific scenario, including the interaction required between the system user
s and the system. A Storyboard "tells a specific story". Storyboards can be used
to explore, understand and reason about the behavioral requirements of the syst
em, especially how the users will interact with the system. Storyboards are mea
nt to make textual scenarios more "real" by using pictorial means to specify the
requirements They are not intended to be a first draft of the user interface, b
ut are intended to just represent the user s interactions with the system. Vario
us storyboards are already covered in SRS above.
8. SUPPLEMENTRY SPECIFICATIONS:-
i. Secure access of confidential data (user’s details). SSL can be used.
ii. 24 X 7 availability
iii. Better component design to get better performance at peak time
iv. Flexible service based architecture will be highly desirable for future exte
nsion.
9.Use case model:-