1. introduction 1.1 aims and objectives - paul mc kevitt · the aim of this project is to initially...

COM556 – Intelligent Multimedia – Assignment 2 – Group 10

1. Introduction

1.1 Aims and Objectives

The aim of this project is to initially complete a literature review and a requirements analysis report which will then be used as the basis for the design and development of a system known as Spoken Language Intelligent Mastermind (SLIM) that will attempt to replicate a game of the well-known television show Mastermind.

A fully functional multimedia system has been created which allows four players to interact with the software via natural spoken dialogue commands as a means of enabling them to answer questions first based on a set specialist subject and then on general knowledge. SLIM serves to act only as an entertainment game with the specialist subjects are researched in a much shallower way than would be accustomed for a subject on the real show.

1.2 Mini-Project Summary

SLIM is designed in line with the current series of the television show which sees an initial four participants competing for the title of mastermind. Although the current series works on a timescale of 2 minutes per round we will just assume that each player gets asked the same amount of question and therefore it will not be timed.

SLIM has a user-friendly interface that will utilize the CLSU toolkit as a means of allowing the players to speak their answers or choices into a microphone which can then be interpreted by the system. In an attempt to make the system more user-friendly the questions are read out by an animated character in combination with being displayed on screen with text laid out in a clear and comprehensible manner

In an attempt to increase the interest and participation levels of classmates and friends who might avail of the system, specialist subjects have been structured on quite broad ranging knowledge from a variety of fun subject that might not be considered “suitable” for the specialist subject part of the television show, these include Arsenal Football Club, Harry Potter, Curb your enthusiasm and Irish Literature. It is anticipated that these topics will allow potential users to claim ownership of SLIM, thus having the knock on effect of increased usage time.

1.3 Mini-Project Overview

Section 2 – Background

The background section will be conducted to provide information relevant to the design and documentation of SLIM. This will include information on: Intelligent Multimedia, speech technologies, the television show Mastermind, and a summary of literature relevant to the application and in particular, relevant literature discussed throughout the entire module.

Section 3 - Requirements Analysis

The requirements analysis will be conducted to provide information about the user requirements of SLIM. These requirements will be defined using a combination of the numerous requirements gathering techniques. This provides a detailed analysis of the television show and looks at other attempted implementations of the game.


Section 4 - Design

The design will take the findings of the requirements documentation and use it as a basis for the creation of the new system, ensuring that the system is built to the specified user requirements. The design documentation will provide information on the SLIM software layout and screen designs via the use of storyboards which will be designed in line with the HCI guidelines discussed in the literature review.

Section 5 - Implementation & Testing

The Implementation and testing documents the delivered system and the testing procedures used to confirm the intended functionality. This includes screenshots of the completed RAD application. It will include a brief definition of what testing involves and the reasons why it is important to test an application.

Section 6 - Conclusion and critical analysis

The conclusion will give a brief summary of the software mini-project detailing each phase of the development lifecycle and an evaluation on the progress made in each of these phases. This section will also include a critical analysis of the software and a discussion in regards to any possible future enhancements that could be made to the SLIM system.


2. Background

2.1 Introduction

The background chapter provides a brief description of both the field of Intelligent Multimedia and speech technologies which are used as part of the software creation. The Mastermind game is discussed including the history of the show and the format. This chapter culminates with the discussion of relevant literature discussed throughout the module with explicit references given as to how these papers relate to the design of SLIM.

2.2 Intelligent Multimedia

According to Mc Kevitt (2000, p. 1) "The area of intelligent multimedia (intellimedia) involves the real-time computer processing and understanding of perceptual input from speech, textual and visual sources and contrasts with the traditional display of text, voice, sound and video/graphics with possibly touch and virtual reality linked in. This is the newest area of multimedia research which has seen an upsurge over the last two years and one where many universities internationally do not have, or have not integrated, such expertise."

2.2.1 Inputs

The processing of Inputs in an Intelligent Multimedia program is facilitated by the use of hardware. These inputs can be comprised of one or a combination of the following options:

• Keyboard

• Mouse

• Microphone

• Camera

• Video Camera

2.2.2 Outputs

As with the facilitation of the input process, hardware is again responsible for the outputs from an Intelligent Multimedia system. The output from the system is presented to the user again via one or a combination of the following options:

• Visual Display Unit (VDU)

• Speakers

• Printer

2.2.3 Multi-modal representation

A Multimedia Learning environment requires a number of elements in order to enable learning to occur. Hardware and software are only part of the requirement. Multimedia learning integrates five different types of media to provide flexibility in expressing the creativity of a student and in exchanging ideas. According to the Online Encyclopaedia (2009, p. 1) these include:


Text

Text has the most impact on the quality of the multimedia interaction as it generally provides the important information. Text acts as the keystone tying all of the other media elements together. It is well written text that makes a multimedia communication wonderful.

Sound

Sound is used to provide emphasis or highlight a transition from one page to another. When used creatively sound can become a stimulus to the imagination; however used inappropriately it can become an annoyance to the user.

Video

The representation of information by using the visualization capabilities of video can be immediate and powerful. Video can be used to give examples of phenomena or issues referred to in the text. One of the most compelling justifications for video may be its dramatic ability to elicit an emotional response from an individual. Such a reaction can provide a strong motivational incentive to choose and persist in a task.

Animation

Animation is used to show changes in state over time, or to present information slowly to students so they have time to assimilate it in smaller chunks. Animations, when combined with user input, enable students to view different versions of change over time depending on different variables.

Animations are primarily used to demonstrate an idea or illustrate a concept. Video is usually taken from life, whereas animations are based on drawings. There are two types of animation: Cel based and Object based. Cel based animation consists of multiple drawings, each one a little different from the others. When shown in rapid sequence, for example, the operation of an engine's crankshaft, the drawings appear to move. Object based animation (also called slide or path animation) simply moves an object across a screen. The object itself does not change.

Graphics

Graphics provide the most creative possibilities for a learning session. They can be photographs, drawings, graphs from a spreadsheet, pictures from CD-ROM, or something pulled from the Internet. With a scanner, hand-drawn work can be included. Standing commented that, "the capacity of recognition memory for pictures is almost limitless". The reason for this is that images make use of a massive range of cortical skills: colour, form, line, dimension, texture, visual rhythm, and especially imagination.

2.3 Speech Technologies

Speech technologies refer to the technologies designed to duplicate and respond to the human voice. Speech technologies enable humans to interact with computers in the most natural form of communication, spoken dialogue. Although speech technologies are becoming more prevalent in their use we have still yet to see them deployed on a mass scale, but it is almost inevitable that their introduction will prove the basis of most future systems. According to Pinker (1995, p.16) "Writing is clearly an optional accessory; the real engine of verbal communication is the spoken language we acquire as children." A spoken dialog system is a dialog system delivered through voice. It usually consists of the following components:


