Oer User Interface 3 1 7 2 example essay topic

Project 5: Good Neighbors Campaign Project Description: Develop a database to keep track of 20 data points for each of USC's 10,000 employees for the past 10 years (and years to come). This database would need to have the ability to generate reports based on various queries in order to answer questions about donation trends among the University employees. Team Members: David Stark David Jena Steven Cao Jamal Mani Contact: Aggie AfarineshCampaign Finance Manager / Program Specialist Office of External Relations University of Southern California (213) 740-7400 CSCI 477-Project Deliverables Operational Concept Description 1.1 Summary The Good Neighbors Campaign (GNC) is an annual giving campaign for the staff and faculty of the University of Southern California. Funds raised by this campaign are granted to nonprofit community organizations located in the University Park and Health Sciences Campus neighborhoods.

These funds go toward community development, economic development, health education and support, arts education, and after school programs for children. The University Of Southern California Office Of External Relations (USC OER) is looking for a database that can store all current and historic donations. They would also like a program or system that can streamline data collection as well as generate reports to track campaign effectiveness. Long-term goals include an easy user interface for the donation process. The system is being built because over the past ten years, the OER has collected a plethora of data and needs an efficient method of interacting and analyzing donation trends. They also would like to have this system implemented for the next campaign drive in fall 2005.

At the moment, all data entry is done by hand by a single person. Also, the only way to interact with the database is through one administrator's computer. The current process also poses a large potential of human error that could significantly compromise the database's integrity. The new system will reduce the error and time of data entry. It will generate reports more easily and flexibly as well as inform department heads about the donation of their employees. It will also provide this functionality through a user friendly web interface. 1.1.

1 Original Description from Client The OER is looking for a database that can integrate all of the donation history for the past ten years. This would include data points for each employee for each of the past ten years. All employee information must be accessed through the payroll department. 1.1. 2 Organizational Goals Goal Identifier OG-1 Organizational Goal Increase donations Measurable Since donations are pledged annually, donations will be measured with respect to previous years.

Relevant Increased donations will provide more funding towards nonprofit organizations located in the University Park and Health Sciences campus neighborhoods that are involved with community development, economic development, health education and support, arts education, and after school programs for children. Goal Identifier OG-2 Organizational Goal Better Understanding of Demographic Factors Description Being able to categorize donation trends based on a single or combination of factors. Measurable Since donations are pledged amongst a variety of faculty and staff, demographic factors will include key components such as department, job title, age, salary, tenure, etc. Relevant Having a better understanding of demographic factors will aid the Good Neighbors Campaign in planning for future campaigns / projects toward better success in funds raised for nonprofit organizations. 1.1.

3 System Capabilities Our client needs a fast and efficient database and system that can integrate all of the donation history for the past ten years. Our proposed system will allow for easy data entry and manipulation, user login through a web-interface, report generation, and detailed analysis on donation trends. Unlike the current system in which our client is using, our proposed system will be faster, more efficient, easily maintained, and user friendly. 1.1. 4 Key Stakeholders Doris Gall an (System Administrator) Campaign Director / Director of Local Government Relations and Strategic Planning Office of External Relations University of Southern California Aggie Afarinesh (System Maintainer) Campaign Finance Manager / Program Specialist Office of External Relations University of Southern CaliforniaDevelopersUSC Faculty and Staff (Users) 1.1. 5 System Boundary and Environment 1.2 The Proposed System 1.2. 1 Project Goals and Constraints Project Goal PG-1: Easy to Use and Maintain Description System is user friendly and does not require a lot of time to troubleshoot if a problem occurs.

Measurable Count the number of times user must refer to manual to complete certain operations. Relevant Easy for user to analyze donation trends based on demographic factors Project Goal PG-2: Efficiency Description System does not require a lot of time to perform list of services desired by user. Measurable Keep track of the time it takes for a user to execute a desired service of the system. Relevant Allows user to accomplish a lot of tasks required for money transaction, report generation, and donation analysis.

Project Goal PG-3: Low Cost Description Implementing and maintaining the system does not place a financial burden on the client. Measurable Determine the cost of setting up and maintaining a web server and database server. Relevant The web server will handle all the user interfaces and the database server will store all the relevant information for the system. Project Constraint PC-1: Dependency on Outdated Payroll System Description Payroll is unwilling to change their current system of sending and receiving data. Measurable Measure the time required by Payroll to send and update faculty / staff data. Relevant Efficiency of the proposed system is affected by the efficiency of Payroll's system.

Payroll generates standardized excel sheets to pass to other departments Project Constraint PC-2: Funding Description Client does not have sufficient funds to build an elaborate and extensive database system. Measurable Determine how much the client can afford to pay for system construction and maintenance. Relevant System scale and efficiency are dependent on funding. 1.2. 2 System Capabilities Identifier SC-1 Name Money Transaction and Logging Description Means of communicating and updating data across different departments, the Office of External Relations, and Payroll. Importance Primary Used In 1. Requesting Employee Donations 2.

Inputting Donation Information 3. Sending Donation Information to Payroll 4. Sending Employee Donation Numbers 5. Running Script to Input Data to Database Priority High (essential to the system) Identifier SC-2 Name Report Generation Description Allows the Office of External Relations to generate reports on USC faculty / staff donations to send to department heads.

Requesting Donation Report from Database Server 2. Sending Donation Report to Office of External Relations 3. Sending Reports on Donation Trends to Department Heads Priority High (essential to the system) Identifier SC-3 Name Employee Donation Description USC faculty / staff members are capable of making a donation through a web-interface. Inputting Donation Information to Web Server 2. Consolidating Donation Information 3. Generating Donation List 4.

Sending List to Payroll from Web Server Priority High (essential to the system) Identifier SC-4 Name Data Backups Description The system will create weekly backups of the new data inputted to database during campaign months. The system will make annual backups of each campaign. Importance Secondary Used In Data loss prevention and to maintain data integrity. Priority Medium (Important to the System) 1.2. 3 Levels of Service Level of Service LS-1: Response Time Description 5 seconds desired, 10 seconds acceptable Measurable Time to update database and to generate donation reports. Relevant Long delays will cause user frustration as well as limit the amount of work the user can accomplish.

Specific Report generation and donation analysis may cause delay due to the number of requests received by the web server and database server. Priority High (essential to the system) Level of Service LS-2: Usability Description Less overhead from user point to accomplish desired tasks and goals. Measurable Time to learn how to use the system and be able to use all the functions available to the user by the system. Relevant A non-user friendly system will cause user frustration as well as limit the amount of work the user can accomplish.

