System and Software Requirements Description (SSRD) Version 10.0
System and Software Requirements Definition (SSRD)
California Science Center Volunteer Tracking System
Team #3
Phongphan Danphitsanuphan / Project ManagerCharlie Lormanometee / Project Coordinator / QA
Deepak Pandey / System Analyst / Tester
Pongtip Aroonvatanaporn / System Architect / Programmer
Natachart Laoteppitak / Software Architect / Programmer
Amit Shah / Quality Focal Point Personnel
Jeremy Stoller / Client
Vincent Tsan / Maintainer
August 25 2008
Version History
Date / Author / Version / Changes made / Rationale /10/1/06 / RK, DP / 1.0 / Made original document Using Lean MBASE so no change / Initial requirement analysis document
10/11/06 / DP / 1.1 / Edit priorities of capability requirements
Sec-3.0 / Edited the priorities to better fit with the Win-Win conditions
10/18/06 / DP / 1.2 / Edit priorities of capability requirements
Sec-3.0 / Edited the priorities to better fit with win win conditions after re-voting
10/22/06 / DP,RK / 2.0 / Edit priorities of requirements and added some requirements
Sec-3.0 , 4.1 / Edited the priorities to better fit for ARB added requirements after ARB session
11/19/06 / DP / 2.1 / Edited Sec-3.0 , 4.1 / Edited the priorities to better fit for LCA draft added requirements after LCO package
11/30/06 / DP / 2.2 / Added CR-13 in the Capability Requirements section / This was a new capability.
02/01/07 / PD / 6.0 / · section 5.0 / · Update win condition matching to the requirement
· Update version to 6.0 (RLCA baseline version)
2/2/07 / PA / 6.1 / · Edited CR-12 to have clearer name
· Added CR-14: Email feature. / · Update after traceability matrix
2/14/07 / PA / 6.2 / · Updated the Level of Service Goals to better correspond with the ones mentioned in OCD.
· Added Section 1.3 RLCA Summary of Change.
· Updated the Evolutionary Requirements. Some capability requirements have been moved to this section.
· Edited Section 6 to show that modes of operation is not applicable to the system.
· Removed “PR-5 Use of class tools” because it does not map to win condition and does not consider to be a project requirement. Use of class tools is not a requirement, but tools only help the process in the project. / · Prepare document for RLCA Package.
4/1/07 / PA / 7.0 / · Add CR-15: Person Information Management Module / · This requirement has recently been added by Team 0
4/1/07 / Phongphan / 7.1 / · Session 2.4, 3.0 / · Update table 15
· Update table 21 and 31 by adding note
4/30/07 / Phongphan / 8.0 / · Session 1.2, 1.3, 3 / · Session 1.2, Change document reference version
· Session 1.3, Add in IOC summary of change
· Session 3
o Move CR5 to ER3
o Move CR7 to ER4
o Mover CR12 to ER5
5/16/08 / Di Wu / 9.0 / · Update all sections / · To comply with LeanICM guideline
8/4/08 / Supannika Koolmanojwong / 9.1 / · Updated section 1.1
· Rewrote PR-3 to Instructional-ICM
· Rewrote PR-4, PR-8, PR-11, PR-12, PR-13, PR-17, PR-19, CR-1, CR-4, CR-5 SR-3, SR-4, SR-5, LOS-2, ER-1, ER-2 and ER-5 requirement statements / · Improve readability, clarify requirement statements and correct the wrong information.
08/20/08 / Di Wu / 9.2 / · Re-arrange sections based on the revised section order in LeanICM guideline
· Add WinWin-Agreement ID / · To comply with Instructional ICM-Sw guideline
· To complete WinWin-Agreement
08/21/08 / Di Wu / 9.3 / · Re-number project requirements and evolutionary requirements / · Requirements ID will be in order after sections are re-arranged
08/25/08 / Supannika Koolmanojwong / 10.0 / · Formatted the document / · To conform with ICM document standard
Table of Contents
System and Software Requirements Definition (SSRD) I
Version History II
Table of Contents IV
Table of Tables V
1. Introduction 1
1.1. Purpose of SSRD 1
1.2. Status of SSRD 1
2. Product Requirements 2
2.1. Capability (Functional) Requirements 2
2.2. Level of Service (L.O.S.) Requirements 5
3. Interface Requirements 8
3.1. User Interface Standards Requirements 8
3.2. Hardware Interface Requirements 8
3.3. Communications Interface Requirements 8
3.4. Other Software Interface Requirements 8
4. Project Requirements 10
4.1. Tools Requirements 10
4.2. Language Requirements 10
4.3. Computer Hardware Requirements 11
4.4. Computer Software Requirements 11
4.5. Computer Communication Requirements 11
4.6. Deployment Requirements 12
4.7. Transition Requirements 12
4.8. Support Environment Requirements 13
4.9. Budget and Schedule 13
4.10. Miscellaneous Development Requirements 13
5. Evolutionary Requirements 15
5.1. Capability Requirements 15
5.2. Level of Service Requirements 17
5.3. Software Interface Requirements 17
Table of Tables
Table 1: Provide online application 2
Table 2: Track clock in/ out hours 2
Table 3: Track working hours 2
Table 4: Track communication 3
Table 5: Submit job requests 3
Table 6: Schedule volunteers 4
Table 7: View volunteer profile 4
Table 8: Edit volunteer profile 4
Table 9: Manage person Information 5
Table 10: Availability 5
Table 11: Query correctness 5
Table 12: System response time to web browsing 6
Table 13: Interoperability 6
Table 14: Use existing templates 7
Table 15: Use XHTML 1.1 standards 7
Table 16: Interface with authentication module 7
Table 17: Interface with authorization module 8
Table 18: Interface with email (newsletter) module 8
Table 19: Separate logic from interface 8
Table 20: Modular Design 8
Table 21: Follow Instructional-ICM guideline 9
Table 22: Use Dreamweaver 8 tool 9
Table 23: Use course required tools 9
Table 24: Use PHP language 9
Table 25: Use SQL language 10
Table 26: Use AJAX in GUI development 10
Table 27: Processor Requirement 10
Table 28: Use MySQL as a database 10
Table 29: Internet/ Intranet protocol 10
Table 30: Deploy on Apache Web Server 11
Table 31: Deliver final product on compact disk 11
Table 32: Provide training 11
Table 33: Test on Linux operating system 11
Table 34: Test on web browsers 11
Table 35: Provide source code documentation 12
Table 36: CSC Web engineer skills 12
Table 37: Schedule of 24 weeks 12
Table 38: Zero monetary budget 12
Table 39: Collaborate with other teams 13
Table 40: Provide database backup capability 13
Table 41: Provide database restore capability 13
Table 42: Track award 14
Table 43: Generate Certificates 14
Table 44: Generate reports 14
Table 45: Upgradable 15
Table 46: Scalability 15
SSRD_OCP_S07b_T03_V10.0 15 Version Date: 8/25/08
System and Software Requirements Description (SSRD) Version 10.0
SSRD_OCP_S07b_T03_V10.0 15 Version Date: 8/25/08
System and Software Requirements Description (SSRD) Version 10.0
1. Introduction
1.1. Purpose of SSRD
The purpose of the SSRD is to document the requirements of the project that derived from WinWin negotiation sessions. Moreover, the SSRD will act as a contract to all stakeholders about the delivered system. Hence, SSRD defines what the delivered system will do, what will be the behavior of the system and other project-specific stakeholders’ agreed win conditions.
1.2. Status of SSRD
The current document is in an Operation Commitment Package. There are no open issues. Based on the requirement recently added by Team 0, Team 3 is to implement a module to maintain the person information that overlap among the three projects. The module needs to keep track of the reference counts of each person of the number of application that refer to that particular person. Whenever the number reaches 0, the person record should be deleted from the database. The module is to provide the interface for all applications to access the person information database as well as allow control for concurrent access. In addition, scope of the project has been reduced because of time constraint. Some of core capabilities were taken out of scope of implementation.
2. Product Requirements
2.1. Capability (Functional) Requirements
Table 1: Provide online application
Capability Requirement: / CR-1: Provide online applicationDescription: / Volunteers should be able to submit their application online through the CSC website.
Priority: / M (Must have)
Input(s): / Volunteers’ personal information required in the application field based on the application criteria such as Name, SSN, and Address.
Source(s): / User input
Output(s): / Entry in database and confirmation that it has been submitted successfully
Destination(s): / The system’s database, GUI
Precondition(s): / GUI screen for input accessed through the California Science Center website.
Post conditions(s): / A confirmation screen and a new entry added to the system’s database
Win-Win Agreement(s): / Agreement1
Table 2: Track clock in/ out hours
Capability Requirement: / CR-2: Track volunteer clock in/ out hoursDescription: / System should provide the capability for volunteers to clock in /out.
Priority: / M (Must have)
Input(s): / Click on the time in/out button
Source(s): / User input
Output(s): / The time in/out entry will be recorded in database.
Destination(s): / The system database, GUI
Precondition(s): / a. GUI screen for input(time in/out)
b. Volunteer login privilege
Post conditions(s): / New time in or time out entry recorded to the database. GUI screen is updated.
Win-Win Agreement(s): / Agreement2
Table 3: Track working hours
Capability Requirement: / CR-3: Track working hoursDescription: / System should be able to track each volunteer’s working hours.
Priority: / M (Must have)
Input(s): / Time entry and volunteer information
Source(s): / User input
Output(s): / Number of working hours will be tracked based on clock in/out.
Destination(s): / The system database, GUI
Precondition(s): / a. GUI screen for input
b. Volunteer login privilege
Post conditions(s): / Number of working hours will be displayed and recorded to the database.
Win-Win Agreement(s): / Agreement3
Table 4: Track communication
Capability Requirement: / CR-4: Track communicationDescription: / System must enable communications (so called “comment log”) between:
a. Different departments
b. Departments’ supervisors and volunteers
c. Departments’ supervisors and volunteer coordinator
These communications will be either private or public and must be traceable.
Priority: / S (Should have)
Input(s): / Text or comment log
Source(s): / User input
Output(s): / Comment Records
Destination(s): / The system database, GUI
Precondition(s): / a. A CSC staff enters comments to another staff either in the same or different department.
b. The supervisor who directs volunteers enters comments to volunteers and vice versa.
c. A department’s staff or volunteer coordinator enters evaluative comments on a volunteer.
Post conditions(s): / Comment entries will be recorded to the user’s record in the system’s database. GUI is also updated.
Win-Win Agreement(s): / Agreement4
Table 5: Submit job requests
Capability Requirement: / CR-5: Submit job requestsDescription: / System must be able to allow supervisor to submit job requests.
Priority: / M (Must have)
Input(s): / Job descriptions with the information about volunteer’s skill needed and schedule required.
Source(s): / User input
Output(s): / Job request information i.e. number of volunteers required
Destination(s): / The system database
Precondition(s): / a. GUI screen for the activities with their information
b. Supervisor or volunteer coordinator log in privilege
Post conditions(s): / Screen confirmed that the system has already received that activity’s information and a new job entry recorded to the system database.
Win-Win Agreement(s): / Agreement5
Table 6: Schedule volunteers
Capability Requirement: / CR-6: Schedule volunteersDescription: / System should be able to facilitate the scheduling of volunteers based on supervisors’ job requests and volunteers’ skills and their available time.
Priority: / S (Should have)
Input(s): / Job requests stored in the system database
Source(s): / User input
Output(s): / Matches between volunteer and job criteria
Destination(s): / User screen
Precondition(s): / a. GUI screen for the activities with their information
b. Volunteer coordinator log in privilege
Post conditions(s): / a. Screen having names of the volunteers with the activities matched.
b. Updated volunteers and job records in the system database
Win-Win Agreement(s): / Agreement6
Table 7: View volunteer profile
Capability Requirement: / CR-7: View volunteer profileDescription: / The volunteer coordinator should have the ability to view the volunteer profile.
Priority: / S (Should have)
Input(s): / Selected volunteer
Source(s): / Volunteer information in the database
Output(s): / Volunteer profile
Destination(s): / GUI
Precondition(s): / a. User is logged in as volunteer coordinator
b. Volunteer information exists in the database
Post conditions(s): / Volunteer profile is displayed on the screen
Win-Win Agreement(s): / Agreement7
Table 8: Edit volunteer profile
Capability Requirement: / CR-8: Edit volunteer profileDescription: / The volunteer coordinator should have the ability to edit volunteer profile.
Priority: / S (Should have)
Input(s): / Selected volunteer
Source(s): / Volunteer information in the database
Output(s): / Updated volunteer profile
Destination(s): / Database
Precondition(s): / a. User is logged in as volunteer coordinator
b. Volunteer information exists in the database
Post conditions(s): / Volunteer profile is updated in the database
Win-Win Agreement(s): / Agreement8
Table 9: Manage person Information
Capability Requirement: / CR-9: Manage person informationDescription: / The system shall provide a module to manage person information
Priority: / M (Must have)
Input(s): / Person information
Source(s): / User input and person information in the database
Output(s): / a. Person information
b. Updated person record
Destination(s): / System database
Precondition(s): / Module receives interface call
Post conditions(s): / a. Module returns the person record
b. The person record is updated
Win-Win Agreement(s): / Agreement9
2.2. Level of Service (L.O.S.) Requirements
Table 10: Availability
Level of Service Requirement: / LOS-1: AvailabilityDescription: / System should be available to user for use with the least amount of downtime as possible.
Priority: / M (Must have)
Desired Level: / 100% of system service uptime excluding network and server downtime.
Accepted Level: / 95% of system service uptime excluding network and server downtime.
Measurable: / The time that the system is available to user
Achievable: / Stable Internet/ Intranet structure, optimized algorism, thorough testing
Relevant: / All capability requirements
Specific: / All capability requirements
Win-Win Agreement(s): / Agreement15
Table 11: Query correctness