SRS-Team-1.docx | bartleby

Software Requirements Specification Team One Andrew Pechin Dean Natale Frans Santoso Jacob Lohman Trenton Hoisington February 21 st , 2022 1

Table of Contents Section/Sub-section Title Author [person(s) with primary accountability for this section] Page # 1. Introduction 1.1 Document Purpose 1.2 Intended Audience 1.3 Project Scope Trenton Hoisington 3 2. Overall Description 2.1 Product Context 2.2 Product Features 2.3 Roles/Actors and Characteristics 2.4 Operating Environment 2.5 Design and Implementation Constraints 2.6 User Documentation 2.7 Assumptions and Dependencies Frans Santoso 4 3. Functional Requirements - Use Case Descriptions 3.1 Log into Database 3.2 Add Records to Database 3.3 Delete Records from Database 3.4 Update Records in Database 3.5 Retrieve Records from Database 3.6 Log out of Database Dean Natale 10 4. Interface Requirements 4.1 User Interfaces 4.2 Hardware Interfaces 4.3 Software Interfaces 4.4 Communications Interfaces Andrew Pechin 17 5. Nonfunctional Requirements 5.1 Performance Requirements 5.2 Safety Requirements 5.3 Security Requirements 5.4 Software Quality Attributes Andrew Pechin 21 6. Other Requirements Jacob Lohman 23 Appendix A: Requirements Traceability Matrix Frans Santoso 24 Appendix B: Analysis Models Dean Natale 27 Appendix C: Issues List Trenton Hoisington 29 Appendix D: Glossary of Terms, Acronyms, and Abbreviations Jacob Lohman 30 2

1. Introduction Trenton Hoisington 1.1 Document Purpose The purpose of this document is to identify the conditions required for the prototype as well as display an early representation of the product. The program contains two major devices:  Database – to hold student or administrator data.  Web Page – to display the data within a browser environment to be manipulated by users. 1.2 Intended Audience The intended audience of this document is anyone who seeks or needs the layout of the system design and its requirements, whether it be a developer, project manager, tester, or a user.  Developer: Every developer must first view this document before making any changes or updates to the product. If a developer wishes to add or adjust requirements, this document must also be updated to reflect any changes.  Project manager: The project manager will need this document to gather the necessary requirements and allocate the tasks and goals to the team.  Tester: Any tester would require this document to ensure that the prototype met the necessary specifications and performs as intended as written out by this document.  User: The user would check to see if the developer has implemented every goal into the product as demonstrated by this document. 1.3 Project Scope The purpose of this prototype is to create a convenient environment for students, staff, and admin alike. The goal is to provide Mountain Valley College with a new and improved web Student Information System to replace the current restricting system. Users interacting with the system will be able to access the system outside of the campus and will no longer have to rely on the campus- only system. This will benefit the students and staff alike as it will improve convenience. 3

2. Overall Description Frans Santoso 2.1 Product Context This product is developed for Mountain Valley College (MVC), who is looking to replace the existing commercial Student Information System (SIS) – which is only accessible from on-campus locations – to be internet-based and universally accessible, as well as unique for the college. This product is strictly for training, a low-cost and minimal risk learning experience for the school but will have certain functionalities from the potential final product that the school is looking to develop. These functionalities will include features such as but not limited to adding new students, retrieving subsets of students for display, and deleting specific students. Figure 2.1 – System Context Diagram 4

The system context diagram shown above represents the external systems that the SIS will have to interact with to function. Since this project is only a prototype, the diagram has been significantly simplified, but it displays all the basic functionalities detailed in the technical overview of this project. The registrar staff in this diagram will also take the role of system administrators as well as students. The system will rely on various external systems, including a web browser, a web server to host said browser, and an artificial student database created by the developers to simulate a real database. The database will follow the data dictionary provided in the technical document. 2.2 Product Features Features in this prototype will only be their most basic counterparts, with limited to no additional security features. They will be summarized in the following list of major features:  Add new students  Query subsets of students  Delete specific students  Change specific students’ data Functions described above are further explained with more details in section 3. 2.3 Roles/Actors and Characteristics 5

Table 2.1 – Roles/Actors and Characteristics Table System/Data Administrator Faculty Student Frequency of Use High – Sys/Data Admins must maintain server upkeep regularly to avoid system interruptions High – Faculty manipulates student data (change grades) Low – Students have the functionality to change their personal data, which is not going to be frequently used. Subset of Product Functions Maintain web server, add/delete/modify student entries Manipulate student data, change grades Change personal student data Technical Expertise High – Sys/Data Admins must have expertise in maintaining the upkeep of back-end servers Moderate – Faculty must have at least minimal data management skills to function in this role Low – Students must have at least a knowledge of how to use an internet browser Security or Privilege Levels High – Sys/Data Admins must have administrator privileges to modify server data, start, shutdown, and reboot servers Moderate – Faculty must have at least system privileges to add modify student data (grades) Low – Students do not require any security or privileges other than to modify their own accounts. Experience High – Sys/Data Admins must have high experience in the system administration field to reduce crucial crashes or data loss Moderate – Registrar staff must at least have minimal experience in data management systems to prevent unwanted student data modifications Low – students must at least have experience in using web browser applications to browse the Internet 6

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help