Specific The process of going about producing reports and donation analysis will determine how fast and efficient a user can manipulate the system's capabilities. Priority High (essential to the system) Level of Service LS-3: Stability Description Zero problems desired, one occasional problem acceptable. Measurable Time in which the system will not produce any problems with providing services to the user. Relevant Having very few problems will help improve on efficiency of the system. Specific Having incorrect data will not generate valid donation reports based on specified demographic factors.

Priority High (essential to the system) Level of Service LS-4: Maintenance Description No technical training for maintenance Measurable The number of times required to maintain the system over a year. Relevant Having scheduled maintenance's will not allow users to use the system's services until the scheduled maintenance is complete. Specific Revising data points for each entry will change the database structure. Priority High (essential to the system) 2.

System and Software Requirements Definition This section will describe the fundamental services provided by the system. It will discuss the project requirements, the system requirements, the system interface requirements, and the evolutionary issues of the system. 2.1 Project Requirements Project Requirement Microsoft Database user interface (PR-1) Description The database for the Good Neighbors campaign must reside on a Microsoft Access Database because that is the only database software that the stakeholders know how to use and maintain Measurable All the database information and coding related to the project must be done within the Microsoft access database program Achievable During the planning and design of the good neighbors campaign the team will base implementation off of Microsoft Access Relevant OCD PG-1 (Ease of Use) Project Requirement No Monetary Expenditures (PR-2) Description Due to the lack of resources for the good neighbors campaign we must be very careful when figuring out the cost of designing and implementing the project Measurable Track and account for all the money required to design the project and making sure that all current designs will be able to run on the stockholder's personal computer Achievable Creating budgeting forecasts for costs and designing programs and scripts on the same OS platform used by the good neighbors campaign Relevant OCD PC-2 (Funding) Specific OCD PG-3 (Low Cost) Project Requirement Efficient for budget purposes (PR-3) Description Due to the long processes current involved in handling and compiling data the stakeholders must have a new system that will significantly reduce the amount of man hours required to do the donation tracking and analyzing process this will cut down on the man hours required to do the task. The reduction of man hours will help ease budget issues.

Measurable The number of hours and people required for the process can be counted to see if we are reducing the manpower required for the process. Achievable Six sigma and lean greenbelt concepts can be applied to minimize process subsections and to balance the man hours required for each subsection. Relevant OCD PG-2 (Efficiency) Project Requirement Deadline by Fall (PR-4) Description Because the system needs to be used during the fall donation period there must be a usable system prior to the collection period which can be any time before any fall collection time. Measurable Date in which a working system is completed or ready to use Achievable System is deployed and ready to use by Fall of the year in which it is desired.

2.2 System Requirements System Requirement Login with Username and Password (SR-1) Description The system must allow USC Faculty and Staff to login with their USC username and password. System Capability Reference OCD SC-1 (Money Transaction and Logging) Measurable Users are logged into the system within 5 seconds of hitting the login button on web-interface Priority High (essential to system) System Requirement Login and Transaction Tracking (SR-2) Description The system must create a log entry for each login and transaction that occurs. System Capability Reference OCD SC-1 (Money Transaction and Logging) Measurable System must report time and username with every login and transaction Priority High (essential to system) System Requirement Report Generation (SR-3) Description The system must generate reports on administrator's request. System Capability Reference OCD SC-2 (Report Generation) Measurable Reports are generated successfully within 10 seconds of administrator's request Priority High (essential to system) System Requirement Report Generation Error Handling (SR-4) Description If system report generation fails, the system must notify the administrator and create an entry in error log file.

System Capability Reference OCD SC-2 (Report Generation) Measurable Error reports are created immediately after an error with report generation occurs. Priority High (essential to system) System Requirement Donation Handling (SR-5) Description The system must allow USC Faculty and Staff to make donations through paper form or a web-user interface. System Capability Reference OCD SC-3 (Employee Donation) Measurable Paper forms and web-interface are easy to use by USC Faculty and Staff for donations. Priority High (essential to system) System Requirement Donation Error Handling (SR-6) Description The system must notify the administrator if donation forms are not filled out correctly by USC Faculty or Staff.

System Capability Reference OCD SC-3 (Employee Donation) Measurable Errors must be easily identified upon inspection of donation forms. Priority High (essential to system) System Requirement Weekly Backups SR-7 Description The system must create weekly backups of donation forms during campaign month. System Capability Reference OCD SC-4 (Data Backups) Measurable Data is correct for each weekly backup. Priority High (essential to system) System Requirement Monthly and Annual Backups SR-8 Description The system must create monthly backups of donations received from Payroll throughout the year.

The system must also create yearly backups of donations from previous campaigns. System Capability Reference OCD SC-4 (Data Backups) Measurable Data is correct for each monthly and annual backup. Priority High (essential to system) 2.3 System Interface Requirements Interface Requirement Excel (IR-1) Description Because of the amount of data that is exchanged between the systems, there is a need to standardize the method of data representation. This will be standardized by using Microsoft Excel. Measurable Ensure that the scripts that are written make use of excel and all document exchange is in excel format. Achievable All documents in Excel.

Relevant OCD PG-1 (Easy to Use) OCD PG-2 (Efficiency) Interface Requirement Http (IR-2) Description To provide an easy method for employees to donate the internet is required to get the maximum number of donations possible. Measurable Web Server that accepts employee donations. Relevant OCD PG-2 (Efficiency) OCD SC-3 (Employee Donation) Interface Requirement Object Link Embedding (OLE) (IR-3) Description OLE will be the interface between the personal computer and the access database. Measurable Ensure that the scripts are written to utilize OLE for database updating and for report generation. Achievable All scripts use OLE.

Relevant OCD PG-1 (Easy to Use) OCD PG-2 (Efficiency) Interface Requirement Email (IR-4) Description Email will be used to interact between the Office of External Relations and the greater USC community. Measurable Ensure that email is the primary method of communicating the donation drive, though it could be supplemented by a paper drive. Achievable Emails go out to all USC faculty. Relevant OCD PG-1 (Easy to Use) OCD PG-2 (Efficiency) Interface Requirement Graphical User Interface (IR-5) Description To facilitate ease of use by the users the proposed system will have a graphical user interface. Measurable Ensure that the donation page of the system utilizes a graphical user interface. Achievable Main page uses a graphical user interface.

