Please see attachment for supporting files

Add new work to SRS Draft file. The Turn in Score for other file was green @ 23 % . Please keep up good work 

Assignment Instructions

Purpose

The purpose of this assignment is to complete the Final SRS for the Case Study.

Directions

1.  Make any necessary revisions to your Preliminary Software Requirements Specification (from the Week 4 assignment) to produce your final Software Requirements Specification for the Case Study. 

2.  Complete the remaining Sections 5, 6, Appendix A, and Appendix B.Be sure to fill out all parts of the template. 

3.  For the Appendix B Analysis Models, follow the following instructions

3.1  If you used the Structured Analysis and Design Technique, add an ERD (Entity Relationship Diagram) to your existing models. Your ERD should include entities, attributes of the entities, and  relationships with names on the relationships. 

3.2  If you used the Object Oriented Analysis and Design Technique, add a class diagram to your existing models.  Your class diagram should include classes, attributes of the classes, and the relationships with names on the relationships.

4.  For the Glossary, include definitions of the items in your respective models.  

4.1  If you used the Structured Analysis and Design Technique, for the DFD include definitions for each external entity, data flow, data store, and process.  For your ERD, include definitions for each entity and include its attributes.

4.2  If you Use the Object Oriented Analysis and Design Technique, for the use cases include defnitions for each actor and use case.  For your class diagram, include the definitions for each class and include its attributes.

Submission Instructions

1.  Start with your submission for your preliminary SRS and name it like FinalSRSYourlastnameYourfirstname.

2.  Submit your assignment in the area below.

Grading Rubric

Your assignment will be graded using the Final SRS Rubric x.

Software Requirements Specification

for

Student Course Registration System,

Release 1.0

Version 1.0 approved

Prepared by

Table of Contents

iiTable of Contents

Revision History
ii

1.
Introduction
1

1.1
Purpose
1

1.2
Document Conventions
1

1.3
Intended Audience and Reading Suggestions
1

1.4
Product Scope
1

1.5
References
1

2.
Overall Description
2

2.1
Product Perspective
2

2.2
Product Functions
2

2.3
User Classes and Characteristics
2

2.4
Operating Environment
2

2.5
Design and Implementation Constraints
2

2.6
User Documentation
2

2.7
Assumptions and Dependencies
3

3.
External Interface Requirements
3

3.1
User Interfaces
3

3.2
Hardware Interfaces
3

3.3
Software Interfaces
3

3.4
Communications Interfaces
3

4.
System Features
4

4.1
System Feature 1
4

5.
Other Nonfunctional Requirements
4

5.1
Performance Requirements
4

5.2
Safety Requirements
5

5.3
Security Requirements
5

5.4
Software Quality Attributes
5

5.5
Business Rules
5

6.
Other Requirements
5

Appendix A: Glossary
5

Appendix B: Analysis Models
5

Appendix C: To Be Determined List
6

Revision History

1. Introduction

1.1 Purpose

The purpose of this software requirements specification (SRS) document is to lay out the structure and requirements for a Student Course Registration System (SCoReS). This is the first release (Release 1.0) of the software. Important to note is that this document is the utmost authority that will provide directions for the implementation of the software. This SRS describes the entire SCoReS system. As such, all the instructions and information specified here should be considered with the utmost seriousness they deserve.

1.2 Document Conventions

All the information shared in this document is high priority. However, any requirement that is underlined or in bold suggests its priority is higher than all the other information shared. Further, any information written in italics is pure commentary and should be regarded as having a small significance as far as priority of information is concerned.

1.3 Intended Audience and Reading Suggestions

This document provides information that should be helpful to the project managers. These people will take up the challenge of ensuring that the Student Course Registration System is fully functional. As such, they need as much detail as they can get to ensure that the implementation process is smooth and streamlined. Other people that might have interest in the document are documentation writers. However, anybody else that might develop interest in the SRS of the Student Course Registration System should find this document helpful.

This document is organized in a structured manner, where it provides a general description of the software in the overview section. The overview section describes the perspective and functions of the program as well as the classes and characteristics of the users. However, the document begins to get into the raw details including a description of the operating environment any constraints that may be met, and other dependencies that might be significant. Other sections of the document describe specific aspects of the software like interface requirements, features of the system, and requirements that are nonfunctional. It is suggested that a reader of this document begins from the first page to the last in that order because a lot information shared in the first five pages are crucial to understanding the information in the pages that come aft.

1.4 Product Scope

The Student Course Registration System targets college students where it will help them to register for courses and to mark attendance in class without having to rely on pen and paper. Working with other solutions like CCTV cameras, International Mobile Equipment Identification (IMEI) number, and other biometric equipment, the registration system should allow the management of students to ensure that they do not skip lessons and let their friends fill out the registration forms for them. The technology ensures that only the real student can fill out the information about them.

1.5 References

Shao, X., & Purpur, G. (2016). Effects of information literacy skills on student writing and course performance. The Journal of Academic Librarianship, 42(6), 670-678.

https://doi.org/10.1016/j.acalib.2016.08.006

