lOMoARcPSD|5450906

Ums - software requirement specification srs

Software Engineering (Lovely Professional University)

StuDocu is not sponsored or endorsed by any college or university

Downloaded by Techi dEeP ([email protected])
 lOMoARcPSD|5450906

SOFTWARE REQUIREMENTS SPECIFICATION

Software Requirements
Specification

For

LPU UMS

Submitted by: - Prabhleen Kour

Roll No: - A-04 (11509802)

Sec:-K1512

Submitted to:-Mrs. Preeti Gupta

Downloaded by Techi dEeP ([email protected])

 Lovely Professional University

ii
Copyright © 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
 lOMoARcPSD|5450906

Table of Contents

1. Introduction................................................................................................................................

1.1 Purpose.................................................................................................................................1

1.2 Intended Audience and Reading Suggestions......................................................................1

1.2 Document Conventions, Definitions....................................................................................1

1.3 Scope...................................................................................................................................2

2. Overall Description..................................................................................................................2

2.1 Product Perspective..............................................................................................................2

2.2 Product Features..................................................................................................................2

2.3 User Classes and Characteristics.........................................................................................3

2.4 Operating Environment........................................................................................................4

2.5 Design and Implementation Constraints..............................................................................4

2.6 User Documenttion..............................................................................................................4

2.7 Assumptions and Dependencies..........................................................................................4

3. Specific Requirements.............................................................................................................5

3.1 Database Storage..................................................................................................................5

3.2 Funcitional...........................................................................................................................5

4. External Interface Requirements...........................................................................................7

4.2 Hardware Interfaces.............................................................................................................7

4.3 Software Interfaces..............................................................................................................7

5. Other Nonfunctional Requirements.....................................................................................14

5.1 Performance Requirements................................................................................................14

Downloaded by Techi dEeP ([email protected])

 5.2 Safety Requirements..........................................................................................................14

5.3 Security Requirements.......................................................................................................15

5.3 Software Requirements......................................................................................................15

5.3 Hardware Requirements.....................................................................................................15

6. Other Requirements..............................................................................................................15
CERTIFICATE: -
This is to certify that the thesis entitled “LPU UMS” submitted by Prabhleen kour, in
partial fulfillment of the requirements for the award of Degree of Bachelor of
Technology in Computer Science and Engineering at Lovely Professional University,
Punjab is an authentic work carried out by them under my supervision and guidance.
To the best of my knowledge, the matter embodied in the thesis
Has not been submitted to any other university institute for the award of any Degree.

Date:
1/03/2017

ACKNOWLEDGEMENT: -

I own a great many thanks to a great many people who helped and supported me
during my project work. I express my sincere gratitude Mr.Vijaya Raju
Sir for guiding and correcting various documents of mine with attention and care. He
has taken pain to go through the project and make necessary correction as
And when needed. Finally I would like to thank and friends for their help and
assistance all through this project.

ABSTRACT: -

Lovely Professional University, Punjab is one of the reputed institutions for technical
education in India. The main purpose of the project is intended to develop
A portal for management of Times of India a web based news. The portal provides a
suitable and easy display for which large population around the world can learn or
will have the knowledge about the world. Basically this is a crowd sourcing
newspaper. The idea is anyone can send a news item using their web based gadget
which is managed by administrator to whom the editor’s panel kept in charge for this
to make it visible for the masses. This portal is developed using HTML, PHP & CSS
technologies and SQL Server.
 Entity Relationship Diagram For UMS: -

ADMIN

