SRS-Team-1

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

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

○ The project is not limited by language requirements as the software will only be a prototype tested by a relatively small number of staff assumed to be able to understand English. ● Communications Protocols ○ There are no limitations in what communications protocols the developers can use as they are not outlined in the technical overview. ● Security Considerations ○ To align with FERPA guidelines, security may limit some implementations of features in this project. ○ However, since the project is only going to deliver a basic system with limited security, security should not hinder development too much as focus is put more on functionality ● Conventions (design or programming standards) ○ The developers are limited to be using a simple coding convention that must be conformed to, but do not have to follow an existing web design standard. ○ The developers are limited to using WAMP (LAMP or MAMP is also allowed) as their development environment using PHP as the programming language. ○ The database used is also limited to using MySQL. 2.6 User Documentation This section describes the user documentation requirements for this project:  User documentation is not included in the prototype as the client specifically requests not to do so. As a result, no standards are needed for this project.  However, the client requested documentation that describes a front-end web server and back-end database server running the WAMP environment, so the developers need to take that part of the deliverable into consideration. 2.7 Assumptions and Dependencies This section of the document describes assumptions and dependencies that might cause issues or limitations, as well as adding constraints to the development:  Since the development environment for testing purposes is limited to the WAMP server, the developers could be potentially limited if drawbacks occur, such as a network failure.  It is advised that the developers do frequent backups in case of an operating system corruption occurring in the servers.  The database should not be needed to be backed up frequently as it will not contain any actual student data.  The queries to modify or gather data from the database, however, must be documented and backed up in server storage.  Since all the components used in the development are open-source, commercial licenses should not be an issue. 9

essential, but not necessary for all the other features to function. o Benefit: 5 (Useful)  Once the data is added to the database, this feature will be utilized less frequently than some of the others. o Cost: 7 (Expensive)  This step involves complicated software checks and physical space in the database. o Risk: 2 (Innocuous)  This case has no notable serious risk factors. Precondition(s) ● The system must be in a logged-in state as administrator Main Flow of Event(s) 1. The use case begins 2. The admin enters all required information for a new student record (SID, last name, first name, middle name, address, city, state, zip, cellphone or work phone or both, major, and loan status) 3. The SID value is validated by the system 4. The admin commits the action 5. The use case terminates Postcondition(s) ● The system will remain logged-in as an administrator with an additional record saved in the database Exceptional Flow of Event(s) Omitting required information: 1. The use case begins 2. The admin omits required information 3. The commit fails 4. The use case terminates Entering an invalid SID: 1. The use case begins 2. The admin enters all required information, but the SID is not valid 3. The SID validation fails 4. The commit fails 5. The use case terminates Losing connection to the database: 1. The use case begins 2. The admin enters all required information for a new student record (SID, last name, first name, middle name, address, city, state, zip, cellphone or work phone or both, major, and loan status) 3. The SID value is validated by the system 4. The connection to the database is lost 5. The commit fails 6. The use case terminates 12

4. The connection to the database is lost 5. The commit fails 6. The use case terminates 3.5 Retrieve Records from System Retrieve Records from System Description and Priority  Allows for records to be retrieved from database and displayed based on search criteria  System/data administrators, faculty, and parents/students can participate in this use case  Priority Rating: High o Priority: 7 (Primary)  No other features rely on this use case, but it is very valuable on its own. o Benefit: 9 (Crucial)  The database system is virtually useless without the ability to view and retrieve data. Having access to data is crucial to the value of the system. o Cost: 4 (Typical)  This use case presents no factors that majorly effect the cost. o Risk: 3 (Innocuous)  If appropriate privileges are in place, this feature presents no serious risks. Precondition(s) ● The system must be logged-in as a system/data administrator, a faculty member, or a parent/student o If logged-in as admin: access to all records o If logged-in as faculty: access to all records o If logged-in as parent/student: access to personal student record(s) ● At least one record must exist in the database system Main Flow of Event(s) 2. The use case begins 3. The user enters a complete last name or SID 4. The system checks if the name or SID exists in the database 5. The system displays all data items for records that match the search criteria (records are sorted by last + first + middle) 6. The use case terminates Postcondition(s) ● The system remains logged-in Exceptional Flow of Event(s) Incomplete or non-existent query: 1. The use case begins 2. The user enters an incomplete or non-existent last name or SID 3. The system check fails and outputs an error message 4. The use case terminates 15

Figure 4.1 Sample login page Mock Database Interface 18