Richards, K., Spagnolo, A., Cronise, R., & Backs, A. (2019, July). How Instructional Design and User-Interface Principles Helped Us Develop an Online Academy for Learners with Mental Illness. In Global Learn (pp. 239-247). Association for the Advancement of Computing in Education (AACE).

2. Overall Description

2.1 Product Perspective

Currently, students mark their attendance manually by using pen and paper. Besides wasting a lot of time, marking lecture attendance manually does not capture comprehensive details about the students, like how long they stay in class or if they actively participate in class activities during lectures. Therefore, the Student Course Registration System acts like a central repository that captures the activities of the students from class attendance, course selection and participation in class during lectures, as shown in Figure 1. According to Shao and Purpur (2016), the more active the students participate in class, the higher the rate of information retention.

The students are expected to access the system through their mobile devices by first connecting to the internet. As they continue to use it, new releases of the system will come out to streamline issues like program crashing when traffic is at its peak.

2.2 Product Functions

The product performs a number of functions, which include allowing the students to request registration (to mark their class attendance). After registration, their information on the system is updated and the student is marked present. On the other hand, the system allows the IT department of the college to receive course/class registration request. The IT department is able to respond to the request after verifying the information entered by the student. If the information is correct, the IT department will approve the request, otherwise they will reject it. Other functions of the system include managing the student information, course information, and a streamlined interfacing of activities among the users.

Student registration request

Course Catalog

Registration

request

marked present

student registration

response

Information retrieval request

Figure 1: Context diagram for Student Course Registration System (Release 1.0)

2.3 User Classes and Characteristics

Student – Student is the learner at the institution who wishes to mark their presence during a lecture. The student is also the user who is interested in registering for a certain course such that he or she can receive an access code to register for relevant classes. The academic institution has approximately 5,690 students and all of them are expected to use the system to register for courses and to mark their presence in class. Each student has an average of three classes in a day; hence, they will need to access the system three times on average in a single day. However, students might need to access the platform more than three times in day to sample the catalog of courses on the system. More than 70% of the students are expected to use their smartphones to access the system while the remaining may access the platform through the institution’s computers that are connected to the school’s intranet. Of the remaining 30%, a small percentage may access the system through computers in cyber cafes and other locations.

IT department – this is the entity that is in charge of maintaining the Student Course Registration System. The institution’s IT specialists will be on hand to respond to registration requests from students. Additionally, the specialists will address any glitches that arise regarding optimal functionality of the system. The IT department will also give lecturers access to the platform, whether through opening an account for them or by simply using the lecturers to facilitate the usage of the platform by the students.

2.4 Operating Environment

There are three operating environments for the Student Course Registration System (SCoReS).

First Operating Environment: Web Browsers

SCoReS shall operate on web browsers on all platforms, mobile and desktop. Particularly, the SCoReS system shall operate on Mozilla Firefox version 71.0 for desktop platform, and Firefox version 21.0 for iOS platform and version 68.3.0 for Android platform.

The product will also operate on Google Chrome for Windows desktop platform, version 79.0.3945.88, Chrome version 79.0.3945.88 for the macOS platform, Chrome version 79.0.3945.88 for Linux, Chrome version 79.0.3945.93 for Android mobile platform, and Chrome version 79.0.3945.73 for iOS mobile platform.

Additionally, the product shall operate on Microsoft Edge version 44.18362.449.0 (for Windows 10 desktop) and version 40.15254.369 (for windows 10 mobile). The product shall also operate on internet explorer version 11 (for windows 10 PC), internet explorer version 11.0 (for windows 8.1, windows RT 8.1 for desktop platform), and internet explorer version 11.0 for Windows 7 PC.

Other web browsers on which the product shall operate include Safari version 13.0 for macOS platform and version 13.0 for iOS, Opera version 65.0.3467.78 for desktop and version 55.2.2719 for Android, and Yandex version 19.7.3.172 for Windows PC, version 19.6.0.1583 for macOS, version 19.12.2.263 for iOS, and version 19.10.4.187 for Android.

Second operating environment: Server

The product shall operate on two servers. The first one is Windows Server version 1809 and the second one is the latest version of Red Hat Enterprise Linux (RHEL).

Third operating environment: Institutional intranet and institutional firewall

Users have two avenues through which they can access the SCoReS system. First, they can do so through the institution’s intranet. Alternatively, the users can access the system through other internet connections but they must be routed through the institution’s firewall.

2.5 Design and Implementation Constraints

· HTML5 shall determine the HTML code of the product

· The language for scripts shall be JavaScript, Java, C++, and Python

· The product shall utilize the SQL server database engine

2.6 User Documentation

The product shall be incorporated with clearly illustrated help systems to guide the users through for optimal utilization of the product. The illustrations will describe the functions of the product in great detail and in a way that all users (technical and non-technical) will understand.

Additionally, the product will be incorporated with ample educational material focused on proper and optimal utilization of the system. The system will provide an illustrated document in pdf file format that is downloadable for the users to familiarize themselves with the platform. Further, there shall be video tutorials that are specially designed to take new users through the product, its functions, and characteristics.