Relevant OCD PG-1 (Easy to Use) Interface Requirement Communication Interface (IR-6) Description For communication between users and the proposed system it will utilize the internet. Measurable The proposed system will use the internet for communications. Achievable The proposed system utilizes the internet. Relevant OCD PG-1 (Easy to Use) OCD PG-2 (Efficiency) 2.4 Evolutionary Issues Capability Evolution Requirement Authentication System Update (AUTHX) (ER-1) Description In our system design, both OER's internal system boundary and internal user boundary have a login accessory which is controlled by AUTHX. Measurable Every time AUTHX changes or gets updated, we want to ensure that the internal system boundary and internal user boundary will have the updated login. Achievable The newest and most updated version of AUTHX is within the database environment.

Relevant OCD PG-1 (Ease of Use) OCD PG-2 (Efficiency) Specific OCD SC-4 (Backups) OCD LS-4 (Maintenance) Interface Evolution Requirement Linking Modification (ER-2) Description In the next 2 years, USC will be changing all employee numbers from 10 digit numbers to 7 digit numbers. Measurable Once this change occurs, we want to ensure that the Employee ID# within the demographic data points of each individual is updated in the database. Achievable The OER database will have only 7 digit Employee ID#. Relevant OCD PG-1 (Ease of Use) OCD PG-2 (Efficiency) Specific OCD SC-4 (Backups) Technology Evolution Requirement Microsoft Access Update (ER-3) Description Microsoft releases a newer, more sophisticated, and more advanced version of Access periodically.

Measurable Every time a newer version of Access is available on the market, we want to ensure that the database is implemented on this updated environment. Achievable The OER database is on the most current version of Microsoft Access. Relevant OCD PG-1 (Ease of Use) OCD PG-3 (Low Cost) Specific OCD PC-2 (Funding) Environment and Workload Evolution Requirement Scripts Update (ER-4) Description Currently we need scripts to configure the donation information on Microsoft Excel spreadsheets, and then place these spreadsheets on OER's main and backup databases. Measurable Every time Access gets updated, the scripts need to be reevaluated to make sure that they are still compatible with the excel format. Achievable The newest, most compatible scripts are used in our system design. Relevant OCD PG-1 (Ease of Use) Specific OCD LS-4 (Maintenance) Levels of Service Evolution Requirement Web-Based (ER-5) Description There is a tremendous amount of paper litter in the process of recording a donation; this primarily has to do with the relationship between OER and Payroll.

Measurable Our 10 year goal is to try and remove all the paper involved in this process, and modify totally to a web-based process Achievable Good Neighbors Campaign donation forms are totally removed from process but may still be used for notification purposes to point to web-based system. Relevant OCD PG-1 (Ease of Use) Specific OCD PG-2 (Efficiency) OCD SC-3 (Employee Donation) 3. System and Software Architecture Description The purpose of this document will be to describe how the system will work and what components will be needed in order to implement it. It will describe in detail the software and hardware requirements as well as give a list of necessary requirements for the cycle 1 release of the system. Possible System Implementation (1) Good Neighbors Campaign Leader Requests Employee Donations Through Email The Good Neighbors Campaign Leader will send an email to the entire USC faculty and staff requesting donations for the Good Neighbors Campaign.

This email will contain a link to the donation page as well as information about the Campaign and where the funds go. (2) Employees (Users) Input Desired Donation Information The USC faculty and staff will go to the web server and input their desired donation number (in either a dollar amount or a percentage of their gross pay). (3) Send Donation Information The server will run a script that will take its donation information for all employees and format it into an excel spreadsheet. This spreadsheet will then be emailed to payroll so that they can take the numbers and use them to deduct the requisite fees from the employee's paychecks. They will also translate the percentage numbers into actual dollar amounts. (4) Send Employee Donation Numbers Once payroll gets all the donation numbers at the end of the campaign they send this information (in excel format) to the Office of External Relations.

(5) Run Script to Input to D BOnce the Office of External Relations gets the excel spreadsheet, they will run a client side script to take the information from the excel spreadsheet and input into the database. 3.1 Architecture Design This section will identify the software and hardware components of the system. It describes how the components interact, and how specifically they communicate. 3.1. 1 Structure and Topology Our system will have a three-layered architecture.

It will consist of the following layers 3.1. 1.1 Layers: Interface The interface layer will consist of the online user interface and the OER user interface. This layer's main function is to give the users of the interfaces the ability to get information form the GNC 3.1. 1.2 Layers: Organization The organization layer consists of the web server and the donation engine. This layer will be used to process the data and the requests by the users of the interface layer.

It will be accessed through the interface layer 3.1. 1.3 Layers: Data Layer The data layer will consist of the database and the backup database. The main function of this layer will be to store the data used in the system. This layer can be accessed through the organization layer. 3.1. 1.4 High Level Diagram This diagram shows the interactions between the various components of our system. We broke it up into four boundaries to show the difference between our groups of components.

The users are interested in the User Boundary which is where their interaction with system occurs. The User Boundary interacts with the Internet System Boundary which is where all the web based system components reside. The Internet System Boundary also interacts with the USC System Boundary where the USC Authentication system resides. The Internet System Boundary is connected to the Office of External Relations Internal System Boundary.

The Office of External Relations Internal System Boundary is where the Office of Internal Relations system resides. All the internal system components are located in this boundary, as is the actual database and scripts to interact with it. This Boundary is also connected to the USC System Boundary for system login. The Office of External Relations Internal System Boundary is also connected to the Office of External Relations Internal User Boundary which is where the Office of External Relations Users interact with the system. High Level Diagram 3.1. 2 Hardware Classifier Model This hardware classifier model shows the hardware components and connectors that will be used in order to maintain and operate the system.

See section 3.1. 5 for an explanation of each of the elements. 3.1. 3 Software Classifier Model The figure below shows all the components and all the interfaces of our system. The users will interact with the user interface components and ever component provides an interface to linking components. See section 3.1. 7 and 3.1.

8 for further detail. 3.1. 5 Hardware Component Classifiers This section will describe the hardware component classifiers 3.1. 5.1 Component Classifier: Workstation (HCMC-1) This section will describe the hardware component classifier called the workstation 3.1. 5.1. 1 Purpose The workstation allows for the online users donating to the Good Neighbor's Campaign (GNC) to access the GNC web server. Workstation refers to any personal computer connected to the internal USC network or the World Wide Web ( ).

