requirement analysis document (rad)sims/sims rad.pdf · zfg requirement analysis document (rad)...

ZFG Requirement Analysis Document (RAD)

Requirement Analysis Document (RAD)

Project: Student Information Management System

1


Purpose of the document

This document mainly discusses the functionalities of the proposed system and its

advantages over the existing system. An overview of the proposed system and its functional and

nonfunctional requirements demanded by the stakeholders are provided in the document. Use

cases, sequence diagram, and the user interface mockups of the proposed system are also

included to illustrate the situation or condition of the proposed system being used by the users.

The last sections of this document which include summary and glossary serve as a reference for

the stakeholders.

Ultimately, this requirement analysis document serves as a legal agreement (a binding

contract) between Southern Illinois University Carbondale Department of Computer Science and

team ZFG in developing a student information management system to solve real-world

problems.

2


About the RAD Document Version Control

Version No. Name (Title) Author Date Authorization

1.0 RAD Report Zhi Kang Wong 12/18/2018 Michael Barkdoll

2.0 RAD Report Zhi Kang Wong Fan Wu

1/20/2019 Michael Barkdoll

3.0 RAD Report Zhi Kang Wong Fan Wu Gabriel Alvarez

2/24/2019

Document Properties

Items Details

Document Title ZFG Requirement Analysis Document

Author Zhi Kang Wong

Creation Date 12/18/2018

Last Updated 2/24/2019

3


Table of Contents

1. Introduction 5 1.1 Purpose of the system 5 1.2 Objective and Success Criteria of the System 6 1.3 Existing System 6

2. Proposed System 8 2.1 Overview 8 2.2 Functional Requirements 9 2.3 Nonfunctional Requirements 17 2.4 System Models 19 2.5 Dynamic Model 37 2.6 User Interface Mockups 52

3. Summary 61

4. Glossary 62

4


1. Introduction

1.1 Purpose of the system

The purpose of this system is to allow users to manage student-related information. A

primary user like department staff could manage submitted student exit survey for ABET

accreditation purpose. Besides that, staff could perform course scheduling and export the final

version of schedule into PDF or Excel Spreadsheet to notify the department, faculty, and students

regarding courses’ title, professor, location, time, etc. that are offered in the semester. The staff

could also update graduate student’s thesis or project option when requested by the student and

inform the changes to users such as faculty, graduate program director, thesis advisor, and

project advisor. Generally, users can use the system to search, sort, add, update, and delete

student-related information according to their assigned roles. For example, users with student

role and currently in their final semester could fill in the exit survey and submit to staff through

the system to fulfill the graduation requirement. Students could also update their interests in the

respective major on their profile to establish the connection with other users with similar

interests. Other roles like graduate program director, undergraduate program director, faculty,

thesis advisor, and project advisor could view student’s information and perform role-specific

tasks.

5


1.2 Objective and Success Criteria of the System

The objective of the system is to increase user productivity and accessibility in managing

student-related information. The system’s success criteria would be a single-page application

(SPA) that is reactive, scalable, adjustable, and functional being developed according to

stakeholders’ requirements. Multi-users will also be enabled to access the system concurrently

and in real-time. Student Information Management System will be an all-in-one system so that it

could allow users to perform tasks such as inserting data from the exit survey into the database,

updating student’s thesis option, planning course schedules for the subsequent semesters, etc.

within a single webpage instead of visiting another web page to achieve similar tasks.

1.3 Existing System

The existing system developed by the previous faculty is decrepit and contains numerous

software bugs or problems. For example, the student exit survey in the current system will

experiences data lost if the users switch to a different interface without saving the entered data.

The presence of system bugs and lacking user-friendly interface decrease the productivity of

current users in handling student information. In addition, the existing system no longer receives

maintenance and support due to the absence of the developer. Thus, developing a new system is

necessary.

The new proposed system will be solving the above problem and provide additional

features such as course scheduling for the specific users. Instead of being an outsourced

development, the new proposed system will be developed in-house to allow the stakeholders to