5. Nonfunctional Requirements Andrew Pechin 5.1 Performance Requirements  The system response time should be within 3 seconds of application startup. Having a database system take too long to boot up will reduce overall value and cost effectiveness.  System throughput, assuming the server runs on a basic, 4 core CPU, should allow over 1700 operations per second. Throughput should be able to easily accommodate users and the PHP application.  Considering the relatively small pool of potential users, system load should be easy to accommodate. Furthermore, the client has specified their server hosting the application will provide sufficient performance.  A MySQL database supports up to 2GB of data. The server hosting the prototype should be able to accommodate the size of the database as well as the application.  Any other technical performance requirements are assumed to be met by the software and hardware systems provided by the client. 5.2 Safety Requirements  Ensure only allowed personnel may access the client’s server to ensure configurations are consistent and not mishandled.  Servers must be stored in a secure location on-site and monitored.  Backups of the student information databases should be made regularly, at least once a day.  Before any changes can be made to the database, user confirmation is required. This is done through a commit button that ensures the integrity of the database data. 5.3 Security Requirements  Usernames and passwords should be stored in a secure manner to prevent the loss of data confidentiality.  Logs of failed logins as well as database logs regarding any manipulation of data should be generated.  Cryptographic hashing algorithm SHA-256 should be adopted for all hashes. MD5 and SHA-1 should be avoided due to their ease of compromise.  The prototype must be FERPA compliant and certified. The database must include information regarding students’ FERPA eligibility.  Ensure the application handles exceptions by treating them as disallowed operations.  Input validation must be implemented.  Ensure all outputs are sanitized. 21

 Assign new users with least privileges. 5.4 Software Quality Attributes Additional Quality Characteristic Description Modifiability During the development phase of the PHP application, ensuring low coupling and high cohesion will allow the software to be easily modifiable. Implementation of this idea may look like dividing the delete student operation into a search function and a delete function. This would allow the search function to be used in multiple areas of the code, allowing for easily modifiable code. Performance Changing the application performance mainly involves hardware changes. While efficient code can increase response time. Hardware changes like upgrading the core count of the server CPU can increase throughput, thus leading to greater load tolerance. Security Security practices aim to increase the immunity and resilience of systems. Security techniques like input validation or middleware to reduce attacks like PHP-injection as well as hashing with SHA-256 to deter intrusion would increase immunity and resilience. Reliability The mitigation and elimination of faults and failures increase the reliability of a system. Wrapping all changes to the database in a transaction through the system application would allow data changes to be undone, thus reducing faults. Furthermore, exception handling would assist in reducing failures. Robustness Recovery tactics like backups would increase the robustness of the system. Because of this, daily creation of backups would allow the system to recover quickly from catastrophic failures. Usability Keeping the user interface uncluttered and easy to use aids in the overall usability of the system. Also, the user interface will be housed apart from the server on a PHP web application, aiding the overall ease-of-use. 22

6. Other Requirements Jacob Lohman Database Requirements  Background data on each student must be entered by MVC staff for: admissions applications, contact and communications, applications for financial aid, etc.  Each student must be identified by a unique student identification number (SID)  A database file must be provided which contains a table for each team.  Tables must be populated with test data.  Changes to the database during Requirements Collection must be made by MVC personnel before the database is handed over to the development team.  Database must be accessible through a computer and mobile device Legal Requirements  All copyright laws must be followed depending on the third-party software used in development  All licensing laws must be respected depending on the third-party software used in development  Stakeholder information must be protected Reuse Requirements  Code must be commented appropriately to allow for future developers to easily comprehend code and adjust accordingly 23

Appendix A: Requirements Traceability Matrix Frans Santoso Table A.1 – Requirements Traceability Matrix Priorit y Requirem ent # by Category Description MVC Scenario Section SRS Section SDS Section STS Section 1 Prototype Scope Technical Overview 1.1 Prototype Requirements 3 1.1.1 Back-end server must be able to communicate with front-end interface Technical Overview 1 1.1.2 The prototype must work properly in the latest version of a browser selected by the developer and deployable by the client Technical Overview 1 1.1.3 The developers must conform to a simple coding convention Technical Overview 1 1.1.4 The prototype must not provide printing functionality, only the browser. Technical Overview 1 1.1.5 The minimal resolution for images must be above 640x480. Technical Overview 1 1.1.6 The first screen of the prototype must display the development team’s name and list the members of the team. Technical Overview 1 1.1.7 The team must use a development environment called WAMP using PHP as the main programming language. Technical Overview 1 1.1.8 For documentation, the developers must describe a front-end web server and back-end database server running the WAMP environment. Technical Overview 2 Data Technical Overview 2.1 Student Data Technical Overview 1 2.1.1 Database must be designed according to the schema table provided Technical Overview 2.2 Security Technical Overview 1 2.2.1 Database schema may have additional data types based on security requirements in FERPA Technical Overview 24

25

