(click to enlarge)
Tuesday, March 17, 2009
UI Screencaps & Interface Requirements
-----------------UI SCREENCAPS-----------------
login screen:
homepage:
"groups" page:
group - members tab:
group - meetings tab:
search option:
settings page:
-----------------INTERFACE REQUIREMENTS-----------------
login screen:
homepage:
"groups" page:
group - members tab:
group - meetings tab:
search option:
settings page:
-----------------INTERFACE REQUIREMENTS-----------------
5. Interface Requirements
5.1 User Interfaces
User interfaces appears as GUI functioning as a web-based application. It is infused into NTU’s edveNTUre website as WebPages and frames. To access the system, user needs to click the
Functional interfaces triggered to display in main frame for each side menu buttons:
· Display pending group invites
· Display meetings scheduled pending for confirmation
· Display users who have joined the group.
· Display upcoming meetings (for the week)
· Display latest updates (e.g. Group XXX meeting has been postponed to XXX).
Groups
· Display Created group
· Display Joined group
· Members tab:
o Search Button to find member by: Display name, Email, Matric Number via NTU Outlook Address book pop up window.
o Button to add member from search results in pop up window.
o Button for creator of groups to remove members.
o Drop down list for creator to add member to other created groups.
o Buttons for creator of groups save changes to modifications of members.
o Button for creator of groups can delete group. Pop up window will show prompt creator to send message to the group to notify the deletion.
o Form for running search on existing groups.//not added
o Buttons to schedule meeting from existing groups (from both Join and created)
o Link to create new group.
· Meeting tab:
o Displays meetings scheduled by creator. Cancel button for creator to cancel meeting.
o Displays meetings pending for user to accept
o Displays details of meetings such as: Group, Time, Date, Duration, Confirmed Attendance, Host.
Plan!
· Plan Schedule
o Set Attendance. Check box to select participants for meeting.
o Radio buttons to set priority of attendance.
o Field text to set minimal attendance.
o Drop down list to select number of days for user to view from starting date.
· Set Constraints
o Drop down lists to set timeslot view.
o Button to display calendar to select start date.
o Each Timeslot shows the number of people attending
o Highlighted box indicates availability
o Mouse over shows a small window on members who are unable to attend. Red indicates high priority.
o Other confirmed meetings taken account into timetable?
· Select available time slots.
· Type message to recipients and send notification
Settings
· Privacy settings allows user to set account to private or public.
o Private: Request invitation to join group
o Public: Accepts all group invitation without asking user’s permissions
· Contact Details
o Option to notify through Default NTU Email Account
o Option to notify through personal Preferred Email Account
o Option to notify through SMS. (User have to provide contact number)
5.2 Hardware Interfaces
The system has no hardware requirements.
5.3 Software Interfaces
The system is a multi-user environment. Client can act as a admistrator (host) as well as a attendee. Client will have access to the database via Edventure (Oracle) and is able retrieve other user’s timetable and email data. Access to the database data is read only and no modifications can be made by the client.
The software shall be designed to run on at least one of the following OS platforms:
· Microsoft Windows (Windows implementations shall be portable to all versions of Windows up to and including Windows XP)
· UNIX (Unix implementation shall be portable to any version of Unix that supports the user interface libraries used)
· Apple Macintosh OS (Apple Mac implementations shall be portable to all current versions of the MacOS)
· Linux (Linux implementations shall run on at least one version of Linux)
Thursday, January 29, 2009
Use Case Descriptions
Use Case 1: Input Constraints for Scheduling
Actors: User
Stakeholders and Needs:
User—To input the constraints for scheduling.
Participant—To receive best scheduling results, with all the constraints being considered.
Preconditions:
The User is logged in and has a computer identifier.
Postconditions:
The constraints are accepted and saved into the system, only if all correctness and completeness checks on the inputs succeed and the User confirms the inputs. Constraints will not be saved if the User log out of the system or cancel the operation.
Trigger:
The User initiates the input constraints operation.
Basic Flow:
1. The User initiates the input constraints operation and enters the computer identifier.
2. The System displays the fields to be filled in.
3. The User enters all available constraints.
4. The System verifies the inputs and asks for confirmation that they should be accepted.
5. The User confirms the input constraints.
6. The System saves the constraints and informs the User that the operation is complete.
Extensions:
*a.The User cancels the operation: The use case ends.
1a.The computer identifier is invalid:
1a1. The System alerts the User of the problem.
1a2. The User corrects the problem and activity resumes.
4a.The System detects invalid or incomplete data:
4a1. The System alerts the User of the problem.
4a2. The User corrects the problem and activity resumes.
5a.The User does not confirm the input data: The use case ends.
6a.The System is unable to save the constraints.
6a1. The System informs the User about the problem.
6a2. The User cancels the operation and the use case ends.
Use Case 2: Input Required Data for Scheduling
Actors: User
Stakeholders and Needs:
User—To input required data such as participants’ matriculation numbers,
timetables etc, into the System for scheduling.
Participants—To receive best scheduling results.
Preconditions:
The User is logged in and has a computer identifier.
Postconditions:
The input data is accepted and saved into the system, only if all correctness and completeness checks on the inputs succeed and the User confirms the inputs. Data will not be saved if the User log out of the System or cancel the operation.
Trigger:
The User initiates the input data operation.
Basic Flow:
1. The User initiates the input data operation and enters the computer identifier.
2. The System displays the fields to be filled in and allows the uploading of files.
3. The User enters all available data and uploads required files.
4. The System verifies the inputs and asks for confirmation that they should be accepted.
5. The User confirms the input data and initiates the scheduling operation.
6. The System saves the data and start the scheduling process. It informs the User when the operation is completed.
*Note: The User may choose to initiate the input constraints use case either before or after entering the required data, or not to input any constraint at all.
Extensions:
*a. The User cancels the operation: The use case ends.
1a.The computer identifier is invalid:
1a1. The System alerts the User of the problem.
1a2. The User corrects the problem and activity resumes.
3a. The System is unable to accept uploaded files or uploaded files have
exceeded the maximum capacity.
3a1. The System alerts the User of the problem.
3a2. The User corrects the problem and activity resumes.
4a.The System detects invalid or incomplete data:
4a1. The System alerts the User of the problem.
4a2. The User corrects the problem and activity resumes.
5a.The User does not confirm the input data: The use case ends.
6a.The System is unable to save the input data.
6a1. The System informs the User about the problem.
6a2. The User cancels the operation and the use case ends.
6b. The Scheduling process is unsuccessful.
6b1. The System informs the User about the problem.
6b2. The User can choose either to retry or cancel the operation. Once the operation is cancelled, the use case ends.
Use Case 2: Input Required Data for Scheduling
Actors: Server, User
Stakeholders and Needs:
User—To request the Server to input relevant data.
Server—To input required data such as participants’ matriculation numbers, timetables etc, into the System for scheduling.
Participants—To receive best scheduling results.
Preconditions:
The User is logged in and has a computer identifier.
The Server is allowed to interact with the System and has an identifier.
Postconditions:
The input data is accepted and saved into the system, only if all correctness and completeness checks on the inputs succeed and the User confirms the data. Data will not be saved if the Server closes connection with the System or the User initiates the cancellation of the operation.
Trigger:
The User requests for Server to input data into the System.
Basic Flow:
1. The User requests for Server to input data into the System and enters the computer identifier.
2. The User enters the Server identifier.
3. The Server starts searching for information and inputs data into the System.
4. The System verifies the inputs and asks for the User’s confirmation that they should be accepted.
5. The User confirms the input data and initiates the scheduling operation.
6. The System saves the data and start the scheduling process. It informs the User when the operation is completed.
*Note: The User may choose to initiate the input constraints use case either before or after entering the required data, or not to input any constraint at all.
Extensions:
*a. The User cancels the operation: The use case ends.
1a.The computer identifier is invalid:
1a1. The System alerts the User of the problem.
1a2. The User corrects the problem and activity resumes.
2a. The Server identifier is invalid:
2a1. The System alerts the User of the problem.
2a2. The User corrects the problem and activity resumes
3a. The Server is unable to acquire all relevant information.
3a1. The System alerts the User of the problem.
3a2. The User corrects the problem and activity resumes or he may
choose to cancel the operation.
4a.The System detects invalid or incomplete data:
4a1. The System alerts the User of the problem.
4a2. The User corrects the problem and activity resumes or he may
choose to end the operation.
5a.The User does not confirm the input data: The use case ends.
6a.The System is unable to save the input data.
6a1. The System informs the User about the problem.
6a2. The User cancels the operation and the use case ends.
6b. The Scheduling process is unsuccessful.
6b1. The System informs the User about the problem.
6b2. The User can choose either to retry or cancel the operation. Once the operation is cancelled,
the use case ends.
Use Case 3: Request for Scheduling Results
Actors: User
Stakeholders and Needs:
User—To request for scheduling results.
Preconditions:
The User is logged in and has a computer identifier.
The scheduling process has completed successfully.
Postconditions:
The scheduling process gives the best possible result, considering all the constraints and input data.
Trigger:
The User initiates the request results operation.
Basic Flow:
1. The User initiates the request results operation after scheduling has been completed.
2. The System displays the best possible result.
3. The User can choose to send the results to the participants or log out
from the System.
Extensions:
*a.The User cancels the operation: The use case ends.
2a.No possible results can be generated:
2a1. The System alerts the User of the problem.
2a2. The User corrects the problem and tries to reschedule or he can choose to end the operation.
Use Case 4: Send Scheduling Results to Participants
Actors: User, Participants
Stakeholders and Needs:
User—Approve the sending of scheduling results.
Participants—Get notified of the scheduling results.
Preconditions:
The scheduling process has completed successfully and the user has approved to sending out the results.
Postconditions:
Participants receive the best possible result successfully.
Trigger:
The User initiates the send results operation.
Basic Flow:
1. The User approves the result that the System has generated and initiates the send results operation.
2. The Participants get notified via email or other channels.
Extensions:
*a.The User cancels the operation: The use case ends.
1a. The User does not approve to the sending of results: the use case ends.
2a. Unsuccessful sending of results to the Participants:
2a1. The System alerts the User of the problem.
2a2. The User can choose to resend the results or cancel the operation.
Actors: User
Stakeholders and Needs:
User—To input the constraints for scheduling.
Participant—To receive best scheduling results, with all the constraints being considered.
Preconditions:
The User is logged in and has a computer identifier.
Postconditions:
The constraints are accepted and saved into the system, only if all correctness and completeness checks on the inputs succeed and the User confirms the inputs. Constraints will not be saved if the User log out of the system or cancel the operation.
Trigger:
The User initiates the input constraints operation.
Basic Flow:
1. The User initiates the input constraints operation and enters the computer identifier.
2. The System displays the fields to be filled in.
3. The User enters all available constraints.
4. The System verifies the inputs and asks for confirmation that they should be accepted.
5. The User confirms the input constraints.
6. The System saves the constraints and informs the User that the operation is complete.
Extensions:
*a.The User cancels the operation: The use case ends.
1a.The computer identifier is invalid:
1a1. The System alerts the User of the problem.
1a2. The User corrects the problem and activity resumes.
4a.The System detects invalid or incomplete data:
4a1. The System alerts the User of the problem.
4a2. The User corrects the problem and activity resumes.
5a.The User does not confirm the input data: The use case ends.
6a.The System is unable to save the constraints.
6a1. The System informs the User about the problem.
6a2. The User cancels the operation and the use case ends.
Use Case 2: Input Required Data for Scheduling
Actors: User
Stakeholders and Needs:
User—To input required data such as participants’ matriculation numbers,
timetables etc, into the System for scheduling.
Participants—To receive best scheduling results.
Preconditions:
The User is logged in and has a computer identifier.
Postconditions:
The input data is accepted and saved into the system, only if all correctness and completeness checks on the inputs succeed and the User confirms the inputs. Data will not be saved if the User log out of the System or cancel the operation.
Trigger:
The User initiates the input data operation.
Basic Flow:
1. The User initiates the input data operation and enters the computer identifier.
2. The System displays the fields to be filled in and allows the uploading of files.
3. The User enters all available data and uploads required files.
4. The System verifies the inputs and asks for confirmation that they should be accepted.
5. The User confirms the input data and initiates the scheduling operation.
6. The System saves the data and start the scheduling process. It informs the User when the operation is completed.
*Note: The User may choose to initiate the input constraints use case either before or after entering the required data, or not to input any constraint at all.
Extensions:
*a. The User cancels the operation: The use case ends.
1a.The computer identifier is invalid:
1a1. The System alerts the User of the problem.
1a2. The User corrects the problem and activity resumes.
3a. The System is unable to accept uploaded files or uploaded files have
exceeded the maximum capacity.
3a1. The System alerts the User of the problem.
3a2. The User corrects the problem and activity resumes.
4a.The System detects invalid or incomplete data:
4a1. The System alerts the User of the problem.
4a2. The User corrects the problem and activity resumes.
5a.The User does not confirm the input data: The use case ends.
6a.The System is unable to save the input data.
6a1. The System informs the User about the problem.
6a2. The User cancels the operation and the use case ends.
6b. The Scheduling process is unsuccessful.
6b1. The System informs the User about the problem.
6b2. The User can choose either to retry or cancel the operation. Once the operation is cancelled, the use case ends.
Use Case 2: Input Required Data for Scheduling
Actors: Server, User
Stakeholders and Needs:
User—To request the Server to input relevant data.
Server—To input required data such as participants’ matriculation numbers, timetables etc, into the System for scheduling.
Participants—To receive best scheduling results.
Preconditions:
The User is logged in and has a computer identifier.
The Server is allowed to interact with the System and has an identifier.
Postconditions:
The input data is accepted and saved into the system, only if all correctness and completeness checks on the inputs succeed and the User confirms the data. Data will not be saved if the Server closes connection with the System or the User initiates the cancellation of the operation.
Trigger:
The User requests for Server to input data into the System.
Basic Flow:
1. The User requests for Server to input data into the System and enters the computer identifier.
2. The User enters the Server identifier.
3. The Server starts searching for information and inputs data into the System.
4. The System verifies the inputs and asks for the User’s confirmation that they should be accepted.
5. The User confirms the input data and initiates the scheduling operation.
6. The System saves the data and start the scheduling process. It informs the User when the operation is completed.
*Note: The User may choose to initiate the input constraints use case either before or after entering the required data, or not to input any constraint at all.
Extensions:
*a. The User cancels the operation: The use case ends.
1a.The computer identifier is invalid:
1a1. The System alerts the User of the problem.
1a2. The User corrects the problem and activity resumes.
2a. The Server identifier is invalid:
2a1. The System alerts the User of the problem.
2a2. The User corrects the problem and activity resumes
3a. The Server is unable to acquire all relevant information.
3a1. The System alerts the User of the problem.
3a2. The User corrects the problem and activity resumes or he may
choose to cancel the operation.
4a.The System detects invalid or incomplete data:
4a1. The System alerts the User of the problem.
4a2. The User corrects the problem and activity resumes or he may
choose to end the operation.
5a.The User does not confirm the input data: The use case ends.
6a.The System is unable to save the input data.
6a1. The System informs the User about the problem.
6a2. The User cancels the operation and the use case ends.
6b. The Scheduling process is unsuccessful.
6b1. The System informs the User about the problem.
6b2. The User can choose either to retry or cancel the operation. Once the operation is cancelled,
the use case ends.
Use Case 3: Request for Scheduling Results
Actors: User
Stakeholders and Needs:
User—To request for scheduling results.
Preconditions:
The User is logged in and has a computer identifier.
The scheduling process has completed successfully.
Postconditions:
The scheduling process gives the best possible result, considering all the constraints and input data.
Trigger:
The User initiates the request results operation.
Basic Flow:
1. The User initiates the request results operation after scheduling has been completed.
2. The System displays the best possible result.
3. The User can choose to send the results to the participants or log out
from the System.
Extensions:
*a.The User cancels the operation: The use case ends.
2a.No possible results can be generated:
2a1. The System alerts the User of the problem.
2a2. The User corrects the problem and tries to reschedule or he can choose to end the operation.
Use Case 4: Send Scheduling Results to Participants
Actors: User, Participants
Stakeholders and Needs:
User—Approve the sending of scheduling results.
Participants—Get notified of the scheduling results.
Preconditions:
The scheduling process has completed successfully and the user has approved to sending out the results.
Postconditions:
Participants receive the best possible result successfully.
Trigger:
The User initiates the send results operation.
Basic Flow:
1. The User approves the result that the System has generated and initiates the send results operation.
2. The Participants get notified via email or other channels.
Extensions:
*a.The User cancels the operation: The use case ends.
1a. The User does not approve to the sending of results: the use case ends.
2a. Unsuccessful sending of results to the Participants:
2a1. The System alerts the User of the problem.
2a2. The User can choose to resend the results or cancel the operation.
Wednesday, January 21, 2009
7PM - The People
Member's Roles
Lab Group: BCG2
Group Name: 7PM
Project Manager - Ng Yong Hwee
Ensure that what is being built will match what the customer expects and that this development occurs within the expected time frame.
Secretary - Cheong Ying Ying
Keep the latest versions of the project documents organised and readily available for the team's reference through the team's website.
Functional Analyst - Pamela Chua Hui Ting
Capture, consolidate, and communicate non-conflicting requirement from the users and develop requirements documents that are clear, precise, concise, and meaningful.
Software Architect - Xiao Yuhong
Convert the requirements into an architecture and design that will become the blueprint for the software.
Development Lead - Jeow Li Huan
Flesh out any of the details in the architecture that the Software Architect didn't spell out in detail and create program specifications from which the developer can work on.
Developer - Tien Zhang Yi Andrew
Write the code that the Development Leads provided specifications for.
Quality Assurer - Joo Hui Ning
Ensure the quality of the software through a set of testing cases and scripts to verify that the system meets the client needs.
Lab Group: BCG2
Group Name: 7PM
Project Manager - Ng Yong HweeEnsure that what is being built will match what the customer expects and that this development occurs within the expected time frame.
Secretary - Cheong Ying YingKeep the latest versions of the project documents organised and readily available for the team's reference through the team's website.
Functional Analyst - Pamela Chua Hui TingCapture, consolidate, and communicate non-conflicting requirement from the users and develop requirements documents that are clear, precise, concise, and meaningful.
Software Architect - Xiao YuhongConvert the requirements into an architecture and design that will become the blueprint for the software.
Development Lead - Jeow Li HuanFlesh out any of the details in the architecture that the Software Architect didn't spell out in detail and create program specifications from which the developer can work on.
Developer - Tien Zhang Yi AndrewWrite the code that the Development Leads provided specifications for.
Quality Assurer - Joo Hui NingEnsure the quality of the software through a set of testing cases and scripts to verify that the system meets the client needs.
7PM - The Project
Mission Statement
To provide students with a user friendly system to remove the complexity arising from scheduling meetings and allocating manpower.
Preliminary Specifications
This system helps a planner to schedule meetings and allocate manpower automatically. Administrator can define the degree of optimisation for attendance.
Provides various input modes for submission of personal schedules and various mediums to inform members of concern the assigned schedule.
User Specifications
Functional:
1. Planner to input timetables of participants into system.
2. Software to output best possible time slots.
3. Able to set constraints.
4. Able to inform participants of scheduled time slot.
Non-Functional:
1. Usability
To provide students with a user friendly system to remove the complexity arising from scheduling meetings and allocating manpower.
Preliminary Specifications
This system helps a planner to schedule meetings and allocate manpower automatically. Administrator can define the degree of optimisation for attendance.
Provides various input modes for submission of personal schedules and various mediums to inform members of concern the assigned schedule.
User Specifications
Functional:
1. Planner to input timetables of participants into system.
2. Software to output best possible time slots.
3. Able to set constraints.
4. Able to inform participants of scheduled time slot.
Non-Functional:
1. Usability
Subscribe to:
Posts (Atom)