modify and improve the system with convenience in the future. The new Student Information

6


Management System will also be more user-friendly than the existing system to assist users with

a less technological background in using it efficiently.

7


2. Proposed System

2.1 Overview

ZFG team’s proposed system is classified as a web application. Hence, we will be using

frameworks including Angular 6 as the system’s frontend and ASP. NETCore as the backend.

Other tools such as MySQL, Bootstrap, HTML, CSS, etc. will be playing a major role in data

storage and user interface design. The end product of our proposed system should allow users

like admin or staff to register new users to the system. Users can log in to the system using the

single-on feature or manually entering their username and password. After successful login,

users will have different interface and functions depending on their assigned roles. The proposed

system has important functions including register and delete users, assign a role to the user, log

in and log out, manage student exit survey, update thesis or project option, course scheduling,

searching and sorting, as well as profile editing.

The actors for this system are admin, staff, faculty, advisors, and students. Primary actors

are admin and staff as they have the most accessibility in terms of managing student-related

information such as register / delete users, role assignment, view / delete student exit survey, and

course scheduling. Other actors such as student and faculty have limited accessibility at the

moment.

8


2.2 Functional Requirements

Name FR-1 Register new user

Summary Ability to add new user accounts to the student information

management system.

Rationale Allow added users to have accessibility to the student information

management system.

Requirements The proposed system shall allow the user with a specific role such as

admin or staff to register a new user(s).

Name FR-2 Delete user

Summary Ability to delete existing user accounts in the student information

management system.

Rationale Allow user that no longer has the accessibility to be removed from the

student information management system.

Requirements Users with a specific role such as admin or staff could remove other

existing users from the student information management system.

9


Name FR-3 Assign roles to users

Summary Ability to assign different roles to different users in the student

information management system.

Rationale Users with different roles could perform different functions in the


Requirements Users with admin role can assign roles to other users in the student


Name FR-4 User login

Summary Ability for users to log in to the student information management

system.

Rationale Authenticate users before allowing them to access the student


Requirements Users shall log in to the student information management system

before use.

10


Name FR-5 User logout

Summary Ability for users to log out from the student information management

system.

Rationale Direct users to the login page when the student information

management system is no longer being used.

Requirements Users shall be able to log out from the student information

management system when finished.

Name FR-6 View the student exit survey

Summary Ability for users to view the student exit survey.

Rationale Allow users to view the submitted student exit survey in the student

information management system

Requirements Staff and admins shall be able to view the exit survey submitted by

students. Students shall be able to view the exit survey filled by

themselves in the student information management system.

11


Name FR-7 Delete the student exit survey

Summary Ability for users to delete the student exit survey.

Rationale Allow users to delete the student exit survey in the student information

management system

Requirements Staff shall be able to delete the exit survey submitted by students.

Name FR-8 Fill out the student exit survey

Summary Ability for specific users to fill out the student exit survey.

Rationale Allow users to fill out and submit new student exit survey to the

student information management system

Requirements Students shall be able to fill out and submit the exit survey to the


12


Name FR-9 Update the student exit survey

Summary Ability for specific users to update the student exit survey.

Rationale Allow users to update the student exit survey in the student

information management system

Requirements Students shall be able to update the exit survey filled by themselves in

the student information management system.

Name FR-10 Update the student’s thesis or project choice

Summary Ability for specific users to update the student’s thesis or project

option.

Rationale Allow users to update the student’s thesis or project choices and notify

other users regarding the changes.

Requirements Staff and faculty shall be able to update the graduate student’s thesis

or project option using the student information management system.

13


Name FR-11 Update the student’s thesis or project topic

Summary Ability for specific users to update the student’s thesis or project topic.

Rationale Allow users to update the student’s thesis or project topic.

Requirements Staff and faculty shall be able to update the graduate students’ thesis

or project topic using the student information management system. In

addition, staff and faculty can update the Ph.D. students’ thesis topic.

Name FR-12 Create course

Summary Ability to create a course