2.7 Assumptions and Dependencies

The first assumption is that the at least half of the 5,690 are in session for every semester. Another assumption is that the usage of the system will be compulsory and that the college administration will enforce the requirement. Lastly, the college will use the product as the sole system for managing the student register, class attendance and course registration.

SCoReS’ operation depends on the alterations that students make to register for new courses or to opt out of a course. Another dependency is the alterations that the IT department makes in while they respond to registration requests from students. In addition, the IT department may make changes on the course catalog by adding, removing, or altering the content of a course.

3. External Interface Requirements

3.1 User Interfaces

The user interface is designed in a way that livens up the user experience of the front-end users. According to Richards, Spagnolo, Cronise and Backs (2019, July), the user interface of a software product is essential since it determines the kind of first impression that it will have on the users. To that end, the product shall use the latest version of Cascading Style Sheets (CSS) to create interactive and interesting windows.

In addition, the product shall abide by certain graphical user interface (GUI) standards like visibility of the status of the system. This way, the users will always know everything about the operations of the system. Further, the product shall abide by other GUI standards like giving control to user as well as the freedom to navigate the interface without too many constraints. Other standards include preventing errors, efficiency of use and flexibility, and documentation to assist the users to optimize the usage of the product.

3.2 Hardware Interfaces

The product will be compatible with all hardware components of the system, both for the mobile and PC platforms. In addition, the software shall support all data types, especially .txt, .xls, and x formats.

3.3 Software Interfaces

To be determined

3.4 Communications Interfaces

The product shall have an email function where users can send messages to the IT department to ask for assistance. In addition, any changes to the product will be communicated via email to all users, both at the back end and at the front end. Particularly, the product shall support the plain text format for all messages. On network server communication, the standard communication protocol shall be HTTP.

4. System Features

4.1 Course Registration

4.1.1
Description and Priority

This feature is of the highest priority. The system is designed to ensure that students sit through classes to the end such that they can retain a lot of content. If course registration fails, the whole system will be non-functional. The cost of such a failure is the complete shutdown of the product.

4.1.2
Stimulus/Response Sequences

Stimulus:
Student requests to register for a course.

Response:
Student is prompted to provide course details and personal details.

Stimulus:
IT specialist requests to change details of a course catalogue.

Response:
System may accept or reject the request.

4.1.3
Functional Requirements

REQ-1: Registration request – once the student logs in the SCoReS platform, the system prompts him or her to register for a course.

REQ-2: Request to mark attendance – the student shall be requested to mark themselves present for the classes under the registered course.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

Many students log in during the morning hours because most classes take place during the period. As such, the system shall allow for 700 users at a time at peak between 6.00 am and 9.00 am (most classes begin at 8.00 am so some students might want to begin registration early). On average, a student shall spend 15 minutes to complete registration.

Student shall be able to report system errors automatically and the IT department shall address the errors within 20 minutes.

5.2 Safety Requirements

To be determined.

5.3 Security Requirements

To access the system, students must sign in their accounts first. This shall be required for the IT staff too. After logging in, the users will be able to perform relevant activities from within their accounts. Another security requirement is that only the IT staff of the college will have the clearance to alter the information in the course catalog. Additionally, users who want to access the system from outside the institution intranet will have to request special authorization before they log in their accounts. Alternatively, there shall be an extranet platform where users shall be required to create a new account but with the same details as those for the intranet account.

5.4 Software Quality Attributes

Availability – Students can access the SCoReS system anytime anywhere for as long as they are still members of the institution. Once they leave after graduation, the students’ data will be transferred to a new account (for the alumni) for continued use. Similarly, the new account shall be available to the users at all times without restrictions.

Maintainability – the IT staff shall be on call 24/7 to address any issues that might arise. This includes addressing system errors, system crash due to overwhelming by traffic and so on.

5.5 Business Rules

To be determined

6. Other Requirements

To be determined

Appendix A: Glossary

Registration request details – full name of the student, school registration number, date of birth (DD/MM/YY)

Student registration response – a notification detailing the acceptance or rejection of the registration request

Student serial number – 8-digit number generated randomly on registration success

Appendix B: Analysis Models

Student cancels registration request

IT staff processes request

System requests registration details

System fails to approve details

System approves registration request

Figure 2: Analysis Model for SCoReS system

Appendix C: To Be Determined List

i. Software interfaces

ii. Software requirements

iii. Business rules

iv. Other requirements

Course Management Information System (Course Manager)

College IT department

Student

Student Course Registration System

Student data availability information

Student Information Database

Request cancelled

Registration request accepted

Request processed

Registration failed

Course details and student personal details

Course registered

Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

Student effectively completed the assignment.

Student partially completed the assignment.

The student provided limited and meaningless substance completing the assignment.

Student failed to complete the assignment.

Student effectively completed the assignment.

Student partially completed the assignment.

The student provided limited and meaningless substance completing the assignment.

Student failed to complete the assignment.

20