`
Login ID

Staff Student/User

Announce
H Result ment
Hall ticket Salary
generation
Daily
Activity Previou
s papers Reg.
form

Activity Profile
Update
result Annou
ncemen Admit card
t
Name Address
Recruitment
form

Identity
 lOMoARcPSD|5450906

I. INTRODUCTION  Data Storage Layer: - This term refer to where all the
data is being stored.
Purpose:-
 Data flow Diagram: - It show the
The main objective of this document is to illustrate relationship or dataflow between the entities.
the requirements of the project University
Management System .This document describes the  Boolean: - A true /false statement.
design decision, architectural design and the
detailed design needed to implement the system. It  Interface: - Something used to communicate
provides the visibility in the design and provide the across different mediums.
information needed for software support .The
document gives the detailed description of both  Unique keys; - Used to differentiate entities
functional and non-functional requirements in database.
proposed by the client.
 Layers: - Represents the section of the
A. Intended Audience and Reading project.
Suggestions
 SQL Server:- A server used to store the data
The document is intended for all the stakeholders’ customer in a well-organized format
and the developer (designers, testers, maintainers). The reader
is assumed to have basic knowledge of all the algorithms used
to reduce the complexity and also have knowledge of all the
basics which are used in the development and maintenance of C. Project Scope: -
the project or an online system and also some basic knowledge The online university management system is developing for
of Entity Relationship diagrams the schools of the university and used to replace the old paper
B. Document Conventions, Definitions:- work system. The software supports a computerized university
management system network. The network enables Teachers,
students to complete simple tasks via U.M.S that may be
The following are the list of conventions and easily accessed to the authorized members at any time. The
acronyms used in this documentation. UMS identifies a USER by a login id which provided by the
administrator and password. It collects information through
 Administrator: - A login id representing a user with the database by following the login id (e.g., profile,
user administration privileges to the software. attendance, examination, fees payment). The software must
 User: - A general login id assigned to users. handle concurrent accesses to the same account correctly.

 Client: - Intended users for the software.

 SQL:-Structured Query Language used to retrieve or II. OVERALL DESCRIPTION

store the information in the database.

 ASP”- Active Server Pages: A Webpage formatted

on the server and delivered to the browser. A. Product Perspective
 User Interface Layer: - The section of the assignment
referring to what the user interacts with directly.

 Application layer: - This section referring the the

The proposed University Management System is an
Web Server where all computations are completed. online University management system .This system
will provide a view submit online payment
uploading various documents and other resources.

Downloaded by Techi dEeP ([email protected])

 lOMoARcPSD|5450906

Downloaded by Techi dEeP ([email protected])

This view will be based on the categories like  Insert/delete/edit the information of
attendance view and daily activities. Further the available on the UMS.
university management staff (faculty) can
add/remove/update the resource or an automatic  Can access all the accounts of faculty
removal of accessing features when the time limit and the students.
completes.
The features that are available to the faculty
The system have also an ADMIN who have full-fledged
rights with the regards to managing resources across branches.
are:
The user can view can submit, online payment, uploading
various documents and information about their account etc.  Can mark the attendance of the
there are basically two types of users one is students and other students online.
are faculty members. Each user facilitates with a different  Can create the continuous
account number having a profile along with a password for assessments for the students.
private use. The two type of user differ from each other due to
the accessing limits to online University Management System
 Can view the online attendance off
the students.

 Can submit the questions papers

B. Product Feature:- online.
There are three types of different user who will be  Can upload marks, assignments,
using this product reading material for the students.
So, every one ha the different interfaces to use the The features that are available to the Students
interface.. are:

 Can view the different types of the

reading material and assignments are
available in their account.
 Can pay their fees by online mode.
 University chancellor. who will be acting
as the administrator  Can view their marks as well as
 Faculty Members who are second level attendance.
users accessing UMS.
 Can view and modify it profile but
 Students of the university who will be cam modify it to some limits range.
accessing the UMS online

The features that are available to the

administrator are:

 Can create or delete the account.

C. User classes and characteristics:-
 Can view the accounts.
There are various by various users for kind of user
 Can change the password. for the product .Usually web products are visited by
various user for different reasons visited different
 Can hide any kind of feature from reasons.
both users.
The user includes:-
  Chancellor who will be acting as the 1) Description and priority:-
controller and he will have all the
privileges of administrator. Proposed Database is intended to store, retrieve,
 Faculty members who will be using update, and manipulate information related to
the above features by accessing the UMS university which include
online.
 Students who will be using the above  Profile of both users
features by accessing the UMS online  Staff information
 Student details
 My account
 Online payment
Operating Environment:-  View attendance/marks/uploading of marks
and assignments.
The product will be operating in windows
environment. Also it will be compatible with the IE
6.0. Most of the features will be compatible with the
Mozilla Firefox & Opera 7.0 or higher version. The
only requirement to use this online product would
be the internet connection Stimulus / Response Sequences:-

Design and Implementation Constraints: - Responses for Administrator:

The Product is developed using ASP. The backend database
for this SQL Server. The product is accomplished with login The administrator can Login and Logout. When the
facility so that specific function is available to specific Administrator Logs into the University management
student. system. The system will check for validity of
login .If the Login and password are valid, the
User Documentation:-
response to this action is the administrator will be
able to modify, view, add, deleting and all other
The product will include user manual. The user
functions that can be performed on the database
manual will include product overview, complete
configuration of the used software (such as SQL
server), technical details, backup procedure and
contact information which will include email
Functional requirement:-
address. The product will be compatible with the
Internet Explorer 6.0 or higher. The databases will
This section gives the list of Functional and
be created in the Microsoft SQL server 2000.
nonfunctional requirements which are applicable to
the University Management System
Assumptions and Dependencies:-
The product needs following third party product.
 Microsoft SQL server to store the database.
 ASP to develop the Product Interface Requirements:-
.
This section describes how the software interfaces
with other software products or users for input or
output.
III. SPECIFIC REQUIREMENTS:-
A. Database Storage:- User Interfaces

This section Describes how this product interfaces

with the user
GUI:- User access:
Each faculty member and student is assigned a
Describes the graphical user interface if present. unique identifier upon admission to the university.
This section should Both of them must know this. This identifying key
Include a set of screen dumps or mockups to maps to all his/her registration record information in
illustrate user interface features. the main registration system. Admitted and current
1. Description students have their online registration accounts also
The user interface must be customizable by the enabled. Such account maybe disabled during
administrator his/her stay as a matriculated student and/or after
graduation or separation From the University.
2. Criticality Uploading of data
This issue is essential to the overall system. All the Each faculty member should facilitates with
modules provided with the software must fit into uploading of data such assignments, their marks and
this graphical user interface and accomplish to the other kind of reading material. Similarly such of
standard defined. option must be present their for students to upload
their assignments.
3. Technical issues Online payment
In order to satisfy this requirement the design The students should have the facility to pay their
should be simple and all the different interfaces payment online any kind of university fee charges
should follow a standard template. There will be the so as there should be facility to check whether the
possibility of changing colors and images, plus entered code for payment is a valid code or not or in
switching between interfaces with the minimum simple word a proper validation is required.
impact for the users.

4. Risks
To reduce the circumstances under which this
requirement might not able to be satisfied, all the
designers must have been developed web sites
previously and they must be aware of html
restriction and cross browsers implementations
before starting the designing. In order to reduce the
probability of this occurrence the entire design team
will be trained in basic html development and
macromedia fireworks, this tool will be used instead
of Photoshop.

5. Dependencies with other requirements

All user interfaces should be able to interact with

the user management module and a part of the
interface must be dedicated to the login/logout
module
IV. EXTERNAL INTERFACE REQUIREMENTS

It include the non – functional requirements.

Input Requirements:-
A. User Interfaces
 Data Flow Diagram : -
Data flow diagram is a graphical representation of data flow Importance of DFDs in a good software design
in an information system. It is capable of depicting incoming The main reason why the DFD technique is so popular is
data flow, outgoing data flow and stored data. The DFD does probably because of the fact that DFD is a very simple
not mention anything about how data flows through the formalism – it is simple to understand and use. Starting with a
system. set of high-level functions that a system performs, a DFD
There is a prominent difference between DFD and model hierarchically represents various sub-functions. In fact,
Flowchart. The flowchart depicts flow of control in program any hierarchical model is simple to understand. Human mind
modules. DFDs depict flow of data in the system at various is such that it can easily understand any hierarchical model of
levels. DFD does not contain any control or branch elements. a system – because in a hierarchical model, starting with a
Types of DFD Data Flow Diagrams are either Logical or very simple and abstract model of a system, different details of
Physical. the system are slowly introduced through different hierarchies.
Logical DFD - This type of DFD concentrates on the system The data flow diagramming technique also follows a very
process and flow of data in the system. For example in a simple set of intuitive concepts and rules. DFD is an elegant
Banking software system, how data is moved between modeling technique that turns out to be useful not only to
different entities. Physical DFD - This type of DFD shows represent the results of structured analysis of a software
how the data flow is actually implemented in the system. It is problem, but also for several other applications such as
more specific and close to the implementation. showing the flow of documents or items in an organization.

Symbols used in DFD

Unified Modeling Language (UML):-

UML, as the name implies, is a modeling language. It may be

used to visualize, specify, construct, and document the
artifacts of a software system. It provides a set of notations
(e.g. rectangles, lines, ellipses, etc.) to create a visual model of
the system. Like any other language, UML has its own syntax
(symbols and sentence formation rules) and semantics
(meanings of symbols and sentences). Also, we should clearly
understand that UML is not a system design or development
methodology, but can be used to document object-oriented and
analysis results obtained using some methodology.

Coding:-
The objective of the coding phase is to transform
the design of a system into code in a high level
language and then to unit test this code. The
programmers adhere to standard and well defined
style of coding which they call their coding
standard. The main advantages of adhering to a
standard style of coding are as follows:
A coding standard gives uniform appearances to
the code
Written by different engineers
it facilitates code of understanding.
promotes good programming practices.
 For implementing our design into a code, we  Application: ASP (Active Server Pages)
require a good high level language. A programming
language should have the following features:

.
Characteristics of a Programming Language
Readability: A good high-level language will V. OTHER NONFUNCTIONAL REQUIREMENTS
allow programs to be written in some ways that A. Performance Requirements
resemble a quite-English description of the
underlying algorithms. If care is taken, the coding The proposed system that we are going to develop
may be done in a way that is essentially self- will be used as the Chief performance system within
documenting. the different campuses of the university
Portability: High-level languages, being Which interact with the university staff and
essentially machine independent, should be able to students. Therefore, it is expected that the database
develop portable software. would perform functionally all the requirements that
are specified by the university
Generality: Most high-level languages allow the
writing of a wide variety of programs, thus relieving
the programmer of the need to become expert in 5.2 Safety Requirements:-
many diverse languages.
Brevity: Language should have the ability to The database may get crashed at any certain time
implement the algorithm with less amount of code. due to virus or operating system failure. Therefore,
Programs expressed in high-level languages are it is required to take the database backup.
often considerably shorter than their low-level
equivalents. 5.3 Security Requirements
Error checking: Being human, a programmer is We are going to develop a secured database for the
likely to make many mistakes in the development of university. There are different categories of users
a computer program. Many high-level languages namely teaching
enforce a great deal of error checking both at Administrator, Staff members and students etc.
compile-time and at run-time. Depending upon the category of user the access
Cost: The ultimate cost of a programming rights are decided. It means if the user is an
language is a function of many of its characteristics. administrator then he can be able to modify the
data, delete, append etc. All other users other than
B. Hardware Interfaces
University Staff only have the rights to retrieve the
information about database.
Hardware Interfaces Server Side:
A. Software Quality Attributes
 Operating System: Windows 9x/ xp,
Windows ME The Quality of the database is maintained in such a
 Processor: Pentium 3.0 GHz or higher way so that it can be very user friendly to all the
 RAM: 256 Mb or more users of the database
 Hard Drive: 10 GB or more

Hardware Interface Client side:

5.5 Hardware Constraints:-
 Operating System: Windows 9x or above,
MAC or UNIX. The system requires a database in order to store
 Processor: Pentium III or 2.0 GHz or higher. persistent data. The database should have backup
 RAM: 256 Mb or more capabilities

Software Interfaces
 Database: SQL Server.
 5.6 Software Constraints: - web browser should be able to use the features of
The development of the system will be constrained the application.
by the availability of required software such as
web servers, database and development tools. The 6.4 ACID Properties:-
availability of these tools will be governed by the
Lovely Professional University. The Online fees payment software must be able to
use several data formats according to the data
formats that are provided by the data bases of
different banks. A transaction should have all the
properties of a data base transaction (Atomicity,
Consistency, Isolation, and Durability).
5.7 Design Constraints:-

The system must be designed to allow web

usability. That is, the system must be designed in
such a way that will be easy to use and visible on
most of the browsers
CONCLUSION:
After processing through all phases of the system
VI. OTHER REQUIREMENTS Development life cycle, the portal is developed. In Future
it will be hosted on the internet server which Will be accessed
6.1 Availability:- by all people in the world and can View the site and learn as
much as news and Information about the university. The
The system should be available at all times, Administrator or Editor who will be assigned for editing or
meaning the user can access it using a web browser, managing Or controlling will be given the secure login
only restricted by the down time of the server on Information and will change or modify the website. As per
which the system the requirements.

Runs. In case of a of a hardware failure or database

corruption, a replacement page will be shown. Also
in case of a hardware failure or database corruption,
backups of the database should be retrieved with the
MySQL server and saved by the administrator.

6.2 Maintainability:-

MySQL is used for maintaining the database and

the Apache server takes care of the site. In case of a
failure, a re-initialization of the program is
recommended.

6.3 Portability:-

The application is Linux-based and should be

compatible with other systems. Apache, PHP and
MySQL programs are practically independent of the
OS-system which they communicate with. The end-
user part is fully portable and any system using any