Table A.1 – Requirements Traceability Matrix cont. Priorit y Requirem ent # by Category Description MVC Scenario Section SRS Section SDS Section STS Section 2.3 MySQL Database Technical Overview 1 2.3.1 Tables must be populated with test data provided by MVC personnel Technical Overview 3 Functional Components Technical Overview 3.1 Adding Student Entries Technical Overview 1 3.1.1 Adding student entries must require a commit action Technical Overview 1 3.1.2 The SID is a school unique number and therefore must have the format and validation stated by the validation rules provided by the client Technical Overview 1 3.1.3 A name must only contain A-Z, a-z letters and must be in sentence case Technical Overview 1 3.1.4 Middle name must contain a value. If there is no middle name given, the entry must have NMI for “No Middle Initial” Technical Overview 1 3.1.5 The mailing address must not contain an international address Technical Overview 1 3.1.6 An address must only contain any letter or number, the city A-Z, a-z letters, the USPS two-digit state code, the USPS five-digit zip code, and must be in sentence case Technical Overview 1 3.1.7 Dashes, spaces, apostrophes, and periods must be allowed in the lastname, firstname, middlename, address, and city items, and must be ignored for validation purposes Technical Overview 1 3.1.8 The cell phone number and work phone number must include area code, and must not contain international codes Technical Overview 1 3.1.9 All fields are required except the two phone numbers and must require at least one of them. Technical Overview 1 3.1.10 There must be an error indicator when an attempt is made to add a duplicate SID. Technical Overview 26

Table A.1 – Requirements Traceability Matrix cont. Priorit y Requirem ent # by Category Description MVC Scenario Section SRS Section SDS Section STS Section 3.2 Querying Student Entries Technical Overview 1 3.2.1 All data items must be displayed when a record is retrieved Technical Overview 1 3.2.2 Data items must be able to be retrieved with a complete SID or complete last name Technical Overview 1 3.2.3 If multiple records are found for a single last name, then all the records with the matching criteria must be displayed Technical Overview 1 3.2.4 All lists of multiple students must be sorted by LastName + FirstName + MiddleName Technical Overview 3.3 Deleting Student Entries Technical Overview 1 3.3.1 Deleting student entries must require a commit action Technical Overview 3.4 Modifying Data in Student Entries Technical Overview 1 3.4.1 Modifying student entries must require a commit action Technical Overview 1 3.4.2 There must be an error indicator when an attempt is made to modify a non-existent SID or when a particular name is not found. Technical Overview 27

Appendix B: Analysis Models Dean Natale 1. Use Case Diagram: 28

2. Activity Diagram: 29

3. State Diagram: Appendix C: Issues List Trenton Hoisington There are many upcoming requirements that are not yet discretely specified within the document that still must be resolved.  Internationalization: The system currently only accommodates for one language.  Performance Requirements: The system must be capable of handling much traffic and many user requests simultaneously.  Security: Student and Staff data should be protected and be private.  Software Licenses: Any third-party tools used must be properly licensed  Mobile Support: The current design only supports desktop browsing. An alternative design to include mobile devices should be included for a final release. 30

Appendix D: Glossary of Terms, Acronyms, and Abbreviations Jacob Lohman Term Definition Actor person or other entity separate from the system that interacts with the system AJAX A group of development techniques using multiple technologies to create asynchronous applications API Application Programming Interface Back-end server Where the technical processes of the server occur Commit Making a set of temporary changes permanent Coupling How highly modules rely on other modules within a system CPU Central Processing Unit Database Collection of information monitored by this system Domain Location of a website FERPA Family Educational Rights and Privacy Act Front-End Everything the user interacts with GB Gigabyte Hash A function to convert one value to another HTTP (Hypertext Transfer Protocol) Protocol used to transfer data over the internet Interface A program that allows a user to interact in person or over a network Internationalization The process of making something accessible to more than one language Log Collection of data and information on all processes of a system or program 31

MVC Mountain Valley College Open Source A program that can be openly modified and shared by the public PHP General purpose scripting language Prototype Early version of a product not yet manufactured or released Query A field or option used to locate information within a database or another location Reboot To restart a system and all its processes Router A networking device that forwards/directs data packets across a network Schema Outline, diagram, or model SID Student Identification Number SIS Student Information system SRS (Software Requirements Specification) The document that describes all functions or a proposed system and constraints to operate by Ssh Secure shell SSMS SQL Server Management System SQL Domain-specific language used in programming Switch Network hardware that connects devices on a network TCP/IP (Transmission Control Protocol/Internet Protocol) Collection of network protocols used to connect devices over the internet Throughput Rate of output over a period of time Upkeep To maintain URL Naming system to access documents over the internet Use Case defines the features to be implemented and the correction of errors 32

User Someone accessing and searching within a program with specific restrictions USPS United States Postal Service WAMP (Windows, Apache, MySQL, and PHP) A virtual server used for testing WAP (Wireless Access Point) Device that forms a wireless local area network Web browser A computer program used to navigate the World Wide Web Web server Software that delivers Web pages and other documents to browsers 33