For our purposes we will classify both the USC network and the as network. Users will use workstations to access and give information to the GNC. The workstation must use the network connector to access the Online User Interface of the GNC's Web Server 3.1. 5.1. 2 Interface (s) The list of interfaces are listed in the subsections below: 3.1. 5.1.

2.1 Feature: Network Interface (HCMCIF-1) The workstation will be connected to a network interface. This should be a standard internet connection. The connection type can vary and will be considered an network interface if it has the ability to upload and download via the network. 3.1. 5.1. 3 Parameters System is simple enough that there is no reason for a detailed description 3.1. 5.1.

4 Behavior System is simple enough that there is no reason for a detailed description 3.1. 5.1. 4.1 Processes System is simple enough that there is no reason for a detailed description 3.1. 5.1. 4.1. 1 Process XNA 3.1. 5.1. 4.2 Modes of Operation System is simple enough that there is no reason for a detailed description 3.1. 5.1. 4.2.

1 Mode XNA 3.1. 5.1. 5 L.O.S. Goals NA 3.1. 5.1. 6 ConstraintsNA 3.1. 5.1. 7 Internal ArchitectureNA 3.1. 5.2 Component Classifier: Server (HCMC-2) This section will describe the hardware component classifier called the server 3.1. 5.2.

1 Purpose The server will be the location of all the GNC information. The server will be located that the OER and will be connected to the internet at all times. It will wait until online users or OER user request services. At the time of the requests the web server will access the internal database to retrieve information to return back to the user. This server will include all of the GNC's needed data to monitor and track donations. This server will currently be running off of an OER personal computer. 3.1. 5.2.

2 Interface (s) The list of interfaces are listed in the subsections below: 3.1. 5.2. 2.1 Feature: Network Interface (HCMCIF-2) The server will be connected to a network interface. This should be a standard 10/100 Based-T Ethernet line connected through the USC ISD department 3.1. 5.2. 3 Parameters System is simple enough that there is no reason for a detailed description 3.1. 5.2. 4 Behavior System is simple enough that there is no reason for a detailed description 3.1. 5.2. 4.1 Processes System is simple enough that there is no reason for a detailed description 3.1. 5.2.

4.2 Modes of Operation System is simple enough that there is no reason for a detailed description 3.1. 5.2. 5 L.O.S. Goals Level of Service Server Response time (LS HCMC-2) Description Provide a fast response time to request made by users of the server whether it be to view a webpage or generate reports Measurable We can see how much computing and networking power is used during peak times to ensure that the users are getting a fast response time when they are requesting information Achievable Create programs that monitors the server's performance and note important information Relevant This is relevant to LS-1 Specific This system will be connected to the internet so there needs to be controls and monitoring for multiple users. 3.1. 5.2. 6 ConstraintsNA 3.1. 5.2. 6 Hardware Connector Classifiers This section will describe the hardware connector classifiers 3.1. 6.1 Connector Classifier: Network (HCMC-1) This section will describe the hardware connector classifiers called network 3.1. 6.1. 1 Purpose This network will provide the physical connection between the users and the web server.

It will allow for the communication between the hardware devices connected together. This network will allow for Local Area Network (LAN) and configurations. 3.1. 6.1. 2 Interface (s) The list of interfaces are listed in the subsections below: 3.1. 6.1. 2.1 Feature or Feature Set The network will be connected to the communication medium using standard interfaces that include dial up and 10/100/1000 Base-T Ethernet. 3.1. 6.1.

3 Parameters System is simple enough that there is no reason for a detailed description 3.1. 6.1. 4 Behavior System is simple enough that there is no reason for a detailed description 3.1. 6.1. 4.1 Processes System is simple enough that there is no reason for a detailed description 3.1. 6.1. 4.2 Modes of Operation System is simple enough that there is no reason for a detailed description 3.1. 6.1.

5 L.O.S. Goals Level of Service Network efficiency (LSH CNC-1) Description Follow standards in setting up the network to ensure that there is proper and efficient use of the network Measurable Using a I standard networking connection will ensure that we are complying with universal standards Achievable Use only I standardized networking connections Relevant LS-1, LS-2 and LS-43.1. 6.1. 6 ConstraintsNA 3.1. 6.1. 7 Software Component Classifiers The section describes the details of the software components specified in section 3.1. 33.1.

7.1 Component Classifier: Online User Interface (SCC-1) This section describes the detail of the software component called online user interface 3.1. 7.1. 1 Purpose This component allows for online users to access the GNC web server's features and capabilities. This interface should consider interoperability and should be able to send information requested by the user to them in a readable and usable format to the user. This online user interface will allow for users to donate to the GNC and track to see how much they have donated over their lifetime and how much they will be expected to donate in the future if they have pledged a certain amount over a period of time.

This online user interface will also allow for department heads to keep track of how their department is progressing in terms of donations and responses. 3.1. 7.1. 2 Interface (s) The list of interfaces are listed in the subsections below: 3.1. 7.1. 2.1 Feature: Information viewing (SCCIF-1) Purpose: To allow for the online users to view their profile information and donation history with the GNCPre: User use be registered with the USC AUTHX system Post: User will be able to see most up-to-date information 3.1. 7.1. 2.2 Feature: Information updating (SCCIF-2) Purpose: To allow for the online users to update their profile information and donation history with the GNCPre: User use be registered with the USC AUTHX system and must have a record with the GNCPost: User will be able to have the most updated information available to the GNC 3.1. 7.1. 2.3 Feature: Information downloading (SCCIF-3) Purpose: To allow for the online users to download their personal profile and donation history so they can have a soft copy of their records Pre: User use be registered with the USC AUTHX system and must have a record with the GNCPost: User will have a soft-copy of their records 3.1. 7.1. 2.4 Feature: Printing Capabilities (SCCIF-4) Purpose: To allow for the online users to print out their information that is displayed on the online user interface so they can obtain a hard copy of their records Pre: User use be registered with the USC AUTHX system and must have a record with the GNCPost: User will have a hard copy of their record 3.1. 7.1.

2.5 Feature: User authentication (SCCIF-5) Purpose: To authenticate that the user can enter this system Pre: Must be registered with the USC AUTHX system and is trying to log on to the system Post: the user will be authenticated and allowed to log onto the system 3.1. 7.1. 3 Parameters When SCC-1 is created a HTML format must be created for the online interface and Excel files must be created for the downloadable files 3.1. 7.1. 4 Behavior The interface that deals with SCC-1 the most would be the users of the interface. This will be the front end of the GNC web server. It will pass information between the user and the web server this could include viewing, updating, downloading, and printing actions. 3.1. 7.1. 4.1 Processes The list of interface processes are listed in the subsections below: 3.1. 7.1. 4.1.