• Speech recognizer

• Text-to-Speech

• Response generator

• Dialog manager

• Knowledge base

• Natural language understanding

2.3.1 CLSU Toolkit

According to CSLU (2009), "the CSLU toolkit is a comprehensive suite of tools to enable exploration, learning, and research into speech and human-computer interaction". Development of the toolkit began in 1992 at the Centre for Spoken Language and Understanding (CLSU) and has since evolved to meet various needs. The toolkit is available free for research use via download and can be customized for corporate use.

The CLSU toolkit has the capability of converting text into computer-simulated speech, and therefore will be useful in the implementation of SLIM. Features found within the CSLU Toolkit will be described in more detail in the Software Analysis section in Chapter 3.

2.4 Mastermind

Mastermind is a British quiz show that is regarded as one of television's greatest tests of intellect and is characterized by its challenging questions, intimidating setting and air of seriousness which is often personified by the host of the show.

'Mastermind' is the brainchild of former television producer Bill Wright, a former RAF gunner, who drew on his wartime experience of being interrogated by the Gestapo as a Prisoner of War in Germany when he chose to answer only three questions - name, rank and number - to create the 'Mastermind' ritual of contestants being asked their name, occupation and specialist subject. Perhaps the most famous icon of the show is the black leather chair in which the contestants sit, lit by a solitary spotlight in an otherwise dark studio which was inspired by Wright's experiences.

The first ever edition of 'Mastermind' was recorded at Liverpool University and aired on BBC1 in 1972. The show was hosted by 43-year-old former journalist Magnus Magnusson, a formidable Scot of Icelandic parentage. The show has remained as part of the BBC's primetime schedule and has become one of television's most enduring successes.

2.4.1 Format

Four contestants take it in turns to answer questions over two rounds against the clock. The first two-minute round comprises questions on each contestant's chosen specialist subject and the second two-minute round tests general knowledge. If a contestant does not know the answer to a question they can either take a guess, and wait to be told the correct answer, or 'pass' and move straight on to the next question.If the clock runs out whilst the quiz master is reading a question, he will continue and give the contestant an


opportunity to answer - hence the show's catchphrase "I've started so I'll finish".The lowest scoring contestant on the first (specialist) round of questions, are always the first to be quizzed in the second (general knowledge) round. This maintains the drama throughout the show, as the highest scoring first round contestant must wait until the very end of the contest to be sure of his or her fate. The winner of each Mastermind contest is the player with the highest number of points at the end of the second round. If final scores are tied, then the winner is the contestant who 'passed' on the fewest questions.

2.4.2 2008/09 Television Series Statistics

According to the website Wiki (2010), the following statistics reveal that the average winning score tended to be in the range 25 to 30. The average specialist subject score in the first round was 12.5 approx. while the average general knowledge score was 9.5 approx. This lead to an average first round score of 22.1 approx. and a winning score being 26.1 approx.

Semi-final averages showed an overall rise in each of the aforementioned values and were recorded as: average specialist subject score was 13.04; average general knowledge score was 9.96; average score was 23.00; and the average winning score was 26.83.

The Final averages again showed an overall rise in each of the aforementioned values and were recorded as: average specialist subject score was 13.50; average general knowledge score was 10.17;the average score was 23.67; with the winner scoring a total of 30.

2.5 Relevant Literature

2.5.1 Computational models for integrating Linguistic and Visual Info (Srihari, 1995)

The paper surveys research in developing computational models for integrating linguistic and visual information. It details systems which have been implemented and continues with computationally motivated theories of human cognition. It categorizes existing research based on inputs and objectives. A key issue discussed throughout the paper is the correspondence problem, namely how to associate visual events with words and vice versa. This is a problem that is relevant to the design of SLIM given that the pictorial representation of the question must correspond with the audio prompt that is spoken by the animated host.

2.5.2 The behaviour expression animation toolkit (Cassell et al., 2001)

The paper details the software created by the team at MIT which allows animators to input typed text that they wish to be spoken by an animated character, and to obtain as output appropriate and synchronized nonverbal behaviours and synthesized speech in a form that can be sent to a number of different animation systems. The nonverbal behaviours are assigned on the basis of actual linguistic and contextual analysis of the typed text, relying on rules derived from extensive research into human conversational behaviour. This is relevant to the design of SLIM given the amount of TTS that will be used in the system, and any further developments would be worthy of considering BEAT as the TTS engine as it is more extensive and extensible that Festival.


2.5.3ANVIL: a generic annotation tool for multimodal dialogue (Kipp, 2001)

The paper presents software created by Michael Kipp known as Anvil which is a tool for the annotation of audio-visual material containing multimodal dialogue. Annotation takes place on freely definable, multiple layers (tracks) by inserting time-anchored elements that hold a number of typed attribute value pairs. Anvil is a highly generic, platform independent, XML based and fitted with an intuitive GUI. It offers the import of speech transcription and export of text and table data for further statistical processing. Although beyond the scope of the timeframe given for completion of this mini-project I believe that this software would be extremely useful for the creation of a game using video of the questions being asked by the host rather than an animated TTS engine derivative.

2.5.4 Research in Multimedia and multimodal parsing and generation (Maybury, 1995)

This paper introduces techniques for parsing and generating multiple media using multiple sensory modalities. There is no automatic generation of the images used by the SLIM due to the relatively short timescale of the project but this would certainly be relevant given the design of a larger system whereby ad-hoc generation would be too work intensive to be considered good programming practice.


3. Requirements Analysis

3.1 Introduction

The requirements analysis chapter provides a means of identifying the requirements that SLIM should meet in order for the system to be considered a success. SLIM's services, constraints and goals are established by two means. First, through consultation with the end users of the software in the form of a questionnaire and secondly, through the analysis of any similar systems currently available in the public domain that are used as a source of entertainment.

The requirements analysis chapter aims to identify user requirements, system requirements, and both functional and non-functional requirements of SLIM. Once these requirements have been refined in detail they serve as a system specification for the design phase of the software development lifecycle.

3.2 User Requirements

According to Sommerville (2007, p. 127) user requirements for a system "should describe the functional and non-functional requirements so that they are understandable by system users without detailed technical knowledge. They should only specify the external behaviour of the system and should avoid, as far as possible, system design characteristics."

The end users of SLIM could potentially come from a wide demographic of the age spectrum given the contestants who have applied for the show in the past. It is therefore important that SLIM is designed in a clear and coherent manner as older users might have difficulties in hearing some of the spoken prompts from the animated host. For this reason is a combination of text and speech to display the question for each of the players.

3.2.1 End User Questionnaire

The questionnaire was completed by a combination of 6 University students from the University of Ulster and 2 family members of each developer.The aim was to help determine some of the possible specialist subjects that users would be wishing to answer questions on. These specialist subject requests could then be compared to some of the subjects that have been deemed adequate for the BBC as having enough depth, as there have been previous subjects turned down by producers for being inadequate.

3.2.1 End User Questionnaires

The initial questionnaire was completed by the 10 test users of the system. The aim was to help determine some of the possible specialist subjects that users would be wishing to answer questions on. These specialist subject requests could then be compared to some of the subjects that have been deemed adequate for the BBC as having enough depth, as there have been previous subjects turned down by producers for being inadequate.

A further questionnaire was also completed by the end users of the system. It was used to ascertain the views of the players concerning the spoken interface system. It helped to identify errors and hence furthered process improvement.


3.2.2 End User Questionnaire Result

From the outcome of the initial questionnaire results the four specialist subjects were chosen by the respondents and deemed adequate enough depth for the purpose of the mini-project software:

• Arsenal Football Club

• Harry Potter

• Curb Your Enthusiasm

• Irish Literature

3.3 Analysis of Similar Systems

There are currently no software applications on the market that can truly encapsulate the tension of answering questions in the infamous black chair. This is perhaps due to the fact the natural language navigated interfaces are only now starting to become widely used in the gaming industry. The BBC website has a mastermind game but it in no way replicates the game as it is a multiple choice system, more in line with, the “who wants to be a millionaire” format.

3.4 System Requirements

According to Sommerville (2007, p. 118) system requirements for a system "set out the system's functions, services, and operational constraints in detail. The system requirements document (sometimes called a functional specification) should be precise. It should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers." This section of the report outlines the minimum hardware and software requirements for the design and development of SLIM.

3.4.1 Hardware Requirements

The minimum hardware requirements for the design and development of SLIM are:

• PC

• 1GHz Processor

• 512MB of Ram

• 100MB of Free Memory

• Sound card

• Microphone / Headset

• Video Card with Open GL


3.4.2 Software Requirements

The minimum software requirements for the design and development of SLIM are:

• Microsoft Windows Operating System

• Microsoft Office Professional 2007

• Microsoft Paint

• IBM Rational Rose

• CLSU Toolkit

• Festival

• Audacity

• Sound Recorder

• BBC iPlayer

3.5 Functional Requirements

According to Sommerville (2007, p. 119) functional requirements for a system are "statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do." The functional requirements of SLIM include:

• Each player will be required to login with their name and specialist subject

• Verbal confirmation will be given through the animated host when a correct answer is given

• Incorrect answers will result in the animated host stating the answer was incorrect and speaking the answer that was required

• A counter will be displayed to show the player's running total of correct answers

• A counter of the number of "passes" will be kept for tie-break purposes

• At the end of each player's turn the animated host will recite the questions that were passed on and give their correct answers

• At the end of the first round the scores of the players will be displayed in reverse order

• This order will be maintained for the general knowledge round with the lowest scorer in the previous round required to go first

• The player with the highest combined score at the end of the game will be displayed as the winner with their list added to previous winners list


3.6 Non-Functional Requirements

According to Sommerville (2007, p. 119) non-functional requirements for a system are "constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process and standards. Non-functional requirements often apply to the system as a whole. They don't usually just apply to individual system features or services."

The non-functional requirements of SLIM include:

• Usability: SLIM's interface should be designed in a simple and consistent manner so that the players will have no problems in understanding the questions

• Performance: SLIM should carry out its required function for each of the four players.

• Reliability: SLIM should be able to perform its functions under stated conditions for a specified period of time.

• Robustness: SLIM should be capable of dealing with unpredictable variations in its operating environment with minimal damage, alteration or loss of functionality.

• Maintainability: SLIM should be easy to maintain and any further updates should be done through the downloading of updates from the website where the finished product will be located.

• Portability: SLIM should be able to operate on all PC/ MAC based environments and possibly on handheld devices in future developments.

• Security: SLIM should keep secure all information relating to the personal details of the end user.

• Operability: SLIM should remain in a safe and reliable functioning condition, according to pre-defined operational requirements.

• Extensibility: SLIM should take into consideration further developments that could be added to the system.

• Documentation:SLIM should contain documentation providing the user with information on the program’s use.

3.7 Software Analysis

This section, of the mini-project software report, details an analysis to determine the software that is required in the design of SLIM.

3.7.1 CSLU Toolkit

According to their website (CSLU 2009) "the CSLU toolkit is a comprehensive suite of tools to enable exploration, learning, and research into speech and human-computer interaction". Development of the toolkit began in 1992 at the Centre for Spoken Language and Understanding (CLSU) and has since evolved to meet various needs. The toolkit is available free for research use via download and can be customized for corporate use.


Goals of the CLSU Toolkit

According to their website (CLSU 2009) the goals of the CLSU toolkit include:

• Easy to use

• Powerful for research and development use

• Systems that work in the real world

• Incorporates research advances

Overview of the CLSU Toolkit

Figure 3.1 – Overview of the CLSU toolkit (CLSU. 2009)

Tools found in the CLSU Toolkit

According to their website (CLSU 2009) the following tools are found in the toolkit:

• Audio and Visual tools

• Speech Recognition

• Text-to-Speech

• Rapid Application Developer

• Language-Training Wizards

• Speech View

• PSL Tools

• Tutorials

• Robust Parsing


Core Technologies in the CLSU Toolkit

Figure 3.2 – Core technologies of the CLSU toolkit (CLSU. 2009)

3.7.2 Tool Command Language (Tcl)

According to the Tcl Developer Xchange, (Tcl Developer Xchange, 2009), "Tcl (Tool Command Language) is a very powerful but easy to learn dynamic programming language, suitable for a very wide range of uses, including web and desktop applications, networking, administration, testing and many more. Open source and business-friendly, Tcl is a mature yet evolving language that is truly cross platform, easily deployed and highly extensible."

According to the tcl Developer Xchange, (Tcl Developer Xchange, 2009), "Tk is a graphical user interface toolkit that takes developing desktop applications to a higher level than conventional approaches. Tk is the standard GUI not only for Tcl, but for many other dynamic languages, and can produce rich, native applications that run unchanged across Windows, Mac OS X, Linux and more."

Tool Command Language Benefits

According to the tcl Developer Xchange (Tcl Developer Xchange, 2009) the benefits of Tcl are as numerous as the users of Tcl but the benefits and features which were highlighted time and time again as proving beneficial in the design of a system include:

• Rapid Development: Applications can be implemented between 5-10 times faster using Tcl in comparisons to other programming languages, especially if it involves GUI's, string handling or integration. Once developed in Tcl applications can be evolved rapidly.

• Graphical User Interfaces: With its Tk toolkit, Tcl provides facilities for creating GUIs that are incredibly simple yet remarkably powerful.

• Cross-platform applications: Tcl/Tk runs on Windows, Macintosh, and nearly every imaginable Unix platform. It provides high-level API's that let you write code that works the same on each of the platforms.

