Srs 1

Software Requirements Specifications Document
CS438 Software Engineering
Software Requirements Specification (SRS) Template
Items that are intended to stay in as part of your document are in bold;
explanatory comments are in italic text. Plain text is used where you might
insert wording about your project.
The document in this file is an annotated outline for specifying software

requirements, adapted from the IEEE Guide to Software Requirements
Specifications (Std 830-1993).
Tailor this to your needs, removing explanatory comments as you go along.

Where you decide to omit a section, keep the header, but insert a comment
saying why you omit the data.
Q:\IRM\PRIVATE\INITIATI\QA\QAPLAN\SRSPLAN.doc Page 1 of 35
08/12/23
f
Course and Grade Management Application
Team 4
Keldin Maldonado, Michelle Brown, Stacy Kirchner, Steven Casey
Software Requirements Specification

Document
Version: (1.0) Date: 04/02/2024
08/12/23
f
Table of Contents
1. Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Definitions, Acronyms, and Abbreviations. 4
1.4 References 4
1.5 Overview 5
2. The Overall Description 5
2.1 System Overview 5
2.1.1 System Interfaces 10
2.1.2 Interfaces 10
2.1.3 Hardware Interfaces 10
2.1.4 Software Interfaces 10
2.1.5 Communications Interfaces 11
2.1.6 Memory Constraints 11
2.1.7 Operations 11
2.1.8 Site Adaptation Requirements 12
2.2 Product Functions 12
2.3 User Characteristics 12
2.4 Constraints 13
2.5 Assumptions and Dependencies 13
2.6 Apportioning of Requirements. 13
3. Specific Requirements 14
3.1 External Interfaces 15
3.2 Functions 15
3.2.1 Get Transcript 16
3.2.2 Get Schedule 16
3.2.3 Add Course 17
3.2.4 Drop Course 17
3.2.5 Get Assignments 18
3.2.6 Create Assignment 18
3.2.7 Update Assignment 19
3.2.8 Delete Assignment 19
3.2.9 Get Assignment Grades 20
3.2.10 Update Grades 20
3.2.11 Get Student Assignments 21
3.2.12 Get Enrollments 22
3.2.13 Update Enrollment Grade 22
3.2.14 Add Course 23
3.2.15 Update Course 23
3.2.16 Delete Course 23
3.2.17 Get All Courses 24
3.2.18 Add Section 24
08/12/23
f
3.2.19 Update Section 25

3.2.20 Delete Section 25
3.2.21 Get Sections 26
3.2.22 Get Sections For Instructor 26
3.2.23 Get Open Sections For Enrollment 27
3.2.24 Find All Users 27
3.2.25 Create User 27
3.2.26 Update User (UserDTO) 28
3.2.27 Update User (int) 28
3.3 Non-functional Requirements 29
3.4 Logical Database Requirements 29
3.5 Design Constraints 32
3.5.1 Standards Compliance 32
3.6 Software System Attributes 32
3.6.1 Reliability 33
3.6.2 Availability 33
3.6.3 Security 33
3.6.4 Maintainability 33
3.6.5 Portability 34
4. Change Management Process 34
5. Document Approvals 34
6. Supporting Information 34
08/12/23
f
1. Introduction
The Course and Grade Management Application built for CST 438’s class project allows
admins, instructors, and students to manage courses, enrollments, assignments, and
grades. The admin user has the ability to manage the user, course and section catalogs,
where they can add, edit and delete records. The instructor user has the ability to manage
assignments and grades for their sections, where they can add, edit, delete and update
grades for assignments. They can also enter grades for enrollments. The student user has
the ability to view their class schedule, drop or enroll in classes, view their assignments
and grades, and view their transcript. When a user logs in, their home page will display
according to their user type (admin, instructor, or student home page). Data checks are
included for each use case. Some examples are: verifying a valid title and due date upon
adding a new assignment; only displaying a list of courses a student is enrolled in upon
entering the desired year and semester; ensuring a user is not already enrolled in a course
upon trying to add one. This project uses Spring Boot for the back-end framework and
React for the front-end.
1.1 Purpose
Identify the purpose of this SRS and its intended audience. In this subsection, describe the
purpose of the particular SRS and specify the intended audience for the SRS.
1.2 Scope
In this subsection:
(1) Identify the software product(s) to be produced by name
(2) Explain what the software product(s) will, and, if necessary, will not do
(3) Describe the application of the software being specified, including relevant
benefits, objectives, and goals
(4) Be consistent with similar statements in higher-level specifications if they exist
This should be an executive-level summary. Do not enumerate the whole requirements

list here.
1.3 Definitions, Acronyms, and Abbreviations.
Provide the definitions of all terms, acronyms, and abbreviations required to properly
interpret the SRS. This information may be provided by reference to one or more
appendices in the SRS or by reference to documents. This information may be provided by
reference to an Appendix.
1.4 References
08/12/23
f
In this subsection:
(1) Provide a complete list of all documents referenced elsewhere in the SRS
(2) Identify each document by title, report number (if applicable), date, and
publishing organization
(3) Specify the sources from which the references can be obtained.
This information can be provided by reference to an appendix or to another document. If

your application uses specific protocols or RFC’s, then reference them here so designers
know where to find them.
1.5 Overview
In this subsection:
(1) Describe what the rest of the SRS contains
(2) Explain how the SRS is organized
Don’t rehash the table of contents here. Point people to the parts of the document they
are most concerned with. Customers/potential users care about section 2, developers
care about section 3.
2. The Overall Description
Describe the general factors that affect the product and its requirements. This section
does not state specific requirements. Instead, it provides a background for those
requirements, which are defined in section 3, and makes them easier to understand. In a
sense, this section tells the requirements in plain English for the consumption of the
customer. Section3 will contain a specification written for the developers.
2.1 System Overview
The following links provide a UML use case diagram for the Course and Grade
Management Application. Screenshots are also displayed for the diagram below;
however, because the diagram is quite large, please use the links for a better view.
Both links provide the same full diagram; one is a PNG, and the other is through
Lucidchart.
PNG:
https://drive.google.com/file/d/16LnbNU4JT-XaByVadLbksk8680dtmtJA/view?usp=driv
e_link
Lucidchart:
08/12/23
f
https://lucid.app/lucidchart/e1d6666c-1c4e-4d00-835f-55764e7418ca/edit?viewport_loc=
-859%2C-708%2C2376%2C1125%2C0_0&invitationId=inv_dc2cfdd0-b7c9-4cec-949f-
987b14ebcf5f
This diagram displays how the three following actors can interact with the application:
admin, instructor, and student. For each actor, use cases are listed to indicate what options
are available to them on their home page (each actor has a different home page upon
logging in). If applicable, child use cases then branch off for additional options the actor
has. Use cases that branch off with an “include” arrow indicate checks that will happen
when the actor performs that action (i.e. verify data input is valid when adding a new
user). Use cases that branch off with an “exclude” arrow indicate action prevention/error
messages if the action/inputs the actor performed are not valid.
At a high level, these are the use cases for each actor:
Admin
An admin can view a list of all user records. They can then add a new user, edit an
existing user, or delete a user. An admin can view a list of all course records. They can
then add a new course, edit an existing course, or delete a course. An admin can view a
list of all section records for a given course, year, and semester. They can then add a new
section, edit an existing section, or delete a section.
Instructor
An instructor can view a list of all assignments for a given section. They can then add a
new assignment, edit an existing assignment, delete an assignment, or show the grades
for an assignment. They can also update the score of the assignment’s grades. An
instructor can view a list of enrollments for a given section. They can then update the
grade for the enrollments.
Student
A student can view their class schedule for a given year and semester. They can then drop
a class from their schedule. A student can enroll in a class. A student can view a list of
their assignments and its score. A student can view their transcript.
08/12/23
f
08/12/23
f
08/12/23
f
08/12/23
f
2.1.1 System Interfaces
List each system interface and identify the functionality of the software to accomplish the
system requirement and the interface description to match the system. These are external
systems that you have to interact with. For instance, if you are building a business
application that interfaces with the existing employee payroll system, what is the API to
that system that designer’s will need to use?
2.1.2 Interfaces
Specify:
(1) The logical characteristics of each interface between the software product and its
users.
(2) All the aspects of optimizing the interface with the person who must use the system
This is a description of how the system will interact with its users. Is there a GUI, a
command line or some other type of interface? Are there special interface requirements?
If you are designing for the general student population for instance, what is the impact of
ADA (American with Disabilities Act) on your interface?
2.1.3 Hardware Interfaces
Specify the logical characteristics of each interface between the software product and the
hardware components of the system. This includes configuration characteristics. It also
covers such matters as what devices are to be supported, how they are to be supported
and protocols. This is not a description of hardware requirements in the sense that “This
program must run on a Mac with 64M of RAM”. This section is for detailing the actual
hardware devices your application will interact with and control. For instance, if you are
controlling X10 type home devices, what is the interface to those devices? Designers
should be able to look at this and know what hardware they need to worry about in the
design. Many business type applications will have no hardware interfaces. If none, just
state “The system has no hardware interface requirements” If you just delete sections
that are not applicable, then readers do not know if: a. this does not apply or b. you
forgot to include the section in the first place.
2.1.4 Software Interfaces
Specify the use of other required software products and interfaces with other application
systems. For each required software product, include:
(1) Name
(2) Mnemonic
(3) Specification number
(4) Version number
(5) Source
08/12/23
f
For each interface, provide:

(1) Discussion of the purpose of the interfacing software as related to this software
product
(2) Definition of the interface in terms of message content and format
Here we document the APIs, versions of software that we do not have to write, but that
our system has to use. For instance if your customer uses SQL Server 7 and you are
required to use that, then you need to specify i.e.
2.1.4.1 Microsoft SQL Server 7. The system must use SQL Server as its database
component. Communication with the DB is through ODBC connections. The system
must provide SQL data table definitions to be provided to the company DBA for setup.
A key point to remember is that you do NOT want to specify software here that you think
would be good to use. This is only for customer-specified systems that you have to
interact with. Choosing SQL Server 7 as a DB without a customer requirement is a
Design choice, not a requirement. This is a subtle but important point to writing good
requirements and not over-constraining the design.
2.1.5 Communications Interfaces
Specify the various interfaces to communications such as local network protocols, etc.
These are protocols you will need to directly interact with. If you happen to use web
services transparently to your application then do not list it here. If you are using a
custom protocol to communicate between systems, then document that protocol here so
designers know what to design. If it is a standard protocol, you can reference an existing
document or RFC.
2.1.6 Memory Constraints
Specify any applicable characteristics and limits on primary and secondary memory.
Don’t just make up something here. If all the customer’s machines have only 128K of
RAM, then your target design has got to come in under 128K so there is an actual
requirement. You could also cite market research here for shrink-wrap type applications
“Focus groups have determined that our target market has between 256-512M of RAM,
therefore the design footprint should not exceed 256M.” If there are no memory
constraints, so state.
2.1.7 Operations
Specify the normal and special operations required by the user such as:
(1) The various modes of operations in the user organization
(2) Periods of interactive operations and periods of unattended operations
(3) Data processing support functions
(4) Backup and recovery operations
08/12/23
f
(Note: This is sometimes specified as part of the User Interfaces section.) If you
separate this from the UI stuff earlier, then cover business process type stuff that would
impact the design. For instance, if the company brings all their systems down at
midnight for data backup that might impact the design. These are all the work tasks that
impact the design of an application, but which might not be located in software.
2.1.8 Site Adaptation Requirements
In this section:
(1) Define the requirements for any data or initialization sequences that are specific
to a given site, mission, or operational mode
(2) Specify the site or mission-related features that should be modified to adapt the
software to a particular installation
If any modifications to the customer’s work area would be required by your system, then
document that here. For instance, “A 100Kw backup generator and 10000 BTU air
conditioning system must be installed at the user site prior to software installation”.
This could also be software-specific like, “New data tables created for this system must
be installed on the company’s existing DB server and populated prior to system
activation.” Any equipment the customer would need to buy or any software setup that
needs to be done so that your system will install and operate correctly should be
documented here.
2.2 Product Functions
Provide a summary of the major functions that the software will perform. Sometimes the
function summary that is necessary for this part can be taken directly from the section of
the higher-level specification (if one exists) that allocates particular functions to the
software product.
For clarity:
(1) The functions should be organized in a way that makes the list of functions
understandable to the customer or to anyone else reading the document for the first
time.
(2) Textual or graphic methods can be used to show the different functions and their
relationships. Such a diagram is not intended to show a design of a product but
simply shows the logical relationships among variables.
AH, Finally the real meat of section 2. This describes the functionality of the system in
the language of the customer. What specifically does the system that will be designed
have to do? Drawings are good, but remember this is a description of what the system
needs to do, not how you are going to build it. (That comes in the design document).
2.3 User Characteristics
08/12/23
f
Describe those general characteristics of the intended users of the product including
educational level, experience, and technical expertise. Do not state specific requirements
but rather provide the reasons why certain specific requirements are later specified in
section 3.
What is it about your potential user base that will impact the design? Their experience
and comfort with technology will drive UI design. Other characteristics might actually
influence internal design of the system.
2.4 Constraints
Provide a general description of any other items that will limit the developer's options.
These can include:
(1) Regulatory policies