1 Process: Establish connections (SCCP-1) Purpose: Connections must be established between both SCC-1 and the web server and the USC AUTHX system Pre: The web server is running Post: a connection is established 3.1. 7.1. 4.1. 2 Process: Compile and compress data (SCCP-2) Purpose: To compile all the data that needs to be sent from user, web server, or USC AUTHX system and compress the data so that it can be sent more efficiently Pre: server is running Post: compile and compress data that needs to be sent 3.1. 7.1. 4.2 Modes of OperationNA 3.1. 7.1. 5 L.O.S. Goals Level of Service Online User Interface Navigation (LSSCC-1) Description The online user interface must be easy to navigate Measurable Have a feedback or review with users and potential users of the system to see if the interface is easy to navigate. Achievable Interview a tenth of all registered members of the online user interface and offer recognition to those that do. Relevant LS-23.1. 7.1.

6 Constraints There could be a few constraints on this component of the system that include the following issues: browser types could vary from user to user and the level of skill of each individual user is different. The browser issue would create a situation where there is a possibility that SCC-1 will not display and the skill of each user could create an problem where the user might not know how to use the interface and therefore make it obsolete 3.1. 7.1. 7.2 Component Classifier: OER User Interface (SCC-2) This section describes the detail of the software component called OER user interface 3.1. 7.2. 1 Purpose This component allows for OER users to access the GNC web server's features and capabilities. This OER user interface will allow for OER employees to monitor donations and track the progress of different departments and allow them to contact the department heads of slowing progress. 3.1. 7.2.

2 Interface (s) The list of interfaces are listed in the subsections below: 3.1. 7.2. 2.1 Feature: Information viewing (SCCIF-6) Purpose: To allow for the OER users to view the profile information and donation history or those registered with the GNCPre: User use be registered with the USC AUTHX system and an administrator of the OERPost: User will be able to see most up-to-date information 3.1. 7.2. 2.2 Feature: Information updating (SCCIF-7) Purpose: To allow for the OER users to update departmental progress information with the GNCPre: User use be registered with the USC AUTHX system and be an administrator of the OERPost: User will be able to have the most updated information available to SCC-13.1. 7.2. 2.3 Feature: Information downloading (SCCIF-8) Purpose: To allow for the OER users to download all the reports stored on the web server Pre: User use be registered with the USC AUTHX system and must be an administrator of the OERPost: User will have a soft-copy of their records 3.1. 7.2. 2.4 Feature: Printing Capabilities (SCCIF-9) Purpose: To allow for the OER users to print out all the reports that are displayed in front of them so they can obtain a hard copy of their records Pre: User use be registered with the USC AUTHX system and must be an administrator of the OERPost: User will have a hard copy of their record 3.1. 7.2. 2.5 Feature: User authentication (SCCIF-5) Refer to 3.1. 7.1.

2.5 3.1. 7.2. 3 Parameters When SCC-2 is created a HTML format must be created for the online interface and Excel files must be created for the downloadable files 3.1. 7.2. 4 Behavior The interface that deals with SCC-2 the most would be the users of the interface. It will pass information between the user and the web server this could include viewing, updating, downloading, and printing actions. 3.1. 7.2. 4.1 Processes The list of interface processes are listed in the subsections below: 3.1. 7.2. 4.1. 1 Process: Establish connections (SCCP-1) Refer to 3.1. 7.1. 4.1.

13.1. 7.2. 4.1. 2 Process: Compile and compress data (SCCP-2) Refer to 3.1. 7.1. 4.1. 23.1. 7.2. 4.2 Modes of OperationNA 3.1. 7.2. 5 L.O.S. Goals Level of Service OER User Interface Navigation (LSSCC-2) Description The OER user interface must be easy to navigate Measurable Talk directly to the administrators to see if the usability is to their linking. Achievable Talk directly to the administrators to see if the usability is to their linking.

This is possible because there should not be more than one or two administrators Relevant LS-23.1. 7.2. The browser issue would create a situation where there is a possibility that SCC-2 will not display and the skill of each user could create an problem where the user might not know how to use the interface and therefore make it obsolete 3.1. 7.2. 7.3 Component Classifier: Web Server (SCC-3) This section describes the detail of the software component called Web Server 3.1. 7.3. 1 Purpose The web server will help the online user interface and OER user interface run properly. This will be the bridge between the two previously stated interfaces and the donation engine depicted in 3.1. 3.

SCC-3 will be run on HCMC-2 which is described in detail in 3.1. 5.2. The web server will retrieve information requested by the users and present it to the user in a user-friendly format. This web server basically allows the user interfaces to run and act as a bridge between users and the donation engine 3.1. 7.3. 2 Interface (s) The list of interfaces are listed in the subsections below: 3.1. 7.3. 2.1 Feature: Multiple Users (SCCIF-10) SCC-3 must allow more than one user at a time because without the multiple user function the server will create a huge bottleneck for users that need information from the GNC 3.1. 7.3. 2.2 Feature: Server-side Scripting (SCCIF-11) The web server must provide a number of scripts that will mainly display reports for the OER users. 3.1. 7.3.

3 Parameters When SCC-3 is created it must be able to hand HTTP request and it must send out HTTP reposes in return. It must also be able to display reports with the scripts that it should already have. 3.1. 7.3. 4 Behavior The interface that deals with SCC-3 the most would be the online users interface and the OER user interface. This will be the link and power house of the GNC web site. It will sit idle and wait for users to request information and upon request the SCC-3 will respond with the appropriate information. 3.1. 7.3. 4.1 Processes The list of interface processes are listed in the subsections below: 3.1. 7.3. 4.1.

