Design Document
Team Builder
Robert Drake, Brian Kopecky, & Chris Moore
Table of Contents
- Design Approach
- System Architecture
- User Interface
- Data Storage/Format
- External System Interfaces
- Detailed Design
- Implementation Platform
- Requirements Issues List
- Cross-Reference Table
- To Do List
- Revision History
Design Approach
Our software is designed to be a series of PHP scripts hosted by the ME Department that will allow Rose-Hulman faculty to form teams of people. These scripts will interface with an MS-SQL Server database. All administration and use of this program will be entirely web-page driven. Administrators will control who has access to particular features as well as ultimate control over survey and question database maintenance. Surveyors, primarily faculty, will be able to create surveys and create/edit teams based on these surveys. The team members will be able to fill out and edit surveys given to them.
- Advantages
- Fits the clients needs for a web-based implementation
- PHP can be object oriented, and the OO model fits our software well
- PHP easily interfaces with most database systems
- Disadvantages
- Not all of our programmers are familiar with PHP.
System Architecture
Software and External Interacting Entitles
User Interface
<Each component in this section must have a unique ID to support cross-referencing. For instance, you might want to use 1, 1.1, 1.2, and so forth for the IDs. In the detailed design, you will want to refer back to the appropriate IDs from this section .>
1 Entity-Relationship Diagram
<INSERT MODIFIED PANDA ERD>
2 Display Screen Formats, Menus, and Fault Handling
2.1 Main menu
Display
Contains access to all sub screens that a given user has access to.
Display Components
· Links for each accessible feature
Error Handling
· None
2.2 Create Survey 1
Display
Contains entry form for creator to enter preliminary information.
Display Components
· Survey name text box
· Description text box
· Surveyees text box
· Deadline text box
Error Handling
· If survey name is taken return same page with a message noting this and survey name highlighted in red
· If surveyees do not exist return same page with a message noting this and surveyees that don’t exist highlighted in red
· If deadline has already occurred return same page with a message noting this and date highlighted in red
2.3 Create Survey 2
Display
Contains entry forms for adding existing questions and link to take you to create new question page as well as a display of questions you have already added.
Display Components
· Drop-down box of existing public questions and private questions
· Button to add selected questions
· Button to remove selected questions
Error Handling
· None
2.4 Create/Edit Question
Display
Contains entry forms for creating/editing a question. The created question may be added to public or private question collections.
Display Components
· Text field for question name
· Text field for question prompt
· Radio Buttons for question type
· Text fields for available responses where appropriate
Error Handling
· If something incomplete or range is not possible pop up a message box saying so
2.5 Take Survey
Display
Contains list of links to all the surveys you currently have accessible. At the end of each link it states COMPLETE or INCOMPLETE to tell the person whether they have filled out the survey already.
Display Components
· Links to all the survey that person currently has access to
Error Handling
· None
2.6 Survey
Display
Contains questions as set up by survey creator
Display Components
· Depends on individual survey
Error Handling
· Depends on individual survey
2.7 View Results
Display
Contains list of links to all the results from individual surveys that have been completed. Also there is a link for viewing aggregate data like average GPA or the class percentage of a particular minority.
Display Components
· Links to all the survey results that person currently has access to
· Non-link list of people who did not submit surveys
· Link to page showing aggregate data
Error Handling
· None
2.8 Individual Results
Display
Contains question results as answered.
Display Components
· Depends on individual survey
Error Handling
· Depends on individual survey
2.9 Aggregate Results
Display
Contains raw data and numerical/graphical analysis as appropriate to each survey.
Display Components
· Depends on individual survey
Error Handling
· Depends on individual survey
2.10 Make Teams
Display
Contains a list of links to all surveys you have access to.
Display Components
· List of links to all surveys to which you have access.
Error Handling
· None
2.11 Team Editing
Display
Contains a table of current teams and their respective members that allow the professor to view currently formed teams and revise them via a combination of radio buttons.
Display Components
· A table of radio buttons and links of each team and its members
· A Move Members button
Error Handling
· None
3 Human Interfaces
3.1 Web Browser
All user interaction will be through a web browser. We will test for support in the latest versions of Internet Explorer and Mozilla Firebird.
Data Storage/Format
<If data structures, input and/or output data files (not program files), or databases are to be used with the software, then describe them here.
The information in this section should not be repeated in other sections, but you may cross-reference back to it, such as from the detailed design.
Entity relationship diagrams from the requirements document should be converted into the data structures, files, or databases that will contain the data. All sizes, formats, and estimated/actual data quantity should be given.>
4 Files
4.1 Team Making Algorithm Input
- Filename: “Current System Time”.in
- File Type: text
- Record Description: This is a text file that contains all the information that the Team Making Algorithm requires.
4.2 Team Making Algorithm Output
- Filename: “Input filename from above”.out
- File Type: text
- Record Description: This is a text file that contains all the information that the Team Making Algorithm creates.
5 Databases
External System Interfaces
6 MS-SQL
MS-SQL is used to store a database containing data for all of the surveys, responses, etc. in the system.
Detailed Design
7 ME Department Server
7.1 Web Interface
Use Case 01: Main Page – Team Maker
Overview
- The main page’s function is to allow the user to reach all main areas of the Team Maker site. The main page displays the sidebar with links to: Create Survey, Edit Survey, Take Survey, View Results, Make Teams, Edit Teams, and Log Out. There are also links with short descriptions in the center of the page which are: Create Survey, Take Survey, View Results, Make Teams, and Edit Teams. The links in the middle are the same as their sidebar counterparts.
Preconditions
- The user is accessing the Main Page on the Web
Scenario
|
User Action |
Software Reaction |
|
1. Create Survey is selected |
1. User is brought to Create Survey page (Use Case 2.2.1) |
|
2. Edit Survey is selected |
2. User is brought to Create Survey page (Use Case 2.2.1) |
|
3. Take Survey is Selected |
3. User is brought to Take Survey page (Use Case 2.3.1) |
|
4. View Results is selected |
4. User is brought View Results page (Use Case 2.2.6) |
|
5. Make Teams is selected |
5. User is brought to Make Teams page (Use Case 2.2.3) |
|
6. Edit Teams is selected |
6. User is brought to Edit Teams page (Use Case 2.2.5) |
|
7. Log Out is selected |
7. User is logged out of the system (Use Case x.x.x) |
Scenario Notes
- 1, 2, 4, 5, and 6 may only be selected if a faculty member is logged in.
- 3 and 7 may be selected by anyone
Post Conditions
- User is taken to the desired site
Required GUI
- GUI 1.1: Main Page
Use Cases Utilized
- Use Case 2.2.1: Create Survey
- Use Case 2.3.1: Take Survey
- Use Case 2.2.6: View Results
- Use Case 2.2.3: Make Teams
- Use Case 2.2.5: Edit Teams
- Use Case x.x.x: Log Out
Timing Constraints
- None
Use Case 02: Main Page – Create Survey
Overview
- The Create Survey page’s functionality is to allow a professor to create a survey for a select group of students. From here, the user can enter information and constraints about the survey as wells as add/edit questions to the survey.
Preconditions
- The user is accessing the Create Survey Page on the Web and is logged in as a faculty member
Scenario
|
User Action |
Software Reaction |
|
1. User enters survey information/constraints |
1. Information and constraints are set for the survey (Use Case 2.2.1.2 and 2.2.1.3) |
|
2. User adds a question to the current survey |
2. The question is added to the current survey (Use Case 2.2.1.4) |
|
3. User edits a question that is already added to the survey |
3. The questions is modified to reflect the changes the user makes (Use Case 2.1.4) |
|
4. User creates a new question |
4. The question is added to the database and to the current survey (Use Case 2.2.7) |
|
5. User removes a question from the current survey |
5. The question is removed from the current survey (Use Case x.x.x) |
|
6. User finalizes a survey |
6. The survey is saved to the database (Use Case x.x.x) |
Scenario Notes
- All options are available at all times
Post Conditions
- User is taken to the main page
Required GUI
- GUI 1.2: Create Survey Page
Use Cases Utilized
- Use Case 2.2.1.2: Enter Survey Information
- Use Case 2.2.1.3: Enter Survey Constraints
- Use Case 2.1.4: Edit Question
- Use Case 2.2.7: Create Question
- Use Case x.x.x: Remove Question from Survey
- Use Case x.x.x: Save Survey
Timing Constraints
- None
Use Case 03: Main Page – Take Survey
Overview
- The Take Survey page’s functionality is to allow a student to select a survey from a list of survey to which they have authorization to take. They then take a survey that a professor has previously created. From here, the user has the choice to answer each question in the manner in which the survey creator designated.
Preconditions
- The user is accessing the Take Survey Page on the Web and is logged in as a valid member
Scenario
|
User Action |
Software Reaction |
|
1. User selects a survey from the list of available surveys |
1. The user is taken to that survey (Use Case 2.3.1.1) |
|
2. User selects/types answers to whichever questions they want |
2. The answers are marked and readied for recording (Use Case 2.3.1.1 and 2.3.1.2) |
|
3. User submits answers |
3. The answers to the survey are recorded to the database (Use Case 2.3.1) |
Scenario Notes
- 2 and 3 may only be done if a valid survey is available in #1.
Post Conditions
- User is taken to the main page
Required GUI
- GUI 1.3: Take Survey Page
Use Cases Utilized
- Use Case 2.3.1.1: Take Survey
- Use Case 2.3.1.2: Take Survey
- Use Case 2.3.1: Take Survey
Timing Constraints
- None
Use Case 04: Main Page – View Results
Overview
- The View Results page’s functionality is to allow a professor to view the results from a survey which they themselves created. From here, the user can select what type of results they would like to view.
Preconditions
- The user is accessing the View Results Page on the Web and is logged in as a faculty member
Scenario
|
User Action |
Software Reaction |
|
1. User selects a survey from a list of those which they previously created |
1. The user is taken to a list of results they can view for the selected survey (Use Case 2.2.6.1 and 2.2.6.2) |
|
2. User selects Summary |
2. A summary of the aggregate results from the survey (Use Case 2.2.6.2) |
|
3. User selects an individual student |
3. The responses of the selected student are displayed (Use Case 2.2.6.1) |
Scenario Notes
- All options are available at all times
Post Conditions
- User is taken to the main page
Required GUI
- GUI 1.4: View Results Page
Use Cases Utilized
- Use Case 2.2.6.1: View Results
- Use Case 2.2.3.2: View Results
Timing Constraints
- None
Use Case 05: Main Page – Make Teams
Overview
- The Make Teams page’s functionality is to allow a professor to create teams for a selected survey. From here, the user can select from which survey they would like to create the teams.
Preconditions
- The user is accessing the Make Teams Page on the Web and is logged in as a faculty member
Scenario
|
User Action |
Software Reaction |
|
1. User selects a survey from a list of available surveys |
1. The user is taken to a page where they specify the weighting for each question (Use Case 2.2.3) |
|
2. User weighs each question individually |
2. The weighting for each question is remembered for use with the Team Creation Algorithm (Use Case 2.2.3.1) |
|
3. User requests teams creation |
3. The algorithm creates teams and the user is presented with the results (Use Case 2.2.3) |
Scenario Notes
- All options are available at all times
Post Conditions
- User is taken to a page from which they can view the created teams and save them.
Required GUI
- GUI 1.5: Make Teams Page
Use Cases Utilized
- Use Case 2.2.3: Create Teams
- Use Case 2.2.3.1: Specify Weights
Timing Constraints
- None
Use Case 06: Main Page – Edit Teams
Overview
- The Edit Teams page’s functionality is to allow a professor to edit the teams created by the algorithm. From the Edit Teams page, the user can select a set of teams to edit. From here, the user can move students between teams.
Preconditions
- The user is accessing the Edit Teams Page on the Web and is logged in as a faculty member
Scenario
|
User Action |
Software Reaction |
|
1. User selects a set of teams from a list of available teams |
1. The user is taken to a page from which they can move students between teams (Use Case 2.2.5) |
|
2. User selects a team member and marks them to be moved to the specified team |
2. The marked team members are moved to the respective teams (Use Case 2.2.5.1) |
Scenario Notes
- All options are available at all times
Post Conditions
- User is taken to the main page
Required GUI
- GUI 1.6: Edit Teams Page
Use Cases Utilized
- Use Case 2.2.5: Edit Teams
- Use Case 2.2.5.1: Edit Teams
Timing Constraints
- None
Use Case 06: Main Page – Log Out
Overview
- The user is logged out of the system.
Preconditions
- The user is accessing the system on the Web and is logged in.
Scenario
|
User Action |
Software Reaction |
|
1. User logs out |
1. The user is logged out (Use Case x.x.x) |
Scenario Notes
- This can be done at any time
Post Conditions
- User is taken to the main Rose-Hulman page
Required GUI
- GUI 1.1: Main Page
Use Cases Utilized
- Use Case x.x.x: Log Out
Timing Constraints
- None
Implementation Platform
8 Development Platform
- Hardware
- Personal computer
- Software
- Windows 2000 and XP
- Linux of different flavors
- Emacs, JCreator
9 Client Delivery Platform
- Hardware
- ME Department Server
- Software
- Windows XP
- Apache
- PHP
- MS-SQL Server
Requirements Issues List
|
Items |
|
None |
Cross-Reference Table
<This table should show exactly how each ID in the design
corresponds to some aspect of the Requirements Specification Document>
|
Requirements ID and Heading Name |
Design ID and Heading Name |
|
<id and heading name for a grouping of full-sentence requirements - one per row> |
|
To Do List
|
Items |
|
None |
Revision History
|
Date |
Name |
Revision |
|
|
Robert Drake, Brian Kopecky |
Initial Creation |
|
|
Chris Moore |
Re-write to correct entire document |