(2) Hardware limitations (for example, signal timing requirements)
(3) Interface to other applications
(4) Parallel operation
(5) Audit functions
(6) Control functions
(7) Higher-order language requirements
(8) Signal handshake protocols (for example, XON-XOFF, ACK-NACK)
(1) Reliability requirements
(10) Criticality of the application
(11) Safety and security considerations
This section captures non-functional requirements in the customers language. A more

formal presentation of these will occur in section 3.
2.5 Assumptions and Dependencies
List each of the factors that affect the requirements stated in the SRS. These factors are
not design constraints on the software but are, rather, any changes to them that can affect
the requirements in the SRS. For example, an assumption might be that a specific
operating system would be available on the hardware designated for the software
product. If, in fact, the operating system were not available, the SRS would then have to
change accordingly.
This section is catch-all for everything else that might influence the design of the system
and that did not fit in any of the categories above.
2.6 Apportioning of Requirements.
Identify requirements that may be delayed until future versions of the system. After you
look at the project plan and hours available, you may realize that you just cannot get
everything done. This section divides the requirements into different sections for
08/12/23
f
development and delivery. Remember to check with the customer – they should prioritize
the requirements and decide what does and does not get done. This can also be useful if
you are using an iterative life cycle model to specify which requirements will map to
which iteration.
3. Specific Requirements
This section contains all the software requirements at a level of detail sufficient to enable
designers to design a system to satisfy those requirements, and testers to test that the
system satisfies those requirements. Throughout this section, every stated requirement
should be externally perceivable by users, operators, or other external systems. These
requirements should include at a minimum a description of every input (stimulus) into the
system, every output (response) from the system and all functions performed by the
system in response to an input or in support of an output. The following principles apply:
(1) Specific requirements should be stated with all the characteristics of a good SRS
● correct
● unambiguous
● complete
● consistent
● ranked for importance and/or stability
● verifiable
● modifiable
● traceable
(2) Specific requirements should be cross-referenced to earlier documents that relate
(3) All requirements should be uniquely identifiable (usually via numbering like
3.1.2.3)
(4) Careful attention should be given to organizing the requirements to maximize
readability (Several alternative organizations are given at end of document)
Before examining specific ways of organizing the requirements it is helpful to understand

the various items that comprise requirements as described in the following subclasses.
This section reiterates section 2, but is for developers not the customer. The customer
buys in with section 2, the designers use section 3 to design and build the actual
application.
Remember this is not design. Do not require specific software packages, etc unless the
customer specifically requires them. Avoid over-constraining your design. Use proper
terminology:
The system shall… A required, must have feature
The system should… A desired feature, but may be deferred til later
The system may… An optional, nice-to-have feature that may never make it to
implementation.
08/12/23
f
Each requirement should be uniquely identified for traceability. Usually, they are
numbered 3.1, 3.1.1, 3.1.2.1 etc. Each requirement should also be testable. Avoid
imprecise statements like, “The system shall be easy to use” Well no kidding, what does
that mean? Avoid “motherhood and apple pie” type statements, “The system shall be
developed using good software engineering practice”
Avoid examples, This is a specification, a designer should be able to read this spec and
build the system without bothering the customer again. Don’t say things like, “The
system shall accept configuration information such as name and address.” The designer
doesn’t know if that is the only two data elements or if there are 200. List every piece of
information that is required so the designers can build the right UI and data tables.
3.1 External Interfaces
This contains a detailed description of all inputs into and outputs from the software
system. It complements the interface descriptions in section 2 but does not repeat
information there. Remember section 2 presents information oriented to the
customer/user while section 3 is oriented to the developer.
It contains both content and format as follows:
● Name of item
● Description of purpose
● Source of input or destination of output
● Valid range, accuracy and/or tolerance
● Units of measure
● Timing
● Relationships to other inputs/outputs
● Screen formats/organization
● Window formats/organization
● Data formats
● Command formats
● End messages
3.2 Functions
Functional requirements define the fundamental actions that must take place in the
software in accepting and processing the inputs and in processing and generating the
outputs. These are generally listed as “shall” statements starting with "The system
shall…
08/12/23
f
3.2.1 Get Transcript

Use Case Name Get Transcript
XRef See Get Enrollments (3.2.12), get Schedule (3.2.2)
Trigger Student presses “View Transcript” button
Precondition Student is accessing any student view page
Basic Path 1. Student opens the web page, landing on the home page.
2. Student clicks on “View Transcript”
3. The student is shown a table of their current and past
enrollments
Alternative Paths N/A
Postcondition The student is shown a table of their past and current
enrollments
Exception Paths The student can abandon at any time.
Other The transcript is shown based on the students user ID.
3.2.2 Get Schedule

Use Case Name Get Schedule
XRef See also Drop Course (3.2.4)
Trigger Student presses the “SEARCH” button
Precondition Student is currently accessing the schedule page
Basic Path 1. Student opens the web page, landing on the home page.
2. Student clicks on “View Class Schedule”
3. The student enters the Year and Semester and proceeds
to press the “SEARCH” button
4. The system checks for valid parameters and returns the
list of enrollments the student is currently enrolled in
Alternative Paths 1. In step 3, invalid parameters cause the operation to
stop and prompts the user to input valid parameters.
2. In step 3, if the student inputs valid parameters but no
enrollments are found, the user is prompted that no
schedule was found and the operation stops.
Postcondition The student is shown a list of current enrollments
Exception Paths The student may abandon the operation at any point
Other The parameters for the form are enrollment year and
enrollment semester.
08/12/23
f
3.2.3 Add Course

Use Case Name Add Course
XRef See also Drop Course (3.2.4)
Trigger The student clicks the “ADD” button
Precondition The page is displayed with open enrollments
Basic Path 1. The student opens the web page, landing on the home
page
2. The student clicks on “Enroll in a class” and is shown a
table of open enrollments
3. The student clicks “ADD” on any of the entries
4. The student clicks “Confirm” in the popup window
5. The student will be enrolled and shown a confirmation
message.
Alternative Paths If in step 4 the student is already enrolled, the operation will
stop and alert the user that they are already enrolled via a
response message.
Postcondition The student is enrolled into the desired course
Exception Paths If the student is already enrolled, the operation will end. The
student may abandon the operation at any time.
Other N/A
3.2.4 Drop Course

Use Case Name Drop Course
XRef See also Get Schedule (3.2.2), Add Course (3.2.3)
Trigger Student clicks on “DROP”
Precondition Student is accessing the class schedule page
Basic Path 1. The student opens the web page, landing on the home
page.
2. The student clicks on “View Class Schedule”
3. The student enters the Year and Semester into the form
and clicks “SEARCH”
4. The system checks for valid parameters and displays a
list of current enrollments
5. The student clicks on the “DROP” button
6. The student clicks on “Confirm” in the pop up window
Alternative Paths 1. In step 3, if the user inputs invalid parameters, the
operation will stop and prompt the user to put in valid
parameters
2. In step 3, if the user inputs valid parameters that return
an empty list of enrollments, the operation will stop
and inform the user that no schedule was found
08/12/23
f
3. In step 5, if the class is already graded, the user will

instead be shown a popup informing them that the class
can no longer be dropped.
Postcondition The student will be dropped from the course
Exception Paths If the course is already graded the operation will end. The user
may abandon it at any time.
Other The form requests enrollment “Year” and “Semester”
3.2.5 Get Assignments

Use Case Name Get Assignments
XRef Also see Create Assignment (3.2.6), Delete Assignment
(3.2.8), and Update Assignment (3.2.7)
Trigger The instructor clicks on view assignments from the instructor
section screen or the student clicks on show assignments from
the view assignments screen.
Precondition The instructor has access to the sections homescreen or student
has access from the view assignments screen.
Basic Path 1. View assignments button is clicked from the instructor
sections screen.
2. All assignment are fetched using the section number
Alternative Paths 1. If the user type is a student, the show assignments
button is clicked from the view assignments screen.
2. All assignments are fetched using the terms year and
the term semester.
Postcondition All available assignments and info for those assignments is
displayed.
Exception Paths NA
Other Assignment information includes title, due date, score, course
id, and assignment id.
3.2.6 Create Assignment

Use Case Name Create Assignment
XRef Also see Update Assignment (3.2.7) and Delete Assignment
(3.2.8)
Trigger The instructor selects to add a new assignment to the database.
Precondition The instructor has access to the assignment catalog screen.
Basic Path 1. The system presents a dialog box to enter title and due
date for a new assignment.
2. The instructor enters the title and due date for the new
assignment.
3. The system checks that the title and due date are valid
values.
4. The database is updated with the new assignment.
08/12/23
f
Alternative Paths At step 3, if an invalid title or date is entered, the system will
display a message stating the necessary fixes to be made
before continuing.
Postcondition The database is updated with a new assignment.
Exception Paths The instructor may cancel the creation of a new assignment at
any point by clicking close.
Other The assignment information includes the title of the new
assignment and the due date.
3.2.7 Update Assignment

Use Case Name Update Assignment
XRef Also see Create Assignment (3.2.6) and Delete Assignment
(3.2.8)
Trigger The instructor selects the edit button from the assignment
catalog screen.
Precondition The instructor has access to the assignment catalog screen.
Basic Path 1. The system presents a dialog box with the current title
and due date of the assignment.
2. The instructor changes the title, due date, or both in the
dialog box.
3. The system checks that the title and due date are valid
values.
4. The database is updated with the changes to the
assignment.
Alternative Paths At step 3, if an invalid title or date is entered, the system will
display a message stating the necessary fixes to be made
before continuing.
Postcondition The database is updated with the changes to the assignment.
Exception Paths The instructor may cancel updating the assignment at any
point by clicking close.
Other The updated assignment information includes title of the
assignment, due date, and the changes that were made.
3.2.8 Delete Assignment

Use Case Name Delete Assignment
XRef See Get Assignments (3.2.5) and Update Grades (3.2.10)
Trigger The instructor selects to delete the desired Assignment record
for a chosen Section.
Precondition The instructor has access to the Instructor home page.
Basic Path 1. The instructor enters a Year and Semester on their
login homepage.
2. The instructor clicks “Show Sections.
08/12/23
f
3. The instructor clicks “View Assignments” next to the

desired Section record.
4. The instructor clicks “Delete” next to the desired
Assignment record.
5. The Assignment is removed from the database.
Alternative Paths 1. In Step 1, if there are no Sections for the Year and
Semester input, there will be no Assignments to delete.
2. In Step 4, if there are any Grades associated to the
Assignment, deletion will be prevented and an error
message will display.
Postcondition The Assignment is removed from the database.
Exception Paths If there are any Grades associated to the Assignment, deletion
will be prevented and an error message will display. The
Editor may abandon the operation.
Other N/A
3.2.9 Get Assignment Grades

Use Case Name Get Assignment Grades
XRef See Get Assignments (3.2.5) and Update Grades (3.2.10)
Trigger The instructor selects to Show Grades for the desired
Assignment record for a chosen Section.
login homepage.
4. The instructor clicks “Show Grades” next to the
desired Assignment record.
5. A list of grades with a score for that assignment
ordered by student name is displayed.
Semester input, there will be no Assignments to view.
2. In Step 5, if there are no grades for that assignment, the
scores for the student(s) will be blank.
Postcondition A list of grades with a score for that assignment ordered by
student name is displayed.
Exception Paths The Editor may abandon the operation at any time.
Other If the grade exists, the score for each grade is generated from
when the Instructor edits the Score field and saves to the
database.
3.2.10 Update Grades
08/12/23
f
Use Case Name Update Grades

XRef See Get Assignments (3.2.5) and Get Assignment Grades
(3.2.9)
Trigger The instructor edits the Score for a Grade record and clicks
“Update”.
login homepage.
4. The instructor clicks “Show Grades” next to the
desired Assignment record.
5. A list of grades with a score for that assignment
ordered by student name is displayed.
6. The instructor edits the Score field for the desired
Grade record, by entering an integer 0-100.
7. The instructor clicks “Update” next to the Grade record
they are editing.
8. The database is updated with the changes to the Grade
record.
2. In Step 6, the instructor is prevented from entering an
integer outside the range of 0-100.
3. In Step 7, if the instructor tries to enter a Score for a
Grade record that doesn’t exist, they will receive a not
found message.
Postcondition The Score for the Grade record is updated in the database.
Other The Score that is populated for the Grade record when the
page first loads is the Score that was last updated to the
database.
3.2.11 Get Student Assignments

Use Case Name Get Student Assignments
XRef See Update Grades (3.2.10)
Trigger The student clicks “View Assignments” on their home page.
Precondition The student has access to the Student home page.
Basic Path 1. The student clicks “View Assignments” on their
student home page.
2. The student enters a Year and Semester.
3. The student clicks “Show Assignments”.
08/12/23
f
4. A list of Assignments with the associated courseId,

assignment title, assignment due date, and score is
displayed for the given year and semester.
Alternative Paths 1. In Step 2, if there are no Assignments for the Year and
A not found error is displayed.
Postcondition A list of Assignments with the associated courseId, assignment
title, assignment due date, and score is displayed for the given
year and semester.
Other The score for the assignment is populated from the database
with the last score the instructor entered.
3.2.12 Get Enrollments

Use Case Name Get Enrollments
XRef Update Enrollment Grade (3.2.13)
Trigger Instructor clicks “View Enrollments” for the selected section
Precondition Must be the instructor for the course
Basic Path 1. Instructor adds year and semester to search for sections
on the home page.
2. Instructor clicks on “View Enrollments” for the section
they wish to view
3. All enrollments will be displayed on enrollment page
Alternative Paths None
Postcondition The enrollment information is displayed
Exception Paths The instructor can abandon the operation at any time
Other Enrollments shown are based on section selected
3.2.13 Update Enrollment Grade

Use Case Name Update Enrollment Grade
XRef Get Enrollments (3.2.12)
Trigger Instructor inputs grade letter and clicks “UPDATE”
Precondition Must be the instructor for the course
Basic Path 1. Instructor adds year and semester to search for section
on the home page
2. Instructor clicks on “View Enrollments” for the section
they wish to update
3. All enrollments will be displayed on enrollment page
4. Instructor edits the “Grade” text box and clicks
“UPDATE”
5. “Enrollment saved” message will be displayed
Postcondition The grade is updated in the database
08/12/23
f
Exception Paths Grade will not be update if “UPDATE” is not clicked

Other Each enrolled student’s grade must be updated individually
3.2.14 Add Course

Use Case Name Add Course
XRef Get All Courses (3.2.17)
Trigger Admin clicks “ADD COURSE”
Precondition Admin is viewing the Courses page
Basic Path 1. Admin clicks on Courses and views current courses
2. Admin clicks “ADD COURSE”
3. CourseId, title, and credits are entered in the modal
window
4. Save is clicked
5. “course added” message is displayed
Postcondition The new course is added to the database
Exception Paths The admin can cancel adding the course by selecting close
instead of save or abandon operation at any time
Other CourseId and title must not be blank and credits must be a
positive integer
3.2.15 Update Course

Use Case Name Update Course
Trigger Admin clicks “EDIT” for the course that is being updated
Precondition Admin must be able to view the course on the Course page
Basic Path 1. Admin clicks on Courses and views all courses
2. Admin clicks “EDIT” next to the course that will be
updated
3. The CourseId, title, and credits are written over the
previous information.
4. “course saved” message is displayed
Postcondition The course is updated in the database
Exception Paths The admin can cancel updating the course by selecting close
instead of save or abandon the operation at any time
Other CourseId and title must not be blank and credits must be a
positive integer
3.2.16 Delete Course

Use Case Name Delete Course
08/12/23
f
Trigger Admin clicks “DELETE” for the course that is being deleted
Precondition Admin must be able to view the course on the Course page
2. Admin clicks “DELETE” next to the course that will
be deleted
3. Yes is selected to confirm the deletion
4. “Course deleted” message is displayed
Postcondition The course is deleted in the database
Exception Paths The admin can cancel the deletion by selecting “no” on the
modal window to prevent confirming the deletion. The admin
can also abandon the operation at any time
Other Must be an admin to delete course
3.2.17 Get All Courses

Use Case Name Get All Courses
XRef Add Course (3.2.3), Update Course (3.2.15), Delete Course
(3.2.16)
Trigger Admin clicks “Courses”
Precondition Need to be Admin type
Postcondition The courses information is displayed
Exception Paths The admin can abandon the operation at any time
Other Displays current courses in database so if courses are deleted
or added it will reflect these actions
3.2.18 Add Section

Use Case Name Add Section
XRef See also Update Section (3.2.19) and Delete Section (3.2.20)
Trigger Admin clicks on add courses from the courses screen.
Precondition The user/client type must have admin privileges.
Basic Path 1. Admin click on Add Course button.
2. Dialog box appears asking for course id, title, and
credits.
3. Entered data is checked.
4. A new course(section) is added to available courses in
the database.
Alternative Paths At step 2, if data inputted is invalid, a message will appear
stating what data is correct.
Postcondition New course is displayed in the list of available courses.
Exception Paths The admin can click the close button at any point to cancel
adding a new course.
08/12/23
f
Other Course data to send and display is CourseId, Title, and Credits.
3.2.19 Update Section

Use Case Name Update Section
XRef See Find All Users (3.2.24)
Trigger The admin selects the “Edit” button next to the desired Section
record.
Precondition The Admin has access to the Admin home page.
Basic Path 1. The admin clicks “Sections” on their home page.
2. The admin enters a Course Prefix, Year, and Semester.
3. The admin clicks “Search for Sections”.
4. A list of Sections records that fall under the inputs
from Step 3 are displayed.
5. The admin clicks “Update” next to the desired Section
record.
6. A dialog box displays for the admin to update fields
secId, building, room, times, instructorEmail.
7. The admin clicks “Save” on the dialog box.
8. Entered data is validated.
9. Updates are saved to the database.
Alternative Paths 1. In Step 6, if the admin enters an invalid
instructorEmail, an error message is displayed,
preventing save.
Postcondition Updates to the existing Section record are saved to the
database.
Exception Paths The admin may cancel updating the section at any point by
clicking “Close” on the dialog box.
Other The instructorEmail is validated against emails in the User
table.
The admin can also specify partial courseId when searching
for sections.
3.2.20 Delete Section

Use Case Name Delete Section
XRef See also Add Section (3.2.18) and Update Section (3.2.19)
Trigger Admin clicks on delete courses from the courses screen.
Precondition The user/client type must have admin privileges.
Basic Path 1. The admin clicks on delete on one of the courses
displayed in the courses screen.
2. Dialog box appears asking for confirmation to delete
the course.
3. The admin clicks on the yes button.
4. The course is successfully deleted from the database.
08/12/23
f
Alternative Paths There are no courses in the database. The ability to delete a
course is not present.
Postcondition Course ise deleted from the database. and is no longer visible
from the courses screen.
Exception Paths At step 3, if the Admin clicks on the no button instead of yes,
the operation will be canceled.
Other Course data includes CourseId, Title, and Credits.
3.2.21 Get Sections

Use Case Name Get Sections
XRef See also Add Section (3.2.18), Update Section (3.2.19), and
Delete Section (3.2.20)
Trigger Admin clicks on “Search for Sections” on the /sections page
Precondition The user is an admin and is accessing the sections page
Basic Path 1. Admin opens the web page, landing on the home page
2. The admin clicks on “Sections”
3. The admin fills the form and clicks “Search for
Sections”
4. The list of sections is presented in table form
Alternative Paths In step 3, if the user inputs invalid parameters, a warning
message is displayed.
Postcondition A table of sections are displayed in table format to the user.
Exception Paths The user may abandon at any time and the operation will end.
Other The form asks the user for “Course Prefix”, “Year”, and
“Semester”.
3.2.22 Get Sections For Instructor

Use Case Name Get Sections For Instructor
Trigger The instructor clicks “Show Sections” after entering a Year
and Semester on their home page.
login homepage.
3. A list of Sections that fall under the Year and Semester
inputs is displayed with SecNo, Course ID, Section ID,
Building, Room, and Times for each Section record.
Alternative Paths 1. If no Section records exist for the Year and Semester
entered, there are no records displayed.
08/12/23
f
Postcondition A list of Sections that fall under the Year and Semester inputs
is displayed with SecNo, Course ID, Section ID, Building,
Room, and Times for each Section record.
Exception Paths The Editor may abandon the operations at any time.
Other The logged in Instructor’s email is currently hard coded as
[email protected].
3.2.23 Get Open Sections For Enrollment

Use Case Name Get Open Sections For Enrollment
Trigger A Student enters the “Enroll in a class” page (/addCourse)
Precondition User is a student and accesses the /addCourse page
Basic Path 1. Student opens the web page and is at the home page
2. Student clicks on “Enroll in a class”
3. The student is presented with a table of open sections
Alternative Paths N/A
Postcondition User is shown a table of open sections.
Exception Paths The user can abandon the operation at any time.
Other Displays open sections with the option to “ADD”
3.2.24 Find All Users

Use Case Name Find All Users
XRef Create User (3.2.25), Update User (3.2.26), Update User
(3.2.27)
Trigger Admin clicks “Users”
Precondition Must be an admin
Basic Path 1. Admin clicks “Users” and all users are displayed
Postcondition The users information is displayed
Exception Paths The admin can abandon the function at anytime
Other Displays all current users in database so if any users are
deleted, modified, or added, it will reflect these actions
3.2.25 Create User