1 Process: Listen to requests (SCCP-3) Purpose: SCC-3 should sit idle when there are no requests because this ensures that the server is not wasting its resources and can respond more effectively if a request does come Pre: server has or does not have processes running Post: server will finish old processes and sit idle until new processes are requested 3.1. 7.3. 4.2 Modes of OperationNA 3.1. 7.3. 5 L.O.S. Goals Level of Service Web Server Response Time (LSSCC-3) Description Provide a fast response time to request made by users of the server whether it be to view a webpage or generate reports Measurable We can see how much computing and networking power is used during peak times to ensure that the users are getting a fast response time when they are requesting information Achievable Create programs that monitors the server's performance and note important information Relevant This is relevant to LS-13.1. 7.3. 6 Constraints There could be a few constraints on this component of the system that include the following issues: the capacity of the server could not be enough to effectively run SCC-3 and there could be an issue with network bandwidth if the OER is subject to strict limits. 3.1. 7.3. 7.4 Component Classifier: Donation Engine (SCC-4) This section describes the detail of the software component called Donation Engine 3.1. 7.4. 1 Purpose The Donation engine will be the power house behind the SCC-3.

It will be in charge of generating the reports that that SCC-3 will pass along to SCC-1 and SCC-2. SCC-4 will be take current database information and create reports and it will also be the link between the system and the USC payroll system. It will extract data from the standard formatted USC payroll systems and then incorporate the new information into the system's database. It will also be in charge of passing information to the database and the backup database. 3.1. 7.4.

2 Interface (s) The list of interfaces are listed in the subsections below: 3.1. 7.4. 2.1 Feature: Report Generation (SCCIF-12) SCC-4 will take the data from the database and compile the information and create reports tracking the donation performance of each individual and department then it will send the report to SCC-3 that will use it for SCC-1 and SCC-2.3. 1.7. 4.2. 2 Feature: Extracting Data (SCCIF-13) Purpose: To extract data from the USC payroll standard formatted files Pre: File from USC payroll will be given to SCC-4 Post: Relevant data from the file will be extracted and SCC-4 will pass the information to the Database components 3.1. 7.4. 2.3 Feature: Backup (SCCIF-14) Purpose: To tell the database to copy its files to the backup database on a weekly basis in order to ensure the integrity of the database Pre: there exists information in the database Post: Copy of the database is stored in the backup database 3.1. 7.4.

3 ParametersSCC-4 must be able to take database information and generate reports based on the request from SCC-2 given to SCC-3 then to SCC-4. It must also have the ability to take data from the USC payroll department's standard format files. 3.1. 7.4. 4 BehaviorSCC-4 will generate reports based on the needs of SCC-3 it will also store or pre-generate reports that are commonly used or summoned by SCC-3. It will also update the reports once it gets new data from the USC payroll department. SCC-4 will also control when the backup database will be used. 3.1. 7.4. 4.1 Processes The list of interface processes are listed in the subsections below: 3.1. 7.4. 4.1.

1 Process: Store reports (SCCP-4) Purpose: When SCC-4 is done generating the reports it will store them so they are easily accessible when they are needed Pre: SCC-4 has generated the reports Post: the reports are stored in the database 3.1. 7.4. 4.2 Modes of OperationNA 3.1. 7.4. 5 L.O.S. Goals Level of Service Donation Engine Response Time (LSSCC-4) Description Provide a fast response time to request made by users of the server whether it be to view a webpage or generate reports Measurable We can see how much computing power is used during peak times to ensure that the other dependant components are getting a fast response time when they are requesting information Achievable Create programs that monitors the server's performance and note important information Relevant This is relevant to LS-13.1. 7.4. 6 ConstraintsNA 3.1. 7.4. 7.5 Component Classifier: Database (SCC-5) This section describes the detail of the software component called database 3.1. 7.5. 1 Purpose SCC-5 will be used to store the information collected form the donors, the USC payroll department and from reports generated by SCC-4.

SCC-5 will allow for quick access to all the data required by either the users of the online user interface or the users of the OER user interface. 3.1. 7.5. 2 Interface (s) The list of interfaces are listed in the subsections below: 3.1. 7.5. 2.1 Feature: User Authentication (SCCIF-15) SCC-5 will have authentication that will only allow SCC-4 access the database and no one else. This will ensure that the database will retain its integrity.

Although this could be considered tight, due to the nature of the system and the ease of use and the limited knowledge of the users it is beneficial to have this type of authentication where users are not able to edit the database by themselves. 3.1. 7.5. 3 ParametersSCC-5 must be able to take information given to it from SCC-4. SCC-4 should be giving SCC-5 all the information it needs in a usable format so there is minimal conversion of information from one format to another. It will be able to export and import files depending on what format SCC-4 will be giving it. 3.1. 7.5. 4 BehaviorSCC-5 will store information and will consistently be in an idle state waiting for a component to request information. It will also be able to convert some already know formats into data that it will place in the database. 3.1. 7.5.

4.1 Processes The list of interface processes are listed in the subsections below: 3.1. 7.5. 4.1. 1 Process: Get Data (SCCP-5) Purpose: To retrieve data from the database Pre: SQL command for data must be given, valid table, valid user Post: results can be returned either to SCC-4 directly in data format or CSV or Excel formats 3.1. 7.5. 4.1. 2 Process: Add Data (SCCP-6) Purpose: To add new data to the database Pre: valid data, existing table, valid user Post: the valid data will be added to the table 3.1. 7.5. 4.1. 3 Process: Manage User (SCCP-7) Purpose: Add or remove or modify users and their profiles Pre: valid administrator Post: user is removed, added, or updated 3.1. 7.5. 4.1. 4 Process: Manage Table (SCCP-8) Purpose: Add, remove, or modify tables Pre: valid user Post: new table is added, old table was removed or current table was updated 3.1. 7.5.

4.2 Modes of Operation The database can have different modes as listed below 3.1. 7.5. 4.2. 1 Mode: Read only (SCCM-1) The entire database is locked in read only mode 3.1. 7.5. 4.2. 2 Mode: Read / Write (SCCM-2) The entire database allows for read and write modes 3.1. 7.5. 4.2. 3 Mode: Administrator (SCCM-3) The administrator mode is allowed to have full access to everything 3.1. 7.5. 4.2.

4 Mode: Guest (SCCM-4) The guest mode is limited to editing the guest's own profile and only allowed to read limited portions of the database and having no editing ability outside their own domain 3.1. 7.5. 5 L.O.S. Goals Level of Service Database maintenance (LSSCC-5) Description Database should be easy to maintain and not require constant administrator monitoring Measurable The database will follow standard formats and will not do anything out of the pre-set boundaries Achievable Do not let anyone except for the administrator modify any of the pre-set formats that the system uses Relevant This is relevant to LS-2, LS-3, LS-43.1. 7.5. 6 Constraints There could be issues where the database is trying to query something that is too big for SCC-4 to handle and it will drastically effect the performance of the system. 3.1. 7.5. 7.6 Component Classifier: Backup Database (SCC-6) This section describes the detail of the software component called database 3.1. 7.6. 1 Purpose The main function of SCC-6 will be to store whatever SCC-5 stores but in weekly intervals. Refer to SCC-5.3. 1.7.

