A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains non-functional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).
[edit] General Outline of a SRS
Software Requirements Specifications (SRS)
Cover Page
Revisions Page
Table of Contents
1 INTRODUCTION
1.1 Product Overview
1.2 Purpose
1.3 Scope
1.4 Reference
1.5 Definition And Abbreviation
2 OVERALL DESCRIPTION
2.1 Product Perspective
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 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Protocols
3.1.5 Memory Constraints
3.1.6 Operation
3.1.7 Product function
3.1.8 Assumption and Dependency
3.2 Software Product Features
3.3 Software System Attributes
3.3.1 Reliability
3.3.2 Availability
3.3.3 Security
3.3.4 Maintainability
3.3.5 Portability
3.3.6 Performance
3.4 Database Requirements
3.5 Other Requirements
4 ADDITIONAL MATERIALS
SRS for UMS (University Management System):
1. GENERAL DESCRIPTION – UMS is University Management System for managing the records of the alumni of the university as well as staff, faculty and higher authorities.
1.1 Purpose – The purpose for developing this type of software or introducing this UMS is to facilitate everyone who is concerned with the university.
1.2 Scope – The scope of UMS is global i.e. it should be able to be accessed from anywhere through internet i.e. registered users must be able to login to their accounts by directly accessing the university’s website and then signing in with their username and password anytime and anywhere.
1.3 Abbreviation – UMS University Management System
1.4 Overview – As the ums is able to have a user interface. It should have a drop down boxes and if we drag mouse on any control at our welcome screen information regarding that the control should be displayed. Help menu should be there. As a teacher it should provide them to upload the various assignments and the attendance of the students. As a developer it should make a user interface which is user friendly. He should make the UMS as simple as he can. Backup at the main server should be made.
2. OVERALL DESCRIPTION
2.1 Product Perspective – product i.e. UMS should be able to provide a basic and easy interchange of information i.e. it should be able to remove the communication gaps between a teacher and the student. It should have chat facilities for all the users that are online. It should be compatible with all the operating systems.
2.2 Product Functions - The following are the product functions of the UMS:
The UMS login box should on the official website of the university.
The password field should be secured.
After signing in all updates and new announcements for users should be displayed.
By clicking on the dropdown box of the options the user should be able to view progress reports, assignments, notes, attendance, placement services and results.
User should be able to change the passwords.
Web pages should support pdf, ppt, doc and similar supported formats so that they can be easily downloadable and unloadable.
2.3 User Characteristics – A user can only have his/her registration number as username so if he joins the university then only he can login. This prevents misuse, unauthorized access and hacking of the product.
2.4 General Constraints – Server capacity is how many users can access or can be online at once. More is the number of users more will be the network traffic and hence the server comes in a down state. Personal firewall and updating is a tough task, it should be such that it should not block the network traffic, making the system slower. Firewall of the UMS should not collide with the firewall of the user system.
2.5 Assumptions and Dependencies – UMS should work even at when the network traffic is high. Server should have a power backup as well as a database backup. The UMS should be compatible with most of the operating systems i.e. previous and latest ones.
3. SPECIFIC REQUIREMENTS
3.1 External Interface Required
3.1.1 User Interfaces – The external users are the students and the teachers of the university. The students can have an access to their accounts for their attendance, assignments etc. The teachers have also an account to access their account for uploading of the students’ attendance and the assignments to be submitted by them.
3.1.2 Hardware Interfaces – The external hardware interface used for accessing the UMS is the personal computers of the teachers and the students. The PCs may be laptops with wireless LAN as the internet connections provided will be wireless.
3.1.3 Software Interfaces – The Operating Systems can be any version of Windows, Linux, Unix or Mac which supports TCP/IP protocols.
3.1.4 Communication Interfaces – The communication interface is a local area network through wireless network routers.
3.2 Performance Requirements – The PCs used must be at least Pentium 4 machines so that they can give optimum performance of the product.
3.3 Design Constraints – The constraints at the designing time are that the needs of the university students and the teachers may keep on changing so the designers must keep this in view and design the product in this way that it is easily updatable.
3.4 Attributes – The following are the attributes of the product UMS:
It should be equipped with current and archive database.
All records can easily be updated.
It should have its personal firewall.
It should facilitate student with updating his/her account, downloading or uploading of assignments from anywhere.
It should also do the same for teachers they can also have their pay checks online i.e. UMS should be capable of online transaction.
3.5 Other Requirements – The software is such that as the time goes by the need of the university management, students and teachers may keep on changing thus it is made to change from time to time.
Tuesday, June 1, 2010
software requirements
Posted by enny efafiqa at 7:29 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment