54075894 time mgt system srs

SOFTWARE REQUIREMENT

SPECIFICATION

For

TIMETABLE MANAGEMENT

SYSTEM

Version 1.0 Approved

PREPARED BY : Minali Chourasia (0611CS081008)

Namrata Jain (0611CS081010)

Namrata Patel(0611CS081011)

Mohini Pathak (0611CS081009)

Pragya Chourasiya (0611CS081015)

[ BE(CS) VI Sem. ]

DATE : 18/03/2011

Software Requirements Specification for TIMETABLE MANAGEMENT SYSTEM 1

Software Requirements SpecificationTemplate

1. Introduction

The Problem is to Manage the Time Table of the all class of the

college according to teacher, and the Purpose of Manage Timetable of

the College is, for any College Teacher timetable scheduling is a very

arduous and time-consuming task. College Timetable management module

helps you to generate class time table as well campus and teacher time

table. Time table management module organizes the campus week,

holidays, breaks in between classes and subject teacher. Timetable

Management module automatically creates your Campus Timetable for

classes, class teachers and students. This module also allows you to

generate temporary timetables.

Class-Teacher Timetabling - This problem is normally associated with

Engineering College where the students are scheduled as a “class”. All

students in the same class take exactly the same/different set of courses.

Typically, teachers and classes are busy most of the day, and the problem is

to find times when each teacher can meet with his/her required classes with

no conflicts

We have decided to investigate the use of a Timetable Management

System. This system would be used by members who may be students or

professors/Teacher’s of that College to check and update the Timetable of

the Classes of College. The purpose of this document is to analyze and

elaborate on the high-level needs and features of the Timetable

Management System. It focuses on the capabilities and facilities provided

by a Time table of Class. The details of what all are the needs of the

Timetable Management System and if it fulfils these needs are detailed in

the use-case and supplementary specifications.


1.1 Purpose

The purpose of Software Requirements Specification (SRS) document

is to describe the external behavior of the Timetable Management System.

Requirements Specification defines and describes the operations,

interfaces, performance, and quality assurance requirements of the

Timetable Management System. The document also describes the

nonfunctional requirements such as the user interfaces. It also describes

the design constraints that are to be considered when the system is to be

designed, and other factors necessary to provide a complete and

comprehensive description of the requirements for the software. The

Software Requirements Specification (SRS) captures the complete software

requirements for the system, or a portion of the system. Requirements

described in this document are derived from the Vision Document prepared

for Timetable Management System.

1.2 Background Details

The Software Requirements Specification captures all the requirements in a

single document. The Timetable Management System that is to be

developed provides the members of the College and Student of the College

with Student information, System Provide all Classes Time Table details of

the college, and it provide many facilities. The Timetable Management

System is supposed to have the following features.

1.3 Overall Description

1. In few minutes, the program generates a complete timetable that

fulfills all your requirements. The program follows all psycho hygienic

and organizational requirements such as:

2. Selection for Number of working days of the week (ex. Saturday off)


3. Zero (attendance) period insertion

4. Periods per day selection .This selection is day wise ex. Can be made

4 periods on Saturday etc.)

5. Subjects could be entered considering

6. Hard subjects in first 4 or 5 periods

7. Subject in which classroom

8. Single or double duration consecutively

9. Periods per week per subject

10. Type of subject ( Hard, easy…)

11. Subjects distributed evenly for entire week

1.4 References

SRS template, 2010-05-10, Computer Engineering department, Kuwait

University.

1.5 Product Perspective

The rest of this document contains the following in the mentioned order:

1- Overall description of the project and its requirements.

2- Specific requirements for the project including the functionality,

usability, reliability, performance, security, safety, design constraints,

and copy right and intellectual properties.


2. Environmental Characteristic

1 Hardware

1.1 Processor P IV & Above

1.2 RAM 256

1.3 O.S. Window Xp & Above

2 People

2.1 Contractor

The Contractor is responsible for developing, updating, and obtaining

approval for the SRS, if it is included as a requirement in the contract.

2.2 Project Manager

The Project Manager is responsible for coordinating the efforts of those

involved in the SRS development, review, and approval.

2.3 Contract Manager

The Contract Manager verifies that the SRS deliverable is provided,

reviewed, and approved.

3. Goods of Implementation

STRATEGIC BENEFITS:

• Low Cost of Ownership

• Holistic Operational Automation of your educational Institute

• Increased Efficiency as more time to focus on Strategic Tasks

• Multiple College Management in a single window

• Any Time Availability

• Easy to Scale, Customize and Supports UNICODE & Localization


BENEFITS TO MANAGEMENT:

• Helps to get a global outlook and exposure for the institute for being Tech

Savvy

• Reduces paper work leads to saves cost and paper

• Increased Productivity by savings in man hrs in managing information with

automation