6.2 Interface (s) The list of interfaces are listed in the subsections below: 3.1. 7.6. 2.1 Feature: User Authentication (SCCIF-15) Refer to SCCIF-15.3. 1.7. 6.3 ParametersSCC-6 will weekly copy what SCC-5 has newly stored it its component. Refer to SCC-5.3. 1.7.

6.4 BehaviorSCC-6 acts as a backup and stores SCC-5's information on a constant basis. It will never have something that SCC-5 did not have before 3.1. 7.6. 4.1 Processes The list of interface processes are listed in the subsections below: 3.1. 7.6. 4.1. 1 Process: Get Data (SCCP-5) Refer to SCCP-53.1. 7.6. 4.1. 2 Process: Add Data (SCCP-6) Refer to SCCP-63.1. 7.6. 4.1.

3 Process: Manage User (SCCP-7) Refer to SCCP-73.1. 7.6. 4.1. 4 Process: Manage Table (SCCP-8) Refer to SCCP-83.1. 7.6. 4.2 Modes of Operation The database can have different modes as listed below 3.1. 7.6. 4.2. 1 Mode: Read only (SCCM-1) Refer to SCCM-13.1. 7.6. 4.2.

2 Mode: Read / Write (SCCM-2) Refer to SCCM-23.1. 7.6. 4.2. 3 Mode: Administrator (SCCM-3) Refer to SCCM-33.1. 7.6. 4.2. 4 Mode: Guest (SCCM-4) Refer to SCCP-43.1. 7.6. 5 L.O.S. Goals Level of Service Backup Database maintenance (LSSCC-6) Description Backup Database should be easy to maintain and not require constant administrator monitoring Measurable The backup database will follow standard formats and will not do anything out of the pre-set boundaries Achievable Do not let anyone except for the administrator modify any of the pre-set formats that the system uses Relevant This is relevant to LS-2, LS-3, LS-43.1. 7.6. 6 Constraints There could be a loss of information if SCC-5 crashes before SCC-6 is able to back it up. 3.1. 7.6. 7 Internal ArchitectureNA 3.2 System Services and Processes In this section we will address the requirements of our project and show that the processes that we have will fulfill the client's needs. 3.2.

1 The Processes Identifier UC-1 Use-Case Name View Online User Interface Information Abstract No Purpose To display the requested pages to the users of the online user interface Actors 1. USC Faculty and Staff 2. Donors Importance Primary Capability 1. OCD SC-1 (Money Transaction and Logging) 2. OCD SC-2 (Report Generation) 3.

OCD SC-3 (Employee Donation) Requirements 1. SSRD SR-1 (Login with Username and Password) 2. SSRD SR-5 (Donation Handling) Risks There could be broken links High-Risk? No Architecturally Significant? Yes Development Status LCAOverview Allows for users of the online user interface to see information that they requested Pre-conditions The web server is running and GNC information is available to use Post-conditions There should be a webpage displaying all of the information requested Identifier UC-2 Use-Case Name View OER User Interface Information Abstract No Purpose To display the requested pages to the users of the OER user interface Actors 1. OER staff 2.

Administrator Importance Primary Capability 1. Yes Development Status LCAOverview Allows for users of the OER user interface to see information that they requested and also to update and allow for the control of viewing for online user interface. Pre-conditions The web server is running and GNC information is available to use Post-conditions There should be a webpage displaying all of the information requested Identifier UC-3 Use-Case Name Generate reports Abstract No Purpose To generate reports based on the donations of different departments and different individuals Actors 1. OER staff Importance Primary Capability 1. OCD SC-2 (Report Generation) Requirements 1. SSRD SR-3 (report generation) Risks Data could be corrupted during generation of reports High-Risk?

Yes Development Status LCAOverview Allows the staff of the OER to generate reports in order to better track the donations of the users of the online interface Pre-conditions The web server is running and GNC information is available to use Post-conditions There should be a report generated from the current data that is requested Identifier UC-4 Use-Case Name View reports Abstract No Purpose To view reports based on the donations of different departments and different individuals that have already been generated and stored Actors 1. OER staff 2. USC staff and faculty Importance Primary Capability 1. SSRD SR-3 (report generation) Risks Data could be corrupted High-Risk? Yes Development Status LCAOverview Allows the users of the online interface to view the reports generated by the OER staff so they can better see their own donation statuses Pre-conditions The web server is running and GNC information is available to use Post-conditions There should be a report generated from the current data that is requested Identifier UC-5 Use-Case Name Connection Establishment Abstract No Purpose Connections must be made between the online web interface, the web server, and the USC AUTHX system Actors 1. USC Faculty and Staff 2.

System Administrator 3. Office of External Relations Importance Primary Capability 1. OCD SC-1 (Money Transaction and Logging) Requirements 1. SSRD SR-1 (Login with Username and Password) Risks Connection could be lost High-Risk?

Yes Development Status LCAOverview This will allow for the users of the online user interface and the oer user interface systems to connect to their respective applications Pre-conditions The web server is running. Post-conditions A connection is established. Identifier UC-6 Use-Case Name Data Compilation and Compression Abstract No Purpose To compile all the data that needs to be sent from user, web server, or USC Actors 1. Office of External Relations 2. System Administrator Importance Primary Capability 1.

SSRD SR-3 (Report Generation) Risks Data could be corrupted and potentially lost during compilation and compression High-Risk? Could potentially compromise the integrity of the database Architecturally Significant? Yes Development Status LCAOverview This will allow for the compilation and compression of the data received and compile by the donation engine. Pre-conditions The web server is running, Post-conditions The data is compiled, compressed, and ready to be sent.

Identifier UC-7 Use-Case Name Request Listener Abstract No Purpose The web server should sit idle when there are no requests because this ensures that the server is not wasting its resources and can respond more effectively if a request does come. Actors Web server Importance Primary Capability 1. OCD SC-3 (Employee Donation) 4. OCD SC-4 (Data Backups) Requirements 1. SSRD SR-3 (Report Generation) 3.

SSRD SR-5 (Donation Handling) 4. SSRD SR-7 (Weekly Backups) 5. SSRD SR-8 (Monthly and Annual Backups) Risks There could be too many processes running on the server and therefore it might be slow at responding to requests High-Risk? Yes Development Status LCAOverview The server needs to sit passively to receiver requests that are needed by the users of the online and the oer user interfaces Pre-conditions Server has or does not have processes running.

