TABLE OF CONTENTS

I. INTRODUCTION
1. Purpose of Project
2. Scope of Project

II. GENERAL DESCRIPTION

1. Functionality of Project

III. SPECIFIC REQUIREMENT

1. Functionality Requirement
2. Interface Requirement
 Software Interface Requirement
 Hardware Interface Requirement
3. Design Constraints

IV. DATA MODELING

1. Data Flow Diagram
2. Use Case Model

V. SOFTWARE DESIGN

VI. CODING

VII. IMPLEMENTATION & MAINTENANCE

I. INTRODUCTION:
The title of the project is COURSE REGISTRATION SYSTEM. It aims at providing
information to all the levels of admission within an organization. This system can be used as
a registration in order to get admission in a course offered by a college. For a given student
a registration code is created and using this the administrator provide its result of the
selected students under some given criteria. In the conventional File Processing System the
details of students are managed, a number of different application programs are written to
extract records from and add records to the appropriate file. But this scheme has a number
of major limitations and disadvantages such as data redundancy, data inconsistency, non-
sharable data, non standardized data, insecure data, incorrect data, etc. This results in an
unsatisfactory registration system. The proposed system will have the capabilities allowing
instructor the ability for creation, modification, migration, and archiving of courses by
implementing the methods for reusability of the content.

1. PURPOSE OF THIS DOCUMENT :

This document is the Software Requirement Specification (SRS) for the Course
Registration System. The purpose of this document is to describe the functionality,
requirements and general interface of the student. The SRS will serve as a guide for the
client and the developers. This document specifies analysis and design guidelines of Course
Registration System. The specifications are intended to guide the group through the
development process by which the matrix are measured and the success of the project is
judged. The goal of developing this model is to reduce the manual work of the Course
Registration System which will therefore improve the overall working and the efficiency of
the college.

2. SCOPE OF THE DEVELOPMENT PROJECT :

Scope of this project is limited to an engineering college. This project aims to
maintain student information. The problem faced by the organization earlier in the
database used to maintain this information cause lot of redundancy and inflexibility. In this
project C++ is used as backend for maintaining the information. This ensures more storage
space and flexible accessing to database. This project follow prototyping model.

THE PROTOTYPING MODEL: Often a Customer defines set of general objective for
software but does not identify Detailed input processing ,or output requirements .In other
cases the developer may be unsure of the efficiency of an algorithm, the adaptability of an
operating system, or the form that human/machine interaction should take. In these, and
many other situations, a prototyping paradigm may offer the best approach.
 1) The prototyping paradigm begins with requirements gathering. Developer and
customer meet and define the overall objective for the software, identify whatever
requirements.
2) A “quick design” then occurs. The quick design focuses on a representation of those
aspects of the software that will be visible to the customer/user (e.g. input
approaches and output formats).The quick design leads to the construction of a
prototype

THE PROTOTYPING MODEL

3) The prototype is evaluated by the customer and used to refine requirements for the
software to be developed. Iteration occurs as the prototype is tuned to satisfy the
need of the customer, while at the same time enabling the developer to better
understand what needs to be done. Ideally, the prototype server as a mechanism
for identifying software requirements.

Yet prototyping can also problematic for the following reasons.

a) When information that the product must be rebuilt so that high level of quality can be
maintained, the customer cries foul and demands that “a few fixes” be applied to make
the prototype a working product.
b) The developer often makes implementation compromises in order to get a prototype.
II. GENERAL DESCRIPTION:
As noted above, the student entity is the core of the system, and it stores information
about the students, courses in which they are registered, fee structure, academic record
etc. it is through this selection that information is stored and accessed regarding student’s
progress in course.

Main motive and benefits of this project are:

(1) It helps in tracking student’s educational information.
(2) The staff of the college can get the details of various students registered in course.

The requirement of the user is to:

(1) Access/Search information
(2) Login to the system through the first page of the application see/change details.
(3) Get help about the Course Registration System how to use the different features of
the system.

1. FUNCTIONALITY OF THE PROJECT:

Main modules of the system:
Login Screen:
This module gives information about
(1) Registration code
(2) Password

Personal information :
This module gives information about

1) Profile Details : It includes personal details of the student

Registration Number
Name
Father’s Name
Address
Mobile Number
DOB
E-Mail Id
Branch Detail
2) Mode of Admission :
AIEEE
3) Hostel Details : It provides information about hostel including fees
 Single Seater
Double Seater
Fee Structure:
Tution Fee
Hostel Fee
Caution Fee
Registration Fee

