Software Requirements

Assumptions

This section should provide a list of any assumptions that may affect the project requirements.   Each assumption is an “educated guess”, a likely condition, circumstance or event, presumed known and true in the absence of absolute certainty. Assumptions may shape the project requirements by identifying the possibilities.

Example:

• Finance Department areas have sufficient personnel to continue supporting scheduling system usage.
• Finance Finding funds for implementation for selected scheduling system usage.
• University Student Center (USC) provides users for selected scheduling system.
• USC provides training process for all users for selected scheduling system.
• USC provides policy process for all users for selected scheduling system.
• USC provides unlimited support for all users for selected scheduling system.
• Registrars Office has adequate software user support for selected scheduling system.
• Registrars Office provides training material or user manual for selected scheduling system.
• OIT vendor provides adequate maintenance support.
• OIT vendor provides systems material and manual for selected scheduling system.

Constraints

This section should provide a list of any constraints that may affect the   project requirements.   Each constraint is a limiting condition, circumstance or event, setting boundaries for the project process and expected result(s). Constraints may shape the project requirements by identifying the limits.

Example:

• Finance integrating selected scheduling system with Banner (Elucian).
• Finance vendor not providing adequate scheduling system user education.
• Finance auxiliary components buying into the process of selected scheduling system.
• Finance the ability to invoice to various department areas using selected scheduling system.
• University Student Center the file format to be inputted into selected scheduling system.
• USC transfer ability from current data and converting into selected scheduling system.
• USC current scheduling system contract expiration dates.
• Registrars Office scheduling system test environment availability for training purposes.
• Registrars Office learning curve for use of setting up classroom within selected scheduling system.
• OIT vendor selected scheduling system responsible for loading CAD images and files into software.
   

Requirements

This section shall capture all the business requirements. It is important to capture all the true business requirements of the proposed solution in a succinct manner using the below categories:

• User Functionality Requirements:  Explain the tasks or functions that the users should be able to do using the software or application.
• System Functionality Requirements: Explain the tasks or functions that the system software or application should be able to do.
• Data Requirements (if applicable):  List the data that is required.
• Additional Requirements (if applicable): List any additional requirements.

Example:

User Functionality Requirements:

For this project, there are two user functionality areas: event scheduling and class scheduling.  The event scheduling user functionality begins when customer (students, faculty, staff, and patrons) makes an inquiry for reserving an event space via the scheduling system.  It ends when the respective stakeholder (Building Director) generates and confirms space and/or contract. The class scheduling user functionality begins when customer (Academic Schedulers) enter courses in Banner system. It ends when the stakeholder (Registrars Office) revise and/or assign classrooms via the scheduling system.

System Functionality Requirements:

• Notification   and   Update function   is   the   ability to notify all primary stakeholders and customers of any scheduling changes.
• Accounting-Billing   and   Receivable function is the capability   of   handling customer transactions via electronically; and the ability to transfer funds amongst the internal University stakeholders (Banner is the primary financial system for the University).
• Organizational   and   Interface functions   is   the   ability   to   interface   with University systems such as OrgSync  (student  organization  system),  Banner (financial and class info entry) and Outlook calendars.
• Venue Configuration function is the ability for the customer to electronically view   room   configurations, layouts, space   availability, cost   structure (if applicable) etc.
• Report and Recording function is the ability to obtain electronic signatures and the ability to track standard forms via electronically, while also having the ability   to   provide   standard   reporting modules (i.e.   attendance   reports, financial reports, revenue reports, etc.).
• Classroom Assignment function is the ability to batch assign classrooms (classes are entered via Banner) and show historical use of classrooms; with ability to manually override when necessary (Banner is the primary class entering system for the University).

Data Requirements (if applicable):

For this project, the selected scheduling system does not require any data requirements:

Additional Requirements (if applicable):

For this project, the selected scheduling system will have the following additional requirements: a feasible timeline to complete and process timesheet data, ability to submit to appropriate parties for signatures and approvals, and the ability to provide calendaring features.