Rationale Allow staff to create a course for scheduling purposes

Requirements Staff shall be able to create a course for later use in populating a

course schedule for the department. Courses’ title, location, lab

session, category, section, etc can be inserted or updated.

14


Name FR-13 Course scheduling

Summary Ability to schedule courses for students easily.

Rationale Allow staff to perform course scheduling by avoiding schedule

conflicts.

Requirements Staff shall be able to schedule courses at appropriate time slot to

prevent schedule conflict. Staff shall also be able to specify the course

title, professor, location, lab, etc. while scheduling and export the final

version into PDF or csv.

Name FR-14 Searching

Summary Ability to search student’s information.

Rationale Allow users to find desired information in a minimal amount of time.

Requirements Users shall be able to search for other users by a set of given fields

15


Name FR-15 Sorting

Summary Ability to sort student’s information.

Rationale Allow users to find desired information in a minimal amount of time.

Requirements Users shall be able to sort information to retrieve specific data.

Name FR-16 Edit user profile

Summary Ability to edit the user profile.

Rationale Allow users to update their names, pictures, interests, etc. to allow

other users to be informed.

Requirements All users shall be able to edit their personal information and upload

pictures or documents. Staff and admins can also edit other user’s

profiles.

16


2.3 Nonfunctional Requirements

Name NFR-1 Fast performance

Summary The proposed system will consist of a single-page application (SPA).

Rationale The single-page application has a fast response time, which loads the

application for users without constantly refreshing.

Requirements The users will be receiving quick responses from the student

information management system with the implementation of the SPA.

Name NFR-2 High security

Summary Student information management system will enforce user

authentication.

Rationale Authentication offer security to users to protect their data from invalid

access.

Requirements Student information management system will enforce security checks

to maintain a safe environment for users.

17


Name NFR-3 High availability

Summary The student information management system should be available 24/7.

Rationale It will be convenient for users to access the student information

management system anytime and anywhere with the internet.

Requirements The student information management system will be programmed to

be available at all time unless system maintenance takes place.

Name NFR-4 User-friendly

Summary The proposed system will be visually appealing, reactive and

user-friendly.

Rationale A user-friendly system increases readability and comprehension, thus

users can use the system with ease and efficiency, even without an

advanced technological background.

Requirements Student information management system will be utilizing bootstrap to

produce a reactive and adjustable user interface for the users.

18


2.4 System Models

Use Cases of Student Information Management System

Use Case Number UC-1

Use Case Name Register new user

Description Allow users to add new user accounts to the student information

management system

Participating Actor Admin and staff

Entry Condition Users must be logged in to the system and select the register new user

feature on their interface

Flow of Events 1. Insert new user’s username, password, and other information

into respective text fields on the registration page.

2. Click the register button.

3. The system will perform an existing user check

4. Registration successful and user entry is entered into the

database.

Alternate Flow 2.b User selects cancel: Registration is aborted and registration

fields are cleared.

4.b If an user already exist with info provided: System will inform

the user of such error.

Exit Condition New user is registered successfully or user selects the cancel button

19



Use Case Name Delete user

Description Ability to delete existing user accounts in the student information

management system


Entry Condition Users must be logged in to the system and select the delete user

feature on their interface

Flow of Event 1. Choose the user(s) to be deleted.

2. Click the delete button

3. Click delete after safety check: System will delete user entry

from database.

Alternate Flow 3.b Click cancel when prompted: System does not delete the user.

Exit Condition Existing user(s) is deleted successfully or cancel button is selected

20



Use Case Name Assign roles to users

Description Ability to assign different roles to different users in the student



Entry Condition User must be logged in to the system and select the assign role feature

on their interface

Flow of Event 1. Select the user for role assignment.

2. Select the role(s) that are suitable to the user.

3. Click the save button.

Alternate Flow 3b. Click the cancel button: Changes are not saved

Exit Condition User clicks save or cancel button.

21



Use Case Name User login

Description Ability for user to login to the student information management

system.

Participating Actor Any user

