Online Examination System: Software Requirements Specification and Design, Study Guides, Projects, Research of Computer Science

Download Online Examination System: Software Requirements Specification and Design and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!

Online Examination System

1

[Shagufta

Majeed -

42]

Session: 2017

• 2019 |

[Online Examination Sys

Software Requirements Specification Document

Revision History

Date Description Author Comments <Version 1>

Document Approval

The following Software Requirements Specification has been accepted and approved by the following:

Signature Printed Name Title Date Dr. Supervisor, CSIT 21306

Online Examination System

2

Online Examination System

• 1. Introduction
  • 1.1 Purpose
  • 1.2 Scope
  • 1.3 Definitions, Acronyms, and Abbreviations.
  • 1.4 References
  • 1.5 Overview
• 2. The Overall Description
  • 2.1 Product Perspective
    • 2.1.1 Operations
    • 2.1.2 Site Adaptation Requirements
  • 2.2 Product Functions
  • 2.3 User Characteristics
  • 2.4 General Constraints
  • 2.5 Assumptions and Dependencies
• 3. Specific Requirements
  • 3.1 External Interface Requirements
    • 3.1.1 System Interfaces
    • 3.1.2 Interfaces
    • 3.1.3 Hardware Interfaces
    • 3.1.4 Software Interfaces
    • 3.1.5 Communications Interfaces
  • 3.2 Functional Requirements
    • 3.2.1 <Functional Requirement or Feature #1>
    • 3.2.2 <Functional Requirement or Feature #2>
  • 3.3 Use Cases
    • 3.3.1 Use Case #1
    • 3.3.2 Use Case #2
  • 3.4 Classes / Objects
    • 3.4.1 <Class / Object #1>
    • 3.4.2 <Class / Object #2>
  • 3.5 Non-Functional Requirements
    • 3.5.1 Performance
    • 3.5.2 Reliability
    • 3.5.3 Availability
    • 3.5.4 Security
    • 3.5.5 Maintainability
    • 3.5.6 Portability
  • 3.6 Inverse Requirements
  • 3.7 Logical Database Requirements
  • 3.8 Design Constraints
    • 3.8.1 Standards Compliance
• 4. Analysis Models
  • 4.1 Sequence Diagrams
  • 4.2 Data Flow Diagrams (DFD)
  • 4.3 State-Transition Diagrams (STD)
• 5. Supporting Information
     • Appendix A – Background Research on:
     • Appendix B – Data Dictionary

1. Introduction

Online Examination System is very useful for Educational Institute to prepare an exam, safe the time that will take to check the paper and prepare mark sheets. It will help the Institute to testing of students and develop their skills. But the disadvantages for this system, it takes a lot of times when you prepare the exam at the first time for usage. And we are needs number of computers with the same number of students. The effective use of "Online Examination System", any Educational Institute or training centers can be use it to develop their strategy for putting the exams, and for getting better results in less time.

1.1 Purpose

This Web Application provides facility to online examination worldwide. It saves time as it allows number of students/candidates to give the exam at same time and display the results at the end of the test, so there is no need to wait for the result. It is evaluated and generated by the server. Administrator has privileges to create, modify and delete the test papers and its particular questions. User can register, login and give the test with his specific id, and can see the results as well. It eliminates the use of items like pen, paper, etc.

1.2 Scope

Scope of this project is very broad compared to manually taken exams. They are: This app can be used in educational institutions as well as in corporate world. Can be used anywhere any time as it is a web based application (user location doesn’t matter). No restriction that examiner has to be present when the candidate takes the test. No manual work of preparing and storing the result information Less time consumption, as the result is calculated immediately after the test and displayed to the student/candidate.For students/candidates, it saves time of going to far away centers to give exams.

1.3 Definitions, Acronyms, and Abbreviations.

In this SRS we use different term keywords and acronyms. Each term has its special meaning and purpose so we define each term. Any person who is not belongs to computer science. When he read these definitions, he easily understands them.

PHP Hypertext Preprocessor

to under development system. Section II contains the general description which includes product perspective, functions, user characteristics and general constraints, Assumption and dependencies. Section III contains the specific requirements which includes functional, non- functional requirement of the system as well as use cases, classes and objects and design constraints. Section IV contains analysis model, data flow diagram, sequence diagram, state transition diagram. At the end, section V contains appendices.

2. The Overall Description

The overall description provides interface requirements for the OES, product perspective, product functions, user characteristics and other constraints.

2.1 Product Perspective

The application of OES will have a user friendly. The OES is a web-based system. The system provides a secure environment for all students and for the storing and retrieving of confidential student information. A student can enter the username, password will be providing. It display information about entry to be prepared by institutes. It displays exam details to the students when they are taking exams. There is a system for taking exam for the students. The system will display of results of students after taking the exam.

2.2 Product Functions

The OES website will allow access only to authorized users with specific roles. Administrator can maintain the website, Institutes will conduct the exams, and Students give the exams online. The major functions of that the website is provide facility to institutes to record to perform an online test. Institutes can enter the number of questions, +ve, -ve marks, questions and answers and the list of eligible students. Students can login and give the tests.

2.3 User Characteristics

Users should be comfortable with the English language. Users should have least information regarding the online examinations. Users should have necessary information and should be easy using general purpose application on computer. There are two type of user for “OES” student and institute. Student can login with their id, name and institute id to give the exams and can view their result. Institutes can also view the result of their students.

2.4 General Constraints

Since the DBMS being used is MS Access 2000, which is not a very popular DBMS, it will not be able to store a very huge number of records. Due to limited features of DBMS being used performance tuning features will not be applied to the queries and thus the system may become slow with the increase in number of records being stored. An extra security as SSL must be used to secure the marks details and other examination information.

2.5 Assumptions and Dependencies

The examinations are all objective. Students can give each exam just once.

3. Specific Requirements

This will be the largest and most important section of the SRS. The customer requirements will be embodied within Section 2, but this section will give the D-requirements that are used to guide the project’s software design, implementation, and testing. Each requirement in this section should be:

• Correct
• (^) Traceable (both forward and backward to prior/future artifacts)
• Unambiguous
• Verifiable (i.e., testable)
• Prioritized (with respect to importance and/or stability)
• Complete
• Consistent
• Uniquely identifiable (usually via numbering like 3.4.5.6) Attention should be paid to the carefully organize the requirements presented in this section so that they may easily accessed and understood. Furthermore, this SRS is not the software design document, therefore one should avoid the tendency to over-constrain (and therefore design) the software project within this SRS.

3.1 External Interface Requirements

3.1.1 System Interfaces

List each system interface and identify the functionality of the software to accomplish the system requirement and the interface description to match the system. These are external systems that you have to interact with. For instance, if you are building a business application that interfaces with the existing employee payroll system, what is the API to that system that designer’s will need to use?

3.1.2 Interfaces

Specify:

1. The logical characteristics of each interface between the software product and its users.
2. All the aspects of optimizing the interface with the person who must use the system This is a description of how the system will interact with its users. Is there a GUI, a command line or some other type of interface? Are there special interface requirements? If you are designing for the general student population for instance, what is the impact of ADA (American with Disabilities Act) on your interface?

3.1.3 Hardware Interfaces

Specify the logical characteristics of each interface between the software product and the hardware components of the system. This includes configuration characteristics. It also covers such matters as what devices are to be supported, how they are to be supported

This section describes specific features of the software project. If desired, some requirements may be specified in the use-case format and listed in the Use Cases Section.

3.2.1 <Functional Requirement or Feature #1>

3.2.1.1 Introduction

3.2.1.2 Inputs

3.2.1.3 Processing

3.2.1.4 Outputs

3.2.1.5 Error Handling

3.2.2 <Functional Requirement or Feature #2>

…

3.3 Use Cases

This section contains use cases of the ------------------------ system.

3.3.1 Use Case #

3.3.2 Use Case #

…

3.4 Classes / Objects

This section contains major classes of the ------------------------ system.

3.4.1 <Class / Object #1>

3.4.1.1 Attributes

3.4.1.2 Functions

<Reference to functional requirements and/or use cases>

3.4.2 <Class / Object #2>

…

3.5 Non-Functional Requirements

Non-functional requirements may exist for the following attributes. Often these requirements must be achieved at a system-wide level rather than at a unit level. State the requirements in the following sections in measurable terms (e.g., 95% of transaction shall be processed in less than a second, system downtime may not exceed 1 minute per day, > 30 day MTBF value, etc.).

3.5.1 Performance

3.5.2 Reliability

3.5.3 Availability

3.5.4 Security

3.5.5 Maintainability

3.5.6 Portability

3.6 Inverse Requirements

State any useful inverse requirements.

3.7Logical Database Requirements

This section specifies the logical requirements for any information that is to be placed into a database. This may include:

1. Types of information used by various functions
2. Frequency of use
3. (^) Accessing capabilities
4. Data entities and their relationships
5. Integrity constraints
6. Data retention requirements If the customer provided you with data models, those can be presented here. ER diagrams (or static class diagrams) can be useful here to show complex data relationships. Remember a diagram is worth a thousand words of confusing text.

3.8Design Constraints

Specify design constraints that can be imposed by other standards, hardware limitations, etc.

3.8.1 Standards Compliance

Specify the requirements derived from existing standards or regulations. They might include: (1) Report format (2) Data naming (3) Accounting procedures (4) Audit Tracing For example, this could specify the requirement for software to trace processing activity. Such traces are needed for some applications to meet minimum regulatory or financial standards. An audit trace requirement may, for example, state that all changes to a payroll database must be recorded in a trace file with before and after values.

4. Analysis Models