• Information required for Decision making is instantly available

• Single suite of Education Management software handing everything saves

on additional investment in different software and management issues

• Removes bottleneck in the process of getting information out of pile of

data and further reduces piles of files

BENEFITS TO STAFF & ADMINISTRATION:

• Easy monitoring of individual modules leads to quick error detection

• Quick & automated report generation

• Centralized data repository for easy data access

• Authenticated profile based data access

• User friendly interface requiring minimal learning and IT skills

• High level data security

• Design for easy Scalability

• Elimination of processes those are people dependent

• Minimal data redundancy


BENEFITS TO TEACHERS:

• Saves time as Student attendance is automated

• Marks and Grades generation is computerized this adds to time efficiency

• Timetable creation before hand

• Assignments to students can be given and tracked

• Availability of more time for teaching to students

• Improved interaction with parents

• Access to own and students' attendance

• Various school activities are better organized

4. Software Requirements Specification Outline

This outline specifies the minimum content elements for the SRS document.

Document formatting is not defined; all formats are acceptable, if the content

elements are complete.

4.1Cover Page

Provide a cover page with the necessary content, such as the name of the document,

date, and the Office of Systems Integration logo and footer.

4.2Revision History

Provide a revision history table with column titles: Revision Number, Date of Release,

Owner and Summary of Changes.

4.3Table of Contents

Provide a table of contents with a list of the document sections and the pages on which

they begin.

4.4 Behavioral Description

In the Behavioral description subsections, provide a view of the entire

SRS. This section should describe how the SRS is organized.


4.4.1 System Purpose

Specify the purpose of the SRS and its intended audience.

4.4.2 Business Content

Provide an overview of the business organization sponsoring the

development of the software, and any related business content.

4.4.3 Scope

Describe the scope of the software application to be produced. Within

the description identify the software product, describe its

functionality, and applications of the software. Include any

description of the benefits, objectives, and goals of the software.

4.4.4 User Characteristics

Identify each type of user of the software by function, location, and

type of device. Specify the number of users in each group and the

nature of their use of the system. Describe the characteristics and

interactions of the users that will interact with the software during

the phases of the software life cycle.

4.5 System State/Assumptions, Dependencies and

Constraints

4.5.1 Assumptions

Describe assumptions made that can affect the requirements of the

SRS. Assumptions are factors that are believe to be true during the

life cycle of the project, that if changed may affect the outcome of

the project.

4.5.2 Dependencies

Describe each dependency that can affect the requirements specified

in the SRS. Dependencies are outside of the scope and control of the

project and must remain true for the project to succeed.


4.5.3 Constraints

Describe factors that limit the scope and functionality of the

software. Constraints are requirements that are imposed on the

software solution.

4.6 Functional Requirements

The functional requirements sections should be customized to

contain the information necessary to define the fundamental actions that

must take place within the software to process inputs and to process and

generate outputs. Functional requirements should include specific

requirements for business rules, which describe and document the steps

in a business process.

In the functional requirement subsections, specify all software

requirements to a level of detail sufficient to enable the developer to

build the software application. Each functional requirement documented

in the requirements sections must have a unique identifier for

requirements traceability and should be ranked for importance and/or

stability.

4.6.1 Business Requirements

Describe all requirements from a business perspective. Business

requirements are the parts of the fully defined business process that

will be automated by the software.

4.6.2 Non Functional Requirements

The Non functional requirements sections should be customized to

contain the information necessary to define the fundamental actions

that must take place within the software to process and generate its

result. Non Functional requirements should include specific

requirements for business rules, which describe and document the

steps in a business process.

4.6.3 Logical Data Requirements

Describe the logical data requirements for the system.


4.6.4 User Requirements

Describe the user requirements; these should capture the intended

behavior of the human interface of the application.

4.6.5System Requirements

4.6.5.1 Performance Requirements

Describe the performance conditions and their associated

capabilities. These requirements should be stated in measurable

terms.

4.6.5.2 Quality Requirements

Describe requirements for the quality characteristics of the

application, such as usability, reliability, and maintainability. These

requirements should be stated in measurable and verifiable terms.

4.6.6 Interfaces

Describe the characteristic of each interface between the software

and other hardware or software, such as communication protocols

and purpose of the interface.

4.6.7 Other Requirements

Identify any additional requirements that could not be appropriately

categorized into the preceding requirements sections.

4.7 References

Provide any references used in the creation of the document.

4.8Glossary

Provide an alphabetized list of definitions for special terms and acronyms

used in the document.

4.9Appendices

The appendices should contain material that is too detailed or large to be

included in the main body of the document. Refer to each appendix in

the main body of the text where the information applies.

54075894 time mgt system srs

Documents

timetable management system

include specific requirements

software requirements specification

functional requirements

business rules

time table

fundamental actions

main body