Entry Condition Proceed to the main page/website of the application

Flow of Event 1. Input the username and password.

2. Click the login button

3. The system will verify the user’s credentials.

4. The system will display the home page with different

functions according to the user’s role.

Alternate Flow 4b. Entered credential are incorrect: Unauthorized to enter

Exit Condition User is successfully logged in or login is canceled

22



Use Case Name User logout

Description Ability for user to log out from the student information management

system


Entry Condition User must be logged in to the system

Flow of Event 1. Click the logout button from the settings.

2. The system will then direct the user to the login page.

Exit Condition User is logged out successfully.

23



Use Case Name View the student exit survey

Description Ability for users to view the student exit survey.

Participating Actor Admin, staff, faculty, student

Entry Condition User must log in to the system

Flow of Event 1. Click the student exit survey button.

2.

2.1. The user logged in as a student.

2.1.1. Click the view button.

2.1.2. The user can view the survey filled by

themselves.

2.2. The user logged in as admin, staff, or faculty.

2.2.1. The user can see all submitted survey in the

student information management system

2.2.2. Select one of the submitted surveys.

2.2.3. Click the view button.

2.2.4. The user can see the specific submitted survey.

Exit Condition The student exit survey is viewed.

24



Use Case Name Delete the student exit survey

Description Ability for users to delete the student exit survey.

Participating Actor Admin, staff



2. The user can see all the submitted survey in the student


3. Select one of the submitted surveys.

4. Click the delete button.

Alternate Flow 4b. Click cancel button: Survey is not deleted

Exit Condition The student exit survey is deleted or cancel button clicked.

25



Use Case Name Fill out the student exit survey

Description Ability for users to fill out the student exit survey.

Participating Actor Student



2. Click the fill out button.

3. Answer survey questions.

4. Click the submit button.

Alternate Flow 4b. Click cancel button: No entry is made for student.

Exit Condition The student exit survey is filled out or cancel button clicked.

26



Use Case Name Update the student exit survey

Description Ability for users to update the student exit survey.

Participating Actor Student



2. Click the update button.

3. Update survey questions.

4. Click the submit button.

Alternate Flow 4b. Click cancel button: Any changes are not saved.

Exit Condition The student exit survey is updated or cancel button pressed.

27



Use Case Name Update the student’s thesis or project choice

Description Ability for specific users to update the student’s thesis or project

option.

Participating Actor Admin, staff, thesis advisor, project advisor

Entry Condition User must be logged in to the system and hold correct role.

Flow of Event 1. Click the thesis/project button.

2. Select one graduate student.

3. Click the thesis or project choice.

4. Click the save button.

Alternate Flow 4. Click cancel button: Update is canceled.

Exit Condition Thesis or project choice is updated successfully.

28



Use Case Name Update the student’s thesis or project topic

Description Ability for specific users to update the student’s thesis or project

topic.

Participating Actor Admin, staff, thesis advisor, project advisor


Flow of Event 1. Click the thesis/project button.

2. Select one graduate student.

2.1. Enter the thesis or project topic.

2.2. Click the save button.

3. Select one Ph.D. student

3.1. Enter the thesis topic.

3.2. Click the save button.

Exit Condition Thesis or project choice is updated successfully.

29



Use Case Name Create course

Description Ability to create a course



Flow of Event 1. Select the course scheduling function.

2. Select add course action.

3. Insert course information into input fields.

4. Click create button: System will create entry in the database

Alternate Flow 4.b Click cancel: Creation is aborted.

Exit Condition Course is created or process is cancelled

30



Use Case Name Course scheduling

Description Ability to schedule courses for students easily.



Flow of Event 1. Select the course scheduling function.

2. Users with granted access can drag and drop courses into

respective time slots.

3. While scheduling courses, student information management

system will check for schedule conflict and notify users if both

different courses scheduled at the same time and location.

4. Click save button: Scheduling will be saved into the database.

Optional Click on create Excel: Excel file will be created.

Alternate Flow Click cancel at any time: System makes no changes

