Student Resources > CMPT 275 > assignment schedule > client meetings

This is the schedule of available Client meeting times for the 2015 Summer semester.

• Each team will be assigned a client meeting appointment soon after teams have been formed.
• It is your responsibility to assure that the instructor has received an email from your team containing an ordered list (in order highest preference to lowest preference) of five meeting times selected from the available times in the schedule below by Friday May 15 at 5:30PM
• Appointments will be assigned based on the information provided by each team.
• Appointments will be placed in the timetable below before 8:30AM May 17 2015
• Appointments will be changed only in cases of conflict with another class (scheduled lecture or lab), conflicts with an academic, medical, or employment commitment made prior to scheduling of appointments, or other exceptional reasons. It is your responsibility to request such changes as soon as possible after the schedule is posted.
• No changes to the schedule will be considered after May 23, 2015
• All meetings, except where otherwise indicated in the table below, will be held in TASC1 9408

NOTE: Slots marked ------- are not available
ALL MEETINGS IN TASC1 9408

Client Requirements Review Meeting

During the Client Requirements Review meeting you will meet with the "client" (the instructor in disguise). and a technical expert from your clients company (Your TA in disguise). Your team will have a chance to ask questions to help you to further clarify the requirements of your project.

Your most useful tool to help you prepare for your client requirements review meeting is the scenario. For each major task the system needs to complete create a scenario describing how the user would interact with your system to complete the task. Each scenario will describe, step by step, how one of more of your requirements will be completed by the user of your system. Remember that a scenario presents the process from the users point of view. It describes how the user uses the system not how your system implements the tasks. Your user perceives your user interface as "the system". This means that an important part of a scenario, particularly when presenting the scenario to a client, is how the user interacts with the user interface of your system. To properly develop a scenario and present it to your client you will need some basic mock ups of your planned user interface. Keep these mock-ups as simple as possible. This is not the time to worry about the details of your user interface or how to make that user interface pleasant to use. At this stage of development it is sufficient to have a simple picture so you can indicate what information is presented on the gui page, what information the user adds, and the results the user is shown. In fact it is usually easiest to present this information in a simple table. Consider details of layout and usability ONLY when non-functional requirements specify particular constraints.

The following are a few pointers to help you prepare for a successful meeting:

• Remember your audience; your client is not a computing science professional. Your client is an expert in the application area who has contracted to have you build an application to fulfill their needs.
• Prepare for the meeting by reviewing the project content specification, the notes from your client meeting and the list of requirements you developed for deliverable 3 (including the comments you received/will receive about your requirements when they are graded). Use these resources to create a series of scenarios that describe how a user would use the system to satisfy each requirement (or group of requirements). Make sure all requirements are satisfied by at least one scenario
• Make sure your team discusses each scenario before the requirements review meeting. This discussion will help you determine if you think your team's understanding of the requirements satisfied by that scenario is correct and complete.
• If you think your team's understanding of the scenario is complete, then present that scenario to the client to verify your team's understanding. It is possible that you have missed something or that the members of your team share a common misconception about the scenario. Presenting to the client gives the client a chance to realize that there is a misconception and correct it.
• It is also possible that there is a part of the scenario that is so obvious to the client that it was omitted from the written specs and not discussed or pointed out in the first client meeting. Listening to your brief, concise, scenario may allow the client to realize that the omission has been made and supply you with the missing information.
• If you realize there are gaps in your team's understanding of the scenario, or missing details about the scenario then you also need to design questions to ask at critical points in the scenario that will elicit the required information from the client.
• When you summarize your understanding using a scenario, to set the stage for a question, or to verify a scenario you think you understand, be clear and concise.
• The meeting will be held in a room with a data projector but with no other audio visual aids. Any visual aids (slides, diagrams, ...) you wish to use should be brought to the meeting on paper or on a laptop. If you bring a laptop make sure it can connect to an overhead data projector before the meeting. Do not overuse visual aids.
• Be flexible; remember that the answers to some questions may make other prepared questions irrelevant or inappropriate. Omit prepared questions that are no longer relevant and be ready to craft addition questions on the spot when it becomes necessary.

Some useful rules to follow during the Client Requirements Review Meeting

• All members of your team must be present at the meeting. If you miss your team's client meeting you will receive a grade of 0 for the client meeting
• All members of the team must participate by presenting scenarios and asking questions during the meeting. It is expected that each member of the team will present at least two significant scenarios during the meeting
• The duration of the meeting will be between 50 and 60 minutes. If your meeting is not completed in 60 minutes marks will be deducted. A well planned and executed meeting should not exceed 60 minutes
• Your team's mark is not dependent on the length of your meeting (unless you exceed 60 min). A better planned and organized meeting will result not only in a higher grade but also in a clearer understanding of the requirements of the project.

Description of submission for this deliverable

When you prepare for your client requirements review meeting you will create a series of scenarios. To present these scenarios in your meeting you will create simple UI mock-ups or tables of information to use as props in your presentation. Mock-ups may be drawn by hand or created with a drawing tool or mock-up generation tool. For most scenarios tables of input and output information may be used instead of mock-ups if you group finds this simpler. For each scenario to be presented you should include the following in your submitted PDF document

• A descriptive name for the scenario, and which requirements it satisfies
• Images of the UI mock-ups or the tables to be used when presenting the scenario
• A VERY BRIEF point form summary of the critical ideas to be presented and questions to be asked
• Which member of your team will be responsible for presenting the scenario

Your list of scenarios MUST be submitted BEFORE your client requirements review meeting.

Marking Scheme - out of 70

The instructor will evaluate the effectiveness and efficiency of each team's meeting according to the criteria listed below. The result of the evaluation will be a score between 0 and 52.5 points.

• All team members presented scenarios, asked questions and participated equally in the meeting
• Scenarios and questions summarized of the team's understanding of the system to be built and elicited further details about the requirements for that systen.
• Scenarios and questions were clear and concise
• Coverage of scenarios, questions, clarifications, and discussions was complete (covered all aspects of the project). It is important to understand that you will not receive credit for knowing about any aspect of the system you do not describe in a scenario or discover as the answer to a question.
• Questions and scenarios were divided in logical groups to provide continuity and flow in the meeting. Organization of scenarios and questions was logical
• The meeting was planned so each team member knew their responsibilities and the order in which they were asking their questions. There were no significant silences between sets of scenarios / questions. Members did not interrupt each other during the meeting.
• Team members were able to pursue and clarify newly discovered ideas/requirements with additional unplanned questions.
• The team made good use of time (e. g. meeting lasted between 50 and 60 minutes, no long pauses, no repeated questions)
• The team began negotiation to determine the contents of the prototype

The remaining 17.5 points will be given for the clarity and completeness of the set of use cases and associated UI mock-ups you prepared for use in your meeting and submitted to COURSESYS before your meeting. Points will not be deducted for misinterpretations or misunderstandings of requirements in your submitted materials because the purpose of the meeting is to find and correct such problems.