• Easy to learn: Tcl is a very simple language. Experienced programmers can learn Tcl and produce their first interesting application in just a few hours or days.


• Mature but evolving: Tcl and Tk have been under continuous, active development and use by a large group of developers since the early 1990's. And because Tcl is constantly evolving, new cutting edge features are being added all the time.

• Extend, Embed, Integrate: Tcl can be included as an embedded scripting language in an application, or make existing C, C++, or Java code look like it was built right into Tcl. These features make it easy to use Tcl as a control language for special-purpose hardware or protocols, add a new GUI or network interface to legacy applications, and more.

• Deployment: Most dynamic languages provide tools to "compile" everything into a single executable (Tcl has had that too, since about 1993). Tcl/Tk goes way beyond this, using other technologies to make deployment more flexible, powerful and transparent.

• Testing: Tcl is an ideal language to use for automated hardware and software testing, and it may well be the dominant language used for this purpose.

3.7.3 Rapid Application Developer (RAD)

RAD is a powerful development tool found within the CLSU which permits rapid development of applications through the visual IDE where users can drag and drop the different objects from the toolbox onto the development area known as the canvas. RAD is written in Tcl/Tk and acts as a visual interface to low-level processing modules which include audio, telephony and speech recognition. Figure 3.17 shows a RAD canvas where objects are dropped and linked to create the speech recognition process.

Figure 3.3 - Typical RAD canvas (CLSU. 2009)


4. Design 4.1 Introduction The design chapter will define the architecture of SLIM which will be produced from the specification from the requirements analysis chapter. It will also be used to identify sub systems and components if any of SLIM.The design chapter will also be used to identify tasks which can be undertaken by the user and performed by the system, and these will be displayed using UML 2.0 diagrams to represent the system in visual terms so that non-technical users will be able to understand the workings of SLIM. The design chapter will detail the interface design of SLIM through the aid of storyboards and these will then be evaluated to ensure that they comply with the HCI guidelines identified in the requirements analysis. The creation of an SLIM logo will also be detailed as a means of creating an instantly recognisable symbol that users will then associate with the software. 4.2 System Architecture According to Sommerville (2007, p. 242) "Architectural design is the first stage in the design process and represents a critical link between the design and requirements engineering processes. The architectural design process is concerned with establishing a basic structural framework that identifies the major components of a system and the communications between these components." Essentially SLIM is realized through threestructural components of the CLSU toolkit as shown below in Figure 4.1:

Figure 4.1 - Overall Architecture of SLIM

SLIM essentially has two components: Memory component This is the listbuilder which will be used to store the questions, answers and graphics that are used during the creation of the SLIM on screen display. Interface component The interface component is the visual representation of SLIM which the end-user will interact with, behind which the functionality is stored. The interface component will be created using the tool command language within the RAD developer found within the CLSU toolkit.


4.3 HCI Guidelines When designing a user interface it is extremely important that design rules and principles are followed. Interface Design is a big part of HCI (Human Computer Interaction). It has been proven that interfaces that follow certain design rules and principles allow the human to interact much better than random and unstructured designs. There are other reasons why it is important to follow interface design. System users usually judge a system by its interface rather than its functionality. A poorly designed system can result in a user making a serious error. Poor user interface design is one of the main reasons that many software systems are never used. It has been scientifically proven that humans react and work better under certain colours and designs than others. Nowadays companies spend huge amounts of money on HCI as it is a vital part of any software that users will interact with. There are lots of different collections of principles and rules which are used in design situations. 4.3.1 Benyon and Turner’s 12 principles (Benyon et al, 2005, p.272)

• Visibility • Consistency • Familiarity • Affordance • Navigation • Control • Feedback • Recovery • Constraints • Flexibility • Style • Conviviality

4.3.2 Shneiderman’s 8 golden rules (Washington, 2010) • Strive for consistency • Enable frequent users to use shortcuts • Offer informative feedback • Design dialog to yield closure • Offer simple error handling • Permit easy reversal of actions • Support internal locus of control • Reduce short term memory load

4.3.3 Nielsen’s 10 heuristics (Nielsen And Molich, 1990, p.256)

• Visibility of system status • Match between system and the real world • User control and freedom • Consistency and standards • Error prevention • Recognition rather than recall • Flexibility and efficiency of use


• Aesthetic and minimalist design • Help users recognize, diagnose, and recover from errors • Help and documentation

4.3.4 Normans 7 principles (Norman, 1988)

• Use both knowledge in the world and knowledge in the head • Simplify the structure of tasks • Make things visible: bridge the gulfs of execution and evaluation • Get the mappings right • Exploit the power of constraints, both natural and artificial • Design for error • When all else fails, standardize

It is important that we take all these design principles and rules into account during the creation and development of SLIM. It should ideally contain a mixture of these rules and principles to ensure a system is built which is functional and easy to use. 4.4 Interface Design The interface facilitates the interaction between the user and the system and therefore must be designed to suit the needs of its intended user group, in this case players of the game Mastermind which will incorporate a wide ranging age demographic. In this section of the design, the SLIM interface will be considered. The user requirements are considered throughout the design process to ensure that proposed design meets the functional and non-functional requirements outlined in chapter 3. The only design pre-requisite is that the user must deliver the answers through natural language through a microphone, with no help facilities displayed on screen only the question. 4.4.1 Logo Design A logo is a graphical element that together with its logotype, form a trademark or commercial brand. The main purpose is the immediate recognition factor that is gained through the design of a good logo. Given that the system is designed upon a pre-existing television show it is sensible to seek images from this media as this is where the recognition probability will be at its highest.The images that have been decided upon are a combination of the black chair in which the contestants are quizzed and one of the many fabulous crystal trophies that are offered to the winner. This is headed with an acronym for the system and Mastermind for the instant recognition which is a key factor in making a successful software product. This can be seen below in Figure 4.

Figure 4.2 – SLIM Logo


4.4.2 Splash Screen Design The black chair in which the contestants are quizzed has become synonymous with the show and it seems highly appropriate that it should form the basis of the initial screenshot. This will be incorporated with the Spoken Language Interface Mastermind displayed as a title. It was created using images from the Mastermind website (BBC, 2010). The design of this can be seen below in Figure 5.

Figure 4.3 – Start-up screen

4.4.3 Menu Screen The screen shown in Figure 6 was created in Paint again with the Mastermind text logo as the header. This will be used as an image map used to navigate the system, it contains clickable areas each of which lead the software in an alternative direction.

Figure 4.4 – Menu screen