Use Case Name Create User
XRef Find All Users (3.2.24)
Trigger Admin clicks “ADD USER”
Precondition Must be an admin
Basic Path 1. Admin clicks “User”
2. All users’ information is displayed
3. Admin clicks “ADD USER”
08/12/23
f
4. Enter name, email, and user type into the modal

window
5. Click “SAVE”
6. User will be added and displayed with all other users
Postcondition User will be added to the database
Exception Paths The admin can cancel adding a user by selecting “CLOSE”
and text fields can not be empty
Other “type” must be “STUDENT”, “INSTRUCTOR”, or “ADMIN”
3.2.26 Update User (UserDTO)

Use Case Name Update User (UserDTO)
Trigger Admin clicks “EDIT” next to the user that is being updated
Precondition Must be an admin and display the user that is being updated
3. The “EDIT” button is clicked next to the selected user
4. The updated information is written over the previous
information
5. The “SAVE” button is selected
6. “user saved” message is displayed
Postcondition The user is updated in the database
Exception Paths The admin can cancel the update by clicking “CLOSE” instead
of “SAVE”
Other “type” must be updated to “STUDENT”, “INSTRUCTOR”, or
“ADMIN”
3.2.27 Update User (int)

Use Case Name Update User (int)
Trigger Admin clicks “DELETE” next to the user that is being deleted
Precondition Must be an admin and user must be an existing user
3. Admin clicks “DELETE” next to the user they would
like to delete
4. Select “Yes” to confirm the deletion
5. “User deleted” message is displayed
Postcondition The User will be deleted from the database
08/12/23
f
Exception Paths Admin can prevent the deletion by selecting “No” in the
confirmation window
Other Must confirm the deletion in the modal window
3.3 Non-functional Requirements
Related to Performance:
To ensure a positive user experience, the system should load a page, list of records or
error message in less than 1 second from when the user clicks on the corresponding link
for them to view. When a user is trying to update a record, such as a grade's score, they
should receive a confirmation message that their change was saved to the database in less
than 1 second.
Related to Security:
The server for the Course and Grade Management application will check the logged in
user’s type. A user can be an Admin, Instructor, or Student. Each user type has their own
version of the home page upon logging in, which restricts them to functions that are only
available for that user’s type. For example, an Admin has the option to Add/Delete Users
on their homepage; however, instructors and students do not. Logged in users can only
read and write/delete to tables they have access to on their homepage.
Related to Reliability:
Backend server must be up and running for database reads and writes to be performed.
Thus, an uptime close to 100% is expected from the backend services. Additionally,
proper input sanitation is required to prevent unexpected downtime that may occur from
improper fields passed in by the client. Ensuring backend services reliability will also
ensure an enjoyable user experience.
3.4 Logical Database Requirements
This section specifies the logical requirements for any information that is to be placed
into a database. This may include:
● Types of information used by various functions

● Frequency of use
● Accessing capabilities
● Data entities and their relationships
● Integrity constraints
● Data retention requirements
08/12/23
f
If the customer provided you with data models, those can be presented here. ER
diagrams (or static class diagrams) can be useful here to show complex data
relationships. Remember a diagram is worth a thousand words of confusing text.
ER diagram:
User_table Data Entity

Data Item Type Description Comment
ID Integer User’s unique ID Auto Increments
Name Text User’s first and last name Max 45 characters
Email Text User’s email address Max 45 characters
Password Text User’s password can be blank, Max 100 characters
Type Text Determines type of user “ADMIN”, “INSTRUCTOR” or
“STUDENT”, Max 10 characters
Enrollment Data Entity
08/12/23
f

Enrollment ID Integer ID of each enrollment Different than user’s ID; not
student’s ID; Auto Increments
Grade Text letter grade of student in course A-F, can be null if not graded yet,
Max 5 characters
Section Number Integer Section number that points to Foreign key to Section Data
course information Entity
User ID Integer Student’s ID number Foreign key to User_table Data
Entity
Grade Data Entity

Grade ID Integer ID of each assigned grade Auto Increments
Enrollment ID Integer Points to which enrolled Foreign key to Enrollment Data
student it belongs to Entity
Assignment ID Integer Points to which assignment the Foreign key to Assignment Data
grade is for Entity
Score Integer Score of grade 0 - 100
Assignment Data Entity

Assignment ID Integer ID of each assignment Auto Increments
Section number Integer Points to which section number Foreign key to Section Data
the assignment belongs to Entity
Title Text Name of the assignment Max 45 characters
Due Date Date Date the assignment is due Format: YYYY-MM-DD
Section Data Entity

Section Number Integer ID for each individual section Auto Increments
Course ID Text Abbreviation and number that Foreign key to Course Data
represents the course Entity, Max 45 characters
Section ID Integer The section of the course Many be many sections of the
same Course ID
Term ID Integer Which term the section is held Foreign key to Term Data Entity
Building Text Building the section is held in Max 45 characters
Room Text Room the section is held in Max 45 characters
Times Text When the section is held Max 45 characters
Instructor Email Text Email of professor teaching the Helps determine user type, Max
08/12/23f
section 45 characters
Course Data Entity

Course ID Text Abbreviation and number that Ex: XYZ101, Max 45 characters
represents the course
Title Text Name of course Max 45 characters
Credits Integer Number of credits/units
Term Data Entity

