Non-functional requirements are what we require from a customer or organization to produce and deliver the software, what users require in order to use our software, and what our customers require from us to produce and deliver the software that is not related to the functionality of the software. Lastly there are the requirements of our software that do not fall under formal specification.
First, these are the non-functional requirements demanded of us (the developers):
Next, the requirements we demand of the customer (Professor Fisher):
Then, the requirements demanded of the users (professors and students):
Lastly, the requirements demanded of the software:
System performance for the Grader will vary depending on the user command. The following classes of commands are expected to be effectively instantaneous and will not require a long waiting period: New commands, Edit commands, and View commands. Although a New command may take from two to three seconds for larger data structures, such as a new Course, most will respond immediately upon a click. Edit commands will always be instantaneously effective, and View commands may take up to four seconds for large seminar classes (eg- over 200 students).
Other commands are computationally heavy and will require a longer time to respond. The following commands will take from several to a dozen seconds to respond, in ascending order: Class Statistic Tools, Save/Open commands, Template Commands, Publish Gradebook, Grade History, and Import Roster. There are caps to each of the previous commands in terms of computational time. No command is allowed to run for over twelve seconds. Save/Open commands are capped at eight seconds, and the largest cap is Import Roster at twelve seconds. Import Roster's timeout is the largest due to the requirement of interacting with an outside server. Upon timing out, Grader will display a System Not Responding message to the user, indicating that the User must opt to either allow it to continue running or end the process.
A large factor of system performance is stored data. The more data that a component of the Gradebook needs, the longer it takes to Create, Edit and Manage. The ascending order of file sizes for a Gradebook is as follows: Categories, Assignments, Students, and Courses. A category is merely a title field and a number of links to various assignments, so it takes little data to make and manage new categories. An assignment is similarly small due to the number of data fields that compose it. A Course, on the other hand, must manage all of the data fields listed before it, so creating and editing a Course will take longer because it is a larger data structure.