4.4.4 Question Screen The question will be dictated by the animated system host but there will also be a need to display a visual representation of the question in the form of a text display. As a means of creating consistency in the system layout a template was designed for the purpose. The Mastermind text logo taken from the website, (BBC, 2010), was used as the header, with the specialist subject being displayed as a footer in the first round, while “general knowledge” is used as the footer for each of the four contestants in round 2. The question was then shown in a prominently coloured green text on black background an example of which can be seen in Figure 7.

Figure4.5 – Question screen

4.4.5 Winner’s Screen The winner of the game will need to be shown some sort of prize for their efforts in the game and for this we have chosen an image of the Mastermind “blue trophy”. As a means of keeping the fluidity of the system as possible all screens will be the same size with a template at the back to cover changing images so that it appears that the screen is just updating, as seen in Figure 8.

Figure4.6 – Winner notification screen


4.4.6 Score Screen As a means of simplifying the design of the system the score for each player will be displayed on its own individual media object. It will be designed in line with the score notification on the television show with the score being shown in white text on a black background, inside of a rounded rectangle as can be seen in Figure 9.

Figure 4.7 – Scoreboard notification screen

4.5Listbuilder Design Due to the unfamiliarity of the software it has been decided to remove the time restriction of the game, instead opting for a 15 question format per round. This will alleviate any fears of unfairness as recognition levels can be tend to vary given inclination and tone of the speaker. Each round will contain the following fields: Question: A text string of the question that will be used by the animated host to dictate it to the user, together with forming the basis of the question screen although this is done manually in this release of the software, there is a possibility to extend this to an automatic generation system. Answer: A text string used by the animated host of the answer to the question. Correct: A text string used by the animated host which confirms when a correct answer is given. Incorrect: A test string used by the animated host to inform the user that it was an incorrect answer that was given, and sticking with the format of the show the correct answer is also given. Image: A link to a filename with a visual representation of the question as earlier detailed. Pron: A phonetic pronunciation of the answer text string that will be used by the system to compare against the answer given by the user Passes: A text string that is used by the animated host at the end of each round, to inform the user of the answer to the questions in which they chose to pass. This is usually given as a combination of both the question and answer and is used at the end of round in the summary section as the number of passes is important should two or more players share a winning score.


4.6 HCI guidelines analysis An analysis is performed on the initial design to ensure that the design complies with each of the HCI guidelines outlined in section 4.3. SLIM is designed to meet the majority of these guidelines and the initial interface prototype has complied thus far. 4.6.1 Consistency SLIMhas interface screens that are the same size and found in the same position throughout the program. The screens are designed following the template shown in Figures 4.2, 4.3, 4.5 and 4.6. 4.6.2 Feedback A guideline contained within both Schniederman’s eight golden rules and Benyon and Turner’s twelve principles, feedback is given to the user at all stages of their interactions regardless of whether their answers are correct or not. This feedback is made clear to the user through visual and audio representations of the feedback semantics. 4.6.3 Flexibility and Control Due to the finite state structure of RAD applications, one area of SLIM must be completed before another is initiated therefore allowing developer to have full control of the system at all times which is then given to the first contestant on loading of the game.


5. Implementation & Testing

5.1 Introduction

During the implementation stage the design is realised as program with the user requirements identified in section 3 being used as the specification. The design of the lists used for the questions in each of the round will be discussed. The format for each of these will be standard in that they will contain the same fields and structure with only the entries changed.

This chapter will also look at the implementation of the SLIM system. It will look at the each canvas used in the implementation and the code used to organize the scoring system and the order of the players in round two based on their specialist subject score.

5.2 Memory Component Implementation

SLIM is implemented using the RAD list builder object as the memory component. There are two lists used in the implementation. The first is used to hold the question details and the associated responses and checks, the second is a simple list of a links to files which is to iterate through the scoreboard cards in response to a correct answer being given by the user. Figure 10 shows the structure of these lists. A full list of the memory component lists can be found in Appendix A with the entries completed.

Figure5.1– Memory component lists structure

5.3 Interface Component Implementation

Figure 11 shown shows the overall canvas architecture of SLIM, with a simple waterfall flow from the “start object” to the “goodbye. Between these objects there are 4 further sub-dialogues which include: the initial welcome and menu section, the first round, the second round, the final score/ summary section.


Figure5.2– Main RAD canvas of SLIM

Figure 12 shows the menu sub-dialogue canvas of SLIM. The first thing done in this section is a further sub-dialogue “variable initialisation” which simply sets an integer value to track the number of passes and the number of correct for each of the four players. The next icon in the flow is a media object which adds the welcome screen. This is followed by a recorded welcome message from the television show that is aligned with the animated host using the Text-To-Speech (TTS) facility offered by the toolkit. This is followed by a “remove media object” that takes away the welcome message before the flow adds a menu screen. From here the user has three choices: begin, listen to instruction, or listen to format.

Figure 5.3– Menu canvas of SLIM


Figure 13 shows the first round sub-dialogue canvas, which in itself is composed of a further 4

sub-dialogues. Again there is a simple waterfall flow, this is because the first round specialist

subjects need to be thoroughly researched and the television show producers would be aware of

the order of the contestants questioning although this could be randomized should it be deemed

necessary in any further developments.

Figure 5.4– Round one canvas of SLIM

For each of the questions in the first round a similar format was used albeit for a few minor changes and

the differing of the individual question lists. Figure 14 shown on the next page shows an example of the

first round question canvas, in this case, the arsenal sub-dialogue. The flow begins with the initialization

of a string variable that is used to detail the passes in the summary section at the end of the round. This is

followed by a recorded TTS message again taken from a BBC recording of the show spoken by the host

John Humphreys, if this is the first contestant it says “please welcome our first contestant”, while the

others are greeted with the message “and our next player please”. This is followed by the addition of a

player start screen, this will compensate for the time taken for the player to take the microphone from the

previous player and acquire a comfortable position. The program then iterates through three generic

objects again containing TTS where the contestant is asked their name, occupation and specialist subject

in the traditional manner of the show. The start screen is an image map whereby the screen is required to

be clicked before the program proceeds. This demo is set up to iterate through each of the specialist

subjects in a pre-determined manner, although it would be relatively simple to operate a conditional

object to branch to a specialist subject sub-dialogue so that the contestants could choose from a bigger last

of subjects this has not been implemented.

Following these generic objects, the start screen is removed before being replaced by a template in the

same location and of the same dimension. From here the question list is entered until coming to the end.


On loop through the question list a picture is displayed with the question displayed on a user-friendly

background with associated logos. The generic list object “questions” is used to present the question list

information to the contestants, the questions field is used as the prompt. The generic question list has

three branches: the first set to the worldbet data contained in the pron field used; the second set to the

word “pass”; the third being set to “*any / *sil / *gardbage” which accounts for any other spoken data.

If the users spoken answer matched the worldbet string contained in the memory component then the

program flows to the “thatsCorrect” generic object which uses the correct field as a spoken prompt to

give the user feedback on their answer before proceeding to the next question. This flow leads to the