III. SPECIFIC REQUIREMENTS:

1. Functional Requirements:
1) Existing System:
In the conventional File processing System the details of the students are
managed which incur the duplicity in course content, a number of different application
programs a appropriate files. But this schema has a number of major limitations and
disadvantages such as data redundancy, data inconsistency, non-sharable data, non-
standardized data, insecure data, incorrect data, etc.

2) Proposed System:
The purpose of this system have the capabilities allowing instructor the ability for
add, update, delete Student personal details for registration by implementing the methods
for reusability of the content. The student records system has been designed to be used and
understood by non-computer experts, means any student who has never used computer
before can feel compatible with this system. Movement around the system is facilitated
through a series of menus, which are accessed in a similar fashion at the level. Menu
selection as is becoming a standard in many software packages can carried out through
typing the highlighted number highlighted before the section.

The client requires the following features:

a) The administrator governs the working of the system.

b) The Technical and Non Technical staff can use system.
c) A mechanism to uniquely identify each student.
d) Performance report can be generated.
e) Slip to be given to the student.
f) Registration department can take list of all applications given by students.
g) System should have a login screen.
h) The System should have the help feature.
DETAILED DISCRIPTION OF FUNCTIONAL REQUIREMENT
Template for describing functional requirements

Purpose A Detailed description of the functional requirements and its reason(s)

Which inputs; in what form/format will inputs arrive; from what sources
Inputs
input will be derived.

Describes the outcome rather than the implementation; include any

Processing validity checks on the data, hoe the handle unexpected or abnormal
situations.

The form, shape, destination and volume of the Output, unit measure of
Outputs the output; process by which the output is stored or destroyed; process
for handling the error messages produced as output.

Features Describe the feature of the form.

Login Screen:

Purpose To provide Security

Inputs Registration Code and Password

Processing Checks if User Is valid or Not

Outputs Main Forms

Features Login And Exit.

Fee Structure:

Purpose It maintains and updates of student fee of various Sections.

Inputs of this form are tution fee, hostel fee, Bus Fee, caution fee and
Inputs
mode of payment(DD, Cheque, Cash)

It sum up all the fee entries (Tution fee, Bus Fee, Caution fee, Hostel Fee)
Processing
and stores in total amount.

Outputs Message box showing the status of payment whether paid or not.

Features Save And Exit

Help Screen Mechanism:

Purpose To provide help about the system

Inputs Processing process of the project

Processing No Processing

Outputs No Outputs

Features Exit
Student Application Form:

Purpose Allows Administrator to add/remove/update Students records

Students profile details, previous academic records, mode of admission,

Inputs
hostel details and bus service information.

Processing Add/remove/Update Student Entries in database.

Outputs New/Update records.

Features Save And Exit.

2) Interface Requirements:
Interface of the Software Course Registration System with User, Software and
Hardware are specified as
1) Software Interface:

OPERATING SYSTEM WINDOWS XP & ABOVE

FRONT END C++
BACK END MS Excess

2) Hardware Interface:

RAM 512 MB
PROCESSOR PANTIUM 4 & ABOVE
HARD DISK 40 GB
3) Design Constraints:
1) Front End:
A front end refers to the client side end i.e., the end at which request is made.
The request is may originate in software are capable of sending it across to the server
capable of serving the request. There are many software packages that can serve as front
end. Each front end has its own features and tools for handling the data. We use the
programming language c++ as front end.

The c++ buzzword:

1. Simple
2. Secure
3. Portable
4. Object Oriented
5. High Performance
6. Dynamic

IV. DATA MODELING:

1. Data Flow Diagram:
A Data Flow Diagram(DFD) can be used to represent software at any level of
abstraction and it is a graphical representation that depicts the information flow and the
transform that are applied as data moves from input to output. It can be used to
represent a software at any level of abstraction. DFDs may be partitioned into level that
represent increasing information flow and functional detail.
DFD models a system using external entities which defines the type and
amount of data to flow a process which transforms it and then creates an output, which
then flow to some other process of external entities as output flow.
DFDs are defined in levels, with every level decreasing the level of abstraction,
as well as defining greater details of the functional organs of the system.
Leveling of DFD: It is easier to solve a problem in ‘top-down’ manner, i.e. starting with
an overview and then working out the detail. It is easier to understand level DFD’s as
compared single large detail DFD’s.
2. Use CASE Diagram:
A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram
defined by and created from a Use-case analysis. Its purpose is to present a graphical overview
of the functionality provided by a system in terms of actors, their goals (represented as use
cases), and any dependencies between those use cases.