Exit Condition Course schedule is saved, cancelled, or exported.

31



Use Case Name Searching

Description Ability to search



Flow of Event 1. Staff, faculty, advisors, etc. select which field they would like

to search by.

2. User enters value into search field

3. System retrieves all entries that match input value and displays

results.

Alternate Flow 3.b If there are no results system will inform user.

Exit Condition Searched results are displayed on the interface

32



Use Case Name Sorting

Description Ability to sort search results.



Flow of Event 1. Staff, faculty, advisors, etc. select which field they would like

to sort by.

2. System will rearrange results based on which field they select

Exit Condition Sorted results are displayed on the interface

33



Use Case Name Edit user profile

Description Ability to edit user profile.



Flow of Event 1. User selects the edit profile function.

2. User can update which ever field they would like.

3. Click the save button to confirm saved changes: System will

update user entry.

Alternate Flow 3.b User clicks cancel: Editing is aborted and changes are not

saved in the database.

Exit Condition User profile is edited successfully or aborted

34


Use Case Diagram

35


Class Decomposition

36


2.5 Dynamic Model

Sequence Diagram for Use Case 1: Register New User

37


Sequence Diagram for Use Case 2:Delete User

38


Sequence Diagram for Use Case 3:Assign Roles to Users

39


Sequence Diagram for Use Case 4:User Login

40


Sequence Diagram for Use Case 5:User Logout

41


Sequence Diagram for Use Case 6: View Student Exit Survey

42


Sequence Diagram for Use Case 7: Delete Student Exit Survey

43


Sequence Diagram for Use Case 8: Fill Out Student Exit Survey

44


Sequence Diagram for Use Case 9: Update Student Exit Survey

45


Sequence Diagram for Use Case 10 and 11: Update Student’s Thesis or Project Choice and Topic

46


Sequence Diagram for Use Case 12: Create Course

47


Sequence Diagram for Use Case 13: Course Scheduling

48


Sequence Diagram for Use Case 14: Searching

49


Sequence Diagram for Use Case 15: Sorting

50


Sequence Diagram for Use Case 16: Edit User Profile

51


2.6 User Interface Mockups

UI Mockup for Login Page

UI Mockup for Main Page (Staff / Admin)

52


UI Mockup for Main Page (Faculty)

53


UI Mockup for Main Page (Advisor)

54


UI Mockup for Main Page (Student)

UI Mockup for Register User

55


UI Mockup for Delete User

56


UI Mockup for Manage Student Exit Survey (Staff / Faculty)

UI Mockup for Manage Student Exit Survey (Staff / Faculty / Student)

57


UI Mockup for Assign Role to User

UI Mockup for Update Thesis / Project

58


UI Mockup for Course Scheduling

59


UI Mockup for Searching and Sorting

UI Mockup for Edit User Profile

60


3. Summary

Currently, the majority of the functional requirements, use cases, sequence diagrams, and

user interface mockups listed in this document are focused toward our primary client, staff from

Southern Illinois University Carbondale Department of Computer Science. For example, staff

could access to specific features including register user, delete user, assign role to user, manage

student exit survey, update thesis or project, and course scheduling. Other users such as faculty

and student could access different features as well. General feature like user login / logout, edit

profile, etc. are available to all users. Additional functional requirements, features and other

related diagrams will be included in this document in the future.

4. Glossary

Actor: Any person who will be using the system.

Functional Requirement: Interactions between the system and its environment independent of

its implementation.

Mockup: scale or full-size model of a design or device, used for teaching, demonstration, and

design evaluation.

Nonfunctional Requirement: User-visible aspects of the system that are not directly related

with the functional behavior of the system.

Sequence Diagrams: Behavior of a use case (or scenario) that is distributed among its

participating objects.

61


Use Cases: Abstraction that describes a class of scenarios.

User Interface: the means by which the user and a computer system interact, in particular the

use of input devices and software.

62

requirement analysis document (rad)sims/sims rad.pdf · zfg requirement analysis document (rad)...

Documents