User Requirements
Requirement types: PROJECT DRIVERS - 1. The Purpose of the Product 2. Client, Customer, Stakeholders 3. Users of the Product PROJECT CONSTRAINTS - 4. Mandated Constraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions FUNCTIONAL REQUIREMENTS - 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements NON-FUNCTIONAL REQUIREMENTS - 10. Look and Feel 11. Usability 12. Performance 13. Operational 14. Maintainability and Support 15. Security 16. Cultural and Political 17. Legal PROJECT ISSUES - 18. Open Issues 19. Off-the-shelf Solutions 20. New Problems 21. Tasks 22. Cutover 23. Risks 24. Costs 25. User Documentation 26. Waiting Room 27. Ideas for Solutions
Requirement #: A1 Requirement Type: 9 Event / use case #: M1
Description: The system should be able to be interface with the existing university registration system
Rationale: With the system being a tool that allows those taking similar courses come together to a medium of discussion, contact lists based on courses that are taken as well as the instructors that are teaching the courses are required. This information is retrieved from the student course registration system.
Source: Undergrad, grad students
Fit Criterion: All students should be able to see their classmates and instructors’ names in their contact lists.
Dependencies: Only students that are currently registered in the courses will be displayed. Thus, this information is dependent on the registration system.
Conflicts: None
Supporting Materials: MSN Messenger categorization of contacts
History: EKMM & DMUR interviews, 6 Mar 2005
Requirement #: A2 Requirement Type: 9 Event / use case #: M1
Description: Contact information retrieved from the course registration system should be minimal
Rationale: Due to privacy concerns, no direct contact information or other personal information such as student or staff numbers should be made visible to others.
Source: Undergrad, grad students
Fit Criterion: Contact information should only be limited to the name of the student/ instructor
Dependencies: Dependent on the registration system
Conflicts: None
Supporting Materials: None
History: DMUR interview, 6 Mar 2005
Requirement #: A3 Requirement Type: 9 Event / use case #: I1
Description: The system should display the course information of those courses that the student/ instructor is part of
Rationale: Since the goal of the system is to bring those who are in the same courses together, basic course information such as the course name and brief description should be made available.
Source: Undergrad, grad students
Fit Criterion: Course information should be limited
Dependencies: Dependent on the registration system
Conflicts: None
Supporting Materials: None
History: EKMM, DMUR interviews, 6 Mar 2005
Requirement #: A4 Requirement Type: 9 Event / use case #: M1
Description: Course information and classmate listings should be up to date
Rationale: Since the information related to the list of students and professors is to be used in real time, this information should be synchronized with the registration system and be accurate
Source: Undergrad students
Fit Criterion: If a student deregisters from the course, his/her classmates should no longer be able to se his/her information on the system.
Dependencies: Dependent on the registration system
Conflicts: Students may lose contact with others
Supporting Materials: We can refer to existing systems here (replace this text)
History: DMUR interview, 6 Mar 2005
Requirement #: A5 Requirement Type: 9 Event / use case #: I1, I2
Description: Users should be able to share text through copying and pasting directly to the messenger system. This text and any single message should not be size limited
Rationale: Users of existing systems are subjected to text / message size limits, and when they copy and paste text, only parts of it is transmitted.
Source: Undergrad students
Fit Criterion: No limits should be imposed on the size of the message that is being transmitted
Dependencies: None
Conflicts: None
Supporting Materials: MSN Messenger
History: EKMM, DMUR interviews, 6 Mar 2005
Requirement #: A6 Requirement Type: 9 Event / use case #: I1
Description: Statistical data should be collected to be able to determine the usage of the system by students and instructors.
Rationale: To determine and gauge the usage of the system, statistical data (logs) should be kept for review by the University’s administration
Source: Undergrad students
Fit Criterion: Data should only be limited to the amount of time the system is used and grouped by the user types.
Dependencies: None
Conflicts: University terms of privacy
Supporting Materials: None
History: DMUR interview, 6 Mar 2005
Requirement #: A7 Requirement Type: 17 Event / use case #: I1
Description: Statistical data collection should be within the terms of the University’s privacy policy
Rationale: To ensure that the collection of data is within the accepted terms and agreements between the university and its population, all rules should be applicable to this system.
Source: Undergrad students
Fit Criterion: All rules within the terms of the University privacy policy should be applied
Dependencies: None
Conflicts: None
Supporting Materials: None
History: EKMM, DMUR interviews, 6 Mar 2005
Requirement #: A8 Requirement Type: 12 Event / use case #: M1
Description: The system’s design should be lightweight and be able to be executed without taking up a lot of resources on the computer users access it from.
Rationale: With this system being a tool that will be used in tandem with other applications related to student work, it should be able to be deployed on a computer whose resources are being shared by other programs.
Source: Undergrad, grad students
Fit Criterion: Users should be able to run this system without ramifications on a Pentium III – 500 MHz computer or equivalent.
Dependencies: None
Conflicts: None
Supporting Materials: None
History: EKMM, DMUR interviews, 6 Mar 2005
Requirement #: A9 Requirement Type: 14 Event / use case #: M1
Description: The system should be designed to run on all platforms that are supported by the University
Rationale: With the University’s acquisition of equipment for use by the students and staff, the system should be able to run on those machines and operating systems that are deemed acceptable and supported by the university’s Help Desk.
Source: Undergrad, grad students
Fit Criterion: All current systems supported by the University’s Help Desk should be supported.
Dependencies: None
Conflicts: None
Supporting Materials: None
History: EKMM, DMUR interviews, 6 Mar 2005
Requirement #: A10 Requirement Type: 10 Event / use case #: I1, I2
Description: The system’s interface should be minimal
Rationale: Systems that are cluttered with numerous elements tend to be intimidating to use.
Source: Undergrad students
Fit Criterion: System’s elements should be minimized through the use of grouping of users, non-flashing and daunting elements.
Dependencies: None
Conflicts: None
Supporting Materials: None
History: EKMM, DMUR interviews, 6 Mar 2005
Requirement #: A11 Requirement Type: 10 Event / use case #: M1, I1, I2
Description: The system should have links to course websites that the student or instructor is involved in
Rationale: Since the system is there to act as a supporting material for the interaction between peers and instructors, it should make course related material easily accessible
Source: Undergrad, grad Students
Fit Criterion: Course information, such as course name, section and description along with a link to the respective course website is required
Dependencies: Course registration system
Conflicts: None
Supporting Materials: None
History: EKMM, DMUR interviews, 6 Mar 2005
Requirement #: A12 Requirement Type: 10 Event / use case #: I2
Description: Users should be able to display their personal picture for others to see
Rationale: Since the University’s community is large, identifying a peer through only the course name and student’s name would be hard for some. The option of a student or instructor to display their picture (i.e. mug shot) on the system will allow for quick identification and recognition.
Source: Undergrad students
Fit Criterion: Picture display formats that should be supported are in either the JPEG or GIF
Dependencies: None
Conflicts: None
Supporting Materials: MSN Messenger
History: EKMM interview, 6 Mar 2005
Requirement #: P1 Requirement Type: 9 Event/use case#: SP1
Description: User should be alerted when they receive a new email message via their Uvic webmail account.
Rationale: This will provide a useful feature and will encourage users to utilize the messenger service whenever they are online.
Source: Development Team
Fit Criterion: User will be cued visually when the Uvic mail server receives a new message for that user.
Dependencies: Authentication information for users Uvic mail account.
Conflicts: None
Supporting Materials: MSN Messenger
History: Team Meeting March 7, 2005
Requirement #: P2 Requirement Type: 9 Event/use case#: SP2
Description: System should allow users to send messages to offline users via email.
Rationale: This will provide users with another method of contacting peers and professors even when they are not online.
Source: Development Team
Fit Criterion: Users can click on an offline contacts name, type a message and that message will be sent to the contact’s Uvic email address.
Dependencies: Users supply their email addresses.
Conflicts: None
Supporting Materials: None
History: Team Meeting March 7, 2005
Requirement #: P3 Requirement Type: 9 Event/use case#: SP3
Description: System should generate for users a daily schedule of their classes based on user’s Uvic registration information.
Rationale: Users may need to view their class schedules and this information is readily available to the system.
Source: Student submitted specification.
Fit Criterion: User can view calendar, which will show classes for the current day and their start and end times.
Dependencies: None
Conflicts: None
Supporting Materials: Student submitted specification.
History: Team Meeting March 7, 2005
Requirement #: P4 Requirement Type: 9 Event/use case#: SP4
Description: System should generate a contact list for the user based on the classes the user is in and the professor who is teaching that class.
Rationale: It would be very beneficial for users to be able to contact their classmates and professors for class related discussion.
Source: Development team discussion/Student submitted specification.
Fit Criterion: When user logs into system in addition to contacts manually added a list of the user’s classmate and the professor teaching the class will appear. The contact list will be updated whenever changes are made to the class list.
Dependencies: None
Conflicts: None
Supporting Materials: Student submitted specification.
History: Team Meeting March 7, 2005
Requirement #: P5 Requirement Type: 9 Event/use case#: SP5
Description: System should allow users to login anonymously, however the user will only be able to communicate with professors.
Rationale: Anonymous login would allow students to express their opinions to professors without fear of reprisal.
Source: Development team discussion/Student submitted specification.
Fit Criterion: When logging into the system users can choose anonymous instead of entering their netlink ID and password.
Dependencies: None
Conflicts: Requirement P8
Supporting Materials: Student submitted specification.
History: Team Meeting March 7, 2005
Requirement #: P6 Requirement Type: 9 Event/use case#: SP6
Description: System should allow users to search for contacts by email address, name and student number.
Rationale: Providing various methods for the user to add other students to their contact list will make the process much easier.
Source: Development team discussion/Student submitted specification.
Fit Criterion: Users can enter the name, email address or student id and will be presented with a list of search results and the ability to add any of those results to their contact list.
Dependencies: None
Conflicts: None
Supporting Materials: Student submitted specification.
History: Team Meeting March 7, 2005
Requirement #: P7 Requirement Type: 9 Event/use case#: SP7
Description: Professor should be able to exert control over system. Professor should be able to view student information and moderate discussions.
Rationale: Professor should be empowered to make sure users are not abusing the system.
Source: Student Interviews.
Fit Criterion: Professor can click on a student in contact list and view their personal information. Professor can also remove students from a discussion.
Dependencies: None
Conflicts: None
Supporting Materials: Student Interview Transcript.
History: Student Interview, March 6, 2005.
Requirement #: P8 Requirement Type: 9 Event/use case#: SP8
Description: System should allow users to send text messages to anyone who is on their contact list.
Rationale: Students need to communicate with their peers and professor; this is the primary function of the system.
Source: MSN Messenger
Fit Criterion: Users can click on another user in their contacts list, a window will open and they will be able to send text messages to that user and the user will be able to reply.
Dependencies: Contact list see requirement P4
Conflicts: None
Supporting Materials: Student Interview Transcript.
History: Team Meeting, March 7, 2005.
Requirement #: R1 Requirement Type: 9 Event / use case #: I2
Description: The system should allow users to create and/or participate in public or private multi-user discussion rooms.
Rationale: This will allow course/peer groups to create an environment for discussion of issues relevant to the context of the course/peer group.
Source: Grad and undergrad students
Fit Criterion: All users shall be able to create a discussion room and set the parameters for who can participate in the discussion.
Dependencies: P4
Conflicts: P7
Supporting Materials: None
History: TDB interview, 6 Mar 05
Requirement #: R2 Requirement Type: 9 Event / use case #: I1
Description: The system shall allow users to type simultaneously, each seeing the other’s words as they are being typed.
Rationale: This will allow for a freer flowing and naturalistic feel in the conversation as opposed to most messenger services which hide user’s words until they enter them.
Source: Grad students
Fit Criterion: Entries for each user that is typing shall appear on the screen at the same time.
Dependencies: None
Conflicts: None
Supporting Materials: None
History: RND interview, 5 Mar 05
Requirement #: R3 Requirement Type: 9 Event / use case #: I1
Description: The system will allow a user to save a message thread into a file.
Rationale: Allows users to revisit discussions at anytime in the future. This is of particular interest in the academic environment with respect to course material.
Source: Grad and undergrad students and professors
Fit Criterion: Can select part or all of a thread and save it to a file.
Dependencies: None
Conflicts: None
Supporting Materials: None
History: RND, TDB interviews, 5,6 Mar 05
Requirement #: R4 Requirement Type: 9 Event / use case #: M1
Description: The system should cue a user when another user is contacting them.
Rationale: Users need to be aware of when they are being addressed so they may respond as needed.
Source: Existing system
Fit Criterion: The system will generate an audio cue upon the receipt of a message.
Dependencies: None
Conflicts: None
Supporting Materials: MSN Messenger documentation
History: Team 4 meeting, 7 Mar 05
Requirement #: R5 Requirement Type: 9 Event / use case #: I1
Description: The system shall remind a user of their current status during idle times.
Rationale: After being away from the system a user needs to know whether they are online or not, visible or not to properly participate in any current discussions.
Source: Grad students
Fit Criterion: After some time being open and idle, the system will remind the user of their current status at the time.
Dependencies: None
Conflicts: None
Supporting Materials: None
History: RND interview, 5 Mar 05
Requirement #: R6 Requirement Type: 10 Event / use case #: I1
Description: The system shall allow a user to customize a variety of visual aspects of the interface.
Rationale: Users are more likely to use the system if allowed to personalize its look and feel.
Source: Grad and undergrad students
Fit Criterion: The user can customize text formatting (font, colour, size), window formatting (frame colour, background colour), etc.
Dependencies: None
Conflicts: None
Supporting Materials: None
History: RND interview, 5 Mar 05
Requirement #: R7 Requirement Type: 10 Event / use case #: I3
Description: The system shall allow a user to customize the information associated with individual users in his/her contact lists.
Rationale: Users are more likely to use the system if allowed to personalize its look and feel. Will also aid in the creation of discussion rooms based on this information.
Source: Undergrad students
Fit Criterion: The user can change or add a contacts name, address, major, etc.
Dependencies: P4 and R1
Conflicts: None
Supporting Materials: None
History: LMD interview, 5 Mar 05
Requirement #: R8 Requirement Type: 10 Event / use case #: I2
Description: The system shall allow the user to customize any status cues, visual or audio.
Rationale: Different users consider different cue types less intrusive.
Source: Grad students
Fit Criterion: User can select cue, cue type and cue options.
Dependencies: R4 and R5
Conflicts: None
Supporting Materials: None
History: TDB interview, 6 Mar 05
Requirement #: R9 Requirement Type: 13 Event / use case #: M1
Description: The system shall be available at all times.
Rationale: Both students and professors have flexible and diverse work schedules, and need to be able to use the system at their convenience.
Source: Requirements team
Fit Criterion: The system shall be available 24 hours a day, 7 days a week.
Dependencies: None
Conflicts: None
Supporting Materials: None
History: Team 4 meeting, 7 Mar 05
Requirement #: R10 Requirement Type: 15 Event / use case #: M1
Description: The system shall be available to all current UVic students and faculty and only current UVic students and faculty.
Rationale: The system is intended for university use only.
Source: System proposal
Fit Criterion: Users will gain access to the system based on a valid university user name and/or student/employee number.
Dependencies: None
Conflicts: None
Supporting Materials: None
History: Team 4 meeting, 7 Mar 05
Requirement #: R11 Requirement Type: 15 Event / use case #: I2
Description: The system shall not allow any non-authorized users to access a private discussion.
Rationale: Users conducting a private discussion should feel confident others are not watching them.
Source: Grad and undergrad students
Fit Criterion: If a user is not included in a private discussion’s access list, they may not enter that discussion.
Dependencies: R1
Conflicts: P7
Supporting Materials: None
History: TDB interview, 6 Mar 05
Requirement #: R12 Requirement Type: 13 Event / use case #: M1
Description: The system shall be easily extendible to other user types.
Rationale: May want to allow other user types on the system in the future.
Source: Requirements team
Fit Criterion: Shall be able to incorporate support staff into the system.
Dependencies: None
Conflicts: R10
Supporting Materials: None
History: Team 4 meeting, 7 Mar 05