incrementing of the variable used to track the number of correct answers for the player before a list of the

scoreboard is visited to update the scoreboard on screen. The question screen is then removed before the

next question is displayed in a fraction of a second.

If the user says “pass”, then the passes statement used in the summary section is appended to include the

passes field, this is then followed by the incrementing of the counter used to track the number of passes as

this could become crucial in the event of a tie break situation. Again the question is removed before the

next question is displayed.

If the user speaks a phrase that does not compare with either the worldbet string or the word pass then the

flow of the program will go to the “thatsIncorrect” generic object, this will use the incorrect field as a

prompt to inform the user that they were wrong before telling them the correct answer.

Figure 5.5– Round 1 Player 1 sub-dialogue


When the question list has iterated through each of the 15 questions for the player the flow leads

to the removal of the final question screen. From here a conditional fork is reached whereby the

number of passes is checked, if the user has had one or more passes, the animated host will go

through each of these informing the user of the required answer using the passes field as a

spoken prompt in the “passesString” generic object before flowing to the “summaryString”

generic object which informs the contestant of their score and passes counts. If the user has had

no passes then it branches immediately to “summaryString”. This is followed by the removal of

the question screen, template screen, and score screen, before exiting the sub-dialogue.

The Round 2 sub-dialogue seen in Figure 15 begins with the creation and sorting of the player

scores from the previous round which was accomplished using tcl code, a full list of which is

found in Appendix Bthat details all code used throughout the mini-project. This is followed by

another recorded prompt with combined TTS with the animated host which informs the

contestants that “So that’s the end of the first round a very close one let’s have a look at the

score”. This is followed by a loop in which the score are visited in reverse order with the list

index variables of player score and player name being used as variables. This is followed by

another TTS prompt which says “General knowledge round now and if there is a tie at the end of

it then the number of passes gets taken into account and the person with the fewer passes is the

winner if they are tied on passes aswell, well there will be a tie break” before visiting each player

sub-dialogue in reverse order dependant on their specialist subject score. Once the four players

have completed their questions the sub-dialogue exists back to the main canvas.

Figure5.6– Round 2 sub-dialogue


The score sub-dialogue canvas seen in Figure 16 shows how again the system starts with the

creation and sorting of a list using the recalibrated scores of each player following the second

round questioning. This is followed by the initialization of a loop count variable and another TTS

aligned prompt recording from the show which says “Well they tried at the end of the round let’s

have a look at the scores”. Again a conditional fork is reached with tcl code determining the

order in which the generic objects are visited with the list items again being used as variables.

On exit of this conditional loop when the list length is reached another conditional fork is

reached where a somewhat personalized image is presented congratulating the player number on

their achievements and that they were today’s mastermind champion. This was followed by an

image detailing how you can apply for the real television show which is again aligned with a

TTS prompt. These files are saved as .sob files and are stored in their own folder as part of the

CLSU toolkit set up.

Figure 5.7– Scores sub-dialogue

The program ends on the main canvas on the stop object which is the animated host being aligned to the goodbye prompt that was again taken from a recording of the BBC show. It should be noted that the .wav files must be in a mono format and can easily be converted using a piece of software called audacity a link of which can be found in the references section.


5.4 Testing

Testing is the process of executing a program with the intent of finding errors. The software testing process has two distinct goals:

1. To demonstrate to the developer that the software meets its requirements. For custom software, this means that there should be at least one test for every requirement in the user and system requirements documents.

2. To discover faults or defects in the software where the behaviour of the software is incorrect, undesirable or does not conform to its specification. Defect testing is concerned with rooting out all kinds of undesirable system behaviour, such as system crashes, unwanted interactions with other systems, incorrect computations and data corruption.

The first goal leads to validation testing, where you expect the system to perform correctly using a given set of test cases that reflects the system’s expected use. The second goal leads to defect testing, where the test cases are designed to expose defects. The test cases can be deliberately obscure and need not reflect how the system is normally used. For validation testing, a successful test is one where the system performs correctly. For defect testing, a successful test is one that exposes a defect that causes the system to perform incorrectly.

Testing cannot demonstrate that the software is free of defects or that it will behave as specified in every circumstance. It is always possible that a test that you have overlooked could discover further problems with the system. As EdsgerDijkstra, a leading early figure in the development of software engineering, eloquently stated (Dijkstra, et al., 1972), ‘Testing can only show the presence of errors, not their absence’. Figure 27 depicts a general model of the testing process.

Figure 5.8 – A model of the software testing process

5.4.1 Test cases

Test cases have been developed and executed against the application in order to ensure proper functionality is achieved when a contestant plays the game. The test cases can be viewed in Appendix C. Each of the test cases have been designed to test the requirements specified in section 3 and highlight any errors/defects that have not yet been discovered.

Design testcases

Prepare test data

Run program with test data

Compare results to test

Test cases Test Test results Test data


5.5 Functional Requirements Evaluation

The Functional Requirements of SLIM, as outlined in section 3, were considered in order to test if SLIM functions as required. Table 5.1 shows a list of the Functional and how well these have been met. Requirements are measured using three levels of classification as follows:

• Average – Requirement marginally met • Good – Requirement satisfactorily • Very Good – Requirement was fully realized and more

No. Functional Requirement Classification

1 Each player will be required to login with their name and specialist subject

Average

2 Verbal confirmation will be given through the animated host when a correct answer is given

Very good

3 Incorrect answers will result in the animated host stating the answer was incorrect and speaking the answer that was required

Very good

4 A counter will be displayed to show the player's running total of correct answers

Very good

5 A counter of the number of "passes" will be kept for tie-break purposes

Average

6 At the end of each player's turn the animated host will recite the questions that were passed on and give their correct answers

Good

7 At the end of the first round the scores of the players will be displayed in reverse order

Very good

8 This order will be maintained for the general knowledge round with the lowest scorer in the previous round required to go first

Very good

9 The player with the highest combined score at the end of the game will be displayed as the winner with their list added to previous winners list

Average


6. Conclusion & Critical analysis

6.1 Introduction

This section of the report will assess whether the initial aims and objectives that were outlined at the commencement of the project have been met and discuss any future developments that could be considered to making the game more enjoyable.

6.2 Conclusion

The first of these aims was the completion of a literature review. The background section discussed: Intelligent Multimedia, speech technologies, the mastermind television show, and papers relevant to the design of the system that have been discussed as part of the module.

To determine the user and system requirements of SLIM, the television show format was analysed to determine the flow of events that were required to be mimicked by the system, together with end user questionnaires the functional and non-functional requirements of the system were defined. This lead to a discussion about the software that would be required for the implementation of SLIM, including: the CLSU toolkit, RAD and the Tcl/TK languages.