Use Case diagrams are formally included in two modeling languages defined by the OMG:

 The Unified Modeling Language (UML).

 The Systems Modeling Language (SysML).

Symbols and Notations:

System:

Draw system's boundaries using a rectangle that contains use cases. Place actors outside the
system's boundaries.
Use Case:

Draw use cases using ovals. Label with ovals with verbs that represent the system's functions.

Actors:

Actors are the users of a system.

Use Case diagram of Course Registration System:

V. SOFTWARE DESIGN:
Design Is the process of applying various techniques and principles for the purpose of
defining a device, a process or a system in sufficient detail to permit its realization .
A software decomposition into modules-description of what each module is
intended to do and of the relationship among the modules.

1. Development of Software Design Model:

Translation of analysis model developed during analysis phase into data
design is shown on next page. All design models are developed by using the elements of
the analysis model as given below:

1) Data Design Requires data dictionary and data flow diagram:

The data objects and their relationships obtained by DFD and data details
from data dictionary made during the analysis phase provides the ground for
implementation of data model of any software.

TRANSLATION OF ANALYSIS MODEL INTO DESIGN MODEL

2) Architectural Design:
Architectural design consists of DFD. It depicts the relationship between
major “Structural Elements” of the software.
3) Interface Design:
Interface Design requires control specifications, state transition diagram and
DFD. It depicts the inter-communication path of software.
4) Component Level Design:
Component Level Design involves the control specification, state transition
diagram and process specifications.

2. Software Design Process:

Software Design Process follows an ordered sequence of steps which are
followed one-by-one to achieve final product. A software design process can be seen in
many perspectives that are:
1) Design Requirements and Criteria:
A design is regarded as a detailed plan for a solution to a problem. To follow
the design requirements and criteria there is a generic design process whose steps are
followed in sequence as shown in figure.
 DESIGN PROCESS
At least two realizations are synthesized. At completion of each step, a review is
planned. Reviews are planned to verify the outcome of each step.

2) Design Levels and their Objectives:

From a system perspective design processes is stepped down. These are series
of discrete levels. Each level begins with a list of requirements and form some form of
realization, which further acts as input to next level. This design process continues until
the next realization is in a physical form, that is the design level produces results that
are in the form of a specification for a specific physical realization in hardware or
software.

DESIGN LEVELS

3) Input/Process/Output (IPO) Approach:

In this approach, for each level or step a definite input is required transform
to the input into a definite output. This is also a feedback path. This approach is shown
in figure.
 INPUT/PROCESS/OUTPUT AT LEVEL N

4) Design Tools:
Tools available to support design are:
a) Data Dictionary
b) Abstract description of problem areas space in terms of:
 Function and Performance
 Data and Information Flow
 Control Flow
 Information Models
 Objects/Attributes/Operation
 Flow Diagram
 Operational Timelines
 Risk Analysis Charts
c) Information Compassion Tools
 Decision Tables
 Test Requirement Matrix
d) Support rationale Tools
 Tradeoff matrices
 Operational Timelines
e) Realization Tools
 Flow Diagram
VI. CODING:
Code development is a practically implementation of the design in a specific
programming language.
Program Quality:
It is the collection of attributes of a program so that is makes itself able
enough to satisfy the need.
Program Quality Attributes of Course Registration System are:

PROGRAMME QUALITY ATTRIBUTES OF COURSE REGISTRATION SYSTEM

VII. IMPLEMENTATION & MAINTENANCE:
The implementation of this project is proceeding step by step as shown
below. User can easily access to each phase. This helps administration to easily sort out
details of any student.

Information
INFORMATION
About Course

STUDENT Detailed
Information of
DETAILS Students

List of
ADMINISTRATION
LOGIN
REGISTERED Registered
MENU LIST Students

Exit to Main
EXIT Menu

Register for
NEW REGISTRATION
SIGNUP New
REGISTRATION FORM Registration

COURSE DISPLAY Display Earlier

REGISTRATION Registration
REGISTRATION
SYSTEM
MODIFY Modify Earlier
STUDENT RAGISTRATION Registration
MENU EDIT
LOGIN
REGISTRATION
DELETE Delete Earlier
REGISTRATION Registration
REGISTRATION Print out
SLIP Registration Form
Exit to Students
EXIT Menu
Exit to Main
EXIT Menu

Help & Instructions about

INSTRUCTIONS using software

Exit out of
QUIT Software

In the maintenance phase of this project errors are corrected which were not
discovered during its working life and tune the system to any variation in its working
environment.