Term ID Integer Represents a specific term Auto Increments
Term year Integer Year of the term
Semester Text Name of the Semester “Spring” or “Fall”, Max 45
characters
Add Date Date Date to add for term Format: YYYY-MM-DD
Add Deadline Date Deadline to add for term Format: YYYY-MM-DD
Drop Deadline Date Deadline to drop for term Format: YYYY-MM-DD
Start Date Date First day of the term Format: YYYY-MM-DD
End Date Date Last day of the term Format: YYYY-MM-DD
3.5 Design Constraints
Specify design constraints that can be imposed by other standards, hardware limitations,
etc.
3.5.1 Standards Compliance
Specify the requirements derived from existing standards or regulations. They might
include:
(1) Report format
(2) Data naming
(3) Accounting procedures
(4) Audit Tracing
For example, this could specify the requirement for software to trace processing activity.
Such traces are needed for some applications to meet minimum regulatory or financial
standards. An audit trace requirement may, for example, state that all changes to a
payroll database must be recorded in a trace file with before and after values.
3.6 Software System Attributes
08/12/23
f
There are a number of attributes of software that can serve as requirements. It is

important that required attributes are specified so that their achievement can be
objectively verified. The following items provide a partial list of examples. These are
also known as non-functional requirements or quality attributes.
These are characteristics the system must possess, but that pervade (or cross-cut) the
design. These requirements have to be testable just like the functional requirements. Its
easy to start philosophizing here, but keep it specific.
3.6.1 Reliability
Specify the factors required to establish the required reliability of the software system at
time of delivery. If you have MTBF requirements, express them here. This doesn’t refer
to just having a program that does not crash. This has a specific engineering meaning.
3.6.2 Availability
Specify the factors required to guarantee a defined availability level for the entire system
such as checkpoint, recovery, and restart. This is somewhat related to reliability. Some
systems run only infrequently on-demand (like MS Word). Some systems have to run 24/7
(like an e-commerce web site). The required availability will greatly impact the design.
What are the requirements for system recovery from a failure? “The system shall allow
users to restart the application after failure with the loss of at most 12 characters of
input”.
3.6.3 Security
Specify the factors that would protect the software from accidental or malicious access,
use, modification, destruction, or disclosure. Specific requirements in this area could
include the need to:
● Utilize certain cryptographic techniques
● Keep specific log or history data sets
● Assign certain functions to different modules
● Restrict communications between some areas of the program
● Check data integrity for critical variables
3.6.4 Maintainability
Specify attributes of software that relate to the ease of maintenance of the software itself.
There may be some requirement for certain modularity, interfaces, complexity, etc.
Requirements should not be placed here just because they are thought to be good design
practices. If someone else will maintain the system
08/12/23
f
3.6.5 Portability
Specify attributes of software that relate to the ease of porting the software to other host
machines and/or operating systems. This may include:
● Percentage of components with host-dependent code
● Percentage of code that is host dependent
● Use of a proven portable language
● Use of a particular compiler or language subset
● Use of a particular operating system
4. Change Management Process
Identify the change management process to be used to identify, log, evaluate, and update
the SRS to reflect changes in project scope and requirements. How are you going to
control changes to the requirements? Can the customer just call up and ask for
something new? Does your team have to reach consensus? How do changes to
requirements get submitted to the team? Formally in writing, email or phone call?
5. Document Approvals
Identify the approvers of the SRS document. Approver name, signature, and date should
be used.
6. Supporting Information
The supporting information makes the SRS easier to use. It includes:
● Table of Contents
● Index
● Appendices
The Appendices are not always considered part of the actual requirements specification
and are not always necessary. They may include:
(a) Sample I/O formats, descriptions of cost analysis studies, results of user
surveys
(b) Supporting or background information that can help the readers of the SRS
(c) A description of the problems to be solved by the software
(d) Special packaging instructions for the code and the media to meet security,
export, initial loading, or other requirements
08/12/23
f

Srs 1

Uploaded by

Copyright:

Available Formats

Srs 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Srs 1

Uploaded by

Copyright:

Available Formats

Software Requirements Specifications Document

CS438 Software Engineering

Software Requirements Specification (SRS) Template

The document in this file is an annotated outline for specifying software

Tailor this to your needs, removing explanatory comments as you go along.

Course and Grade Management Application

Keldin Maldonado, Michelle Brown, Stacy Kirchner, Steven Casey

Software Requirements Specification

Version: (1.0) Date: 04/02/2024

3.2.19 Update Section 25

This should be an executive-level summary. Do not enumerate the whole requirements

1.3 Definitions, Acronyms, and Abbreviations.

This information can be provided by reference to an appendix or to another document. If

2. The Overall Description

2.1 System Overview

2.1.1 System Interfaces

2.1.3 Hardware Interfaces

2.1.4 Software Interfaces

For each interface, provide:

2.1.5 Communications Interfaces

2.1.6 Memory Constraints

2.1.8 Site Adaptation Requirements

2.2 Product Functions

2.3 User Characteristics

(1) Regulatory policies

This section captures non-functional requirements in the customers language. A more

Before examining specific ways of organizing the requirements it is helpful to understand

3.1 External Interfaces

It contains both content and format as follows:

3.2.1 Get Transcript

3.2.2 Get Schedule

3.2.3 Add Course

3.2.4 Drop Course

3. In step 5, if the class is already graded, the user will

3.2.5 Get Assignments

3.2.6 Create Assignment

3.2.7 Update Assignment

3.2.8 Delete Assignment

3. The instructor clicks “View Assignments” next to the

3.2.9 Get Assignment Grades

3.2.10 Update Grades

Use Case Name Update Grades

3.2.11 Get Student Assignments

4. A list of Assignments with the associated courseId,

3.2.12 Get Enrollments

3.2.13 Update Enrollment Grade

Exception Paths Grade will not be update if “UPDATE” is not clicked

3.2.14 Add Course

3.2.15 Update Course

3.2.16 Delete Course

3.2.17 Get All Courses

3.2.18 Add Section

3.2.19 Update Section

3.2.20 Delete Section

3.2.21 Get Sections

3.2.22 Get Sections For Instructor

3.2.23 Get Open Sections For Enrollment

3.2.24 Find All Users

3.2.25 Create User