The design section discussed the architecture of SLIM with the memory component and the interface component being highlighted. This was followed by a list of HCI guidelines that should be adhered to in the design of the screens. The design of the interface components and the memory components are also discussed.

The implementation of SLIM was carried out using the CLSU toolkit. This software was chosen as it is an effective tool used to demonstrate spoken language interaction and it is extensible with a lot of other pieces. The system was implemented with the use of images created in Microsoft paint together with Tcl code to look after the incrementing of the scores and the sorting of the score lists after the rounds.

6.3 Critical Analysis

As a means of evaluating the system it is necessary to confirm that the initial aims and objectives of the project have been met together with the functional requirements.

The deliverables were that on completion of the project it was anticipated that a fully functional multimedia system would have been created which allowed four players to play the Mastermind game through a natural language input. This is something which we believe has been achieved with complete success as the system is capable of running from start to finish with each of the four players being given their chance to play the game.

Due to issues regarding recognition problems in the early stages of development it was deemed appropriate that the time limit would be removed from the system instead opting for a set number of questions for each player. This would not have been difficult to implement however given the timing facility offered by the toolkit.

Due to the specialist knowledge required for the first round of questions it was decided that the order of the end users would be predetermined and so the login facility was never implemented as part of the system. If the player login had been used then it would have been more likely that the users would have claimed ownership of the system, a violation of a user requirement.


Going through each of the other user requirements, it seems that the target goals have been accomplished given that: the host confirms correct answers; the host acknowledges incorrect answers with the correct answer; the running score board totals are displayed; the number of passes is incremented; the host recites all passed question answers; the users are informed of their performance at the end of each round; the scores are ordered in reverse order at the end of the specialist subject round; and the player with the winning score is deemed the winner with the associated personalized image being displayed.

6.4 Future Developments

We believe that if done correctly this is a product that would have mass commercial appeal, the inclusion of an animated character that resembled the host John Humphreys would be a starting point for creating a memorable user experience as the faces found within the festival package although showing value are not detailed enough to fulfil this remit.

For any further developments it might be worthy to include a database as the memory component of the software as a means of alleviating expected high redundancy levels in the system should it scale using the techniques deployed thus far.

The automatic generation system of the screen images would also be something worthy for research into given that the information is always available from the memory component of the system. If this was created in a Visual Studio environment it would be possible to use a text box inside the screen with the text property of this item being assigned to an appropriate variable.

The system shows some ambiguity on the entry of similar sounding words and the recognition could be worked upon to yield improvements. This can be achieved by creating custom pronunciation models where natural language processing techniques can be used to determine alternative means of pronunciation.


References

Audacity (2010).Audacity audio software.[online]. Available from: http://audacity.sourceforge.net [Accessed 02/04/2010]

BBC (2010a).Mastermind.[online]. Available from: http://www.bbc.co.uk/entertainment/mastermind [Accessed 08/03/2010]

BBC (2010b).iPlayer. [online]. Available from http://www.bbc.co.uk/iplayer/ [Accessed 28/03/2010]

Benyon, David,Turner, Philip and Turner, Susan. (2005). Designing Interactive Systems: People, Activities, Contexts, Technologies. Essex: Addison-Wesley

Cassell, J. et al. (2001). The behaviour expression animation toolkit. In SIGGRAPH ’01: Proceedings of the 28th annual conference on Computer graphics and interactive techniques, pp. 477-486

Kipp, M. (2001).ANVIL: a generic annotation tool for multimodal dialogue.In Proceedings of the 7th European Conference on Speech Communication and Technology (Eurospeech).

Maybury, M.T. (1995). Research in Multimedia and Multimodal Parsing and Generation. Artificial Intelligence Review, v.9 n.2-3, p.103-127, June

McKevitt, P. (1998). Superinformationhighways and IntelliMedia 2000+: bring together humanities, science and engineering. WWW and Printed Proceedings of the International Conference on The Future of the Humanities in the Digital Age: problems and perspectives for humanities education and research. University of Bergen, Bergen, Norway, September, 17-22

Nielsen, J., and Molich, R. (1990).Heuristic evaluation of user interfaces, Proc. ACM CHI'90 Conf. (Seattle, WA, 1-5 April), 249-256.

Norman, D. (1988). The psychology of everyday things. New York: Basic Books.

Pinker, Steven. (1995). The Language Instinct. The new science of language and mind.Penguin.

Sommerville, Ian. (2007). Software Engineering.8th Edition. Essex: Addison-Wesley.

http://audacity.sourceforge.net/

http://www.bbc.co.uk/entertainment/mastermind

http://www.bbc.co.uk/iplayer/


Srihari, R.K. (1995). Computational models for integrating linguistic and visual information: A survey. Artificial Intelligence Review v.8, p.249-269

Washington (2010).Shneiderman’s Eight Golden Rules. [online]. Available from: http://faculty.washington.edu/jtenenbg/courses/360/f04/sessions/schneidermanGoldenRules.html

http://faculty.washington.edu/jtenenbg/courses/360/f04/sessions/schneidermanGoldenRules.html


Appendices

Appendix A – Populated Listbuilder

Appendix A.1 – Player 1 Round 1


Appendix B – Tcl code explanation

Location Login sub-dialogue, variable-initialisation

Code set p1correct 0

Purpose Initialisation of variable to count the total number of correct answers given by player 1


Code set p1pass 0

Purpose Initialisation of variable to count the number of passes taken by player 1





Code set p2pass 0






Code set p3pass 0







Code set p4pass 0


Location Round_1 & Round 2 (each of the 4 players)

Code set pop " ok now and for your passes"

Purpose Creation of a text string that can be appended and used as a prompt should the user have 1 or more passes in a round

Location Round_1 & Round 2 (each of the 4 players)

Code append pop " ,,,,,,,,,,,,,,,,$passes"

Purpose Adds the text string contained in the “passes” field of the relevant Listbuilder component to the “pop” variable which can then be used in the summary section for each of the 4 players on both rounds

Location Round_1 & Round 2 (player 1)

Code incr p1correct

Purpose Adds 1 to the variable used to track the total number of correct answers for player 1


Code incr p1pass

Purpose Adds 1 to the variable used to track the total number of passes player 1



Code incr p2correct



Code incr p2pass



Code incr p3correct



Code incr p3pass



Code incr p4correct



Code incr p4pass



Location Round 2, sorted_score_list

Code set playerList [list [list 1 $p1correct] [list 2 $p2correct] [list 3 $p3correct] [list 4 $p4correct]]

set sortedList [lsort -integer -index 1 $playerList]

foreach entry $sortedList

{

set playerID [lindex $entry 0]

set playerScore [lindex $entry 1]

}