Post-conditions Server will finish old processes and sit idle until new processes are requested. Identifier UC-8 Use-Case Name Report Storage Abstract No Purpose When the donation engine is done generating the reports it will store them so they are easily accessible when they are needed. Actors 1. System Administrator 2. Office of External Relations Importance Primary Capability OCD SC-2 (Report Generation) Requirements 1. SSRD SR-2 (Login and Transaction Tracking) 2.

SSRD SR-7 (Weekly Backups) 3. SSRD SR-8 (Monthly and Annual Backups) Risks Data could be lost during the transfer High-Risk? Yes Development Status LCAOverview This process will just store the data generated from the requests of the OER users Pre-conditions The donation engine has generated the reports. Post-conditions The reports are stored in the database.

Identifier UC-9 Use-Case Name Data Retrieval Abstract No Purpose To retrieve data from the database. Actors 1. USC Faculty and Staff 3. OCD SC-2 (Report Generation) 2. SSRD SR-3 (Report Generation) 2.

SSRD SR-5 (Donation Handling) 3. SSRD SR-7 (Weekly Backups) 4. SSRD SR-8 (Monthly and Annual Backups) Risks Potentially retrieve data that is not in the database High-Risk? Yes Development Status LCAOverview The process just allows for the system to retrieve data that is already in the database Pre-conditions SQL command for data must be given. There must be a valid table and valid user. Post-conditions Results can be returned either to donation engine directly in data format or CSV or Excel formats.

Identifier UC-10 Use-Case Name Data Storage Abstract No Purpose To add new data to the database Actors 1. USC Faculty and Staff 2. Office of External Relations 3. OCD SC-1 (Money Transaction and Login) 2. SSRD SR-8 (Monthly and Annual Backups) Risks Data base corrupted and cannot be accessed High-Risk?

Yes Architecturally Significant? Yes Development Status LCAOverview This just stores data into the database Pre-conditions Data must be valid, the table must exist, and the user must be valid. Post-conditions Valid data will be added to the table. Identifier UC-11 Use-Case Name User Management Abstract No Purpose Add or remove or modify users and their profiles. Actors 1.

System Administrator Importance Primary Capability OCD SC-1 (Money Transaction and Logging) Requirements 1. SSRD SR-2 (Login and Transaction Tracking) Risks There could be possible security issues with the users if the properties are not set properly High-Risk? Yes Development Status LCAOverview This allows for the management of users and their profile and their existence on the system Pre-conditions System Administrator must be valid. Post-conditions User profile is added, removed, or modified. Identifier UC-12 Use-Case Name Data Management Abstract No Purpose Add, remove, or modify tables. Actors 1.

SSRD SR-5 (Donation Handling) Risks Data could be compromised by mishandling tables High-Risk? Yes Development Status LCAOverview This process will control the tables and the management of the tables Pre-conditions User must be valid. Post-conditions Table is added, old table was removed or current table was updated. 3.2. 2 Levels of Service Online User Interface NavigationL.O.S. Requirement Applies To HowLOS-1 Online User Interface Navigation 1. SSAD UC-1 (Connection Establishment) 2. SSAD UC-3 (Request Listener) 3.

SSAD UC-7 (User Management) The online user interface must be easy to navigate. OER User Interface NavigationL.O.S. Requirement Applies To HowLOS-2 OER User Interface Navigation 1. SSAD UC-5 (Data Collection) 4. SSAD UC-6 (Data Storage) 5.

SSAD UC-7 (User Management) 6. UC-8 (Data Management) The OER user interface must be easy to navigate. Web Server Response TimeL.O.S. Requirement Applies To HowLOS-3 Web Server Response Time 1. SSAD UC-2 (Data Compilation and Compression) 3. SSAD UC-3 (Request Listener) 4. SSAD UC-4 (Report Storage) 5.

SSAD UC-5 (Data Collection) 6. SSAD UC-6 (Data Storage) Provide a fast response time to request made by users of the server whether it be to view a webpage or generate reports. Donation Engine Response TimeL.O.S. Requirement Applies To HowLOS-4 Donation Engine Response Time 1. SSAD UC-6 (Data Storage) 7.

UC-8 (Data Management) Provide a fast response time to request made by users of the server whether it be to view a webpage or generate reports. Database maintenanceL.O.S. Requirement Applies To HowLOS-4 Database Maintenance 1. SSAD UC-2 (Data Compilation and Compression) 2. SSAD UC-4 (Report Storage) 3. SSAD UC-6 (Data Storage) 4. SSAD UC-7 (User Management) 5.

SSAD UC-8 (Data Management) Database should be easy to maintain and not require constant administrator monitoring. Backup Database maintenanceL.O.S. Requirement Applies To HowLOS-4 Donation Engine Response Time 1. SSAD UC-8 (Data Management) Backup Database should be easy to maintain and not require constant administrator monitoring. 3.3 Alternatives Explored As a group, we originally wanted to design a unified web-based database that interacted with both the Office of External Relations and the USC Payroll Department. However, the major restriction imposed upon us was the fact that the payroll department wanted to maintain their current database environment, despite its outdated and archaic nature.

Therefore, we then decided to implement a separate "backup" web-based database simply for OER's records. Naturally, the communication process between all systems involved is now more complicated and has a greater possibility of error, however, given this restriction, it seems to be the best alternative and was met with great approval from our contact. We wanted the database to be web-based in nature to try and remove the paper trail that is presently current in the donation process. Our implementation design is a stand-alone process that is independent of paper trail. However, given the realistic nature of OER's donation extraction, we understand that a paper trail is somewhat inevitable at least for the near future and therefore can serve as an additional recording of information with our database.

3.4 Implementation Design Our implementation design consists of five major components, namely, the user boundary, the internet system boundary, the Office of External Relations internal system boundary, the Office of External Relations internal user boundary, and the payroll boundary. 3.4. 1 User Boundary The user boundary simply consists of a web browser with clients entailing it. This is the initial phase that must be entered by a user to check, analyze, or update any donation or personnel information. This user boundary serves as a mediator between a generic user and the desired application that particular user intends on exercising with respect to our system. It is accomplished in a web-based manner. 3.4. 2 Internet System Boundary The internet system boundary consists of a login, which is controlled by a USC authentication system (A.