Purpose Creates a list consisting of {playerID score} tuples which is then sorted on the score (the second element in each sublist before looping over the sorted list and running the sub-dialogue for each player ID.


Code set listIndex 0

Purpose Loop position set to zero


Code set listIndex 0

Purpose Loop position set to zero

Location Round 2, score_summary

Code $listIndex==0

Purpose Upon sorted list declare the person in list index 0 as being in 4th place



Code $listIndex==1

Purpose Upon sorted list declare the person in list index 1 as being in 3rd place


Code $listIndex==2

Purpose Upon sorted list declare the person in list index 2 as being in 2ndplace


Code $listIndex==3

Purpose Upon sorted list declare the person in list index 3 as being in 1st place

Location Round 2, increment_list

Code incrlistIndex

Purpose Adds 1 to the list index so that iteration through loop can occur

Location Round 2, again & done looping

Code $listIndex< [llength $sortedList]

Purpose Continue to loop while the list index is less than the length of the list

Location Round 2, again &done_looping

Code $listIndex< [llength $sortedList]

Purpose Continue to loop while the list index is less than the length of the list


Appendix C – Test Cases

ID 1

Purpose Does the game load properly?

Test Data Double click on the Mastermind 5.0 icon.

Expected Result Mastermind 5.0 should load. The start-up screen is displayed and the quiz master introduces the game. The menu screen is then displayed to the contestants.

Actual Result PASS

Comment None

Action Taken None

ID 2

Purpose When the contestant clicks on the ‘Show Format’ option from the menu screen, does the quiz master state the format of the game?

Test Data Click on ‘Show Format’ on the menu screen.

Expected Result The format of the game is explained to the contestants.

Actual Result PASS

Comment When a contestant clicks on the ‘Show Format’ option, no other option can be selected until the format is explained.

Action Taken None

ID 3

Purpose When the contestant clicks on the ‘Instructions’ option from the menu screen, does the quiz master give instructions?

Test Data Click on ‘Instructions’ on the menu screen.

Expected Result Instructions on how to start a game and the rules of the game are explained to the contestants.

Actual Result PASS

Comment When a contestant clicks on the ‘Instructions option, no other option can be selected until the instructions are explained.

Action Taken None


ID 4

Purpose When the contestant clicks on ‘Start’ from the menu screen, does the game start?

Test Data Click on ‘Start’ on the menu screen.

Expected Result The quiz master starts the game and introduces the first contestant. The player one start screen is displayed.

Actual Result PASS

Comment A start screen is displayed for each contestant i.e. player two start screen when they start each round.

Action Taken None

ID 5

Purpose Does the round begin when the contestant clicks on the screen?

Test Data Click anywhere on the screen to begin the round.

Expected Result The contestant is asked to state his/her name.

Actual Result PASS

Comment None

Action Taken None

ID 6

Purpose Can the contestant state his/her name?

Test Data State name after the beep.

Expected Result The contestant is asked to state his/her occupation.

Actual Result PASS

Comment The contestant is asked to repeat the name if not recognised by the system in the first instance.

Action Taken None


ID 7

Purpose Can the contestant state his/her occupation?

Test Data State occupation after the beep.

Expected Result The contestant is asked to state his/her specialist subject.

Actual Result PASS

Comment The contestant is asked to repeat the occupation if not recognised by the system in the first instance.

Action Taken None

ID 8

Purpose Can the contestant state their specialist subject?

Test Data State specialist subject after the beep.

Expected Result Round one begins. The question screen appears and the quiz master reads the question displayed on the question screen.

Actual Result PASS

Comment The question screen changes according to the player and the specialist subject. Again the contestant is asked to repeat the specialist subject if not recognised by the system in the first instance.

Action Taken None

ID 9

Purpose Can the contestant answer a question correctly?

Test Data State answer to the question after the beep.

Expected Result Quiz master moves onto the next question.

Actual Result PASS

Comment None

Action Taken None


ID 10

Purpose Does the score screen appear when a question is answered correctly?

Test Data Answer a question correctly.

Expected Result The score screen appears with a value of 1 if at zero while incrementing any other score.

Actual Result PASS

Comment None

Action Taken None

ID 11

Purpose Does the score screen increment the score according to each correct answer?

Test Data Answer more than one question correctly.

Expected Result The score screen increases its value by 1 for each correct answer.

Actual Result PASS

Comment None

Action Taken None

ID 12

Purpose Can the contestant answer a question incorrectly?

Test Data State the wrong answer to a question after the beep.

Expected Result The quiz master states the correct answer to the question.

Actual Result PASS

Comment None

Action Taken None


ID 13

Purpose Can the contestant pass on a question?

Test Data Answer pass after the beep.

Expected Result Quiz master moves onto next question.

Actual Result PASS

Comment None

Action Taken None

ID 14

Purpose Does the quiz master state the question and answer to each question that the contestant passed on?

Test Data Pass on at least one question throughout the round.

Expected Result At the end of the round the quiz master states the number of questions passed on and the original question followed by the answer.

Actual Result PASS

Comment None

Action Taken None

ID 15

Purpose Does the quiz master state the contestants score at the end of their round.

Test Data Complete a round.

Expected Result Quiz master states the number of questions answered correctly and the number of questions passed on. Applause then follows.

Actual Result PASS

Comment None

Action Taken None


ID 16

Purpose Does round one move onto round two?

Test Data Complete round one with each contestant.

Expected Result Quiz master brings the round to a close. Each contestants score is then stated by the quiz master from the lowest to the highest. Applause follows; round two start-up screen is displayed.

Actual Result PASS

Comment None

Action Taken None

ID 17

Purpose Does round two take the contestants in the order of their score, from the contestant that scored the lowest to the highest?

Test Data Check scores at the end of round one. See if the contestants are taken in order of score in round two (lowest-highest).

Expected Result Player 1, 2, 3 or 4 is displayed in the round two start-up screen in order of score at the start of the round and after each contestant completes a round.

Actual Result PASS

Comment None

Action Taken None

ID 18

Purpose Can the contestant start round two?

Test Data Click anywhere on the round two start-up screen.

Expected Result General knowledge question screen appears and the quiz master reads the questions.

Actual Result PASS

Comment None

Action Taken None


ID 19

Purpose Does round two finish once each contestant has participated?

Test Data Complete round two with each contestant.

Expected Result At the end of round two there is applause, the quiz master then states the scores of each contestant from lowest to highest. The contestant with the highest score is named as Mastermind and the winner notification screen is displayed with the contestant that was named Mastermind i.e. Player one.

Actual Result PASS

Comment An error in start-up script appears at the end of the game.

Action Taken None

ID 20

Purpose Does the system accept keystrokes as input

Test Data At the start of the game and throughout, enter random keystrokes.

Expected Result Keystrokes should not be recognised as input at any stage of the game.

Actual Result None

Comment An error in start-up script appears at the end of the game.

Action Taken None

1. introduction 1.1 aims and objectives - paul mc kevitt · the aim of this project is to initially...

Documents