Hasbro: Consumer Product Design Report by Kat Ingalls

Hasbro Product Design Team Semester 1

Katie Ingalls An overview of the work done for the Hasbro Consumer Product Design project for the Fall 2010 term. Individual work done for the “Battle Doll” concept generation and detailing including context diagram, use cases, behavioral diagram, customer value proposition, concept fragments, functional requirements, subsystem organization, goal-question-metrics analysis, house of quality, and originating requirements.

HASBRO PRODUCT DESIGN CORNELL UNIVERSITY PROJECT ADVISOR: DAVID SCHNEIDER

Table of Contents 1 Abstract ........................................................................................................................ 3 2 Project Objective ...................................................................................................... 4 3 Battle Doll Overview .................................................................................................... 5 4 Concept Generation................................................................................................... 6 4.1 Annotated Concept Sketch - Initial ................................................................................ 6 4.2 Annotated Concept Sketch - Refined ............................................................................ 7

5 Customer Evaluation ................................................................................................... 9 5.1 Customer Affinity Process ................................................................................................. 9 5.2 Customer Value Proposition........................................................................................... 11

6 Functional Conceptualization .................................................................................. 12 6.1 Context Diagram ............................................................................................................. 12 6.2 Use Cases ........................................................................................................................ 15 6.3 Behavioral Diagrams ...................................................................................................... 16 6.5 Functional Requirements ................................................................................................ 19

7 Draft Prototype Development .................................................................................. 22 7.1 Concept Fragment Generation ..................................................................................... 22 7.2 Prune and Expansion with Notes ................................................................................... 23 7.3 Decision Matrix ................................................................................................................ 23 7.4 Originating Requirements Issue Resolution .................................................................. 24 7.5 Subsystem Development ............................................................................................... 25 7.6 Draft prototype summary and knowledge gain .......................................................... 27 Battle doll and battle system form .................................................................................... 27 Scoring Control Mechanism .............................................................................................. 28 Conclusions.......................................................................................................................... 30 7.7 Bill of Materials Estimate ................................................................................................. 31

8 Customer Value Assessment Criteria & Technical Optimization .......................... 32 8.1 Goal-Question-Matrix (GQM) ........................................................................................ 32 8.2 Analytical Hierarchy Process ......................................................................................... 34 8.3 House of Quality .............................................................................................................. 35

Hasbro Product Design Team

1 Abstract The Hasbro Consumer Product Design team is a collaborative effort between Cornell University System Engineering and Hasbro, Inc. The purpose of this collaboration is to develop a consumer product (i.e. a toy) concept using systems engineering knowledge and techniques. However, these techniques can be applied to the development of any project. The project ran from September 2010 to May 2011, and was divided into two semesters. The first half of the project was done individually, and is the concept detailed in this section of the report. The design done during this segment of the project includes work on the customer affinity process, customer value proposition, context diagrams, use cases and behavioral diagrams, as well as development of functional requirements. Following this, determination of core functionality, concept fragment generation, sub-system development and draft prototyping were completed. Next, customer value assessment was done using GQM to determine how customer needs would be measured as well as a House of Quality to relate customer needs to technical performance measures. Finally, a bill of materials estimate was done to ensure that the concept was within the budget set by Hasbro. The second half of the project work was completed in a team, the results of which are included in a second, accompanying report.

All work detailed in this report can be found in its original format in the Appendix, which is included on the accompanying CD.

Kat Â Ingalls Â

3 Â

2 Project Objective At the beginning of the project the following request for proposal (RFP) was delivered: Hasbro is a worldwide leader in children's and family leisure time products and services with a rich portfolio of brands and entertainment properties that provides some of the highest quality and most recognizable play and recreational experiences in the world. As a brand-driven, consumer-focused global company, Hasbro brings to market a range of toys, games and licensed products, from traditional to high-tech and digital, under such powerful brand names as TRANSFORMERS, MONOPOLY, LITTLEST PET SHOP, MY LITTLE PONY, PLAYSKOOL, TONKA, GI JOE, MR. POTATO HEAD, NERF, BABY ALIVE, STAR WARS, FURREAL FRIENDS, EZ BAKE OVEN, PLAY DOH, I-DOG and many others. As a member of the DAVANNE LLC toy consulting company, you have been given the opportunity to pitch your own toy design to Hasbro. In order to remain competitive in today's market, initial market research suggests that Hasbro will be most interested in toys that involve some “working components” whether they’re mechanical, electrical, or both. Toy concepts that demonstrate both the most unique and the best thoughtout designs will be given the highest consideration. The target shelf price for the toy should be no more than approximately $50, with toys under the $30 range preferred. Your final design will be presented in two bound copies, one for the Cornell Library and one for Hasbro Team to review. Additionally a presentation on your design must be given to all senior personnel and key Hasbro design representatives. Some of the presentation content may be used to “sell” your product design to a perspective toy designer and/or consumer. However, the majority of the design presentation and the elements that Hasbro will be scrutinizing the most will be the design documentation that demonstrates the translation of customer needs into a final design, documentation justifying your design decisions and trade-offs, as well as details on the functional description, operation, implementation, and validation of your design. (GDR-H-F10) The work that follows was done for the purpose of meeting the criteria of this RPF.

Hasbro Product Design Team

3 Battle Doll Overview The battle doll combines elements of traditional doll play with action figure excitement as well as the nurturing aspects of the digital pet. A concept sketch is shown below, in Figure 1.

Figure 1: Battle Doll concept sketch

The main purpose of the Battle Doll is as an interactive battle game. The doll has control mechanisms (upper left of figure) for her limbs, enabling her to make “hits.” She also has scoring areas, or buttons, on her body that, when depressed, result in a score. The user that scores the most points or does not run out of health first, wins. When a hit is made, the action is communicated to the battle system (lower right). This system translates the hit into point scored, depending on the accessories that are equipped. Clothes and weapons result in either offensive or defensive strength, depending on the particular accessories. For instance, a sword that is equipped would result in more health points being taken away from the opponent doll comparative to a bare fist. Conversely, a jacket might provide the user’s doll with greater defense, and thus less health points lost, when being hit. These accessories are added into the battle system, and equipped by the doll. They are then translated into battle statistics (defense and power) that influence gameplay. In addition to the battle gameplay, Battle Doll also functions as a standalone, traditional doll. Furthermore, the battle system doubles as a digital pet that displays the doll. The user can feed, play with, and take care of the doll via this digital pet functionality. How well the doll is taken care of, as a digital pet, can influence the health level of the doll during battle gameplay.

Kat Ingalls

4 Concept Generation In order to develop a toy design that met Hasbro’s RFP, the first step taken was to generate toy concepts that incorporated a working mechanism. This process was done concurrently with the customer evaluation method, which gave insight to the concept generation process, and will be discussed in greater detail in Section 5. Initially, ten ideas were generated, which were discussed with the project advisor for appropriateness and feasibility. Two concepts showed strong potential: (1) A tea set which would also teach about culture and geography, and (2) a girl’s action figure used for a battle game. These concepts were discussed with fellow students, and a clear preference was shown for the doll. With the consideration of these preferences, customer values, and Hasbro’s RFP requirement of a working mechanism considered, the concept chosen for development over the course of the semester was the Battle Doll.

4.1 Annotated Concept Sketch - Initial In order to develop the original concept of the “female action figure” an initial concept sketch was done, highlighting the features and processes of the product. This annotated concept sketch helps determine the functionality and purpose of the concept, as well as communicate it to others. The purpose of the annotated concept sketch is to convey ideas about the design, not to communicate the detailed workings of the product. The initial annotated concept sketch for the Battle Doll is shown in Figure 2.

Figure 2: Initial concept sketches

Hasbro Product Design Team

This original concept sketch shows a platform on which the doll would be used. The platform would read a card which has information about the doll and her fight experience, which would result in greater strength when battling. The platform would sense the position of the doll, possibly using magnets, and would display the score and battle status at each end. The sketch of the doll highlights pressure-sensitive scoring areas, as well as key joints important for movement. Accessories are also sketched, detailing how they would interact with the doll, and the gaming platform. Although the doll and accessories concepts remained fairly constant throughout the development of the product, the battle platform was adapted. Due to considerations of both the cost and complexity of such a battle platform, the idea was reassessed, and a battle system resembling a Tamagotchi was adopted, which is detailed in the next section.

4.2 Annotated Concept Sketch - Refined In order to reduce the cost and increase the technical feasibility of the product, the battle platform shown in the previous concept sketch was redesigned. Additionally, the mechanisms of the Battle Doll are developed more fully in the refined version, shown in Figure 3.

Figure 3: Refined annotated concept sketch

The purpose of the battle platform was to keep score during the battle game, as well are read accessories and translate them into a gameplay algorithm. However, there were

Kat Â Ingalls Â

7 Â

many technically exciting but expensive and superfluous features, such as sensing where a doll was on the battle platform, which had little positive influence on gameplay. Additionally, the electronics system was unnecessarily complex, because it included the materials needed for two players. To remedy these issues, the platform was removed entirely, as a playing area was not a necessary feature for the success of the product. Additionally, the scoring and scanning mechanism was divided so that each player would carry his or her own scoring system. Not only did this make the product concept more portable as well as more affordable, but it also lent itself readily to the concept of a digital pet, increasing the gameplay variability. Inspired by the Tamagotchi Connect digital pet, the battle system closely resembles this already famous toy, as shown in Figure 3. The infrared used to connect two Tamagotchis could be altered to connect two Battle Dolls, and communicate scores wirelessly, while still achieving this at low cost. While functioning as a scoring and status display device during battle games, the unit could also function as a digital pet when not involved in interactive gameplay. This increases the variability of play, as well as offering the traditional nurturing gameplay that is usually marketed to girls. As shown above, the Battle System device could be connected to the doll via the data transfer plug, which is retractable and connects to the back of the doll. The unit could be modeled to look like a backpack for ease of storage with the doll when not in use for battle games, during which it would need to be removed to communicate with other devices using IR. The Battle system features a speaker to play sound effects when a point is scored. It has displays for the current score, ability levels (Strength, Defense, Experience), as well as display for how much health remains before the doll is defeated. It also features a hit location display, indicating where on the doll the opponent has scored, so that the user may better defend that area - mimicking real martial arts. The infrared sensor for communication between battle systems is located at the top of the device. The doll itself is shown with four control mechanisms: one for each arm and each leg. The control mechanism could be used as a joystick with a ball-and-socket mechanism. In order to extend the limb, the control point would be pushed, which would then push rods to extend the limb into a punching or kicking motion. It is important to note that at this stage, these are only initial ideas for the working mechanisms of the doll. Further details on the various options and final implementation of the mechanisms constituting the functionality of the Battle Doll are discussed in Concept Fragment Generation of this report, as well as the Prototyping section of the accompanying Semester 2 Report.

Hasbro Product Design Team

5 Customer Evaluation The purpose of the customer evaluation process is to determine the objectives of the product, from the perspective of the customer. Information about customer values are used to determine or inform nearly all other aspects of product concept detailing, including generating the originating requirements, developing use cases, and developing the house of quality.

5.1 Customer Affinity Process At the beginning of the project, the team was provided with 109 customer statements relating to perceptions of and preferences about toys (the full list of statements is included in the Appendix). In order to measure preferences, the customer statements were categorized according to content. The first iteration of categorization resulted in the Level 3 categories listed in the following table: Figure 4: Customer affinity grouping

Level 1

Level 2

Business

Physical

Feelings

Emotional: Accomplishment

Styles of Play

Variability

Construction Quality

Human Interaction Technology

Level 3 Price Advertising Visual Aural Tactile Cool Pride Collectable Education Imagnination Inventiveness Solo Family Friends/Group Play Environment Grown up/realistic Longevity Pieces Safety Durability Materials Set up/Clean up Low Tech High Tech

Figure 4: Customer affinity grouping

Kat Ingalls

After doing this low-level categorization, the statements were then further grouped into broader categories. For instance, the visual, aural and tactile toys are all aspects of the physical feel of the product. Blank Level 2 categories indicate that the Level 3 categories could not be grouped further; they are a subset of the broad Level 1 categorization. The process of creating larger groups was continued until no further categorizations were conceived. The number of statements in each category was summed (with no weighting applied). A summary of the results is shown in Figure 5.

Customer Values: By Percentage 7%

32%

22%

Business Feelings Styles of Play Variability ConstrucTon Quality

9% 30%

Figure 5: Customer Affinity Process Results (unweighted)

The customer affinity diagram is extremely useful for enabling a large amount of information to be readily processed. Because there were 6 members involved in the affinity process, the categorizations were relatively objective. By consolidating 109 customer statements into just 5 general categories, which can be analyzed further, the information regarding consumer preferences was made readily available. Furthermore, the information is more readily communicated in the customer affinity format, which proved very useful when presenting the product concepts that were developed. Finally, the results of this affinity process influences a large number of the tools used throughout the design, which will be discussed later in greater detail. The customer affinity process defines the basis for which later design decisions are made.

Hasbro Product Design Team

5.2 Customer Value Proposition A customer value proposition (CVP) is a brief explanation of why a customer should choose the product being offered. It communicates the value the Battle Doll proves both to the user, as well as to Hasbro, Inc. The CVP for the Battle Doll is included below.

“Battle doll designed for girl of the digital age, which can communicate with other dolls using infrared technology and reacts to accessories and experience programmed into personal battle system.” • • • • • • •

• • • • •

Battle system uses digital-age technology to enhance traditional doll play by increasing variability and longevity of play. Unlike traditional dolls or action figures, battle doll combines elements of both, empowering girls to be strong and independent. Doll can actually sense when a hit has been made, just like a real fight! Unlike other action figures, scoring system and sound effects gives REAL outcomes! Arena displays how well your doll is doing in battle so you can take care of her when needed. The doll “knows” what weapons and clothing she’s wearing, so each fight is different and unique! Battle arena keeps track of win and loss record, and increases doll’s experience accordingly, so your doll can keep growing as you nurture her skills. More experience means a better advantage in your next fight! Fighting accessories (weapons) are modular and assemble-able, so that there’s always a new way of playing. Different weapons have different damage levels and damage types associated with them, giving you a wide range of options for attack. Clothing accessories give doll different strengths and abilities, meaning a wide range of options for defense. Can battle your friends, making gameplay interactive. Can battle monsters, so you can gain experience, even when your friends aren’t around!

Kat Ingalls

6 Functional Conceptualization The purpose of the functional conceptualization phase is to define the usage and requirements of the project under consideration. The following tools and methodologies were used to achieve this.

6.1 Context Diagram A context diagram is used to define the scope of the system under consideration. They illustrate interactions and relationships between the system under consideration and its environment or related systems. Context diagrams are used to evaluate and communicate the factors that should be taken into consideration while determining the system requirements. The stakeholder context diagram, shown on the following page in Figure 6, illustrates the interactions occurring between the Battle Doll and entities who affect or can be affected by the system under consideration. Key stakeholders, including the child who will be using the toy, the parent purchasing it, and the toy manufacturer (i.e Hasbro), are considered. This context diagram communicates the impacts the design of the toy will have on people or organizations, which need to be taken into consideration throughout the rest of the design process. The system-level context diagram, shown in Figure 7, is an elaboration of the TOY referred to at the center of Figure 6. Here, battle doll refers to the doll figurine, rather than as an abbreviation for the entire product system. This context diagram shows the relationships within the complete battle doll system. It is a graphical representation of the basic functionality of the entire Battle Doll system.

Hasbro Product Design Team

Figure 6: Context Diagram – Stakeholders. The entity TOY at the center of the diagram is detailed further in the next figure.

Kat Ingalls

Figure 7: System-level context diagram depicting basic functionality of Battle Doll system.

Hasbro Product Design Team

6.2 Use Cases In order to further understand how the Battle Doll system would interact with its surroundings, use cases were generated using information from the context diagrams. The use cases listed below focus on interactions between the intended user of the system (“Child”), as well as use cases which address unintended users and uses which may result from situational context. A list of the use cases generated is listed below in Figure 8. Core functionalities which were later developed into behavioral diagrams are in bold. Use Cases 1

Child equips doll

Game is initiated

A hit is made

Doll uses weapon

System is set up

A point is scored

Child wins game

Child loses game

Child puts clothes on doll

Child attaches weapon to doll

Child puts doll on scanner

Parent steps on scanner

Child inserts smart card into scanner

Child loses smart card

Child inserts weapon into smart card slot

Parent plays with doll

Child dresses weapons in clothes

Friend brings doll, interacts with Child’s doll on arena

Friend and Child’s dolls battle when not standing on arena

Child scans weapon ID into scanner/arena and “equips” doll

Parent puts toy away

Child takes doll into bathtub

Dog finds toy, chews/buries it

Boy plays with toy (vs. “girl” market)

Older sibling plays with toy

Younger sibling plays with toy

Child’s doll kicks friends doll

Friend’s doll shoots Child’s doll

Child friends’ doll clothes on their doll

Child disassembles weapon

Child reassembles weapon

Child removes clothes from doll

Child bangs on scanner

Child uses weapon on arena, without doll

Water is spilled on doll or toy

Small child puts weapon parts in mouth

Child puts another toys' clothes on doll

Scanner is hit or stepped on

Figure 8: Use Cases

Kat Ingalls

6.3 Behavioral Diagrams Using the use cases generated in the previous section, behavioral diagrams were created in order to determine the functional requirements of the Battle Doll system. After selecting a use case, start and end conditions which define that use case were specified. The actions of the operator and requirements of the system are filled in according to what is needed to achieve the specified end condition. By creating a series of behavioral diagrams focusing on the core functionality of the Battle Doll, the majority of the functional requirements needed by the system were derived. The five use cases chosen to represent the core functionality are presented sequentially in order of toy use. The use case “Child equips doll” is shown in Figure 9. *+,-.)#;<,"1).'-I4(.(6)+&34*(.(34/ !" <3))+(/+-46..(10* #" H06,34/+610+43.+)36*0*+(4.3+/7/.0? $ &)3.'(45+(/+43.+)36*0*+(4.3+/7/.0? % K7/.0?+(/+.-140*+34" !"#$%&'$()*+,-. &'()*+,-./+*0/(10*+2)3.'(45+6220//317+ 8962:0.;+34.3+*3))"

/01&#2()3'--)4)5%&&-#)/01&#2

6#%"'7)899#11'$0

*-'&+,7:)899#11'$0

<3))/+/'6))+=0+3>+-4(>31?+/(@0+8/3+.'6.+6))+ 2)3.'(45+?64->62.-10*+>31+(.+A())+>(.;" B'0+2'()*+/264/+962:0.+(4.3+.'0+=6..)0+ /7/.0?" B'0+=6..)0+/7/.0?+/'6))+=0+6=)0+.3+106*+ 23*0/C/04/31/+34+2)3.'(45+6220//317+ (.0?/" B'0+2)3.'(45+6220//31(0/+/'6))+=0+6=)0+.3+ =0+102354(@0*+=7+=6..)0+/7/.0?" B'0+=6..)0+/7/.0?+/'6))+=0+6=)0+.3+ 102354(@0+6..1(=-.0/+3>+2)3.'(45+ 6220//317+(.0?/" B'0+2)3.'(45+6220//31(0/+/'6))+'6D0+EF/+ 64*+6=()(.(0/+6//32(6.0*+A(.'+.'0?" B'0+=6..)0+/7/.0?+/'6))+=0+6=)0+.3+ 234D01.+2)3.'(45+6..1(=-.0/+.3+56?0,)67"+ B'0+2'()*+2'3/0/+6+A06,34+.3+6//0?=)0" <3))+/'6))+=0+6=)0+.3+G'3)*G+A06,34/"+ H06,34/+/'6))+43.+26-/0+2'()*+.3+=0+2-.+ 31+3.'01A(/0+(49-10*" &'()*+6//0?=)0/+A06,34" H06,34/+/'6))+'6D0+,61./+.'6.+264+ 6//0?=)0+(4.3+?647+.7,0/+3>+A06,3417" &'()*+/264/+A06,34+(4.3+=6..)0+/7/.0?" H06,34/+/'6))+=0+6=)0+.3+=0+102354(@0*+ =7+=6..)0+/7/.0?" B'0+=6..)0+/7/.0?+/'6))+=0+6=)0+.3+106*+ 23*0/C/04/31/+34+A06,34+6220//317+ (.0?/"

B'0+=6..)0+/7/.0?+/'6))+=0+6=)0+.3+ 102354(@0+6..1(=-.0/+3>+A06,34+ 6220//317+(.0?/" B'0+=6..)0+/7/.0?+/'6))+=0+6=)0+.3+ 234D01.+*6?650+6..1(=-.0/+.3+56?0,)67"+

B'0+A06,34+6220//31(0/+/'6))+'6D0+ *6?650+)0D0)/+64*+*6?650+.7,0/+ 6//32(6.0*+A(.'+.'0?"

J4*(45+234*(.(34/ !" <3))+(/+6..(10*+A(.'+2)3.'0/ #" <3))+(/+6..(10*+A(.'+A06,34 $ &)3.'(45+(/+)36*0*+(4.3+/7/.0? % H06,34+(/+)36*0*+(4.3+/7/.0? M3.0/ !" B'(/+/7/.0?+'6/+43.+70.+=004+*0.6()0*+.3+.'0+0L.04.+A'010+6))+?0.'3*3)35(0/+64*+ 23?,3404./+610+:43A4+(4+/,02(>(2"

Figure 9: Use Case - Child equips doll

Hasbro Product Design Team

In order to begin gameplay, the doll’s equipment must be loaded into the battle system. The “Child equips doll” use case details the requirements of the accessory scanning mechanism, as well as the requirements of the weapons themselves. The next step in establishing gameplay is turning on and connecting the battle system to both the battle doll, as well as another user’s battle system. The 5%&&-#)101&#2),1)1#&)7" details of this use case are shown at B?'3'2(*%.?)'3'.?0 right, in Figure 10. This behavioral !" <233(,*0403,-*'0*3@+?,)*.;;" diagram details the functional #" <233(,*003,-*'0*.?*).((*5/'2*6127892786:" requirements of the battle system, $ G.((*'0*?.3*7.??,73,)*3.*1233(,*0403,-" including structural and data transfer !"#$%&'$()*+,-. /01&#2()3'--)4)5%&&-#)/01&#2 considerations. %&'()*+,-./,0*1233(,*0403,-* 56127892786:*;+.-*).((" After both the accessories and <233(,*0403,-*0&2((*1,*03.+,)*='3&*).((>0* battle system have been set up, 1.)4*'?*;.+-*.;*12789278" gameplay can begin. This behavioral %&'()*0,30*1233(,*0403,-*.?*9(24*0@+;27,A* 0.*3&23*BC*0,?0.+*'0*)'+,73,)*92+2((,(*3.* diagram references both of the ;(..+" previous use cases as a subset of <233(,*0403,-*0&2((*1,*21(,*3.*(',*;(23*.?* beginning gameplay, and is shown 9(24*0@+;27," <233(,*0403,-*0&2((*7.?32'?*'?;+2+,)* on the following page in Figure 11. 0,?0.+" This diagram details the requirements %&'()*9.=,+0*1233(,*0403,-*.?" <233(,*0403,-*0&2((*1,*9.=,+,)" of the play mode selection to be <233(,*0403,-*0&2((*'?)'723,*3.*@0,+*3&23* implemented into the battle system, 9.=,+*'0*.?" %&'()*,D3,?)0*)232*3+2?0;,+*7.+)E9(@F" as well as readings of previous win <233(,*0403,-*0&2((*&2/,*)232*3+2?0;,+* and loss record. 7.+)" G.((*0&2((*&2/,*)232*3+2?0;,+*9(@F" The next use case analyzed using <233(,*0403,-*0&2((*&2/,*)232*3+2?0;,+* a behavioral diagram is “A hit is 9(@F" made.” This behavioral diagram G232*3+2?0;,+*7.+)*0&2((*1,*23*(,203*#* ;,,3*(.?F" analyses the steps needed to make %&'()*'?0,+30*)232*3+2?0;,+*9(@F*;+.-* an impact on an opponent doll. It 1233(,*0403,-*'?3.*).((>0*1278" G232*3+2?0;,+*7.+)*0&2((*7.??,73*).((>0* defines the functionality of the 1.)4*2?)*1233(,*0403,-" control mechanism, as well as scoring %&'()*)'+,730*BC*0,?0.+*3.=2+)0*H+',?)>0* BC*0,?0.+" mechanism of the doll’s body. This behavioral diagram is shown in Figure BC*0,?0.+*0&2((*0,?)*2?)*+,7,'/,*)232*3.* 2?)*;+.-*.3&,+*1233(,*0403,-0" 12 on the next page. <233(,*0403,-*0&2((*)'09(24*03230A* The fifth use case analyzed using '?7(@)'?FI*JKA*9.=,+A*),;,?0,A*2?)* behavioral diagrams is shown in ,D9,+',?7," %&'()*,L@'90*).(("6 Figure 13, in which a hit is scored. This behavior translates the physical hit N?)'?F*7.?)'3'.?0 !" <233(,*0403,-*'0*3@+?,)*.?" received in the previous use case #" <233(,*003,-*'0*.?*9(24*0@+;27," into a score dependent on equipped $ G.((*'0*7.??,73,)*3.*1233(,*0403,-" M %&'()>0*2?)*H+',?)>0*).((0*,D7&2?F,*)232" accessories as well as the doll’s previous win/loss record. This use O.3,0 case examines requirements related !" K(,20,*0,,*1,&2/'.+2(*)'2F+2-*,?3'3(,)A*6%&'()*,L@'90*).(("6 to the gameplay algorithm which will Figure 10: Use Case - Battle system is set up convert these variables into a scoring methodology which is integrated with the battle system.

Kat Ingalls

:%2#),1),7,&,%&#. P-&*&0')$4-(&*&4-. !" E2.*13)&.)*+,-1()4>>):-4*)6471,1(= #" I.1,)7&-9'4..),184,()&.)-4*)'40(1()&-*4).2.*13" !"#$%&'$()*+,-. $%&'()*+,-.)/0**'1).2.*13)4-"

/01&#2()3'--)4)5%&&-#)/01&#2 5%1)/0**'1).2.*13).%0'')/1)6471,1("

$%&'()84--18*.)(4'')*4)0,1-0" 5%1)/0**'1).2.*13).%0'')/1)0/'1)*4),10()7&-9'4..),184,() :;1<61,&1-81;=)0>*1,)(4'')&.)0**08%1()*4)0,1-0" 5%1)/0**'1).2.*13).%0'')/1)0/'1)*4)*,0-.'0*1)1<61,&1-81) &-*4)?0316'02)0(@0-*0?1." $%&'()1A+&6.)(4''" ! 5%1)/0**'1).2.*13).%0''),1A+1.*)7%0*)6'02)34(1)&.)(1.&,1() 0>*1,)(4'')&.)1A+&6*" $%&'().1'18*.)34(1)4>)6'02 5%1)/0**'1).2.*13).%0'')%0@1)(&>>1,1-*)6'02)34(1.B)/0.1() 4-)-+3/1,)4>)6'021,.):4-1)4,)*74=)0-()1&*%1,).84,1C/0.1() 6'02B)1'&3&-0*&4-)4,)+-'&3&*1()6'02")# $%&'().1'18*.);574)D'021,)E84,1CF0.1("; 5%1)/0**'1).2.*13).%0''),1A+1.*)&-6+*)>,43)+.1,)&>).84,1C /0.1()34(1)&.)8%4.1-" 5%1)/0**'1).2.*13).%0'')/1)0/'1)*4),10()0-(),184,().84,1() 64&-*." $%&'()&-6+*.).84,1)-11(1()>4,)7&5%1)/0**'1).2.*13).%0'')0'1,*)+.1,)*4)&->4,3)*%13)*%0*) ?031)%0.)/1?+-" J-(&-?)84-(&*&4-. !" N031)6'02)34(1)&.).618&>&1(" # G&-9'4..),184,()&.)'40(1()&-*4).2.*13" H" N031)&.),10(2)*4)/1?&-" Q4*1. !" E11).160,0*1)/1%0@&4,0')(&0?,03B);$%&'()JA+&6.)O4''; #" 6-%0)2'.#1),78-9.#()E&-?'1)D'021,)I-'&3&*1(B)E&-?'1)D'021,)E84,1CF0.1(B)574)D'021,)I-'&3&*1(B)574)D'021,)E84,1C F0.1(") E84,1C/0.1()6'02)1-(.)7%1-)0)81,*0&-)-+3/1,)4>)%&*.B).1*)/2)+.1,B)&.),108%1()/2)1&*%1,)6'021,")J'&3&-0*&4-)6'02)1-(.) 7%1-)0)(4''K.)LD)&.)(&3&-&.%1()*4)M1,4):;(&1.;=")I-'&3&*1()6'02).*&'')84+-*.).84,1B)/+*)(41.-K*).*46)0>*1,)0)81,*0&-).84,1) &.),108%1("

Figure 11: Use Case - Game is initiated

6)"',7&),1)18'$#.

6)+,&),1)2%.# F2%0%)&(#,2'%0%,2+ !" E%*.(3403)104'" !"#$%&'$()*+,-. #$%&'()%*+(',&&-+(&%*.(/%0$(1,203,&(*41$)2%+*"

/01&#2()3'--)4)5%&&-#)/01&#2 5)1$(,6(',&&-+(&%*.+(78()3*+9(8(&4:+;(+$)&&(.4( *)24<=43).&4(.>(1,203,&(*41$)2%+*" #,203,&(*41$)2%+*(+$)&&(*,=4(&%*.(<?()2'( ',/2()2'(+%'4(0,(+%'4"

#$%&'(*)@4+(A?<21$A(/%0$(1,203,&(*41$)2%+*( .>(?<+$%2:(',/2"

I8636'&+J-80636-8/ !" K(/3),+6/+3=*8)0+-8" #" J&-3:)/L+9)'A-8/+'80+)@A)*6)87)+'*)+&-'0)0+683-+/(/3)," $ M',)+A&'(+,-0)+6/+/A)76>6)0" !"#$%&'$()*+,-. %&'()*+!+,-.)/+0-&&1/+&)2+3-+456754+%&'()*+#1/+ 0-&&" %&'()*+!1/+0-&&1/+&)2+,'5)/+7-83'73+963:+%&'()*+ #1/+0-&&"

;-&&+/:'&&+<)+'<&)+3-+*)26/3)*+9:)8+'+4:634+:'/+ <))8+/=77)//>=&&(+,'0)" ?:)+<'33&)+/(/3),+/:'&&+<)+'<&)+3-+3*'8/&'3)+ )@A)*6)87)+B*)7-*0C+3-+',-=83+->+D%+ *)0=7)0EA-683/+2'68)0+9:)8+:63" ?:)+<'33&)+/(/3),+/:'&&+<)+'<&)+3-+3*'8/&'3)+ '<6&636)/+B7&-3:)/C+3-+',-=83+->+D%+ *)0=7)0EA-683/+2'68)0+9:)8+:63" ?:)+<'33&)+/(/3),+/:'&&+06/A&'(+8=,<)*+->+ A-683/+/7-*)ED%+*)0=7)0+3-+A&'()*/"

#,203,&(*41$)2%+*(+$)&&(4B042'(&%*.(%2( ?<21$%2:C@%1@%2:(*,0%,2" #,203,&(*41$)2%+*(+$)&&(34D1,203)10(&%*.()6043( 4B042+%,2(%+(*)'4" #,203,&(*41$)2%+*(0%?(+$)&&(.4(&)3:4(42,<:$( 6,3(1$%&'(0,($)2'&4(4)+%&>" 52'%2:(1,2'%0%,2+ !" E%*.(4B042'4'"

Figure 12: Use Case - A hit is made

/01&#2()3'--)4)5%&&-#)/01&#2

F80682+7-80636-8/ !" G+/7-*)+:'/+<))8+,'0)" H-3)/ !" G//=,)+A-683/+,)7:'86/,+B/=7:+'/+'+<=33-8C+6/+0)>68)0" #" G//=,)+=/)*/+7'8+*)'0+'80+=80)*/3'80+8=,<)*/"

Figure 13: Use Case - A point is scored

Hasbro Product Design Team

6.5 Functional Requirements The requirements derived from the behavioral diagrams discussed in the previous section were then compiled into a list of functional requirements. The original compilation is shown below, in Figure 14.

OR.1

Originating Requirements The battle system shall be able to read codes/sensors on accessory items.

Abstract Function Name Read accessories

OR.2

The battle system shall be able to recognize attributes of accessory items.

Recognize attributes

OR.3

Convert attributes to scores

OR.4

The battle system shall be able to convert experience and accessory attributes to scores. Doll shall be able to "hold" weapons.

OR.5

Weapons shall not cause child to be cut or otherwise injured.

Be safe

OR.6

Assemble weapons

OR.7

Weapons shall have parts that can assemble into many types of weaponry. The battle system shall be powered.

OR.8

The battle system shall be able to read win/loss record.

Read win record

OR.9

Input play mode input

OR.12

The battle system shall request what play mode is desired after doll is equipped. The battle system shall have different play modes, based on number of players (one or two) and either score-based play, elimination or unlimited play. The battle system shall request input from user if score-based mode is chosen. The battle system shall be able to read and record scored points.

OR.13 OR.14

The battle system shall alert user to inform them that game has begun. Doll shall be able to register when a "hit" has been successfully made.

OR.15

The battle system shall display number of points score/HP reduced to players.

OR.10

OR.11

Hold weapons

Power on

Contain play mode options

Input score Determine scores Alert game begin Receive hit Display score

Figure 14: Originating Requirements (initial)

The originating requirements were later expanded, and continued to do so throughout the system’s development. As the system became more defined, more functional requirements arose and were added to the list of originating requirements. For instance, many new originating requirements were added while developing subsystem categories. A system to update and make revisions to these requirements is discussed in Section 7. A finalized list of the originating requirements developed during the first half of the project is given in Figure 15 on the following page.

Kat Ingalls

Figure 15: Originating Requirements (final) Index OR.1 OR.2 OR.3 OR.4 OR.5 OR.6 OR.7 OR.8 OR.9 OR.10 OR.11

Dolls shall be of uniform size (so that all clothing manufactured for it will fit). The battle system shall be able to recognize accessory items. The battle system shall be able to recognize attributes of clothing accessory items. The battle system shall be able to convert clothing attributes to gameplay. Doll shall be able to "hold" weapons. The battle system shall be able to read codes/sensors on weapon accessory items. The battle system shall be able to recognize attributes of weapon accessory items. The battle system shall be able to convert damage attributes to gameplay. Weapons shall not cause child to be cut or otherwise injured. Weapons shall have parts that can assemble into many types of weaponry. Weapons shall be able to be recognized by battle system.

Abstract Name Uniform size Read clothing Read clothing attributes Clothing to Play Hold weapons Read weapons Read weapon attributes Weapons to Play Safety Weapon Assembly Readable weapons

OR.12

Accessories weapons shall have impact on gameplay.

Weapons damage

OR.13

The clothing accessories shall be able to be recognized by battle system.

Readable clothing

OR.14

Accessories clothing shall have impact on gameplay.

OR.15

The battle system shall be powered.

OR.16

The battle system shall be able to read win/loss record ("experience") after doll is attached to arena.

OR.17 OR.18 OR.19 OR.20 OR.21 OR.22 OR.23 OR.24

OR.25 OR.26

Originating Requirement

The battle system shall be able to translate experience into gameplay advantages. The battle system shall request what play mode is desired after doll is equipt. The battle system shall have different play modes, based on number of players (one or two) and either scorebased play, elimination or unlimited play. 2 The battle system shall request input from user if scorebased mode is chosen. The battle system shall be able to read and record scored points. The battle system shall alert user to inform them that game has begun. Doll shall be able to register when a "hit" has been successfully made. The battle system shall be able to translate experience (record) to amount of HP reduced/points gained when hit. The battle system shall be able to translate abilities (clothes) to amount of HP reduced/points gained when hit. The battle system shall display number of points score/HP reduced to players.

Hasbro Product Design Team

Weapons abilities Power Read Experience Experience to Play Play mode request Play mode options Score input Keep score Game begine alert Sense hit Experience to Play

Clothing to Play Points Display

OR.27

Battle system shall be stored with doll's body in form of backpack.

OR.28

Battle system shall be able to lie flat on play surface.

OR.29

Battle system shall be able to communicate with other battle systems.

OR.30

Battle system shall indicate to user that power is on.

OR.31

Battle system shall have data transfer cord.

OR.32

Doll shall have data transfer plug.

OR.33

Battle system shall have data transfer plug.

OR.34

Data transfer cord shall be at least 2 feet long.

OR.35 OR.36 OR.37 OR.38 OR.39 OR.40 OR.41 OR.42 OR.43

Doll's body shall be able to communicate with battle system. IR sensor shall send and receive data to and from other battle systems. Battle system shall display stats, including: HP, power, defense, and experience. Doll's limbs shall be able maneuverable (to make motion to "hit.") Control mechanism shall move limb up and down and side to side. Control mechanism shall extend limb in punching/kicking motion. Control mechanism shall re-contract limb after extension is made. Control mechanism tip shall be large enough for child to handle easily. Doll shall be fixed in space during battle gameplay for fairness.

Backpack Play Surface Communication Sensor Power Indicator Communication Cord Doll plug System plug Communication cord length Communication Cord connection Sensor Send and Receive Display stats Move limbs Transversal motion Extension motion Un-extend motion Control handle size Fairness

Kat Ingalls

7 Draft Prototype Development This section examines the potential mechanisms by which the requirement discussed in the previous section could be realized. These generated implementation options are used to define the subsystem organization of the project. Finally, using the knowledge gained through the application of these methods, a draft prototype is created to examine the physicality and explore the key functional mechanisms of the Battle Doll system.

7.1 Concept Fragment Generation For each of the originating requirements detailed in the section above, possible solutions for how the requirements might be met were generated. !"#$"%&%'

!"##

$%&'()

!"##

$%&'()

*+##,

-(./"0&

(%)&*+,

1234

1235

1236

1237

1238

1239

123:

123;

123<

1234=

12344

5"667+78166+9&+":+ A8&+91''6&+7B7'&#+ A8&+91''6&+7B7'&#+ 4%/:".#+7/;&+<7"+'81'+ 78166+9&+196&+'"+.&1)+ 78166+9&+196&+'"+ 166+=6"'8/%0+ =")&7C7&%7".7+"%+ .&="0%/;&+1''./94'&7+ #1%4:1='4.&)+:".+/'+ =6"'8/%0+1==&77".B+ ":+=6"'8/%0+1==&77".B+ >/66+:/'?@ /'&#7@ /'&#7@

-./0/%1'/%0+ 2&34/.&#&%'

H97'.1='+I1#&

J%/:".#+7/;&

2&1)+=6"'8/%0

$).##>*?"##%>?"@A(', 2BC! P(GEM)>*Q.JNE(, I.&(J>$@.00(J !"%=&$'+Z.10#&%'7 I.JH(>*+)(JE@.0>UEJ#, F"G(>J(.G(J C0OJ.J(G Q#M('""'D

2&1)+=6"'8/%0+ 1''./94'&7 2BC!>@DE/ Q.J@"G( F"G( C2WJ(.G.N#(>@DE/

A8&+91''6&+7B7'&#+ 78166+9&+196&+'"+ ="%D&.'+=6"'8/%0+ 1''./94'&7+'"+ 01#&$61B@+ !"'8/%0+'"+K61B *F"GE0H, P"J(>R?& +GGE'E"0.#>/"E0'& V+NE#E'E(&V UJ(.'(J>!(O(0@(

-(./"0&>G.).H( F#"'DE0H F#"'DE0H $%&'()Y!"## 12345 12346 12347 12348 A8&+>&1$"%+ A8&+=6"'8/%0+ A8&+=6"'8/%0+ 1==&77"./&7+78166+ 1==&77"./&7+78166+9&+ 1==&77"./&7+78166+ -./0/%1'/%0+ 81D&+)1#10&+6&D&67+ A8&+91''6&+7B7'&#+ 196&+'"+9&+ 81D&+LK7+1%)+ 1%)+)1#10&+'B$&7+ 78166+9&+$">&.&)@ 2&34/.&#&%' .&="0%/;&)+9B+91''6&+ 19/6/'/&7+177"=/1'&)+ 177"=/1'&)+>/'8+ 7B7'&#@ >/'8+'8&#@ '8&#@ F&1$"%7+)1#10& 2&1)196&+=6"'8/%0 !6"'8/%0+19/6/'/&7 K">&. H97'.1='+I1#& *$.)(>.&>123;, *$.)(>.&>1235, *$.)(>.&>1237, ?#MHWE0 Q.''(JE(& !"%=&$'+Z.10#&%'7 $"#.J RM).0W/"T(J(GZ

!"#$"%&%' (%)&*+,

!"## 12356

!"#$"%&%' (%)&*+,

$%&'() 12357

$%&'() 12358

$%&'() 12359

A8&+91''6&+7B7'&#+ A8&+91''6&+7B7'&#+ 78166+9&+196&+'"+.&1)+ 78166+9&+196&+'"+ 5"66+78166+9&+196&+'"+ =")&7C7&%7".7+"%+ .&="0%/;&+1''./94'&7+ E8"6)E+>&1$"%7@+ >&1$"%+1==&77".B+ ":+>&1$"%+1==&77".B+ /'&#7@ /'&#7@ L"6)+>&1$"%7 I.'@D>"0'">D.0G $"@A('>S>&0./ I.'@D>"0'">.J)

2&1)+>&1$"%7 *&.)(>.&>1235,

H97'.1='+I1#&

M&%7&+8/'

QM''"0 ?J(&&MJ(W&(0&E'E](> ?J(&&MJ(>&(0&"J !"%=&$'+Z.10#&%'7 F"0GM@'E]E'%>

$%&'() 1234:

$%&'()Y!"## 12368

!6"'8/%0+'"+K61B *$.)(>.&>WW,

K"/%'7+5/7$61B 10>!"## 10>&%&'()>&@J((0 `(JN.#>

$%&'()>S>!"## 12369

$%&'() 1236:

$%&'() 1234;

A8&+91''6&+7B7'&#+ A8&+91''6&+7B7'&#+ 78166+9&+196&+'"+ 78166+.&34&7'+>81'+ '.1%761'&+&*$&./&%=&+ $61B+#")&+/7+)&7/.&)+ /%'"+01#&$61B+ 1:'&.+)"66+/7+&34/$'@ 1)D1%'10&7@ R*$&./&%=&+'"+K61B UJ(.'(J>G(O(0@( UJ(.'(J>"OO(0@( V2(T.JG&V>O"J>TE0>

$%&'()Y!"## 1235:

$%&'() 1235;

M'".10&

K61B+M4.:1=&

Q.@AN.@A>O"J)>O.@'"J LY+ ?MJ&( +&>G"##a&>/('

$%&'() !"## 1236; 1236< U1''6&+7B7'&#+78166+ 51'1+'.1%7:&.+=".)+ (2+7&%7".+78166+7&%)+ R1=8+":+)"66V7+6/#97+ U1''6&+7B7'&#+78166+ 51'1+'.1%7:&.+=".)+ )/7$61B+7'1'7O+ -./0/%1'/%0+ 78166+="%%&='+)"66V7+ 1%)+.&=&/D&+)1'1+'"+ <Q+1.#7O+Q+6&07?+78166+ 81D&+)1'1+'.1%7:&.+ 78166+9&+1'+6&17'+Q+ /%=64)/%0W+LKO+$">&.O+ 9")B+1%)+91''6&+ 1%)+:."#+"'8&.+ 9&+#1%&4D&.196&+9B+ 2&34/.&#&%' $640@ :&&'+6"%0@ )&:&%7&O+1%)+ 7B7'&#@ 91''6&+7B7'&#7@ ="%'."6+#&=81%/7#@ &*$&./&%=&@ !"##4%/=1'/"%+=".)+ !"##4%/=1'/"%+!".)+ M&%7".+M&%)+1%)+ H97'.1='+I1#& MB7'&#+$640 5/7$61B+7'1'7 Y"D&+6/#97 6&%0'8 ="%%&='/"% 2&=&/D& ?#MH>@"JJ(&/"0GE0H> LY+ ?D%&E@.#>@"JG $('>"0>HJ"M0G>E0> Q.&E@>IF!>GE&/#.% $E0H#(>c"%&'E@A -EJ(#(&&>"/'E"0>*ddd, -EJ(#(&&>@"00(@'E"0 ?D%&E@.#>@"00(@'E"0b `"E@(>.00"M0@()(0' e"%&'E@A>O"J>(.@D>#E)N ?"GEM)>"J>&'.0G F"#"J>@"G(G>GE&/#.%> $'JE0H&YJ(E0& !"%=&$'+Z.10#&%'7 QM''"0 e"%&'E@A>S>NM''"0

!"#$"%&%' (%)&*+,

$%&%() 12367

R*$&./&%=&+'"+K61B *$.)(>.&>1234:,

F&1$"%7+'"+K61B *F"GE0H, P"J(>!.).H( V+NE#E'E(&V

M1:&'B

F&1$"%+H77&#96BNN

$D.J/>(GH(&K> LM)N(J>"O>/.J'& $).##>/.J'&K>$).##(&'> R"T>'">@"00(@'

2&1)196&+>&1$"%7 *$.)(>.&>1235,

XX>-.0'>'">GE'@D>'DE&> $%&'() 12349 A8&+91''6&+7B7'&#+ 78166+9&+196&+'"+.&1)+ >/%C6"77+.&=".)+ <E&*$&./&%=&E?+1:'&.+ )"66+/7+1''1=8&)+'"+ 1.&%1@ 2&1)+R*$&./&%=& F"JG FDE/ $).J'>@.JG F"G( C0'(J0('>@0^0

A8&+91''6&+7B7'&#+78166+ A8&+91''6&+7B7'&#+78166+ 5"66+78166+9&+196&+'"+ 9&+196&+'"+'.1%761'&+ 9&+196&+'"+'.1%761'&+ A8&+91''6&+7B7'&#+ U1''6&+7B7'&#+78166+ U1''6&+7B7'&#+78166+ .&0/7'&.+>8&%+1+E8/'E+ &*$&./&%=&+<.&=".)?+'"+ 19/6/'/&7+<=6"'8&7?+'"+ 78166+)/7$61B+%4#9&.+ 9&+7'".&)+>/'8+)"66V7+ 9&+196&+'"+6/&+:61'+"%+ 817+9&&%+74==&77:466B+ 1#"4%'+":+LK+ 1#"4%'+":+LK+ ":+$"/%'7+7=".&CLK+ 9")B@ $61B+74.:1=&@ #1)&@ .&)4=&)C$"/%'7+01/%&)+ .&)4=&)C$"/%'7+01/%&)+ .&)4=&)+'"+$61B&.7@ >8&%+8/'@ >8&%+8/'@

-./0/%1'/%0+ 2&34/.&#&%'

2&1)+>&1$"%+ 1''./94'&7 *$.)(>.&>1236,

A8&+91''6&+7B7'&#+ F&1$"%7+78166+81D&+ F&1$"%7+78166+9&+ 78166+9&+196&+'"+ F&1$"%7+78166+%"'+ $1.'7+'81'+=1%+ 196&+'"+9&+ ="%D&.'+)1#10&+ =147&+=8/6)+'"+9&+=4'+ 177&#96&+/%'"+#1%B+ .&="0%/;&)+9B+91''6&+ 1''./94'&7+'"+ ".+"'8&.>/7&+/%G4.&)@ 'B$&7+":+>&1$"%.B@ 7B7'&#@ 01#&$61B@+

K61B+#")&+.&34&7' !(GE@.'(G>NM''"0 $@J"##>.0G>&(#(@'

$%&'() 1235< U1''6&+7B7'&#+78166+ ="%'1/%+/%:.1.&)+ 7&%7".@ !"##4%/=1'/"%+ M&%7". *C2>&(0&"J,

$%&'() 1234< A8&+91''6&+7B7'&#+78166+ 81D&+)/::&.&%'+$61B+ #")&7O+917&)+"%+%4#9&.+ ":+$61B&.7+<"%&+".+'>"?+ 1%)+&/'8&.+7=".&P917&)+ $61BO+&6/#/%1'/"%+".+ 4%6/#/'&)+$61B@+ Q

$%&'()Y!"## 1236=

A.1%7D&.716+#"'/"%

$%&'() 12364

U1''6&+7B7'&#+78166+ U1''6&+7B7'&#+78166+ /%)/=1'&+'"+47&.+'81'+ 9&+$">&.&)@ $">&.+/7+"%@

K">&.+M"4.=& !M/#E@.'(Z>!(#('(3>

!"## 12374

$%&'() 12354

A8&+91''6&+7B7'&#+ A8&+91''6&+7B7'&#+ 78166+.&34&7'+/%$4'+ 78166+9&+196&+'"+.&1)+ :."#+47&.+/:+7=".&P 1%)+.&=".)+7=".&)+ 917&)+#")&+/7+ $"/%'7@ =8"7&%@

K61B+#")&+"$'/"%7 M=".&+/%$4' $E0H#(>?#.%(J> LM)N(J>/.G $E0H#(>?#.%(J>$@"J(W $@J"##>.0G>&(#(@' [T">?#.%(J>\0#E)E'(G> [T">?#.%(J>$@"J(W [E)(WN.&(GYJ.@(

!"## 1237= !"%'."6+#&=81%/7#+ 78166+#"D&+6/#9+4$+ 1%)+)">%+1%)+7/)&+ '"+7/)&@

$%&'() 1235=

K">&.+(%)/=1'".

S&&$+7=".& *.#H"JE'D),

R*'&%7/"%+#"'/"%

A8&+91''6&+7B7'&#+ 78166+16&.'+47&.+'"+ /%:".#+'8&#+'81'+ 01#&+817+9&04%@ T1#&+9&0/%+16&.' Q((/ VQ.''#(V>0"E&(>*RE%.Z, +00"M0@(J>]"E@( IEHD'

$%&'()Y!"## 12365

!"##>/#MH 12366

U1''6&+7B7'&#+78166+ 81D&+)1'1+'.1%7:&.+ =".)@

5"66+78166+81D&+)1'1+ '.1%7:&.+$640@

!"##4%/=1'/"%+!".)

5"66+$640

IEHD' +#&">TEJ(#(&&>"/'E"0_> \$Q Q.@A#E'>&@J((0 PE0EW+ V10V>0"E&( PE0EWQ [MJ0>!E&/#.%>"0 1'D(JY@M&'") *D.](>@"0&'.0'#%>"0b,

!"## 12375

!"## 12376

!"%'."6+#&=81%/7#+ !"%'."6+#&=81%/7#+ !"%'."6+#&=81%/7#+ 78166+&*'&%)+6/#9+/%+ 78166+.&P="%'.1='+6/#9+ '/$+78166+9&+61.0&+ $4%=8/%0CX/=X/%0+ 1:'&.+&*'&%7/"%+/7+ &%"408+:".+=8/6)+'"+ #"'/"%@ #1)&@ 81%)6&+&17/6B@

$#EG(J>)(@D.0E&)>O"J> ?M&D e"%&'E@A>O"J>(.@D>#E)N ?M## $E0H#(>c"%&'E@A>O"J>.##> [TE&'

$%&'()Y!"## 12355

J%P&*'&%)+#"'/"% $/JE0H 2MNN(J>N.0G ?M##>"0>)(@D.0E&)

!"%'."6+81%)6&+7/;& Q.##Y&/D(J(>&D./( $'E@A !EJ(@'E"0.#>/.G QM''"0&

$'.0G 12377 T1#&$61B+78166+9&+ E:1/.@E

EZ1/.%&77E $'.0G>'">D"#G>G"## Q.&(>'">.''.@D>'">G"## 10#%>M&(>.J)&_>.''.@D> 10#%>M&(>#(H&_>.''.@D> +''.@D>"0(>#(H_>AE@A> $'.0GK>R"#G>M0G(J> $'.0GK>R"#G>.'>T.E&'

Figure 16: Concept fragments, first pass

This tool enabled all potential options to be communicated and explored. It is a method by which ideas for possible concepts are documented in order to communicate that the problem of meeting a given requirement has been explored thoroughly.

Hasbro Product Design Team

7.2 Prune and Expansion with Notes For the concept fragments discussed above, the fragments with requirements surrounding the core functionality of the project were detailed further. Options for the implementation of the requirement were added to the original concepts. During this phase, ideas that were not feasible were encouraged to be recorded so that the idea was acknowledged and documented. After expanding on the concept fragments for the core functionality of the overall system, those that were deemed unfeasible were crossed off. A note including the justification for the elimination was added, for clarification and future reference. The pruning and expansion matrix is listed below, in Figure 17. For a larger view, please see Appendix. !"#$%& '%()*+#,-(&(.% /0*$12+. !"#$%&,3,4*00 4*00 5678 56798 5679: 567;< 567;= 56&+71''8&+9:9'&#+96188+7&+ >"88?9+7"):+96188+7&+178&+'"+ >"88?9+8/#79+96188+7&+178&+ H;;&99"./&9+B@&1$"%9+1%)+;8"'6/%0E+96188+61A&+/#$1;'+"%+ -./0/%1'/%0+2&34/.&#&%' 178&+'"+.&;"0%/<&+1;;&99".:+ ;"##4%/;1'&+@/'6+71''8&+ #1%&4A&.178&+B'"+#1C&+ 01#&$81:= /'&#9= 9:9'&#= #"'/"%+'"+D6/'=DE !"##4%/;1'/"%+!".)+ H79'.1;'+I1#& 2&1)+1;;&99"./&9 J&1$"%9+)1#10& !8"'6/%0+17/8/'/&9 K"A&+8/#79 ;"%%&;'/"% 6?@4 @+AB%(#%,4(&(.% @+AB%(#%,4(&(.% @6 !2+.0%,C*"#$2AD !"%;&$'+L.10#&%'9

!"#$"%&%' (%)&*+,

I"'&9

I(#%B,!A(++%B

@+AB%(#%,4%J%+#%

M+$%B,(,A*-%

NL202$2%#,OP(.2AQ,!G)%BQ,!$%(0R NL202$2%#,OP(.2AQ,!G)%BQ,!$%(0R F0G%$**$1

@+AB%(#%,4%J%+#%

'2,?2

!$(+!"#$%& 4*00 567>> 5678= 5678; >"88+96188+7&+F/*&)+/%+9$1;&+ G1''8&+9:9'&#+96188+7&+178&+ >"88+96188+7&+178&+'"+.&0/9'&.+ )4./%0+71''8&+01#&$81:+F".+ '"+;"##4%/;1'&+@/'6+"'6&.+ @6&%+1+D6/'D+619+7&&%+ F1/.%&99= 71''8&+9:9'&#9= 94;;&99F488:+#1)&= DL1/.%&99D

!"##4%/;1'/"%+M&%9".

M&%9&+6/'

E#%,(,#$(+-

FG$$*+H,/0*$1%#

K*"#$2AD,J*B,%(A1,02&L

E#%,(,#$B()

'2,?2

!$B2+.#SB%2+#

E#%,*+0",(B&#Q,($$(A1,0%.#

F0G%$**$1

FG$$*+H,F*-",($,A*+$(A$, )*2+$# FG$$*+H,2+,J2#$#SJ%%$

@+JB(B%-

/*B-

FG$$*+O#R

5+0",G#%,0%.#Q,($$(A1,(B&#

/*-%T$*T/*++%A$

UB%##GB%T#%+#2$2V%,&($%B2(0

F0G%$**$1

U0G.

K*"#$2AD,3,LG$$*+

/*B-

UB%##GB%,#%+#*B

@+$%.B($%-S@+,-*00

X(+-,/*+$B*0,OP(+G(0R

N$$(A1,*+%,0%.Q,D2AD,W2$1, *$1%B,O)2V*$,)*2+$R

U0G.

/*+-GA$2V2$",L%$W%%+,-*00#

I"'&9N !$B(),B%&*V%-,LSA,02&2$%-, )0(",(B%(#,W12A1,$*,($$(A1

I"'&9N I"'&9N '2J2,(+-,F0G%$**$1,B%&*V%-, FG$$*+,2+,A0*$1%#,B%&*V%-, LSA,A*#$,)B*12L2$2V% LSA,2+$B*-GA%#,G++%AA(B", B%)%($%-,A*#$

I"'&9N I(#%B,B%&*V%-,LSA,A*#$ F0G%$**$1,B%&*V%,LSA,A*#$

I"'&9N 6(A1%$,P%A1(+2#& '2J2,(+-,F0G%$**$1,B%&*V%-, !W2$A1,P%A1(+2#& LSA,A*#$,)B*12L2$2V% I%.,U2V*$ 42B%A$2*+(0,U(-

UB%##GB%,#%+#2$2V2$",B%&*V%-, LSA,A*#$,2+$%+#2V%

I"'&9N 6%2+#,B%&*V%-,LSA,-GB(L202$", 2##G%#

/*+-GA$2V2$",B%&*V%-,LSA, B2#D,*J,%0%A$B*AG$2*+

P(+G(0,A*+$B*0,B%&*V%-,LSA, $**,AG&L%B#*&%

Figure 17: Documenting the addition and elimination of concept fragments

7.3 Decision Matrix In order to determine the best option for the control mechanism to be prototyped, a decision matrix was used, evaluating the four concept fragments generated for OR.39: Move Limbs. The concepts were evaluated on the customer attributes listed below in Figure 18. Each concept was rated on the attributes listed below on a scale of 1 to 3, with 1 being the worst performing 3 being the best. The attributed “technologically complicated” and “cost of materials” are reversed scored in order to account for their negative connotations, comparative to the other attributes. The attributes themselves were then weighted according to importance, with 1 being of little consideration and 3 being of significant importance. These ratings are based on the customer affinity process, whose weighting process is discussed in more detail in Section 8.2. In order to determine the weighted rating, the score for the concept is multiplied by the weight of the attribute. Then, both the unweighted and weighted scores for all attributes are totaled for each concept. Figure 18 shows that the button concept fragment was the winning option, with a single joystick being the second best option. The results of this decision matrix were taken into consideration during the draft prototyping process, discussed in Section 7.6.

Kat Ingalls

Joystick for Each Limb

Rating

Weighted Rating

Rating

Weighted Rating

Rating

Weighted Rating

Joystick + Button

Weighted Rating

Buttons

Rating

Attribute Weight

Single Joystick

Cost of materials (reverse scored)

Ease of Use

Technologically complicated (reverse scored)

Safety

Durability

Attribute

TOTAL

Figure 18: Decision Matrix - Limb movement concept fragments

7.4 Originating Requirements Issue Resolution With the investigation inherent in concept fragment generation, the originating requirements generated previously were revisited for validity. In order to track changes in the originating requirements, a matrix tracing requirement resolution matrix was created, shown in Figure 19. !"#$% !"#$ !"#8$ !"#8= !"#$@ !"#FG !"#F@

!"#==

&'()("*+("),-$./('$0$"+ %&'()*++,'(-.-+'/(-&*,,()'(*),'(+0(1'*2(302'-4-'5-01-( 05(3,0+&657(*33'--01.(6+'/-# %&'(9'*:05(*33'--016'-(-&*,,(&*;'(2*/*7'(,';',-(*52( 2*/*7'(+.:'-(*--036*+'2(96+&(+&'/# %&'(3,0+&657(*33'--016'-(-&*,,(&*;'(>?-(*52(*)6,6+6'-( *--036*+'2(96+&(+&'/# A*++,'(-.-+'/(-&*,,(305+*65(65B1*1'2(-'5-01#

123+'*4+,5*0$

!""#$ -$367/+(6" !"#$%&'%(')"*&+,-'*.)"*&/'01"2+(+"&'33' 89$,2*++7$,3:3+$0,39*77,2$,*27$,+6, ."*4"')%%5'(%)'+,,%4*#+%,6 '$46)"(;$,*44$336':,(+$03< 7*5"1.*/'+51*2#'+0'*.)"*&/'01"2+(+"&'3' 144$336'($3,=$*>6"3,39*77,9*?$,(0>*4+,6", <'*:05-(2*/*7' ."*4"')%%5'(%)'+,,%4*#+%,6 )*0$>7*:< 7*5"1.*/'+51*2#'+0'*.)"*&/'01"2+(+"&'3' 144$336'($3,476+9("),39*77,9*?$,(0>*4+,6", <'*:05-(*)6,6+6'."*4"')%%5'(%)'+,,%4*#+%,6 )*0$>7*:< !"#$%&'%('2%558,+2*#+%,'+0'*.)"*&/' @*++7$,3:3+$0,39*77,2$,*27$,+6, C0//D563*+605(E'5-01 01"2+(+"&6 4600/"(4*+$,=(+9,6+9$',2*++7$,3:3+$03< H*+*(+1*5-B'1(3012(-&*,,(3055'3+(20,,I-()02.(*52()*++,'( 9:%)&9'0%.8#+%,'0$%8.&',%#'/"#';"' A677B3,26#:,39*77,2$,*27$,+6,4600/"(4*+$, C0//D563*+605(C012(3055'3+605 -.-+'/# 01"2+(+"&6 =(+9,2*++7$,3:3+$0< J*3&(0B(20,,I-(,6/)-(K$(*1/-L($(,'7-M(-&*,,()'( <%#'*..'='.+5;0',"2"00*)+./'>+..';"' A677B3,7(023,39*77,2$,*27$,0*"$/?$'*27$,C+6, N0;'(,6/)/*5'D;'1*),'().(305+10,(/'3&*56-/# 5%4+,-?'%)',""&'#%'5%4"'@0""'AB6==C 0*D$,06+(6",+6,E9(+<EF O*/':,*.(-&*,,()'(PB*61#P D*+),"00'+0',%#'01"2+(+"&6'E%>'2*,' -*5"1.*/';"'5*&"'9(*+)F9'G$"'+008"' A677,39*77,2$,G(%$#,(",3>*4$,#/'("),2*++7$, Q*615'->*0'>+#$'5%4+,-'#$"'&%..'*>*/'>$",' )*0$>7*:,G6',G*('"$33< *'$+#'>*0'*;%8#'#%';"'5*&"?'0%' (*+),"00';*0"&'%,'.%2*#+%,6 "'*2(3,0+&657

Figure 19: Requirements issue resolution matrix

Most of the problems encountered with the originating requirements result from unnecessary specificity in the requirement statement. For instance, OR.39 states that 2 arms and 2 legs shall be maneuverable; in order to leave room for innovation, this statement was changed such that the requirement was simply “dolls limbs shall be maneuverable.” This innovation space was an important consideration throughout the design process. The systems engineering process aims to create as much structure as necessary to define and organize the solution of a problem, without specifying the details of how it may be fixed. That expertise often lies in other fields of engineering. It is important that the insight and problem solving capabilities provided by other fields not be hindered.

Hasbro Product Design Team

7.5 Subsystem Development The concept fragments generated for the requirements defining the key functionality of the battle doll system were compiled. After collecting these, they were organized into groups of similar functionality. These groups of similar functionality were labeled constituted the subsystem organization of the battle doll. The first pass of subsystem organization is shown in Figure 20 below.

Figure 20: Subsystem development - core functionality Accessory Recognition System

Accessory Gameply System

Scoring Communication System

!"#$%&''(#$)*)'#+$)"&(($%#$&%(#$',$ 4..#)),-1#)$56#&7,0)$&08$ -#.,/012#$&..#)),-*$1'#+)3 .(,'"10/9$)"&(($"&:#$1+7&.'$,0$ /&+#7(&*3 !"#$ #%&'()*(+$),)-(

;,((<)$%,8*$)"&(($%#$&%(#$',$ .,++=01.&'#$61'"$%&''(#$)*)'#+3

.)*('+/&)%%(' >%5('+)+&6;( #%0')'(; 394(5665:

12+"2 394(5665: 86'; J94#%5(-')5(;H#%+;699 @&''(#$)*)'#+$)"&(($%#$&%(#$',$ .,++=01.&'#$61'"$,'"#-$%&''(#$ )*)'#+)3 #!

#%&'()*(+$(0(%*( ?@29252(*+AB)-2&C+/4<('C+/5()9D G'()5('+$(0(%&(

12+"2 394(5665: 86;(K56K86%%(&5+A:6MND 86'; J94-

Scoring System Point Acquisition System ;,(($)"&(($%#$&%(#$',$-#/1)'#-$ 6"#0$&$>"1'>$"&)$%##0$ )=..#))?=((*$+&8#3 34556%7+8965:(* /(%*(+:25 34556%7+2%+02*5*H0((5 J'(**4'(K*(%*252I(+,)5('2)9 J'(**4'(+*(%*6' 86%;4&52I25=+@(5M((%+;699*

(Scoring System) @&''(#$)*)'#+$)"&(($81)7(&*$)'&')A$ 10.(=810/B$CDA$7,6#-A$8#?#0)#A$ &08$#E7#-1#0.#3 3)*2&+.8$+;2*<9)= E6&)92F)526% ?;I)%&(;+.8$+;2*<9)= L%+$699 L%+*=*5(,+*&'((%

E('@)9+)%%64%&(,(%5 !"#$).,-10/$)*)'#+$)"&(($%#$&%(#$ ',$-#&8$610F(,))$-#.,-8$ 5>#E7#-1#0.#>9$6"#0$&''&."#8$',$ 8,((3 86'; 8:2< /,)'5+&)'; 86;( #%5('%(5+&%O% !"#$%&''(#$)*)'#+$)"&(($"&:#$ 81??#-#0'$7(&*$+,8#)A$%&)#8$,0$ 0=+%#-$,?$7(&*#-)$5,0#$,-$'6,9$ &08$#1'"#-$).,-#G%&)#8$7(&*A$ #(1+10&'1,0$,-$=0(1+1'#8$7(&*3$H /2%-9(+J9)=('+P%92,25(; /2%-9(+J9)=('+/&6'(K3)*(; QM6+J9)=('+P%92,25(;+ QM6+J9)=('+/&6'(K3)*(; Q2,(K@)*(;H')&( !"#$%&''(#$)*)'#+$)"&(($-#I=#)'$ 6"&'$7(&*$+,8#$1)$8#)1-#8$&?'#-$ 8,(($1)$#I=17'3 $(;2&)5(;+@4556% /&'699+)%;+*(9(&5

This organization focuses exclusively on the originating requirements which define the core functionality of the system. These subsystems were further expanded and refined into additional categories as all originating requirements were considered. In this revision, the functionality of the entire system is considered. The outcome is shown in Figure 21 on the following page. The requirements representing the core functionality of the total system are indicated in bold. A summary of the final subsystem organization is shown in Figure 22.

Kat Ingalls

Figure 22: Subsystem development (final)

FORM FACTOR SYSTEM

PHYSCIAL FORM

POWER SYSTEM

POWER SYSTEM FAIRNESS SYSTEM DATA ACQUISITION SYSTEM

SCORING SYSTEM

DATA TRANSFORMATION SYSTEM USER INTERFACE SYSTEM

Doll's Form System Battle Device Form System Accessories Form System Power System Fairness Assurance System Accessory Scanning System Skill Level Acquisition System Gameplay Algorithm Data Transfer Hardware System Scoring Input System Information Display System Scoring Control Mechanism System Play Modes

Figure 21: Summary of final subsystem organization

Hasbro Product Design Team

7.6 Draft prototype summary and knowledge gain Informed by the tools discussed above in this section, a draft prototype was created. The objective of this exercise was to prototype a subsystem in order to get a sense for the physicality of the system, and how it would work. Additionally, the draft prototype’s purpose to test some of the assumptions that had been developed and built upon. Because the Battle Doll concept relies so heavily on digital components, it was not feasible to prototype the electronic components of the system. Focus was given, instead, to a rudimentary exploration the movement mechanism as well as the form of the doll and battle system were draft prototyped.

Battle doll and battle system form In order to explore the form factor system, the doll and battle system were prototyped. In order to get a “feel” for the size and shape of the doll, a Barbie doll with movable joints was obtained and used as the figurine prototype. Although the prototype was commercially produced, it mimicked the conceptualized doll form well enough to be used in the draft prototyping stage. To get a feel for the mechanical structure of the battle system to be used, as well as its interactions with the battle doll, a form was modeled out of sculpting clay. The results are shown below in Figure 23.

Figure 23: Draft prototype of battle system and doll forms

Kat Ingalls

Scoring Control Mechanism In order to explore the feasibility and functionality of the control mechanism, which is the method by which the doll’s limbs are extended in order to make a hit, a very simple apparatus exploration was developed. In order to have a means by which to study the motion of a limb, attempts were made to disassemble the doll’s arm. However, it was discovered that the arm was made of solid plastic, and fixed at a point within the doll’s chest. Because a hollow form was needed to implement the idea under consideration, two pieces of paper were cut, rolled, and taped in order to model hollow “arm” pieces. These were attached using thread, which mimics a hinge which would be used to connect the upper and lower arm components. The resulting device is shown below in Figure 24.

Figure 24: Prototyped arm mechanism

Using this rudimentary form, two mechanism concepts were explored. The first mechanism explores a push-button type interface. A rod, modeled by a pencil, moves between the upper and lower arm, as shown in Figure 25.

Figure 25: Rod extension prototype

Hasbro Product Design Team

The second extension mechanism explored was an elastic pulling method. This was modeled using a rubber band placed within the hollow arm form, secured at the end by a needle at the wrist which modeled a cross-rod structure. This is shown in Figure 26 below.

Figure 26: Elastic extension prototype

The extension is achieved by pulling on the rubber band near the shoulder (see Figure 27), which transforms a limp limb to a taut, extended limb.

Figure 27: Demonstration of elastic extension mechanism prototype

Kat Ingalls

Conclusions The purpose of prototyping these subsystems was largely to determine what unknown problems existed and test the assumptions that had been made in the concept development un until this point in the design process. Knowledge gained from this draft prototyping stage included better understanding of both the structural and mechanical needs of the physical form and control mechanism subsystems. With respect to the control mechanism, both methods prototyped are very straightforward and not technically complicated. However, the elastic extension mechanism raised concerns as to the level of durability. To address this, in future improvements, thin cables could be used to pull the arm rather than a rubber band, which is more prone to breakage. The benefits of the elastic prototype are that the ends of the cables could easily be fasted to a one joystick for control of all limbs (see Figure 22). As shown in Section 7.3, this has many benefits. For the rod extension mechanism, the durability concern was with respect to the interface with the user: Would buttons be able to be used to survive the amount of force subjected to them during gameplay? Another issue brought to the surface in prototyping was how the rod mechanism would be contracted back after extension. A spring could be used, but this increases the complexity of the Figure 28: The end of the cable could easily be attached mechanism. to a joystick to control all limbs. In regards to the doll form, it was determined that the size of the doll is well-suited to implementing the control mechanism. It is not so small as to be difficult to integrate the actuation mechanisms, and is not so large to be considered cumbersome to carry. By playing with the doll, it was discovered that the jointed legs did not add much functionality to play; rather, it made it more difficult for the doll to stand on its own. As a result, it was decided that in the final prototype, the legs will probably be a single piece, rather than a jointed part. The most significant revelation was how difficult it was to move the doll’s limbs while holding her upright. It was decided that a stand to hold the doll would be needed to free the user’s hands to operate the doll’s limbs. This consideration, and the appropriate changes, are reflected in the methods discussed earlier in this section. The battle system size was well suited to storage with the doll. The backpack form would also allow for data connection with the doll via the back of the neck even when battles were not in process (see Figure 22). This would make it easier to set up if the battle system cord was already connected to the doll. The battle system could simply removed and placed to face the opponents battle system while still be attached to the doll via the extendable wire. There would be no need to connect or disconnect the data transfer wire. For future improvement to the prototype, creating mock connections between the Figure 29: Highback form battle system and the battle doll could be created to determine allowing for constant data the best distance of wire to be used, or other connection connection options. The draft prototype phase helped to determine the false assumptions that had been made in previous systems development. Following this process, subsystem organization and originating requirements were revised accordingly.

Hasbro Product Design Team

7.7 Bill of Materials Estimate In order to determine a general price point for the Battle Doll concept, a bill of materials (BOM) was created. The bill of materials estimate is listed below in Figure 30. Bill of Materials Material # Component ! "#$%&%'()%'&('% @ A&..'%<'9 B A8../#9)4<.0)5/#.&5.9)[0<.)D/#'9;\ Z A8../#9)4<.0)5/#.&5.9)[J&..;')9K9\ , 7890)J8../#)6'50&#<96 Y M/;;)$/%6 ^ H>M)95%''# W 7;&9.<5)(/;;)9.&#( _ ><%58<.)J/&%(

Cost Per Unit *+,, *+@B *+!* *+!* *+Z* *+W* !+** *+W* @+**

Supplier -'#.%/# C6&D/# :9.<6&.' :9.<6&.' :19<;/# :19<;/# C;<J&J& :19<;/# :9.<6&.'

Quantity Sub Totals per Toy 0..1233444+%'#.%/#+5/637%/(85.93:;'5.%/#<5=>/61/#'#.9+0.6 ! ?*+,,) 0..1233444+&6&D/#+5/631&5E=FCG:HH=CI!B=J8../#=J&..'%K3(13A**!LMNO> ! ?*+@B) [&..&50).<#)$<;6)./)J&5E)/$)D/#'9\ Z ?*+Z*) [&..&50).<#)$<;6)./)96&;;)%8JJ'%\ Z ?*+Z*) 0..1233'19<;/#<#(89.%<'9+5/631%<5<#]35/9.=/$=.//;<#]3 @ ?*+W*) 0..1233'19<;/#<#(89.%<'9+5/631%<5<#]35/9.=/$=.//;<#]3 ! ?*+W*) 0..1233444+&;<J&J&+5/631%/(85.=]93ZZWB_*^,!3!RWR<#50R.$.R;5(R95%''#+0. ! ?!+**) 0..1233'19<;/#<#(89.%<'9+5/631%<5<#]35/9.=/$=.//;<#]3 ! ?*+W*) [8#&J;')./)('.'%6<#'\ ! ?@+**) !"!#$ %&'() Reference

Figure 30: Bill of Materials - Estimate

The cost of small, simple parts, such as buttons with contacts was estimated, as information about manufacturing such a small component individually could not be found. Additionally, the type of circuit board and processor needed to run the electronics systems of the battle doll could not be determined from the market research conducted. To be safe, this was estimated at twice the cost of the highest costing component. It is important to note that this BOM is only an approximation of the hardware requirements needed for the manufacturing of the product. Although the functionality of the concept has been refined and detailed, the particulars of how such functionality would be realized was intentionally left open-ended. This is so the system design and specifications do not eliminate potential solutions considered by those more knowledgeable about the best way to implement the functionality specified. The total cost of materials was estimated to be approximately $7. If this is multiplied by a factor of 4 or 5 to determine market price, as is typical in the industry, the cost of the toy to customers would be approximately $30. Further details about the price point of the Battle Doll are included in the accompanying Semester 2 report.

Kat Â Ingalls Â

31 Â

8 Customer Value Assessment Criteria & Technical Optimization This section concludes the work completed for the first half of the project. Methods for determining and measuring the goals of the system according to customer values are detailed, as well as development of technical performance measures. The relationship between the customer values and technical performance measures are then mapped in a house of quality.

8.1 Goal-Question-Matrix (GQM) In order to determine the goals of the measurement, information from the customer affinity process discussed in Section 5 was used. Each attribute (ease of use, variability, safety, etc.) was converted into a statement of intent. To ensure that the goal was clearly defined, the target, purpose, relationship, perspective and context were examined. An example of this process is shown in Figure 31. !"!#$%&

!"#$%&'$'()'*+&$"!

+234567,+89:+23456,;<, -;6=;>5>4,?5@48<5

(>A5<34@>A7,B53CD>7,-;>4<;E7, /6=<;F5

()%&,)&+'&-.,%"

!#"*$%&', '&)+'&-./0&,"!

'<;G5H4,*9G5H4CF5

(35<7,I825<7,-;>45J4,K@4<CJ

%&'$%&',-*".&1.$"!

&>FC<;>65>4@E,-;>45J4

*+,-$./-$.01$-+21$.0$32-4

.01

5-2678

-+2-$09$32-

:/6;5

2687;-$9+<6;1$/0<-$=0>$ +81?;+:-@A

*+,-$./-$.01$/+B-$<+81$ 5699->-8.$C+12$09$?;+1687$ =+5+?.+D6;6.1EB+>6+D6;6.1A4

.01

5-2678

B+>6+D6;6.1$09$?;+1

:/6;5

2687;-$9+<6;1$/0<-

*+,-$./-$.01$.-:/80;076:+;;1$ .01 68.->-2.687E+??-+;6874

5-2678

.-:/80;076:+;$68.->-2.

:/6;5 D31->

2687;-$9+<6;1$/0<-

*+,-$./-$.01$2+9-$.0$32-4

5-2678

2+9-.1

:/6;5 D31->

2687;-$9+<6;1$/0<-

.01

Figure 31: Defining system goals

After goals were clearly defined, questions to determine how goals may be measured were developed. For instance, to determine the amount of variability the toy has (a customer attribute), one might ask how many ways the battle game can be played (see Figure 32). These questions are ways to assess whether the goals are being met. Finally, metrics to determine methods by which to measure the questions were generated. !"#$%

&'(%)*"+%

*4-567-894:-79:;-<94-9-=9>>?@-A98@-=@B?9:@CD !"#$%&'$%&()%'"*$%+",)% 367-894:-79:;-<94->5@->6:-=@-<J;>68FN@C-.//$0$,&%1")2%(/%34").,5% 9G>@E-BJE<59;@D-O0?6>5@;L-9<<@;;6EF@;L-<6?6E6"-"3&"7.4.&)8*"0."7.4.&)9: ,6@;->5@-<5F?C-J;@->5@->6:-9;-9-E@AJ?9E-C6??-F49CCF>F64->6-J;F4A-=9>>?@-A98@D ,6@;->5@->6:-89I@-AFE?;-G@@?-B66E?:-9=6J>->5@FE!"#$%&'$%&()%.,2&.44%"%3(2.&.*$;% =6C:D ,6->5@-B9E@4>;-46>F<@-94:-CFGG@E@4<@;-F4->5@2&0(,5;%.,-$3$,-$,&%2$4/<.+"5$% AFE?R;-<64GFC@4<@-?@M@?D .,%5.042: ,6@;->5@-<5F?C-;@@->5@-C6??-9;-9-E6?@-86C@?-G6EB@E;649?-;>E@4A>5D 367-?64A-C6@;->5@-<5F?C-;B@4C-=EJ;5F4A->5@C6??R;-59FED

*,(#$-.()/*0 H

,@>@E8F4@-GFE;>-E94A@-6G-9<<@;;6EF@;-6GG@E@4CG6E-C6??L-<6J4>K "=@EMF4A-<5F?C

+J8=@E->5@-CFGG@E@4>-79:;-F4-75F<5-9-C6??-<94=@-<J;>68FN@CK 19E@4>9?-PJ@;>F649FE@

%JEM@:F4A-94CQ6E-6=;@EMF4A-<5F?CE@4

#;IF4A-B9E@4>;

19E@4>9?-94;7@E-S-:@;Q46

%JEM@:F4A-<5F?CE@4

#;IF4A-<5F?C-B;:<56?6AF;>

"=;@EM@-<5F?CS-367-894:-8F4J>@;-9E@-;B@4>=EJ;5F4A-C6??T;-59FE-F4-9-UVH8F4J>@-B?9:-;@;;F64L64-9M@E9A@D "=;@EM@-<5F?CS-,6@;->5@-<5F?C-@4A9A@-*4>5@-C6??D 4JE>JEF4A-9<>FMF>F@;L-F4<?JCF4A-=EJ;5F4A-59FELG@@CF4AL-;6<F9?FNF4AL-@><KD *;->5@-J;@E-86E@-6J>A6F4AQ=E9M@D "=;@EMF4A-<5F?CT;-=@59MF6E-9G>@E-B?9:F4A-7F>5>6:-94CQ6E-9;IF4A-<5F?C-CFE@<>?:-FG-;5@-G@@?;=E9M@ !"#$%&'$%&()%.,23.0$%"%2$,2$%(/% ,6@;->5@-<5F?C-G@@?-@8B67@E@C-9G>@E-J;F4A->5@- "=;@EM@-<5F?C-6M@E-B@EF6C-6G->F8@Y-C6@;->5@>6:D <5F?C-89I@-86E@-F4C@B@4C@4>-<56F<@;-9G>@E2&0$,5&': J;F4A->5@->6:D *;->5@-<5F?C-86E@-@4@EA@>F<-9G>@E-J;F4A->5@->6:D "=;@EM@-<5F?C-94C-6=;@EM@-567-@4@EA@>F<-;5@-F;=@G6E@-94C-9G>@E-B?9:-O;<9?@-)\,]K

!"#$%&'$%&()%"33$"4.,5%&(%5.042=% ,"&>0"4%,>&>0.,5%30$/$0$,?$2: ,6@;->5@-<5F?C-G@@?->5@-4@@C->6-W>9I@-<9E@X-6G-

#11/"2*.#)(-.()/*0

,@>@E8F4@C-GE68-C@;FA4-H-?66I-JBK

,#)#-0"$$(0)*"+-.()3", /@G@E->6-C@;FA4L-?F;>-M9?J@ +J8=@E@C-?F;> 19E@4>9?-%JEM@: 19E@4>9?-%JEM@: *4>@EMF@7-6E-%JEM@: 1E6G@;;F649?-E@G@E@4<@

06??@<>F4A-C9>9-64-;F8F?9E->6:;

Figure 32: Snapshot of GQM

/@;@9E<5

06??@<>F4A-C9>9-64-;F8F?9E->6:; /@;@9E<5

The complete GQM table is included in Figure 33 on the next page, as well as in the #;IF4A-B9E@4>;-FG->5@:-59M@-46>F<@C-9->E@4C-F4Appendix included on the accompanying CD. The GQM is an important tool to measure <5F?CT;-6J>A6F4A4@;;K 19E@4>9?-%JEM@: how customer preferences will be met. ZEF>@-9-?F;>-6G-79:;-F4-75F<5->5@-C6??-BE@;@4>;-

Hasbro Product Design Team

!"#$%&'$%&()%2"/$%&(%>2$:

,6@;->5@->6:-8@@>-;9G@>:-E@PJFE@8@4>;)56E6JA5-949?:;F;-6G-9??-<68B64@4>;-6G->6:-F4;B@<FGF@C-=:-39;=E6-;>94C9EC;-94CQ6E-<64;J8@E- E@G@E@4<@->6-E@AJ?9>F64;K BE6CJ<>-E@AJ?9>F64;D 367-8J<5-EF;I-F;-9;;6<F9>@C-7F>5-9-<5F?C-J4C@E- ^6E89?-EF;I-949?:;F;-@M9?J9>F64

94-[@8B67@EF4A[-E6?@-86C@?K #;I-B9E@4>;K !@4@E9?-949?:;F;-6G-<68B64@4>;-F4-E@G@E@4<@->6E@AJ?9>F64;K \9;F<-EF;I-949?:;F;-@M9?J9>F64

$F;>-6G-G@9>JE@; 19E@4>9?-%JEM@: #49?:;F;-<5@<I?F;>

!"#$% !"#$%&'$%&()%$"/)%&(%+/$-

!"#$%&'$%&()%'"7$%9",)%6.**$1$,&% 5")/%(*%04").,2% <"6"0&";.4.&):7"1.";.4.&)=-

!"#$%&'$%&()%&$3',(4(2.3"44)% .,&$1$/&.,2:"00$"4.,2-

!"#$%&'$%&()%/"*$%&(%+/$!"#$%&'$%&()%.,/&.44%"%0(/.&.7$?% /&1(,2?%.,6$0$,6$,&%/$4*>.9"2$%.,% 2.14/-

&'(%)*"+%

):6:8D-7?;K<-GF454A@=A>L-BA46-<:6=-<49-:>D:M=8-5:<E4;<-789-:8><A;F<:48I

,4=>-<E=-FE:K?-7>@-B4A-E=KO-BA46-78-7?;K<P ,4=>-<E=-O=A>48->=<<:8D-;O-<E=-<49-K44@-7<-<E=-?:A=F<:48>P-345-K48DP *8-E45-6789-579>-F78-7-Q7<<K=-D76=-Q=-OK79=?P

"Q>=AM:8D-FE:K?->=<-;O-<49I "Q>=AM:8D-FE:K?->=<-;O-<49I ,=<=A6:8=?-BA46-?=>:D8-T-K44@-;OI

#>@-O7A=8<>I "Q>=AM:8D-7?;K<->=<-;O-<49I T

345-6789-579>-F78-<E=-<49-Q=-F;><46:U=?-7B<=A-O;AFE7>=P-G0K4<E=>N7FF=>>4A:=>N-F4K4A-M7A:7<:48N-7A<:><:F-BK4;A:>E=>L ,4=>-<E=-FE:K?-;>=-<E=-<49-7>-7-A=D;K7A-?4KK-:8-7??:<:48-<4-;>:8D-Q7<<K=-D76=P ,:?-<E=-O7A=8<-Q;9-4A-FE:K?-A=C;=><-<E=-?4KK-Q=F7;>=-4B-:<>-<=FE84K4D:F7K7<<A:Q;<=>P-:I=I-*8<=A7F<:M=-OE9>:F7K-V-M:A<;7K-D76=-78?-*/-F466;8:F7<:48

,=<=A6:8=-B:A><-A78D=-4B-7FF=>>4A:=>-4BB=A=8?B4A-?4KKN-F4;8<I "Q=AM:8D-FE:K? %;AM=9-7>@:8D-5E9-FE:K?A=8-578<=?S-O7A=8<>Q4;DE<-<49

+;6Q=A-<E=-?:BB=A=8<-579>-:8-5E:FE-7-?4KK-F78Q=-F;><46:U=?I 17A=8<7K-C;=><:487:A= #>@-F454A@=A>-5E9-<E=9-54;K?-578<-<4-Q;9<E=-<49I

WE=8-7>@=?-5E9-<E=9-54;K?-Q;9-<E=-Q7<<K=-?4KK-4M=A-7-<A7?:<:487K-?4KKN-:>-<E=XQ7<<K=->9><=6Y-A=B=A=8F=?P ,4=>-<E=-<49-6==<->7B=<9-A=C;:A=6=8<>->O=F:B:=?-Q9-37>QA4-><78?7A?>-78?S4AF48>;6=A-OA4?;F<-A=D;K7<:48>P

%;AM=9-7>@:8D-5E9-FE:K?A=8-578<=?S-O7A=8<>Q4;DE<-<49 )E4A4;DE-787K9>:>-4B-7KK-F46O48=8<>-4B-<49-:8A=B=A=8F=-<4-A=D;K7<:48>I

#>@-F454A@=A>-5E9-<E=9-54;K?-578<-<4-Q;9<E=-<49I !=8=A7K-787K9>:>-4B-F46O48=8<>-:8-A=B=A=8F=<4-A=D;K7<:48>I

345-6;FE-A:>@-:>-7>>4F:7<=?-5:<E-7-FE:K?-;8?=A-<E=->;DD=><=?-7D=-OK79:8D-5:<E- Z4A67K-A:>@-787K9>:>-=M7K;7<:48 <E=-?4KKP ,4=>-<E=-<49-67@=-D:AK>-B==K-O44AK9-7Q4;<-<E=:A-Q4?9P %;AM=9:8D-78?S4A-4Q>=AM:8D-FE:K?A=8

J7>:F-A:>@-787K9>:>-=M7K;7<:48

,4-<E=-O7A=8<>-84<:F=-789-?:BB=A=8F=>-:8-<E=-D:AK[>-F48B:?=8F=-K=M=KP

17A=8<7K-78>5=A-\-9=>S84

,4=>-<E=-FE:K?->==-<E=-?4KK-7>-7-A4K=-64?=K-B4A-O=A>487K-><A=8D<EP 345-6;FE-<:6=-?4=>-<E=-;>=A-OK79-5:<E-<E=-?4KK-:8-7-D:M=8-OK79->=>>:48P

%;AM=9:8D-FE:K?A=8 "Q=AM=A:8D-FE:K?-T-<:6=-Q=<5==8-O:F@:8D-;O<49-78?-64M:8D-<4-784<E=A-<49 "Q>=AM=-8;6Q=A-4B-<:6=>-FE:K?-O:F@>;O-?4KK

#>@:8D-FE:K?-O>9FE4K4D:>< 04KK=F<:8D-?7<7-48->:6:K7A-<49>

345-K48D-:>-<E=-<49-OK79=?-48-<E=-K48D-<=A6-Q=B4A=-:8<=A=><-:>-K4><-78?-:>A=OK7F=?-5:<E-784<E=A-<49P WE7<-A78D=-4B-7D=>-:>-:8<=A=><=?-:8-<E=-<49P

,4=>-<E=-?4KK-DA45-78?-7?`;><-5:<E-<E=-;>=AP

*>-<E=-;>=A-64A=-4;<D4:8DSQA7M=P

!"#$%&'$%&()%.,/0.1$%"%/$,/$%(*% /&1$,2&'-

,4=>-<E=-FE:K?-B==K-=6O45=A=?-7B<=A-;>:8D-<E=-<49P

*>-<E=-FE:K?-64A=-=8=AD=<:F-7B<=A-;>:8D-<E=-<49P *>-<E=-<49-;>=?-64A=-B4A-Q7<<K=-OK79-5:<E-O7A<8=A>N-4A->4K:<7A:K9P

!"#$%&'$%&()%$,3(+1"2$%04")%5.&'% (&'$1/-

,4=>-<E=-FE:K?-:67D:8=->F=87A:4>-B4A-5E:FE-<E=-?4KK-:>-Q7<<K:8DP

WE7<-:>-<E=->67KK=><-><78?7K48=-O7A<-4B-<E=-<49P-G>67KK-c-=7>9-<4-K4>=L ,4=>-<E=-<49-:8FK;?=-><4A7D=->9><=6>-:8-:<>-?=>:D8P 345-6789-O7A<>-?4=>-<E=-?4KK-E7M=P 345-K48D--?4=>-:<-<7@=-<4-F4KK=F<-O:=F=>-7B<=A->F7<<=A=?P

WE7<-:>-<E=-F4><-4B-F46O7A7QK=-OA4?;F<>P-,4=>-4;A-<49-F4><-64A=-4A-K=>>P

,4-Q;9=A>-B==K-<E=-OA:F=-:>-B7:A-e-<E7<-<E=9-7A=-?=A:M:8D-M7K;=P

,4-@:?>-578<-<E=:A-458-<49P

!"#$%&'$%&()%.,/&.44%"%/$,/$%(*%01.6$% ,4=>-<E=-FE:K?->E45-<E=-<49-4BB-<4-<E=:A-BA:=8?>P .,%&'$%+/$1%<3((4%*"3&(1=,4=>-<E=-FE:K?->E45-<E=-<49-4BB-<4-<E=:A-O7A=8<>P 345-6789->4;8?>-?4=>-<E=-<49-67@=P

!"#$%&'$%&()%"+1"44)%/&.9+4"&.,2-

,4-<E=-<49[>->4;8?>-=8E78F=-<E=-Q=K:=M7Q:K:<9-4B-D76=OK79P

345-6;FE-<:6=-?4=>-<E=-FE:K?->O=8?-<4;FE:8D-<E=-<49-5E=8-84<-:8-D76=64?=P

!"#$%&'$%&()%&"3&.4$>4)%/&.9+4"&.,2,4=>-<E=-FE:K?-QA;>E-<E=-?4KK[>-E7:AP 345-K48D-?4=>-<E=-FE:K?->O=8?-=H76:8:8D-<E=-?4KK[>-B=7<;A=>P

!"#$%&'$%&()%7./+"44)%/&.9+4"&.,2-

,4=>-<E=-?4KK-E7M=-A=7K:><:F-OA4O4A<:48>P

,4=>-<E=-?4KK-E7M=-A=7K:><:F-E7:AP 345-K48D-F78-<E=-<49-Q=-OK79=?-5:<E-Q=B4A=-7-F46O48=8<-QA=7@>-GQ;<-><:KKB;8F<:48>LP 345-K48D-F78-<E=-<49-Q=-OK79=?-5:<E-Q=B4A=-:<-8==?>-<4-Q=-A=OK7F=?P 345-K48D-F78-<E=-<49-Q=-OK79=?-5:<E-Q=B4A=-:<->E45>->:D8>-4B-5=7AP

!"#$%&'$%&()%6+1";4$?%1$/./&",&%&(% 6"9"2$-

*>-<E=-?4KK-57<=AOA44B-78?S4A-;87BB=F<=?-Q9-E;6:?-F48?:<:48>P

*>-<E=-?4KK-7QK=-<4-Q=-;>=?-4;<-4B-?44A>-5:<E4;<-?767D=P

345-K48D-?4=>-<E=-FE:K?->O=8?-QA;>E:8D-<E=-?4KK[>-E7:AP

!"#$%&'$%&()%"00$"4.,2%&(%2.14/8% ,"&+1"4%,+&+1.,2%01$*$1$,3$/-

,4=>-<E=-FE:K?-B==K-<E=-8==?-<4-X<7@=-F7A=Y-4B-<E=-?4KKP

345-4B<=8-:>-<E=-<49-OK79=?-5:<EP

,4=>-<E=-FE:K?-FE44>=-<E:>-<49-5E=8-D:M=8-<E=-4O<:48-4B-FE44>:8D-4<E=A>P

!"#$%&'$%&()%*+,-

#>@:8D-O7A=8<>-E45-4B<=8-<49-:>-OK79=?-5:<EM=A>;>-4<E=A-<49>-48->F7K=-4B-]-<4-^ 04KK=F<:8D-?7<7-48->:6:K7A-<49>

$:><-4B-<:6=> 17A=8<7K-%;AM=9N-R=>S+4 $:><-4B-<:6=> /=B=A-<4-?=>:D8N-K:><-M7K;= +;6Q=A=?-K:>< 17A=8<7K-%;AM=9 0454A@=A-%;AM=9 0454A@=A-%;AM=9 #87K9>:>-FE=F@K:>< /:>@-787K9>:> 17A=8<7K-%;AM=9 *8<=AM:=5-4A-%;AM=9 1A4B=>>:487K-A=B=A=8F= /=>=7AFE 17A=8<7K-%;AM=9 /=>=7AFE

04KK=F<:8D-?7<7-48-7D=-A78D=-:8<=A=><=?-:8<767D4<FE:-78?S4A-J7AQ:=

/=>=7AFE

04KK=F<:8D-?7<7-48->:6:K7A-<49> /=>=7AFE #>@:8D-O7A=8<>-:B-<E=9-E7M=-84<:F=?-7-<A=8?-:8FE:K?a>-4;<D4:8D8=>>I WA:<=-7-K:><-4B-579>-:8-5E:FE-<E=-?4KK-OA=>=8<>78-_=6O45=A:8D_-A4K=-64?=KI #>@-O7A=8<>I

17A=8<7K-%;AM=9

$:><-4B-B=7<;A=> 17A=8<7K-%;AM=9

/=>=7AFE-?7<7-B4A-M7K;=>-B4A->:6:K7A-<49>I /=>=7AFE

"Q>=AM=-FE:K?-OK79:8D-5:<E-?4KKb-4A-?4=>-<E=04KK=F<-?7<7-48->:6:K7A-<49>I FE:K?-7K>4-;>=-<E=-?4KK-7>-7-<A7?:<:487K-?4KK-5:<E4<E=A>P-R=>S84 *>-<E=-?4KK-;>=?-B4A-<A7?:<:487KN-:67D:87<:M=-?4KK-OK79-:8-7??:<:48-<4-Q7<<K=-OK79P "Q>=AM=-FE:K?-OK79:8D-5:<E-?4KKb-:>-:<-;>=?-48K9- 04KK=F<-?7<7-48->:6:K7A-<49>I :8-D76=OK79N-4A-?4=>-<E=-FE:K?-7K>4-;>=-<E=?4KK-7>-7-<A7?:<:487K-?4KKP-R=>S84

!"#$%&'$%&()%6$7$4(0%&'$%+/$18/% .9"2.,"&.(,-

!"#$%&'$%&()%"**(16";4$-

"Q>=AM:8D-FE:K?-4M=A-F4;A>=-4B-_OA4?;F<:8<=A=><_-T-5E=8-?4=>-<49-><4O-Q=:8D-OK79=?5:<E-7<-K=7><-48F=S5==@P %;AM=A9-4B-FE:K?A=8-7B<=A-Q=:8D->E45867A@=<:8D-7?M=A<:>=6=8<>-4A-Q=:8D-D:M=8-7?4KK-<4-OK79-5:<E "Q>=AM:8D-FE:K?-4M=A-F4;A>=-4B-_OA4?;F<:8<=A=><_-T-5E=8-?4=>-<49-><4O-Q=:8D-OK79=?5:<E-7<-K=7><-48F=S5==@P "Q>=AM:8D-FE:K?a>-Q=E7M:4A-7B<=A-OK79:8D-5:<E<49-78?S4A-7>@:8D-FE:K?-?:A=F<K9-:B->E=-B==K>QA7M= "Q>=AM=-FE:K?-4M=A-O=A:4?-4B-<:6=b-?4=>-<E=FE:K?-67@=-64A=-:8?=O=8?=8<-FE4:F=>-7B<=A;>:8D-<E=-<49P "Q>=AM=-FE:K?-78?-4Q>=AM=-E45-=8=AD=<:F->E=:>-Q=B4A=-78?-7B<=A-OK79-G>F7K=-)J,LI "Q>=AM=-FE:K?-<4->==-E45-6789-<:6=>-<E=-?4KK:>-O:F@=?-;O-78?-OK79=?-5:<E-48-48=a>-458M=A>;>-:8-DA4;OI

#>@:8D-O7A=8<>

,#)#-0"$$(0)*"+-.()3",

*>-<E=-<49-;>=?-B4A-<A7?:<:487K-?4KK-OK79-5:<E-4<E=A>P

,4=>-<E=-;>=A-:67D:8=-=8M:A486=8<>-:8-5E:FE-<E=-?4KK-:>-Q7<<K:8DP

!"#$%&'$%&()%$"/)%&(%34$",%+0:,(&% 9$//)-

#11/"2*.#)(-.()/*0

):6:8D-FE:K?-BA46-<:6=-<49-:>-D:M=8N-5:<E4;<789-:8><A;F<:48I

345-4B<=8-:>-<E=-<49-OK79=?-5:<E-O=A-?79SO=A-5==@P

!"#$%&'$%&()%04")";4$%*(1%"%4(,2% &.9$-

*,(#$-.()/*0

345-6789-6:8;<=>-?4=>-:<-<7@=-<4-<A78>:<:48-BA46-7C;:A:8D-<E=-<49-<4-;>:8D-:<<4-?4-7-A=C;:A=?-B;8F<:48-G=HI-J7<<K:8DLI

,4=>-<E=-FE:K?->6:K=-5E:K=-OK79:8D-5:<E-<E=-<49P ,4=>-<E=-FE:K?-7>@-<4-QA:8D-<E=-<49-48->E4A<-<A:O>P

"Q>=AM=-FE:K?-OK79:8D-5:<E-?4KK-T-?4=>-<E=#>@-O7A=8<>I FE:K?-><7<=-<E7<-<E=-?4KK-:>-:8-<E=-`;8DK=N-:84;<=A->O7F=N-4A-4<E=A-:67D:87<:M=-OK79>=<<:8D>P "Q>=AM=-FE:K?-OK79:8D-5:<E-?4KK-T-?4=>-<E=#>@-O7A=8<>I FE:K?-><7<=-<E7<-<E=-?4KK-:>-B:DE<:8D-<4->7M=-<E=OK78=<N-B4A-OA4<=F<:8D->46=48=-4A->46=<E:8DN4A-<4-67@=->46=<E:8D-E7OO=8P .=7>;A=-?:6=8>:48>-4B->67KK=><-O7A<-4B-<49I T /=M:=5-OA4?;F<->O=F:B:F7<:48>-T-K:><-579>-:85E:FE-><4A7D=->4K;<:48>-E7M=-Q==8-:8FK;?=?I /=M:=5-OA4?;F<->O=F:B:F7<:48>-<4-?=<=A6:8=8;6Q=A-4B-_BA==-><78?:8D_-O7A<>-:8-<49I "Q>=AM=-O7A=8<-O:F@:8D-;O-O:=F=>->F7<<=A=?-:8<9O:F7K-B7>E:48-7B<=A-OK79-78?-<:6=-E45-K48D-:<<7@=-<4-O;<-:8-><4A7D=-7A=7I /=>=7AFE-67A@=<-OA:F=>-4B-F46O=<:<4A>S>:6:K7A<49>I-WE7<-:>-<E=-O=AF=8<-?:BB=A=8F=-Q=<5==84;A-OA:F=>P

T T "Q>=AM=-F454A@=A>-O:F@:8D-;O-O:=F=>>F7<<=A=?-:8-<9O:F7K-B7>E:48-7B<=A-OK79-78?<:6=-E45-K48D-:<-<7@=-<4-O;<-:8-><4A7D=-7A=7I T

#>@-O7A=8<>-T-?4-FE:K?A=8->E45-4A-<=KK-4<E=A>7Q4;<-<E=:A-<49P T

17A=8<7K-%;AM=9

.=7>;A=6=8< 1A4?;F<-B=7<;A=>-K:><:8D d7K;=-BA46-OA4?;F<->O=F:B:F7<:48> 0454A@=A-/=>=7AFE

/=>=7AFE

17A=8<7K-%;AM=9

17A=8<7K-%;AM=9 17A=8<7K-%;AM=9

T 1A4?;F<->O=F:B:F7<:48-M7K;=

#>@-FE:K?A=8-:B-<E=->4;8?>-67@=-?;A:8D#>@-7?;K<>-:B->4;8?>-67@=-?;A:8D-<E=D76=OK79-67@=>-<E=-D76=-64A=-A=7K:><:F-G:8- D76=OK79-67@=>-<E=-D76=-64A=-A=7K:><:F <E=:A-4O:8:48LI "Q>=AM=-FE:K?\-.7@=-FE=F@K:><-4B-E45-6789P 7F<:48>-<E=-FE:K?-O=AB4A6>-A=K7<:8D-<4-<7F<:K=><:6;K7<:48-G64M:8D-?4KK>-7A6>N-64M:8D-?4KK>K=D>N-67@:8D-E=A->:<N-O4>:8D-E=A-:8-2-O4>:<:48gL "Q>=AM=-FE:K?\-,4=>-FE:K?-QA;>E-?4KKa>-E7:AP "Q>=AM=-FE:K?\-W:<E:8-<E=-B:A><-]h-6:8;<=>-4BD76=OK79N-E45-K48D-?4=>-<E=-FE:K?->O=8?-`;><K44@:8D-7<-G84<-64M:8DL-<E=-?4KKI /=M:=5-OA4?;F<->O=F:B:F7<:48>b-/=>=7AFE_<9O:F7K_-Q4?9-A7<:4>-B4A-<E=-#6=A:F78-B=67K=I,4-<E=>=-A7<:4>-67<FE-<E=-?4KKa>P-R=>S+4

#>@-O7A=8<>-:B-FE:K?-QA;>E=>-?4KKa>-E7:A #>@-FE:K?N-O7A=8<>-4A-F454A@=A>\-*>-<E=-?4KKM:>;7KK9-:8<=A=><:8DP-R=>S+4

#>@-FE:K?-:B-E7:A-K44@>SB==K>-A=7K:><:FI 09FK=-<49-<EA4;DE-FE:K?A=8-;8<:K-848T=>>=8<:7KF46O48=8<-QA=7@>-T-?=<=A6:8=-7M=A7D=-E4;A>4B-OK79I 09FK=-<49-<EA4;DE-FE:K?A=8-;8<:K-<49-QA=7@>-T?=<=A6:8=-7M=A7D=-E4;A>-4B-OK79I "Q>=AM=-FE:K?A=8\-345-6789-E4;A>-4B-OK79;8<:K-B:A><->FA7FES?=8<SFE:O-7OO=7A>P /=M:=5-OA4?;F<->O=F:B:F7<:48>\-078-<E=-?4KK-Q=OK79=?-5:<E-:8-57<=AP-WE7<-:>-<E=-E:DE=><<=6O=A7<;A=-78?-E;6:?:<9-;8?=A-5E:FE-<E=?4KK-5:KK-><:KK-B;8F<:48P "Q>=AM=-E45-<49-A=7F<>-<4-Q=:8D-OK79=?-5:<E48-A4;DE-F48FA=<=N-:8-=H<A=6=-E=7<-4A-F4K?N48-?=59-DA7>>-T-=8M:A486=8<7K-B7F<4A>I

#>@-F454A@=A>-:B-E7:A-K44@>SB==K>-A=7K:><:FI 37M=-O7A=8<>-A=O4A<-E45-K48D-7B<=A-Q;9:8D?4KKN-848T=>>=8<:7K-F46O48=8<-QA=7@>I

0454A@=A->;AM=9

"Q>=AM7<:48

17A=8<7K-%;AM=9 %;AM=9

T 1A4?;F<-%O=F:B:F7<:48>-F46O7A=?-<4-/=>=7AFE

37M=-O7A=8<>-A=O4A<-E45-K48D-7B<=A-Q;9:8D?4KKN-?4KK-QA=7@>I 04KK=F<:8D-?7<7-48->:6:K7A-<49>

0454A@=A->;AM=9 17A=8<7K-%;AM=9 17A=8<7K-%;AM=9 /=>=7AFE

+48= 1A4?;F<-%O=F:B:F7<:48-,7<7 /=M:=5-OA4?;F<->O=F:B:F7<:48>-T-E45-?;A7QK=-:><49a>-B:8:>EP-345-57<=A-78?-E=7<TA=>:><78<-7A=/=>=7AFE-*8-A=K7<:48-<4-OA4?;F<->O=F:B:F7<:48> <49a>-F46O48=8<>P-046O7A=-5:<E-M7A:4;>4;<?44A-F48?:<:48>I 04KK=F<:8D-?7<7-48->:6:K7A-<49> /=>=7AFE

"Q>=AM=-FE:K?\-345-6789-6:8;<=>-7A=->O=8<QA;>E:8D-?4KKa>-E7:A-:8-7-]^T6:8;<=-OK79>=>>:48N-48-7M=A7D=P "Q>=AM=-FE:K?\-,4=>-<E=-FE:K?-=8D7D=-*804KK=F<:8D-?7<7-48->:6:K7A-<49> 8;A<;A:8D-7F<:M:<:=>N-:8FK;?:8D-QA;>E:8D-E7:ANB==?:8DN->4F:7K:U:8DN-=<FIP "Q>=AM=-FE:K?-4M=A->=M=A7K-E4;A>-:8-_E46=T #>@-O7A=8<>-<4-=><:67<=I K:@=_->=<<:8Db-E45-6789-<:6=>-:>-?4KK-O:F@=?-;O78?-OK79=?-5:<E-B4A-7<-K=7><-^-6:8;<=>P-345K48D-:>-<E=-?4KK-OK79=?-5:<E-48-7M=A7D=-Q=B4A=Q=:8D->=<-?458P "Q>=AM=-FE:K?\-345-6789-<:6=>-:>-<E:>-<49-<E=B:A><-FE4>=8-B4A-=7FE-OK79->=>>:48P "Q>=AM=-FE:K?\-*>->E=->6:K:8D-7>->E=-OK79>-5:<E<E=-<49P-R=>S84 "Q>=AM=-FE:K?\-,4=>-FE:K?-7>@-<4-QA:8D-?4KK5:<E-<E=6-5E=8-7>@=?-<4-D4->46=OK7F=G>FE44KN-DA4F=A9-><4A=N-BA:=8?>a-E4;>=NDA78?67a>-E4;>=L

/=>=7AFE

,7<7-<7QK=-4B-O=AF=8<-?:BB=A=8F=>-:8-OA:F=

%;AM=A9-O7A=8<>-:8-A=>O=F<-<4-<E=:A-O=AF=:M=?- /=>=7AFE-?7<7-B4A->:6:K7A-OA4?;F<>-78?M7K;=-T-<44-=HO=8>:M=-B4A-5E7<-<E=9-A=F=:M=?N- >;AM=9>-?48=-B4A-<E=:A-OA:F:8DI B7:AN-4A-_DA=7<-?=7K_ "Q>=AM=-FE:K?-7B<=A->E45:8D-<E=6-=:<E=A-7-<49- #>@-O7A=8<>-:B-FE:K?A=8-54;K?-578<-<49I :8-7-><4A=->=<<:8DN-7-<49-Q=:8D-OK79=?-5:<E-Q9784<E=A-FE:K?N-4A-7-67A@=<:8D-F466=AF:7KI-,4<E=9->79N-_*-578<-<E7<f_ "Q>=AM=-FE:K?A=8-:8-FK7>>A446N-K;8FEA446N-4AE46=->=<<:8DI-,4=>-<E=-FE:K?-67@=-7-O4:8<-4B>E45:8D-4A-<=KK:8D-BA:=8?>-7Q4;<-<49P-R=>S84I #>@-O7A=8<>-:B-FE:K?-K:@=>->E45:8D-4A-<=KK:8DO7A=8<-7Q4;<-<E=:A-<49I /=M:=5-OA4?;F<->O=F:B:F7<:48>-T-E45-6789;8:C;=-84:>=>-7A=-?=>:D8=?-:8<4-<E=-<49P-

/=>=7AFE

#>@-O7A=8<>-5E7<-O=AF=8<7D=-4B-FE:K?a>-<:6=>O=8<-OK79:8D-:>-5:<E-<E:>-<49I #>@-O7A=8<>-:B-FE:K?->6:K=>-5E:K=-<49-:>-Q=:8DOK79=?-5:<EI #>@-O7A=8<>-:B-FE:K?-4B<=8-7>@>-<4-QA:8D-<495:<E-<E=6-B4A-=HF;A>:48>I-R=>S84I-345-4B<=8?4=>-FE:K?-QA:8D-<49-5:<E-<E=6-48-7-<A:OP(M=A9-<A:OS-48=-7-5==@S-K=>>-<E78-48F=-7-5==@

/=>=7AFE

17A=8<7K-%;AM=9I

17A=8<7K-%;AM=9 17A=8<7K-%;AM=9

17A=8<7K-%;AM=9

Figure 33: Complete GQM matrix

Kat Ingalls

8.2 Analytical Hierarchy Process In order to determine the relative importance of each goal, the customer statements discussed in Section 5 were weighted in an analytical hierarchy process. This weighting was achieved by summing the number of statements for each attribute considered, and then dividing this by the total number of customer statements. Using this method, the following weighting was obtained:

Attribute Shortname Nurturing Sense of Strength Pride Imagination Collaboration Longevity Tech Interest Variability Sound Touch Look Usability Cost Clean up Durability Safety

GQM Attributes Make the toy appealing to girls' natural nuturing preferences. Make the toy instill a positive, strong, independent self-image in girls. Make the toy instill a sense of pride in the user (cool factor). Make the toy develop the user's imagination. Make the toy encourage play with others. Make the toy playable for a long time. Make the toy technologically interesting/appealing. Make the toy have many different ways of playing (variability). Make the toy aurally stimulating. Make the toy tactile-ly stimulating. Make the toy visually stimulating. Make the toy easy to use. Make the toy affordable. Make the toy easy to clean up/not messy. Make the toy durable, resistant to damage. Make the toy safe to use. Figure 34: Customer affinity weighting

Hasbro Product Design Team

Customer weight (%) 3.5 5 9 10.5 8 3.5 2 9 5 1 9 8 6 3.5 5 12

8.3 House of Quality Using the analytical hierarchy determined in the previous section, a house of quality (HoQ) was developed to show that the product design meets the customer values. The HoQ has the following components:

Figure 35: Structure of the House of Quality*

The customer weightings are comprised of customer attributes, otherwise known as the voice of customer (VOC), in combination with the relative importance discussed in the previous section. This information is placed in the left side of the HoQ. Technical performance measures (TPM) were generated to determine how to meet the VoC requirements. These are shown below in 8.3.1. Justifications for these TPMs can be found in the Appendix.

8.3.1 Technical Performance Measures • • • • • • • • • • • • • •

Ratio of leg-to-torso Ratio of waist-to-hip ratio Number of fully articulated joints Maximum velocity of hit Number of pieces/components included in packaging Maximum number of connections to other players Data connection/transfer speed Number of (specified) modes of play Cost of electronic components Cost of all materials Time to assemble Minimum radius of curvature Minimum yield strength Number of materials used

The TPMs are placed at the top of the HoQ, and their dependencies are mapped in a correlation matrix. Then the relationships between the TPM and VoC are determined in the central relationship matrix. This is important to determine the relationships between * From <http://themanagersguide.blogspot.com/2011/05/constructing-basic-house-of-quality.html>

Kat Ingalls

()&*)+,-+($#)&'$.

!"#$%+&-%**&$'$("&%-%9):$&-."+,:$ %+;)()+;)+-$&)*1<%=',)$%+$,%.*&3

!"#$%+&-%**&$'$&)+&)$"1$(.%;)$%+$->)$ 0&).$?2""*$1'2-".@3

10.5

3.5

!"#$%&$-)2>+"*",%2'**#$ %+-).)&-%+,E'(()'*%+,3

!"#$>'&$='+#$;%11).)+-$C'#&$"1$ (*'#%+,$?9'.%'D%*%-#@3

B,C))+D5%8)+/)$*

1#,&+A3&+3;$%,&+-%'"#)

M3="',&

3.5

P"Q"+/)$*

!"#$%&$'(()'*%+,$-"$,%.*&/$+'-0.'*$ +0-0.%+,$(.)1).)+2)&3

G,;=+F2+(,;=+F2+G,6,$*

M3#6%)

!"#$"#%&'

+++CUSTOMER ATTRIBUTES

:323',$;.%

BATTLE DOLL+HOD(MGEN

engineering and marketing in the product. The relationship matrix communicates how customer needs will be met by the engineering characteristics of the product, and therefore that the system’s goals are being met by the product’s specifications. Next, competitor products and the concept product are listed and compared with respect to the VoC. This establishes a relative customer perception ranking, which is useful for determining the strengths and weaknesses of the product compared to similar products. The competitor products used and their scores are included below in Figure 36 and Figure 37.

4>(:EAFG+/FG4F/:1E!+HIJB,#*$K+LJM)*$N

/#%0) 123'%&3$%,& 4,5536,#3$%,& 7,&')8%$9 :);.+1&$)#)*$ <3#%36%5%$9

!"#$;)9)*"(&$->)$0&)./&$ %=',%+'-%"+3 A'B)$->)$-"#$)+2"0.',)$(*'#$ C%->$"->).&3 !"#$%&$(*'#'D*)$1".$'$*"+,$-%=)3

!"#$%&$'0.'**#$&-%=0*'-%+,3

(,"&0

!"#$%&$-'2-%*)<*#$&-%=0*'-%+,3

:,";.

!"#$%&$9%&0'**#$&-%=0*'-%+,3

7,,= >*36%5%$9

!"#$%&$)'&#$-"$0&)3 !"#$%&$'11".;'D*)3

4,*$ 45)3&+"?

!"#$%&$)'&#$-"$2*)'+$0(E+"-$ =)&&#3

3.5

@"#36%5%$9

!"#$%&$;0.'D*):$.)&%&-'+-$-"$ ;'=',)3

!"#$%&$&'1)$-"$0&)3

(3-)$9

6F 6G 5G 54 68 67 5G 66

Figure 36: Customer perception analysis ()*+)*,-." '" /930+@"

/0-10"23"/+*0-.+4"

&" G)*9=,<,+@"

5*,60"

;<09-")F"

789.,-9:2-"

;21+"

;2<<9=2*9:2-"

E19=,<,+@"

>2-.0?,+@"

HIAA>J"GK>>"LMI/HNKO" H9*=,0" A989.2+B4," N2BD"J8"/2BD"J8"N2=2+1"

>22D"

A0B4"7-+0*01+"

P)Q)"50+1" H9D).2-" 7*2-"R9-"9B:2-"S.)*0" T2U00"I<,?0"50+1" A2)B4"

C9*,9=,<,+@"

/2)-6"

Figure 37: Graphical representation of customer perception

Hasbro Product Design Team

The 8 products considered in the customer perception analysis were rated on a scale from 1 to 5, where 5 is the best performing product and 1 is the weakest performing product. As seen in the previous figures, the Battle Doll is successful in meeting the customer goals determined by the GQM process. After the customer assessment portion of the HoQ was complete, an outline of the objective measures needed to quantify the TPMs was created. The numbers for the specifications of the TPMs for each of the products considered was beyond the scope of this project. In conclusion, the HoQ, as a tool of quality function deployment (QFT), helped to communicate the relationships between customer needs and product specifications, in order to ensure that the objectives of the system under consideration were being met. The completed house of quality is listed on the following page in Figure 38.

Kat Ingalls

HOUSE OF QUALITY

CU + HASBRO

BATTLE DOLL !"#$%&'()*&+),-".

9"()",'4, 4&5!+'*$+77*!3!6&*+$+,-A!*$%&'(A! 9%2"(6%* +'/-6-'/-'$!*-79"+13(-!+'!(+%7*; 4&5!+'*$+77*!3!*-'*-!&9!6%+/-!+'!$B-! :2&;" 0*-%!C:&&7!93:$&%D; <=$6&($%&'(

4&5!/-,-7&6*!$B-!0*-%8*! +13(+'3$+&';

5'##$>'2$%& .3E-!$B-!$&5!-':&0%3(-!6735!F+$B! &$B-%*; '( 4&5!+*!67353G7-!9&%!3!7&'(!$+1-; ?'(6"@&%. A"3*, <(%"2")%

4&5!+*!$-:B'&7&(+:3775! +'$-%-*$+'(H366-37+'(;

4&5!B3*!13'5!/+99-%-'$!F35*!&9! B$2&$>&#&%. 6735+'(!C,3%+3G+7+$5D; 9'8(; A'83*

4&5!+*!$3:$+7-"75!*$+1073$+'(; 4&5!+*!,+*03775!*$+1073$+'(;

?''C D)$>&#&%.

4&5!+*!-3*5!$&!0*-; 4&5!+*!399&%/3G7-;

5')% 5#"$(,8+ 182$>&#&%. 9$4"%.

OBJECTIVE MEASURES

4&5!+*!30%3775!*$+1073$+'(;

4&5!+*!-3*5!$&!:7-3'!06H'&$!1-**5; 4&5!+*!/0%3G7-A!%-*+*$3'$!$&!/313(-; 4&5!+*!*39-!$&!0*-;

UNITS OF MEASURE

BATTLE DOLL,LGH9M!NO M$2>&" A$=$6'%3*& !'3C,E=,9'3C,E=,!'>'%) Y8Z8,:"%) M$C86'( <2'(,J$(,$3%&'(,4&682" X'U"",H#&@",:"%)

4+1-!$&!3**-1G7-

.+'+101!%3/+0*!&9!:0%,3$0%-

.+'+101!5-+7/!*$%-'($B

201G-%!&9!13$-%+37*!0*-/

0 //

// /

10.5

// /

/ //

2 9

8 3.5

// //

00 00

3.5 5

00 K

P;>I

=P)

>.%") P)

=&(R

J+$

Q Q @ Q

A"3*(&3$#,1&44&38#%.,,,LST?'UV,WTG&6*O <=+8%";,<=+'2%$(3",,,LST?'UV,WTG&6*O

E)%&=$%";,!"#$%&@",5')%,,,LST?'UV,WTG&6*O A$26"%)

Figure 38: Completed House of Quality

[END OF REPORT 1] 38

Hasbro Product Design Team

5D9ANJE!,:E!5E:A<N7,LSTX'2)%V,WTM")%O

X'U"",H#&@",:"%)

O&*$!&9!377!13$-%+37*

<2'(,J$(,$3%&'(,4&682"

O&*$!&9!-7-:$%&'+:!:&16&'-'$*

M$C86'(

201G-%!&9!C*6-:+9+-/D1&/-*!&9!6735

Y8Z8,:"%)

N3$3!:&''-:$+&'H$%3'*9-%!*6--/

!'3C,E=,9'3C,E=,!'>'%)

.3M+101!'01G-%!&9!:&''-:$+&'*!$&!&$B-%!6735-%*

A$=$6'%3*&

201G-%!&9!6+-:-*H:&16&'-'$*!+':70/-/!+'!63:E3(+'(

I 3.5

M$2>&"

.3M+101!,-7&:+$5!&9!B+$

1&2"3%&'(,'4,5*$(6"

201G-%!&9!90775!3%$+:073$-/!L&+'$*

,,,CUSTOMER ATTRIBUTES

4&5!+*!366-37+'(!$&!(+%7*8!'3$0%37! 782%82&(6 '0$0%+'(!6%-9-%-':-*;

// /

E7F<7EE!<7F,5GH!H5AE!<9A<59

/ / //

K3$+&!&9!F3+*$"$&"B+6!%3$+&

K3$+&!&9!7-("$&"$&%*&

BATTLE DOLL,LGH9M!NO

!"!#$%&'(!)&*+$+,!"!.-/+01!)&*+$+,!"!.-/+01!2-(3$+,!"!#$%&'(!2-(3$+,-

>> >I =J =< >@ >? =J >>

Hasbro Product Design Team Semester 2

Katie Ingalls WITH SIGNIFICANT CONTRIBUTIONS FROM: Nnamdi Alwabudine | Swapnil Bansal | Kenneth Bayus Aaron Johansen | Eric Ross | Paul Yen An overview of the work done for the Hasbro Consumer Product Design project for the Spring 2011 term. Work done as a team for the “Battle Doll” concept development, including system architecture and interface documentation, verification test plans, risk management, project planning and project execution.

HASBRO PRODUCT DESIGN CORNELL UNIVERSITY PROJECT ADVISOR: DAVID SCHNEIDER

Table of Contents 1 Introduction.................................................................................................................... 3 Transition ..................................................................................................................................... 3 Battle Doll .................................................................................................................................... 3 Overview (CVP) ...................................................................................................................... 3 Concept .................................................................................................................................. 3 Further Details .......................................................................................................................... 4

2 System Architecture & Interface Control Documentation ........................................ 5 2.1 Operations Description Template (ODT) ............................................................................ 5 2.2 Requirements Traceability Matrix ....................................................................................... 6 2.3 State Transition Matrix ........................................................................................................ 11 2.4 Interface Matrix .................................................................................................................. 13

3 System Verification and Test Plan .............................................................................. 14 3.1 Behavioral Test Plan ........................................................................................................... 14 3.2 Test Methodologies for Non-Behavioral Requirements .................................................. 14 3.3 Trace Test Procedures to Originating & Derived Requirements Matric ......................... 15 3.4 Trace Test Procedures to Non-Behavioral Requirements Matrix ................................... 16 3.5 Verification Cross-Reference Matrix ................................................................................ 17

4 Risk Management ....................................................................................................... 18 4.1 Severity Rating System....................................................................................................... 18 4.2 Likelihood Rating System................................................................................................... 19 4.3 Risk Assessment/Risk Priority Number Table .................................................................... 19 4.4 Failure Mode and Effect Analysis (FMEA) Worksheet ..................................................... 21

5 Project Planning and Execution ................................................................................. 23 5.1 Activity Table ...................................................................................................................... 23 5.2 Task Input and Output Matrix ............................................................................................ 25 5.3 Activity (PERT) Graph ......................................................................................................... 26 5.4 Subsystem Decision Matrix ............................................................................................... 28 5.5 Bill of Materials.................................................................................................................... 30 Subsystem Accounting......................................................................................................... 31 Price Point .............................................................................................................................. 32 5.6 Prototyping.......................................................................................................................... 33 5.6.1 Battle Form and User Interface .................................................................................. 33 5.6.2 Joint Actuation ............................................................................................................. 38 5.6.2 Scoring system placement, size and shape ............................................................. 40 5.6.2 Fairness Assurance System .......................................................................................... 44 5.6.2 Electronics System ........................................................................................................ 47 5.7 Gannt Chart ........................................................................................................................ 51

Katie Ingalls : Hasbro Product Design

1 Introduction Transition The report now transitions from individual work to efforts achieved as a team. Concluding the first half of this project, members of DAVANNE LLC toy consulting company visited Hasbro headquarters in Pawtucket, Rhode Island. The work done individually over the past several months was summarized and each member of DAVANNE LLC presented the results of his or her concept to the Vice President of Engineering at Hasbro. Following this visit, a decision was made with regards to which projects would continue development. Of the twelve individually developed concepts, the Project Advisor (David Schneider) and Hasbro’s Vice President of Engineering (Adam Craft) chose two for continuation. The Battle Doll toy concept was one those chosen, and is described in the remainder of this report.

Battle Doll Overview (CVP) “The Battle Doll is designed for the girl of the digital age, which can communicate with other dolls and reacts to accessories and experience programmed into personal battle system.” • • • • • • •

• • • • •

Battle system uses digital-age technology to enhance traditional doll play by increasing variability and longevity of play. Unlike traditional dolls or action figures, battle doll combines elements of both, empowering girls to be strong and independent. Doll can actually sense when a hit has been made, just like a real fight. Unlike other action figures, scoring system and sound effects give REAL outcomes! Battle system displays how well your doll is doing in battle so you can take care of her when needed. The doll “knows” what weapons and clothing she’s wearing, so each fight is different and unique! Battle arena keeps track of win and loss record, and increases doll’s experience accordingly, so your doll can keep growing as you nurture her skills. More experience means a better advantage in your next fight! Fighting accessories (weapons) are modular and assemble-able, so that there’s always a new way of playing. Different weapons have different damage levels and damage types associated with them, giving you a wide range of options for attack. Clothing accessories give doll different strengths and abilities, meaning a wide range of options for defense. Can battle your friends, making gameplay interactive. Can battle monsters, so you can gain experience, even when your friends aren’t around!

Concept The battle doll combines elements of traditional doll play with action figure excitement as well as the nurturing aspects of the digital pet. A concept sketch is shown below, in Figure 1.

Katie Ingalls : Hasbro Product Design

Figure 1: Battle Doll concept sketch

Further Details The initial Battle Doll concept was generated and detailed by Kat Ingalls (B.S. Mechanical Engineering, 2011). For further details, please refer to Report 1 on her individual work for the first half of concept development. All work detailed in this report can be found in its original format in the Appendix, which is included on the accompanying CD.

Katie Ingalls : Hasbro Product Design

2 System Architecture & Interface Control Documentation 2.1 Operations Description Template (ODT) The operational description template (referred to as ODT from this point forward) is an important organizational document which is a compilation of all originating and derived requirements divided into subsystems and organized by use cases. Three tiers of subsystems were used into which these requirements were organized: three high-level subsystems, six mid-level subsystems, and 13 low-level subsystems. The organization of these subsystems is shown below in Figure 2.

Figure 2: ODT Subsystem Organization

All the originating requirements from use cases were then entered into the ODT with the requirements categorized into appropriate low-level subsystems. By organizing the requirements in this manner, it was discovered that the interfaces between subsystems was not adequately defined by our original use cases. To define the subsystems better, additional requirements were added at these. An example of adding requirements near these interfaces is shown below in Figure 3. The requirement in red was added after reviewing the requirements required of the battle device form system. Although this requirement was implied, it was never explicitly stated in the original use cases.

Figure 3: Adding interface requirements.

The ODT was also modified to track the states of the battle doll. Twenty-two states were created which completely define the system, which are discussed further in Section 2.3.

Katie Ingalls : Hasbro Product Design

The ODT was useful in evaluating the relationships between the system architecture. The full ODT table is located in the Appendix. Due to the length and complexity of the ODT, it can be difficult navigate when looking for information. For this reason, the ODT was further analyzed to distinguish relevant information. The next sections document the analysis our group performed on the ODT.

2.2 Requirements Traceability Matrix After constructing the ODT, the requirements that had resulted from all use cases were compiled. These requirements were then refined, analyzed and sorted for categorization. In order to check for completeness, team member collected and sorted the requirements of another member’s use case. The requirements were also checked for the appropriate level of specificity. Statements that required too little room for maneuverability were refined so that other design options could be considered; conversely, statements that were too general were modified to be clear what was to be measured. While constructing the ODT, the derived requirements (DRs) were highlighted in order to differentiate them from originating requirements (ORs). Originating requirements are those that have been defined by the user; they constitute the core functionality of the system design and are informed by the customer affinity process. Derived requirements are needs that have been deduced from the originating requirements, and can be traced back to them. After requirements statements were checked for completeness and level of specificity, they were then compiled into separate tables of originating and derived requirements. Refinement was necessary to eliminate duplicate requirements between use cases, and to combine requirements that necessitated the same outcome, but were worded slightly differently. To see an example of the documentation of this process, please see Figure 4 below. Changed Items Add? Delete/ Replace? Change type? DR DR DR DR DR DR DR A DR

Behavior Num

Req

4 11 12 13 13 13 13 13

DR.34 DR.61 DR.73 OR.31 OR.30 OR.34 OR.32

DR.48

Description The system shall have a power on/off switch for user Doll's form shall hold weapon firmly

Replace with Req DR.7 DR.30

Weapon accessories shall be removable by significant impact Battle system shall be stored with doll's body in form of backpack. Doll's form shall be able to hold battle system for storage. Battle system shall indicate to user that power is on. Battle system must be able to display conncection status to user. Battle system shall indicate to user that it is not connected (Tamagotchi Mode)

DR.X OR.2 DR.8 DR.4 OR DR

Description Battle system shall have a power switch. Weapon shall be able to be held by doll securely. Same as DR. 30 Traceable to OR.1 Doll's form shall be able to hold battle system for storage. Battle system shall indicate to user that power is on. Battle system shall be able to display conncection status to user. Battle system shall have tamagotchi ("digital pet") mode. Battle system shall indicate to user that it is in Tamgotchi mode.

Figure 4: Modification tracking system for refining requirements.

After this refinement, derived requirements were traced back to their originating requirements. This is important to ensure that the requirements being inferred relate back to the user-specified (originating) needs. It checks to ensure that the requirements are being met. The finalized list of originating and derived requirements are shown in Figure 5, Figure 6 and Figure 7 on the following pages.

Katie Ingalls : Hasbro Product Design

Originating Requirements Index

Originating Requirement

Abstract Function Name

OR.1

Battle system shall be stored with doll's body (for ease of storage)

Storage

OR.2

Doll's form shall be able to hold battle system for storage.

Hold battle system

OR.3

Battle system shall be able to communicate with other battle systems.

System-system communication

OR.4

Battle system shall be powered.

Power

OR.5

Doll-system communication

OR.6

Data shall transfer from doll to system. The system shall be able to determine whether the smart card inserted has data that was previously created by the system.

OR.7

The system shall be able to write the data into the smart card.

Write data

OR.8

The system shall be able to read the data that was previously created by the system.

Read data

OR.9

Doll shall be of uniform size.

Body size

OR.10

The accessories (clothing and weapon) shall be able to be recognized by battle system.

Accessory scannable

OR.11

The clothing accessories shall have HPs and abilities associated with them.

Clothing attributes

OR.12

Doll shall be able to "hold" weapons.

Hold weapons

OR.13

Weapons shall have parts that can assemble into many types of weaponry.

Weapon modularity

OR.14

The weapon accessories shall have damage levels and damage types associated with them.Weapon attributes

OR.15

The battle system shall be able to read win/loss record ("experience") after doll is attached to battle Read experience system

OR.16

The battle system shall be able to translate experience into gameplay advantages.

Experience to gameplay

OR.17

The system shall have play modes to select.

Play modes

OR.18

The system shall request what play mode is desired after doll is equipped.

Play mode request

OR.19

The system shall put on play mode as requested by user

Play mode selection

OR.20

Doll's limbs shall be maneuverable by control mechanism

Control mechanism

OR.21

Control mechanism shall move limb up and down and side to side.

Directional control

OR.22

Control mechanism shall extend limb in punching/kicking motion.

Extension control

OR.23

Controlmechanism shall re-contract limb after extension is made.

Retraction Controll

OR.24

Weapons shall be able to be recognized by battle system.

Weapon reading

OR.25

The doll shall be designed so the weapons do not slip out during battle

No slip weapons

OR.26

System shall not cause harm to user

Safety

OR.27

The battle system shall be able to translate abilities (clothes) to scores calculated when hit.

Clothing to Experience

OR.28

The battle system shall be able to translate experience from scores calculated when hit.

Experience to HP

OR.29

Doll shall be able to register when a "hit" has been successfully made.

Hit register

OR.30

The scoring input shall calculate a score based on the hit.

Hit to score

OR.31

Battle systems shall have means of connecting with doll.

System-doll connection

OR.32

The battle system shall display update scores upon a hit.

Fight stats display

OR.33 OR.34

The doll shall be able to differentiate between being hit by another doll or by a child's hand. The battle system shall alert users that a cheating behavior has occured.

Check previous data

Hit type Alert user of cheating

OR.36

The battle system shall not translate experience to amount of HP reduced/points gained when hit is not made by doll. The battle system shall be able not to translate abilities (clothes) to amount of HP reduced/points gained when hit is not made by doll.

OR.37

The clothing accessory shall be able to be removed by average user in under X seconds.

Clothing time

OR.38

Clothing shall be removable (form-fitting but loose enough to remove)

Removable Clothing

OR.39

Battle system shall have tamagotchi ("digital pet") mode.

Digital pet mode

OR.40

Weapon time

OR.41

The weapon shall be able to be removed by average user in under X seconds. The doll's gameplay algorithm shall be altered accordingly when an accessory is removed or replaced.

OR.42

Information system shall display system status

Display status

OR.43

Doll's form shall noto create injury or damage upon impact to others or objects

Doll form safety

OR.44

Device shall be durable to f1 force and i1 impacts at force f2.

Durable

OR.35

No points when hit is not by doll No abilities when hit is not by doll

Accessory Status

Figure 5: Originating Requirements

Katie Ingalls : Hasbro Product Design

Derived Requirements Index

Derived Functional Requirement

Source OR

Battle system shall be removable.

Removability

OR 1

DR.2

Data transfer system shall be powered.

Data Power

OR.4

DR.3

Battle system shall be able to be placed within communication distance of other system.

Communication distance

OR 5

DR.4

Battle system shall be able to lie flat.

Flat surface

OR 42

DR.5

Battle system shall be able to display conncection status to user.

Connection status

OR 42

DR.6

Battle system shall have communication connection.

Communication connectioin

OR.3

DR.7

Communication connection shall be powered.

Power to com connect

OR.4

DR.8

Battle system shall be able to be powered off.

Power switch

DR.9

Battle system shall indicate to user that power is on.

Power on

DR.10

Data transfer shall have means of communicating between system Data transfer and doll.

DR.11

Battle system shall have means to transfer data to doll.

Battle system transfer

OR 31

DR.12

Battle system shall have data transfer plug.

Data transfer plug

OR 31

DR.13

Data transfer cord shall be long enough to have needed distance between two systems

Data cord length

OR 3

DR.14

Data transfer cord shall connect doll's body and battle system.

Connection route

OR 31

Data system shall communicate to info system that connection is established. Battle system shall indicate to user that a connection has been established.

Connection established system Connection established user

DR.17

Data transfer mechanism shall send data to other battle systems.

Data sending

OR 3

DR.18

Data transfer mechanism shall receive data from other battle systems.

Data receiving

OR 3

DR.19

The card reader shall transfer the data to battle system.

Transfer data

OR 8

DR.20

The card reader shall not transfer the data to battle system due to cheating.

No transfer after cheating

OR 33

DR.21

The system shall display "corrupted data" in not able to be read

Display "Corrupted data"

OR 8

DR.22

The system shall be able to detect wheather the data has been modified/hacked by other device.

Check for modified data

OR 8

DR.23

Clothing shall be of uniform measurement (to fit doll).

Uniform clothing

OR 9

DR.15 DR.16

DR.24 DR.25

The battle system shall be able to read codes/sensors on clothing accessory items. The battle system shall be able to recognize attributes of clothing accessory items.

OR.4 OR.42 OR 5

OR 5 OR 42

Read clothing

OR 10

Read clothing attriibutes

OR 11

DR.26

Weapons shall be able to be held by doll.

Weapon holding capability

OR 12

DR.27

The battle system shall be able to convert clothing attributes to gameplay.

Clothing to gameplay

OR 27

DR.28

Battle system shall communicate to user that clothing is equipt.

Clothing equipt

OR 42

DR.29

Doll shall be able to maneuver with weapons.

Range of motion weapons

OR 21

DR.30

Doll shall have continued interface with weapon throughout battle. Weapon interface

OR 25

DR.31

Weapons shall not cause child to be cut or otherwise injured.

Weapon harm

OR 26

DR.32

The battle system shall be able to read codes/sensors on weapon accessory items.

Read weapon

OR 10

DR.33

Information display system shall displays power on message

Show Power On

OR.42

DR.34

Information display system shall ask user for play mode input

Show Ask input

OR.42

DR.35

The system shall accept play mode input from user

Accept Play mode

OR.17

DR.36

The system provides power to all toy circuitry

Provide power

Figure 6: Derived Requirements

Function Name

DR.1

Katie Ingalls : Hasbro Product Design

OR.4

Derived Requirements Index

Function Name

Source OR

DR.37

Information system shall display play mode selected

Show Play mode selected

OR.42

DR.38

Information system shall inform user that game has begun

Show game started

OR.42

DR.39

Doll's legs shall be maneuverable by control mechanism.

Leg maneuver

OR 20

DR.40

Control mechanism shall extend leg in kicking motion.

Extend leg

OR.22

DR.41

Control mechanism shall retract leg after kicking motion is made.

Retract leg

OR 23

DR.42

The force of the doll's kick shall be a maximum of w lb of force.

Kick force

OR 20

DR.43

The force of the doll's punch shall be a minimum of q lbs of force

Punch force

OR 20

DR.44

Scoring mechanism shall record a hit

Record Hit

OR.30

DR.45

Information system shall display the hit being recorded

Show hit recorded

OR.42

DR.46

Both of the doll's arms shall be maneuverable by control mechanism.

Arm maneuver

OR 20

DR.47

Control mechanism shall retract arms after punching motion

Arm retract

OR 23

DR.48

Control mechanism shall extend arms in punching motion.

Arm extend

OR 22

Source of hit

OR.33

Scoring-Gameplay communication

OR.16

HP algorithm

OR.27

Experience algorithm

OR.28

Experience display

OR.32

DR.49 DR.50 DR.51 DR.52 DR.53 DR.54 DR.55

Derived Functional Requirement

The doll shall be able to differentiate between being hit by another doll or by a child's hand. Data shall be transferred between the scoring and gameplay algorithms. The gameplay algorithm shall determine change in HP based on the hit. The gameplay algorithm shall determine experience gained based on the hit. The battle system shall display experience gained to the player who initiated the successful hit. The data transfer hardware system shall transfer cheating flag from fairness system to data acquisition system. The game play algorithm shall drop/cancel game when cheating behavior has occered X times in a single round.

Fairness alerts data acquisition of cheating Cancel game due to cheating

OR 34 OR 34

DR.56

The clothing removal system shall not contain pinch points.

Pinch Points

OR 20

DR.57

The scanning system shall recognize that clothing has been removed.

Clothing removed

OR 10

DR.58

The data transfer system shall be continually updating.

Update

DR.59

The doll's gameplay algorithm shall be altered accordingly when clothing is removed or replaced.

Clothing update

OR 41

DR.60

Weapon shall be sized to be held by doll's hand.

Weapon Size

OR.12

DR.61

Doll shall be sized to be storable in a volume of s cm^3

Doll Size

OR 1

DR.62

Battle System shall be sized to be storable in volume of s_2 cm^3

Battle System Size

OR 1

DR.63

Accessories shall be sized to be storable in a volume of s_3 cm^3

Accessory Size

OR 1

DR.64

Doll shall release weapon with proper application of tension

Release Weapon

OR 12

DR.65

Information system shall display that the doll is/ is not connected

Display Connected

OR.42

DR.66

Doll s form shall be sized to be held by a child's hand

Doll Form Size

DR.67

Clothing and weapons shall remain equiped when doll is handled quickly

Equip Clothing and Weapons

OR.25

DR.68

Doll's form shall be flexible and robust to handle impacts

Flexible Form

OR 44

DR.69

Battle device system shall be able to obsorb doll impact

Absorb Impact

OR 44

Water Resistant

OR 44

Tamagotchi mode

OR.39

DR.70 DR.71

Doll's form shall be resistant to water for up to 1 minute before retrieval Battle system shall indicate to user that it is not connected (Tamagotchi Mode)

OR 3

OR.9

DR.72

Battle system shall switch from tamagotchi game mode

Switch tamagotchi

OR.39

DR.73

The doll's gameplay algorithm shall be altered accordingly when a weapon is removed or replaced.

Algorithm update

OR 41

Figure 7: Derived Requirements (cont'd)

Katie Ingalls : Hasbro Product Design

DR.1

OR 1

DR.2

OR.4

DR.3

OR 5

DR.4

OR 42

DR.5

OR 42

DR.6

OR.3

DR.7

OR.4

DR.8

OR.4

DR.9

OR.42

DR.10

OR 5

DR.11

OR 31

DR.12

OR 31

DR.13

OR 3

DR.14

OR 31

DR.15

OR 5

DR.16

OR 42

DR.17

OR 3

DR.18

OR 3

DR.19

OR 8

DR.20

OR 33

DR.21

OR 8

DR.22

OR 9

DR.24

OR 10

DR.25

OR 11

DR.26

OR 12

DR.27

OR 27

DR.28

OR 42

DR.29

OR 21

DR.30

OR 25

DR.31

OR 26

DR.32

OR 10

DR.33

OR.42

DR.34

OR.42

DR.35

OR.17

DR.36

OR.4

DR.37

OR.42

DR.38

OR.42

DR.39

OR 20

DR.40

OR.22

DR.41

OR 23

DR.42

OR 20

DR.43

OR 20

DR.44

OR.30

DR.45

OR.42

DR.46

OR 20

DR.47

OR 23

DR.48

OR 22

DR.49

OR.33

DR.50

OR.16

DR.51

OR.27

DR.52

OR.28

DR.53

OR.32

DR.54

OR 34

DR.55

OR 34

DR.56

OR 20

DR.57

OR 10

DR.58

OR 3

DR.59

OR 41

DR.60

OR.12

DR.61

OR 1

DR.62

OR 1

DR.63

OR 1

DR.64

OR 12

DR.65

OR.42

DR.66

OR.9

DR.67

OR.25

DR.68

OR 44

DR.69

OR 44

DR.70

OR 44

DR.71

OR.39

DR.72

OR.39

DR.73

OR 41

OR.44

OR.43

OR.42

OR.41

OR.40

OR.39

OR.38

OR.37

OR.36

OR.35

OR.34

OR.33

OR.32

OR.31

OR.30

OR.29

OR.28

OR.27

OR.26

OR.25

OR.24

OR.23

OR.22

OR.21

OR.20

OR.19

OR.18

OR.17

OR.16

OR.15

OR.14

OR.13

OR.12

OR.11

OR.10

OR.9

OR.8

OR.7

OR.6

! !

! ! !

OR 8

DR.23

OR.5

OR.4

OR.3

OR.2

OR.1

After all derived requirements were traced back to their originating requirements, this was tracked visually using a Derived Requirements Matrix, also known as a Requirements Traceability Matrix. This is to provide further evidence that project requirements are being met. The Requirements Traceability Matrix is shown in Figure 8.

! !

! ! !

! !

! ! !

! !

Figure 8: Requirements Traceability Matrix

10 Katie Ingalls : Hasbro Product Design

! ! ! !

2.3 State Transition Matrix In order to track the condition of the states described in Section 2.1, a state transition matrix was developed. The system had various electrical and mechanical states associated with it. These states were constantly changing and sometimes a change in one state could result in the change in several others. A state transition matrix was created to trace the state changes, and to ensure that all states were documented. To do this, state definitions and the manner in which they changed were determined. The states defined were to cover all scenarios that occurred when the toy is in operation. The table below shows the finalized state descriptions: Number 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

State Battle system on/off System connected / not connected Doll Connected /not connected Battle System/Doll Communication on/off Battle system /Battle System Communication on/off Card Inserted/not inserted Scanner on/off Fairness on/off Data Loaded/Unloaded Corrupted Data Yes/No New Data Yes/No Clothing On/Off Clothing Data loaded/unloaded Weapons On/Off Weapons loaded/unloaded Play Mode Selected / Not Selected Arm Not Extended/ Extended Leg Extended/Not Extended Hit Registered/Unregistered Score Calculated/Uncalculated Cheating flag on/off Battle Stand set up/not set up Tamagotchi mode on/off Figure 9: States describing Battle Doll system

The states selected include all subsystems associated with the battle doll. The way in which different elements of these subsystems would interact and how to represent this interaction in the state transition matrix was also considered. These states were then combined according to what order they would occur. First, an initial set up state was created which described the initial condition of the doll before any connection or data transfer had occurred. The table below illustrates the states which constitute the initial set-up phase.

Katie Ingalls : Hasbro Product Design

Initial Setup Defined as Battle system OFF Doll NOT CONNECTED Battle System/Doll Communication OFF Battle system /Battle System Communication OFF Card NOT INSERTED Scanner OFF Fairness OFF Data UNLOADED Corrupted Data NO New Data NO Clothing OFF Clothing Data UNLOADED Weapons OFF Weapons UNLOADED Play Mode NOT SELCTED Arm NOT EXTENDED Leg NOT EXTENDED Hit NOT REGISTERED Score NOT CALCULATED Cheating OFF Battle Stand NOT SET UP Tamagotchi mode OFF Figure 10: Initial setup definition.

After this initial set-up phase was created, the states were then changed according to what how they interacted with each other. For example, in the sample state transition matrix shown below, the state “initial setup” changes to the state “Battle System ON” when the battle system is turned on. This sort of relationship is then repeated for the other states with the entry in the cell signifying what event occurred before the state is the row changes to the state in the column (see Figure 11). For a full view of the entire state transition matrix, see Appendix. Initial Set Up Initial Set Up

Battle System ON

Doll Connected

Battle System - Doll Communication ON

"Turn on"

Battle System ON

"Connect Doll" "Establish Communication"

Doll Connected Battle System - Doll Communication ON Figure 11: Portion of State Transition Matrix

12 Katie Ingalls : Hasbro Product Design

2.4 Interface Matrix The Hasbro Battle Doll design team created an interface matrix in order to describe the interfaces between systems and subsystems. This matrix, due to its size, is provided in the Appendix of this report. The purpose of the matrix was to explore and then organize the ways in which the subsystems interact. The method used to construct the interface matrix used the ODT discussed earlier in this section. The columns of the ODT – the subsystems of the Battle Doll - were used to generate a set of interfaces. Once this set was generated, the interface specifications were detailed in the ODT’s row. With systems and subsystems comprising the leftmost column and topmost row, it became very clear which specific pieces of information, and which specific actions, were taking place across the Hasbro Battle Doll. The interfaces (pieces of information, specific actions, etc.) of information were filled into the body of the Interface Matrix. The end result was an organized systems engineering tool that allowed the design team to clearly identify information flow, and have insight to issues/consequences between subsystems or overall design changes.

Katie Ingalls : Hasbro Product Design

3 System Verification and Test Plan 3.1 Behavioral Test Plan Behavioral test plan give a detailed description on how to perform the tests used as the final verification that requirements have been satisfied. The test procedure was broken down into test method, test facilities, entry condition and exit condition. The test method states the actual steps that an operator needs to do in order to conduct the verification process. The test facilities give details on where the test should be performed and what items were involved. Lastly, the entry condition and exit condition gives information on the condition of the system before the test and the expected result after the test has been performed.

Figure 12: Example of behavioral test plan

3.2 Test Methodologies for Non-Behavioral Requirements Non-behavioral test plans are similar to behavioral test plans in that they both lists test method, test facilities, entry condition and exit condition. In addition, non-behavioral test plans also include verification methods which specify whether the test is an analysis, inspection, demonstration, or physical test. This information is useful when the scheduling different verifications, for example, an analysis verification should be scheduled prior to a physical test. An example of the test plan for non-behaviors is included below.

Figure 13: Example of non-behavioral test plan

Please refer to the Appendix for the full test plan procedures.

14 Katie Ingalls : Hasbro Product Design

3.3 Trace Test Procedures to Originating & Derived Requirements Matric It is important to ensure that the test procedures do, in fact, verify that requirements are met by the design. In this project, it was easy to create test procedures that seem important, but upon further review, do not test anything of value. By tracing the test procedures back to specific documented requirements, one can verify exactly what is being tested and just how important that test can be. A sample document showing this tracing procedure is found below in Figure 14. Master Tracing Test Procedure TP.1 TP.2 TP.3 TP.4 TP.5 TP.6 TP.7 TP.8 TP.9 TP.10 TP.11 TP.12 TP.13 TP.14 TP.15 TP.16 TP.17 TP.18 TP.19 TP.20 TP.21

Originating Requirements OR.1 OR.3 OR.4 OR.10 OR.12 OR.16, OR.27, OR.28, OR.32 OR.39 OR.39 OR.38, OR.37 OR.15 OR.7 OR.43 OR.21 OR.15 OR.16, OR.17, OR.18, OR 19 OR.20, OR.21, OR.22, OR.23, OR.24

Derived Requirements DR.10, DR.11, DR.12, DR.14, DR.15, DR.16 DR.3, DR.5, DR.17, DR.18, DR.19 DR.2, DR.7, DR.40 DR.25, DR.29, DR.34, DR.35 DR.27 DR.58, DR.59, DR.60, DR.61 DR.87 DR.72, DR.73, DR.88 DR.72, DR.73 DR.79, DR.74 DR.75,DR.76, DR.77 DR.80 DR.81, DR.82, DR.83, DR.84, DR.85, DR.86 DR.44,DR.45 DR.37 DR.38 -‐ DR.42 DR.49, DR.50

Figure 14: Test precedence matrix

Katie Ingalls : Hasbro Product Design

3.4 Trace Test Procedures to Non-Behavioral Requirements Matrix Non-Behavioral requirements of the Hasbro Battle Doll are those requirements that have distinct performance criteria that can be measured. Traditional behavioral requirements are more binary – meaning that the system either can accomplish that function, or it can’t. Tracing test procedures to the non-behavioral requirements matrix allowed the design team to quickly outline which of the originating requirements had performance criteria. These criteria were kept in mind throughout the design process, and test procedures for each associated originating requirement were generated. Figure 15 below traces test procedures to non-behavioral requirements: Requirement OR.4

Non-‐Behavioral Requirement Data transfer system shall be powered at 1 watts/second

Abstract Name

Test Procedure

Data Power

TP.3

OR.3

Battle system shall contain infrared sensor sensitive to 2 ft

Sensor

TP.2

OR.42

Information display system shall displays power on message with 5 bars

Show Power On

TP 19

OR.42

Information display system shall ask user for play mode input for 60sec after start

Show Ask input

TP 20

Accept Play mode

TP 20

Provide power

TP 20

Extend leg

TP. 18

Show hit recorded

TP 21

OR.17

OR.4

OR.22

OR.42

The system shall accept play mode input from user for 60 seconds The system provides power to all toy circuitry at 6 watts/second Control mechanism shall extend leg in kicking motion in <2 sec Information system shall display the hit being recorded in <1ms

OR.16

Data shall be transferred between the scoring and gameplay algorithms in <1ms

Scoring-Gameplay communication

TP.6

OR.27

The gameplay algorithm shall determine change in HP based on the hit in < 1ms

HP algorithm

TP.6

OR.39

Battle system shall initiate tamagotchi game mode if 60 sec pass without game mode selection

Initiate tamagotchi

TP.8

Figure 15: Test Procedures and Non-Behavioral Requirements

16 Katie Ingalls : Hasbro Product Design

3.5 Verification Cross-Reference Matrix

OR.43

x x

Satisfies a DR?

OR.39

OR.32

OR.38

OR.28

OR.37

OR.27

OR.24

OR.23

OR.22

OR.18

OR.21

OR.16

OR.20

OR.17

OR.19

OR.16

OR.15

OR.12

OR.7

TP.8

TP.3

OR.4

TP.2

OR.3

OR.1

TP.7

TP.1

OR.10

The verification cross reference matrix was developed during design to track the alignment between test procedures and originating requirements. The Hasbro Battle Doll VCRM is provided in Figure 16 below. This systems engineering tool seeks to ensure that requirements are being met through testing.

x x x x

TP.4

TP.5 TP.6

TP.9

TP.10

Y x

TP.11

TP.12

TP.13

Y Y

TP.14

TP.15 TP.16

x x

TP.17

TP.18 TP.19 TP.20 TP.21

x x

Figure 16: VCRM

Some test procedures for the Hasbro Battle Doll were written strictly for derived requirements. For these instances, an additional column was added to the VCRM (which is an atypical practice) to capture that the test procedure did carry a derived-requirementonly purpose. Originating requirements with no associated test procedures created null columns, which were omitted here.

Katie Ingalls : Hasbro Product Design

4 Risk Management 4.1 Severity Rating System The design team used a severity rating system in conjunction with a likelihood rating system (next section) to evaluate the various failure modes that were possible with the Hasbro Battle Doll. This systems engineering tool applies a defined, quantitative scale to the severity of each failure. Figure 17 below defines the 1-10 scale that was used where 1 corresponds to non-severe failure and 10 corresponds to a highly severe failure.

Severity 1 2 3 4 5 6 7 8 9 10

Description

Explanation

None Very minor Minor Very low Low Moderate High Very High Hazardous With Warning Hazardous Without Warning

Variation within performance limits Variation correctible during production Reparable within 10 min Reparable within 30 min Reparable within 1 hour Reparable within 4 hours Not worth repair; degraded functionality or capability Not worth repair; mission failure Affects safety of operator and others but with advance warning Affects safety of operator and others with no advance warning

Figure 17: Severity rating system used

The quantitative scale used safety, repair and performance to divide severity ratings into three distinct levels. If the design team recognized that safety was compromised due to a failure mode, it would be marked with a 9 or 10 on the scale. For a non-working toy that would require repairs, an estimated repair time was used (levels 3-8). For failure modes that would still allow the user to operate the Hasbro battle doll, the degradation in performance was used (levels 1 and 2). While some failure modes were measurable, other failure modes required estimates – effectively a qualitative assessment using a quantitative scale. This prompted the design team to aggregate severity ratings into an average to mitigate individual bias that could occur during subjective assessments.

18 Katie Ingalls : Hasbro Product Design

4.2 Likelihood Rating System The design team also assessed each failure mode for its likelihood to occur. Similar to the severity rating system, the likelihood rating system used a quantitative scale of 1-10 with defined by the mean time between failures (MTBF). When the likelihood (or occurrence) was 1, it meant that the user would rarely experience the failure. When the likelihood is 10, it meant that the user would experience the failure very often. Figure 18 below defines the likelihood rating system that was used.

Figure 18: Likelihood rating system

The likelihood and severity ratings for failure modes for the Battle Doll system can be found in the Appendix. Similar to the activity that took place for the severity rating system, the DAVANNE LLC design team averaged the assessed likelihoods to mitigate bias and error.

4.3 Risk Assessment/Risk Priority Number Table The design team used criticality ratings in order to numerically prioritize and weigh the risks of the Hasbro Battle Doll. The sub-ratings used to calculate criticality were the severity and likelihood rating systems. The formula used was: Criticality Ratings Min Max High 70 100 Medium 30 69

Severity x Likelihood = Criticality

The severity and likelihood scales used a 1-10 rating system defined in sections 4.1 and 4.2 above. The criticality ratings parsed apart the range of products of severity and likelihood into the groupings seen in Figure 19 at left. The numerical Low 1 29 system allotted approximately 30% of the available range to Figure 19: Criticality ratings both low and high risks, and the middle 40% of the range to medium risks. The definition used by the design team for each criticality range is defined in Figure 20 below. These definitions allowed the team to verify when critical Hasbro Battle Doll characteristics were being met: 1) Whether or not the game could be played, 2) The user’s experience (e.g. value of the toy) and 3) the safety in operating the Hasbro Battle Doll.

Katie Ingalls : Hasbro Product Design

Definitions

High Medium Low

of the toy may be lost. Safety has been compromised. The game cannot be played. The value The game can be played. The user experience may be diminished. Safety may be reduced. The game can be played. The user experience is only temporarily diminished. Safety has not been reduced. Figure 20: Criticality ratings - range definitions

The failure modes and their associated risk assessment ratings were completed by every member of the Hasbro Battle Doll design team. The significance of these assessments was their impact upon guiding which testing should take place during prototyping efforts. For example, and significant failure mode identified was that of how the Battle Doll itself would remain attached and standing during gameplay – which became an independent prototyping exercise for the design team. Figure 21 below contains the failure modes and risk assessments for the Hasbro Battle Doll. Failure

Assessment

Criticality

Failure to remain attached to surface during gameplay

High

Failure to keep doll attached to stand during gameplay

High

Failure of the stand during gameplay (material) Failure to provide a physical connection to another battle doll stand Failure to establish connection between 2 battle systems.

High

Medium

Failure to provide sufficient electricity to battle system Failure to establish connection between battle system and doll's body. Failure to receive input from user (button failure)

Medium

Arm does not respond when actuator activated

Medium

Failure to communicate battle stats to user (stats or score).

Medium

Failure to communicate connection status.

Medium

Failure to record a proper hit Failure to communicate correctly with sensor system (the hit sensor subsystem) Failure to transfer data properly.

Medium

Low

Failure to move in prescribed method

Low

Leg does not respond when actuator activated

Low

Failure to integrate proper hit zones into doll's form Failure to create hit zone size, shape and placement that allow the control system to move limbs and accessories to strike zones Arm cannot move at all

Low

Failure to display data to user (viewing angle)

Low

Failure to generate correct game statistics. (Software failure)

Low

Failure to generate correct game statistics Failure to hit zone performance due to accessory interference (accessory blocks a hit zone) Failure to provide stable current to battle system

Low

Failure to move in prescribed method

Low

Leg cannot move at all Failure to detect proper hits - All hits detected from single hit zone (an indicator that the hit triggers may have been tampered with)

Low

Figure 21: Failures and risk assessments for the Hasbro Battle Doll

20 Katie Ingalls : Hasbro Product Design

4.4 Failure Mode and Effect Analysis (FMEA) Worksheet A failure mode and effect analysis (FMEA) is a procedure in product development used for analysis of potential failure modes within a system. A good FMEA helps the team identify the risks involved with a particular component in a system and design the risk out of the system hence reducing the cost of repairs and increasing the quality of the product. In developing an FMEA, it is important to identify the failure mode which is an error or defect in the process or design of the item and the effect which deals with the consequence of this failure. The team constructed an FMEA matrix in an effort to qualify the identified failure modes and potential causes with the different subsystems. To do this, each team member created a prototype of a particular function in a subsystem and during testing found several areas in which a component could fail and what the effect of this failure would be on the overall goal of the system. After the failure mode was identified, the effect of this failure was then identified and these were classified into three separate levels. The first was local which means is the effect of this failure limited to just the subsystem affected? The second was a system failure effect in which the whole system was affected and the last level was mission in which the whole mission of the system was jeopardized due to this failure. After these effects were stated, the team then explored the possible causes of each failure. A failure effect severity number was then assigned to each failure and also an occurrence likelihood number. These two numbers were then calculated to get the risk priority number (RPN). Finally, a criticality value was assigned to the risk based on if the RPN value. The values of this criticality could either be low, medium or high. The team decided on a critical RPN value of above 50, meaning any RPN value above 50 needed to be revisited and re-designed to reduce this RPN number. Also any changes which could be made to increase the quality or reliability of the product was documented in the corrective action section. The team also created a person responsible section to keep track of who identified these risks and made changes to it. The table below shows a snapshot of the FMEA derived. The full FMEA may be viewed in the appendix attached with this document. Failure Effects Failure Mode#

F.10

F.11

F.12

Identification Failure Mode of Item

Battle Doll Stand

(a. Local b. System c. Mission)

Failure to remain c. Unable to attached to continue surface during playing gameplay

Battle Doll Stand

Failure to keep c. Unable to doll attached continue to stand during playing gameplay

Battle Doll Stand

Failure of the stand during gameplay (material)

c. Unable to continue playing

Possible Cause

(1) Using an improper play surface

Corrective Action (a. design, b. manufacturing process, c. operation)

Occurrence Likelihood

Risk Priority Number

Criticality

(under current design)

(=severity * occurrence)

(Corrective Action Priority)

High

Failure Effects Severity

(1-c) Use a proper, clean surface

(2) Suction cup (2-a) More becomes suction design detached (1) Doll's leg becomes loose due to excessive rotation (2) Doll's leg becomes loose due to excessive force applied

(1) More robust design (2-c) Use of less force by operators (desired age group)

(1) Cyclic loading of stresses

(1-a) Use stronger materials

(2) Excessive impact force

(2-c) User "manhandles" the stand

Figure 22: Portion of FMEA

Katie Ingalls : Hasbro Product Design

From the FMEA above, we notice that the failures with an RPN value of over 50 are colored in red to distinguish them from less critical failures. In analyzing these failures, we notice that the most critical failures occur with the battle doll stand. This is because several minute parts have to be used in the design of the stand and since it will be connected to the doll constantly, the wear and stress on these parts could cause breakage. If any part of the doll is no longer functional, it disrupts the integration between the doll and the stand hence undermining our game play. The team then analyzed the critical failure modes and a corrective action was then suggested which if implemented would drastically reduce the RPN number. The first failure mode analyzed was failure F.10 or “Failure to remain attached to surface during game play.” With this failure, we see that if the system cannot remain secured while in use, it would constantly tip over which will reduce ensure that our dolls cannot battle one another. A way to reduce this would be simply to make sure the surface area is suitable for use before game play is initiated. A more complex solution would be to provide a better design of a suction cup which would ensure that no matter what surface the doll is attached on, it remains stable. Doing this would reduce the occurrence of the doll getting detached. Hence, that number would reduce from 8 to 4 thereby reducing the RPN number to 40. The second critical mode analyzed was failure F.11 or “failure to keep doll attached to stand during game play.” This was very similar to the previous failure mode and we found that with a more robust design we can reduce the occurrence from 8 to 4 as well hence reducing the RPN number to 40. The final failure mode analyzed was failure F.12 or “Failure of the stand during game play (material)”. This dealt with material failure or wear and tear on the structure of the device due to use. The effect of this failure would be the user would be unable to continue playing with the doll as it would be missing some vital pieces needed for game play. We found that by using stronger materials to build the stand and with careful handling, we were able to reduce the occurrence of this failure from 7 to 3. Hence, the RPN number went from a 70 to 30. In conclusion, we found that with effective prototyping, we were able to identify the risks associated with different subsystems. Also, after these risks were identified, we were able to find out what risks could undermine the operation of our system and take actions to reduce these risks.

22 Katie Ingalls : Hasbro Product Design

5 Project Planning and Execution 5.1 Activity Table Careful planning was an extremely important and necessary step due to the complexity of the various systems involved in the battle doll. In order to ensure that all of the major components were suitably designed and in compliance with requirements an activity table detailing the necessary work was generated, see Figure 23. There were four major activities which were determined to be the most important: developing the subsystem requirements (ODT), developing prototyping design plans, building the prototypes and testing the prototyped systems. Each of these activities was further divided into more activities which were determined based upon the subsystems. The major activities were given numbers, such as A.01, for identification purposes. The behavioral test plans which corresponded to the appropriate testing activities were also included. The estimated amount of work required for each of these tasks was recorded, and then upon completion of the project the final amounts of work completed, additional work completed and work remaining were recorded. Additional work completed corresponds to time spent on the activity which was not originally budgeted in the time estimates. Lastly the percentage of the task completion was calculated based upon the duration and the work completed. The activity table served as a useful organizational tool for determining all of the activities which needed to be completed for the prototyping phase. It was also the first step for generating the task input and output matrix and activity (PERT) graph.

Katie Ingalls : Hasbro Product Design

Percent Complete

Develop subsystem requirements (ODT construction)

25 hrs

100%

A.02

Develop Prototyping Design Plans

29 hrs

22!

!76%

Determine electronic equipment required

5 hrs

100%

Determine user preferences

2 hrs

100%

Method for connecting systems

4 hrs

100%

Attributes in use during gameplay

1 hr

100%!

Accessories and weapons database

5 hrs

40%

How accessories are read

2 hrs

50%

Power required by system

2 hrs

50%

Final Doll Dimensions

2 hrs

Gameplay Algorithm

3 hrs

100%

Specs of hit input data

1 hr

100%

Determine range of motion without accessories

1 hr

100%

Determine range of motion with accessories

1 hr

100%

Build Prototypes

79 hrs

51%

Code the algorithms Develop connections between doll and battle system Integrate gameplay algorithm with data transfer

6 hrs

100%

4 hrs

100%

4 hrs

100%

Establish connection between two battle systems

4 hrs

100%

Wiring of power system

4 hrs

100%

Wire the hit sensors

4 hrs

100%

Connect arm joints

2 hrs

Connect leg joints

2 hrs

Build arm actuators

4 hrs

Build leg actuators

4 hrs

Connect actuators to doll

6 hrs

Display user interface

3 hrs

33%

Model form (shape / size)

3 hrs

Model buttons

1 hr

8 hrs

2 hrs

0% 83%

A.03

Build doll-battle system connection Build physical connection between two battle systems Build doll-stand connection

6 hrs

Build surface-stand connection

6 hrs

83%

Paint hitzones

2 hrs

100%

Refine range of motion A.04

Additional Work

Work Remaining

Work Completed

Duration

A.01

Activity #

Prototyping Activity Table

Test Prototyped Systems

4 hrs

100%

45 hrs

36%

TP.18

Test arm control mechanism

4 hrs

TP.18

Test leg control mechanism

4 hrs

TP.18

Test joint movements

4 hrs

TP.21

Test hitzone geometry

8 hrs

50%

TP. 17

Test the stand

3 hrs

100%

TP.6

Test battle system interface

1 hr

TP.12

Test battle system form

3 hrs

TP.2

Test data transfer between two systems

5 hrs

100%

TP.3

Test power systems

4 hrs

100%

Figure 23: Activity table which outlines required tasks for prototyping.

24 Katie Ingalls : Hasbro Product Design

5.2 Task Input and Output Matrix While the activity table is useful for determining all of the activities which need to be completed, it does not show any of the interdependencies between the tasks. The task input and output matrix is useful for resolving potential problems between different tasks, see Figure 24. Develop subsystem requirements (ODT construction)

(row) task supplies to (column) task

A.01 Develop subsystem requirements (ODT construction)

A.01

Develop Prototyping Design Plans

A.02

Build Prototypes

A.03

Test prototyped systems

A.04

Test joint movements

TP.18

Test hitzone geometry

TP.21

Test the stand

TP. 17

Test battle system interface

TP.6

Test battle system form

TP.12

Test data transfer between two systems

TP.2

Test power systems

TP.3

Develop Prototyping Design Plans

A.02 Subsystem Requirements and Interface Specifications

Build Prototypes

A.03 Subsystem Requirements and Interface Specifications

Test prototyped Test joint systems movements

A.04

Test hitzone geometry

TP.18

TP.21

Hits using actual doll

Test the stand

TP. 17

Test battle system interface

TP.6

Test battle system form

TP.12

Test data transfer between two systems TP.2

Test power systems

TP.3

Subsystem Requirements and Interface Specifications

Design Specifications and Drawings

Completed prototypes

x x x

Working user interface

x x Power available

Figure 24: Task input and output martix

The first step in creating the matrix was to determine the deliverable which was the end product for each activity. This deliverable was then written in the corresponding row under the column for the activity which required the deliverable as input. For example, activity A.01 has “Subsystem Requirements and Interface Specifications” as its deliverable. This is a required input for activities A.02, A.03, and A.04, so it appears under those corresponding columns. This matrix can then be used to determine if any of the activities are in conflict: no two activities should have both inputs to each other and no two activities should have both outputs to each other. The activities underneath A.04 were checked for conflicts in this manner. The activities within the testing section were broken down by their identifying test procedure (TP) elements and their deliverables were checked for consistency in order to ensure no conflicts. The broader activity categories (A.01-A.04) were not broken down into as much detail since the majority of the prototype design and build phases were completed during the duration of the project. The task input and output matrix provided the framework for mapping the deliverables to their necessary tasks and served to ensure that no conflicts would arise due to activities sharing inputs or outputs.

Katie Ingalls : Hasbro Product Design

5.3 Activity (PERT) Graph An activity graph was generated using Microsoft Project 2010 software in order to provide a baseline estimate for the completion time and to determine the critical tasks in the prototyping phase, see Figure 25.

Figure 25: PERT chart

The critical tasks are identified by red boxes in the diagram, and the critical path (using task numbers) was determined to be: 1→8→11→12→14→15→17→35→46→47→40→48 These task numbers correspond to the tasks in Figure 26, on the following page The total completion time for all of the prototyping tasks was estimated to be 55 hours. The actual amounts of time spent and progress made on tasks was recorded in the activity table.

26 Katie Ingalls : Hasbro Product Design

Figure 26: Task list for PERT chart

The activity graph was especially useful for determining the order in which tasks must be completed and which tasks must be completed before others can start. For example, task 7 cannot be started until tasks 1, 3 and 6 are completed, meaning that if any of those tasks gets delayed then task 7 will be delayed. Using the activity graph it is also possible to calculate the slack time which each of the non-critical tasks is allowed. This time is the extra time which the task has before it must be completed in order to keep the project on track. In addition, the activity graph allows for the calculation of both an earliest start date for each task and a latest start date for each task. The earliest start date is the time at which the task can begin based upon the completion of its predecessors and the latest start date is the time at which the task must begin no later than in order to keep the project on schedule. The activity graph was an essential tool in scheduling the prototyping tasks and making sure that each subsystem was able to work on the appropriate tasks. Without the activity graph it would have been very difficult to ensure that separate subsystems were on track and able to complete their assigned tasks and provide the required input for subsequent tasks.

Katie Ingalls : Hasbro Product Design

5.4 Subsystem Decision Matrix

'()&*+(#,-.",)

'(/$0(.)$*+/1-2",)

3&/1)4-"0-."*5

6*&(-"0-."//&.)"*-7#$1

'(8+%$%-*(/1&-"0-9+*&#&,,5()(-)*(/,0&*

!"#$%&-"0-7"9&*-,9+).4

:;()(-)*(/,0&*-,<,)&%=>2"//&.)+"/-,7&&5

!"#$%$&'()*'+",-'('.&$

!"#$%&

The next step in the design process was to determine the best way to meet each subsystem’s requirements. Decision matrices were used to ensure the process was as objective and accurate as possible. Several options are rated with respect to various dependencies. Higher scores are indicative of that dependency better meeting that objective’s needs. The weights are derived from a “mini house of quality.” These mini houses of quality are constructed by seeing how the relevant subsystem requirements affect the dependencies. The decision matrices and weighting analyses can be found in the appendix. The power subsystem will be used as a case study here. The weighting analysis is shown below for the power subsystem in Figure 27. In this subsystem, eight dependencies were identified and are shown along the top row. There were eight requirements that this subsystem must satisfy and they are listed along the first column. Derived requirements are differentiated from originating requirements by italicizing. The imputed importance listed in the last row determines the weights to be used in the decision matrix. These weights are calculated by summing how many and how strongly each requirement affects each dependency.

Battle system shall be powered.

Infrared sensor shall be powered.

Data transfer system shall be powered.

@ @

The system shall have a power on/off switch for user The system provides power to all toy circuitry

Toy shall have power switch with ON and OFF positions on exterior

The On/Off switch shall be flush with the battle-doll surface Power cord/batteries shall have an independent pocket for storage inside storage backpack. Imputed Importance

@ @@

@@ C

Figure 27: Power subsystem weighting analysis

28 Katie Ingalls : Hasbro Product Design

Three different options were considered for the power subsystem: AAA batteries, button cell power, and USB charging. Each of these options were rated with regard to the dependencies (shown in the columns marked normalized score). These weights are then multiplied by the weights determined in the prior matrix and all these weighted scores are summed up. The option with the highest score is chosen as the best. In this case study, the AAA batteries wound up with the best weighted score and is therefore deemed the best. Figure 28 below shows this decision matrix. User

Normalized Score

Dependencies

Final Score 01*"23$'4(-4

*+%%,-"2&//

!!!"#$%%&'(&)

Weight

Min Score

01*"23$'4(-4

*+%%,-".&//

!!!"#$%%&'(&)

!"#$%&

(

)

(

-./&01.#234"2/

(

-.7$8.4/$01793:"2/

(

)

;&79/<3"834"0=

?0&.3"834"77&4/"03@#$9

-.A1%$%30.79&3"83 B10&#&223=./.3/0.728&0

)

!"#$%&3"83@"B&032B1/4<

CD./.3/0.728&032E2/&%FG3 :"77&4/1"732@&&=

HI-

Figure 28: Power subsystem decision matrix

Katie Ingalls : Hasbro Product Design

5.5 Bill of Materials In order to determine the cost of our product, a bill of materials (BOM) was produced. The BOM lists the components and parts that will be needed to manufacture the entire battle doll system. The final BOM is shown below in Figure 29. Mechanical system components are listed first, followed by electrical components. For references for the following prices, please see Appendix.

Figure 29: Bill of Materials

It is important to note that the electrical and mechanical specifications have not been detailed, only prototyped, due to the objectives of this project. As a result, minor components were not accounted for. For instance, components such as screws and wires are left out of this estimate because it is uncertain how many there will be in the final design, and also because they will be very inexpensive which ordered at scale.

30 Katie Ingalls : Hasbro Product Design

Subsystem Accounting The materials that define the system, however, are accounted for. To show that all subsystems have been accounted for, they will be addressed from top to bottom as they appear in Figure 30.

FORM FACTOR SYSTEM

PHYSCIAL FORM

POWER SYSTEM

POWER SYSTEM FAIRNESS SYSTEM DATA ACQUISITION SYSTEM

SCORING SYSTEM

DATA TRANSFORMATION SYSTEM USER INTERFACE SYSTEM

Figure 30: System Hierarchy

Physical Form. The doll form system and battle device form system, as larger components, have been estimated in the above BOM. The battle device form, in addition to plastic, includes the cost of the buttons that interface with the information display system. Accessory forms, such as weapons and other outfits, could be sold separately. The “starter kit” may just include a very simple cloth outfit and a very small, simple weapon. Because of their extremely small size, and because of decreased costs due to scale manufacturing, the costs of these were considered small enough to be negligible. Power. The power system accounts for the AAA battery that would be included with sale of the doll, though this could be eliminated if the manufacturer felt it would add too much to the cost, and was not worth the convenience to the customer. Fairness. The plastic and suction cups listed refer to the fairness assurance system, which was later refined to be the stand that would hold the doll in place. Data Acquisition. For the data acquisition subsystem, only the accessory scanning subsubsystem requires a hardware component; the skill level acquisition is translated from the accessory to the gameplay algorithm, and requires only programming. The accessory scanning system, as currently prototyped, is included in the cost of the microcontroller. Data Transformation. The gameplay algorithm has no material requirements because, like skill level acquisition, it is a software issue. The data transfer hardware system includes the microcontroller and the printed circuit board (PCB). As stated before, additional wire and connectors were not accounted for because the specifications have not been done to that level of detail, to allow room for design innovation by Hasbro. The scoring input system, i.e. the buttons on the doll used to sense a hit, is accounted for by the pressure sensitive resistance sensors. User Interface. The information display system is accounted for in the BOM through the costs of a small 1.8” LCD screen (listed as $3 on Alibaba). As will be discussed shortly, this price will decrease significantly depending on the scale of the product, and was estimated to cost $1 at scale. The scoring control mechanism system added additional material costs due to the complexity of joint actuation, as well as material for the control buttons. Play modes is another subsystem which is dependent on software rather than hardware.

Katie Ingalls : Hasbro Product Design

Price Point The total costs of the mechanical system components (the first five items of the BOM) were estimated as $3.70. The costs of the electrical system components (the last six items) totaled $4.13. This came to a grand total estimate of $7.83. If the market price of the product is 4.5 times this, the market price of the doll is estimated to be $35.24. However, this cost may decrease depending on the scalability of the Battle Doll, and the details of the particular manufacturing facilities and practices, which were not familiar to DAVANNE LLC. For reference, the costs of three similar products are listed below in Figure 31.

Figure 31: Market prices of similar products.

A jointed Barbie doll, whose form has great resemblance to the Battle Doll, has a market price of $12. The Iron Man action figure, which also includes licensing costs, has a market price of $20. The actuation mechanism of the Iron Man action figure is a close approximation the actuation system of the battle doll. And finally, the Tamagotchi Connect uses hardware and algorithms very similar to the battle system, including display, as well as more complicated infrared technologies – which the battle doll will not include – for connection to other systems. Considering the price points of these items, the battle system – when experts take manufacturing scalability into consideration of the cost – would probably be around the $30 price range. Although this is quite expensive comparative to the similar products discussed above, One must consider the increased functionality comparatively. The doll contains advanced technical features, as well as a physicality which most digital pets lack. The value provided to the customer substantiates the price point. Furthermore, selling the base separately from the rest of the battle doll could lower this price point. The base, which is responsible for a substantial amount of the cost of the toy, could be sold separately as a starter item. Because the stand contains the advanced actuation mechanisms and the electronics for connection between the doll as well as other systems, it constitutes a large part of the investment of the toy. It could be designed to work with all dolls. Then, a doll-battle system set could be sold separately of the largest costs. Not only would this reduce the price friction of the battle doll, by having the largest cost be the startup cost, but it would also increase the variability of the game. Users could collect different dolls for their different personas and looks, without having to purchase a battle stand each time.

32 Katie Ingalls : Hasbro Product Design

5.6 Prototyping

5.6.1 Battle Form and User Interface Objective

The purpose of prototyping the battle form and user interface systems was to determine how the user would interact with the device. Determining the size and shape of the battle system, as well as the placement and size of the screen and buttons were important considerations in our design, in order to ensure usability. The battle form system interacts closely with both the electronics subsystems (including power system, data transfer hardware, and accessory scanning system), and the fairness assurance system (stand). Prototyping the battle form and user interface addressed interface issues with these systems. Method

In order to develop prototypes for the form system, both shape and size were important considerations. The size of the device needed to be large enough to house the electronic components needed, and large enough to hold a display that is easily readable, but small enough to fit easily into a child’s hand, and be easily transportable. Information about the size of the electronics the battle system needed to contain was needed from the electronics prototyping team. The size of the prototyped device was determined by considering the maximum space needed for the final circuitry (about 1”x1”), and considering the size of a child’s grip, which was largely informed by the current Tamagotchi form, which is 5cm x 6cm. The size of the prototypes is slightly larger, to accommodate for more maneuverability and greater display size, depending on price. After the size of the device was determined, concept sketches for potential forms were done. These are shown in Figure 32.

Katie Ingalls : Hasbro Product Design

Figure 32: Concept sketches for battle device form. (1)Traditional, (2)Arcade, (3)Pager, (4)Backpack, (5)ScrollSelect.

These concept forms take into account button size and placement, storage strategies, and graphical interface. For instance, the concept in the upper left is reminiscent of the traditional digital pet form, with four buttons and a keychain attachment. However, the rectangular form below that was inspired by an arcade machine, with a designated area to display the score, as with a hockey table. It could have a slot in the back, allowing for attachment to a belt. The third concept was inspired by a pager, and could clip onto the waist, without the need of a belt, or to a backpack strop. The backpack form concept would be carried with the doll, as an attachment directly to the doll’s back. It also has a circular graphical interface and selection mode. Finally, there is a scroll-select concept, where a dial is used to select options, rather than buttons. It could be carried by the doll as a purse or be attached to a carabineer and carried on a garment. Of these concepts, the Arcade and Pager forms were chosen to prototype based on their balance of features and simplicity. For the graphical user interface, information about how the device may be navigated with respect to loading weapons, scoring points, and displaying information to the user was discussed with the electrical team. Using this information, a mockup of the graphical UI was rendered in Photoshop. Building

Foam was used to sculpt the two forms. Green floral foam was the only material available at the local craft store, so that was used instead of higher-quality foamcore. A knife was used to sculpt, and the final forms are shown in Figure 33.

34 Katie Ingalls : Hasbro Product Design

Figure 33: Prototyped Battle Systemforms.

The Pager concept is shown on the left, and the Arcade concept at right. The “belt clip” on the pager concept is visible. The buttons, although not able to be sculpted into the model due to low foam resolution, are located on the top of the device, easily accessible to the user while being worn. The clip can also be used as a contact point with the stand, which is used to hold the doll in place during battle. By attaching the two systems, power can be shared between the doll and the device, eliminating extra batteries. Additionally, this connection is needed for the battle system to determine when and where the doll has been hit. The Arcade concept would have contact points on the back or bottom of the device, depending on how the stand was constructed, and the electrical needs of the doll and battle device. It would connect to the stand using a sliding mechanism. The score would be displayed on the two LED number displays at the top of the device, tilted for ease of viewing. Buttons are located at the base of the device. To create the user interface, Photoshop was used to render a screen shot of the display system during battle mode. This is shown in Figure 34.

Katie Ingalls : Hasbro Product Design

Figure 34: Graphic display UI.

This interface includes status displays for Health, Defense and Power. Health is how much “life” the doll has left before she dies/is defeated. Defense is determined by the accessories loaded into the doll, such as a shield, which provide defensive strength. Power is the doll’s offensive strength, which is also determined by accessories. Each of these statuses can be diminished during a battle, and as they are diminished, their status is displayed to the user. The equipment (i.e. accessories) the doll has been armored with is displayed on the right side, with the accessory name being listed. Under the Equipment display is a Status area, where recent actions are communicated to the user. In this instance, the opponent’s doll has been hit in the chest, and this is communicated to the user both in the status area, as well as graphically on the doll figurine shown at center. The status would read, as an example, “Gold belt has been equipped. Power: 2 points” when loading an accessory. While connecting to another device/opponent, the status would read, “Connection with opponent: COMPLETE.” Testing

In order to test the graphical and structural user interface of the battle system, ideally, a child would be given the form and asked to hold it, We would then ask questions such as: Does if feel too big, too small? Is it too sharp? Is it ugly? However, with few children to be found on campus, the form was given to three college-age students to test the size and feel of the form. It was decided that having “real” buttons to push would have been helpful in determining the effectiveness of the prototype, and that the material that the forms were constructed out of were much lighter than the device would actually be. In addition, there were concerns about the size of the device in relation to a child’s grip size. Despite these

36 Katie Ingalls : Hasbro Product Design

concerns, however, the test users were happy with features such as the display size, the belt clip functionality, and the score display. For the user interface, the same three test users, after being given a brief background on the purpose of the toy, were asked to “Explain this display.” No explanation of the display was given. The users were able to determine what the health, defense, and power statuses meant, and how deducted points would be communicated. They were also able to understand that the items listed under equipment were accessories currently loaded into the doll system. In one instance out of three, there was confusion as to the purpose of the highlighted area of the figure. However, after reading the status information, all test users were able to infer that a hit had been made in that area. Conclusions

The biggest problem with this prototype was the material used. It was not able to describe the concept with enough detail, and was extremely fragile. Although orders were put in for higher quality sculpting foam, they did not arrive in time for our prototyping deadline. As a result, we went to a local crafts store, but only floral foam was available, which proved to be of very low resolution and far too soft. Future improvements for the battle device form would be to use a material with higher resolution, so that button impressions, data connection areas, and stand connections could be included in the form. Additionally, using a material that more closely mirrored the weight of the actual system would have been useful; this could be done by adding clay or coins to the center of the form to simulate weight. It could not be done in this prototype due to the low quality of the foam. By prototyping the battle system device form, interface issues with both the electronics system and stand system were brought to the surface. It was originally envisioned that the battle system would communicate with other systems wirelessly, using infrared, as Tamagotchi connect systems do. However, the electronics team discovered that the data transfer rate between the doll and the system, and the system with an opponents system would be much too high to be handled by IR. As a result, it was decided that the battle form had to be capable of having a physical attachment to the doll, via cord or directly. Furthermore, as the control mechanism was integrated with the fairness assurance stand, it made sense that the battle form be integrated as well. The power could be shared between the doll and the battle system, and it would make for a more simplified user interface. A rough sketch for how the three could potentially be integrated in the future is included in Figure 35. Figure 35: Concept for Fairness Assurance, Battle System and Control Mechanism systems integration.

Katie Ingalls : Hasbro Product Design

5.6.2 Joint Actuation Objective

It was necessary to model the arm actuation to determine the type of motion that was possible as well as how the user can control this motion. The team also considered the following objectives when modeling the arm. 1. Elbow control 2. Mechanism for control of arms 3. Integration of battle stand with control of arms Method + Building

The entire prototype/modeling procedure was carried out using the computer-aided design software SolidWorks. This was done because we could model all ranges of motion in the software. It also provided an inexpensive method for trying out different concepts to find the best combination of tools to use to achieve the type of motion required. The first and most important thing was to find an inexpensive method to control both arms. The first design that was modeled was a button design, which when pushed, would rotate the arm’s shoulder forward and backward. This forward and backward movement was found to be the simplest that could be achieved. The button design consisted of a connecting mechanism that would connect the doll and the joint. When pushed, the connecting mechanism would then rotate and this rotation would cause the doll’s arm to move forward. The figures below show the button design and the parts that comprise it. The left image shows a mock-up of the doll with the mechanism attached. The right image shows a cut-away highlighting the actuation mechanism.

Figure 36: Actuation mechanism

An advantage of this design is its intuitiveness. However, a key flaw with this design is found in the inner workings of the design, which requires many small pieces. These can easily break because of the amount of wear it would have to endure over the lifetime of the system. Once this connecting system breaks, the user would not be able to control the arms. Also, integrating this mechanism into the battle stand was problematic. This integration

38 Katie Ingalls : Hasbro Product Design

ended up being a hindrance since the user still had to push the button on the back of the doll even after the battle stand was attached. This removed the intuitiveness advantage that the design originally espoused. To combat this problem, a lever design was adapted. This design is less intuitive to the user but integration with the stand is much simpler. Using this design, the lever would be on the back of the doll and when pushed up, would rotate the arm. The figure below shows this lever design.

Figure 37: Model of lever mechanism

This design is less intuitive since most users are used to pushing buttons instead of pushing up on levers. When the battle stand is connected to the doll with this lever design, the buttons integrated in the battle stand can be used to control the arms of the doll. For a full description of how this will work, read the battle stand section of the report. Another area explored with our prototype was developing a control mechanism for the elbow independent of the shoulder. The team decided that there should be no more than two mechanisms on the back of the doll. Therefore, any elbow control would have to be integrated into the same control as the shoulder joint. After much exploration, however, individual elbow actuation was found infeasible. Instead, the team settled on a design in which the angle of the elbow was set by the user and locked into place using a screw. This provided another dimension for the user interaction as the user could set the arm angle based on strategy. Conclusions

The first lesson the team learned was the difficulty in individual control of multiple joints. The elbow joint could not be controlled because it would require extra buttons/levers. There was a tradeoff between the number of buttons/levers and user control of the arms. Eventually, the team settled on having two levers and a movable forearm which would have its position set by the user and locked into place using a screw. This also provided a phase of user interaction which had not predicted as the user could now set the arm angle based on strategy. The second lesson learned was that using a lever design was better a button design. The button design could not be integrated with the battle stand and also had tiny components which lowered the dolls effective lifespan. Though the lever design is more complex and would require moving parts within the battle stand, it is a better design because it enables user control of the arms by pushing buttons on the battle stand. Hence, the battle stand becomes a factor in the game play instead of a hindrance.

Katie Ingalls : Hasbro Product Design

5.6.2 Scoring system placement, size and shape Objective

Battle doll hit zones will be tested for their size, shape and placement according to the available range of motion (ROM) available to the doll’s limbs and accessories. This failure mode and effects analysis (FMEA) testing of this subsystem will utilize two wooden anatomical figures whose ROM is tailored to the expected ROM of an operational battle doll. This testing will be sensitive to the following Battle doll subsystems (considered Primary subsystems for hit zone testing because these systems are predecessors to executing this test): 1) Doll’s form subsystem. The Doll’s form subsystem will determine the number of joints, the size of each doll anatomical component (e.g. thigh), and the range of motion available to each component. When two dolls are spaced apart at a predetermined distance, their range of motion will interact and create contact zones. These zones can then be used to characterize the best hit zone size, shape and placement. 2) Accessories form subsystem. The Doll’s accessories will change the interaction zone between two battle dolls by increasing or decreasing the range available to each doll. In addition, accessories may interfere with hit zones by covering them, changing their shape or even reducing their effectiveness in certain places. Characterizing these impacts will allow for an optimal hit zone size, placement and shape design. Other subsystems that are impacted by the hit zone size, placement and shape include (considered Secondary subsystems for hit zone testing because these systems are impacted by the results of this test, or must be done in tandem with this test) 1) Fairness Assurance System. If every “strike” or “score” to a doll is occurring on a single hit zone, this could be suspicious activity (e.g. system tampering). The fairness assurance system may take into account special cases to mitigate the likelihood that unfair gameplay is occurring. 2) Scoring Input System. The scoring input system will receive information from the hit zones. The size, shape and placement of hit zones must compliment the method of registering “strikes” or “scores” in order to assure the best user experience during gameplay. Method

Determining the size, shape and placement of hit zones will make use of a simple method that can solve a very difficult modeling problem. A sharpie equipped doll will mark another doll without accessories, and the ranges of motion will be exercised with the equipped at a pre-determined distance. The zones that are marked on the “unpainted” doll will be evaluated with the doll’s physics construction in-mind (e.g. a hit zone on a join area could be both difficult and expensive, so joints will not be considered viable hit zones). Accessories will then be added and their contact range “painted” a different color before going through the same process. The final design of the hit zone sizes, placement and shape will be denoted by marked zones on the doll. Intended changes to marked areas will be recommended and justified as necessary. Two female wooden artist models will be used in this testing. The model design being used can be seen below. The range of motion of these models will be limited or extended to match the range of motion that will be available to the Battle Doll. Representative

40 Katie Ingalls : Hasbro Product Design

accessories (e.g. a sword) will be fixed to the hands a body of the models to determine how this range of motion is impacted. These “zones” will be characterized by two different color paints. One model will act as the marking model (wet paint), while the other model will act as the zone model (will be painted). Building

Assumptions used for building: 1. The Range of Motion of the doll can be represented by an anatomically accurate Artist Doll. The Artist doll used for testing was the Mini Wooden Artist’s Model (ISBN 978-06419322-8). This doll is designed is a “proportioned figure, fully jointed to allow realistic human poses.” 2. An accessory equal in length the doll’s arm can be used to determine extended ranges. For the scale used, a 3.15” toothpick satisfied this assumption. 3. The distance between the two dolls is equal to the distance from the wrist to the armpit. 4. The dolls cannot be back to back. The zones that could be reached by limbs were marked in black. If the doll has no weapon accessory attached, these zones depict the size, shape and placement of hit zones that are within reach.

Figure 38: Interaction between dolls

When the doll is equipped with an accessory equal in length to the doll’s arm, the hit zones will change shape due to the extended range. In the following images, red denotes the zones that can be reached when an accessory is used to reach the extended areas (in this cause a toothpick 3.15” in length).

Katie Ingalls : Hasbro Product Design

Testing

Figure 39: Front, side and back of doll

Activity 1): Determine range of motion from Doll’s form subsystem: The black markings on the doll depict what the battle doll’s natural hit zone size, placement and shape are. The range of motion was determined through angle measurements of the Artist Doll joints using standard methods in Kinesiology. The results of these measurements are: Joint Elbow Forearm Wrist

Shoulder

Shoulder Hip

Extended Hip Knee Ankle

Movement Flexion Hyperextension Pronation Supination Extension (Dorsiflexion) Flexion (Palmar flexion) Radial Deviation Ulnar Deviation Flexion Hyperextension Abduction Adduction Internal Rotation Flexion Hyperextension Abduction Internal Rotation External Rotation Flexion Plantar flexion Dorsiflexion

Artist Doll (In Degrees) 140 0 80 80 60 60 20 30 180 50 180 50 90 100 30 40 40 50 150 20 30

Figure 40: Anatomical doll range of motion

Activity 2): Determine range of motion with accessories form subsystem: The extended range of motion provided by the accessories form subsystem is depicted in red on the battle doll prototype images above. The extended range was provided by a weapon accessory proportional to the length of the doll’s arm from wrist to armpit. The angular range of motion with and without an accessory remained unchanged – only the length of reach was affected with the addition of the accessory.

42 Katie Ingalls : Hasbro Product Design

Activity 3): The hit zone size, shape and placement both with and without accessories is shown above in the prototype images. Black denotes where a Doll’s limb can reach the surface of the other doll. Red denotes where a Doll’s limb + Accessory can reach the surface of the other doll. Activity 4): Determine Fairness Assurance System rule(s) that will identify tampering with a hit zone: The following rule may be considered due to observations in this prototype process – “If a single zone report more than five strikes consecutively, that zone should refrain from reporting further hits for a set period of time or a set number of additional strikes.” The level of complication in adding this rule, and associated cost, could refrain from its inclusion in the Fairness Assurance System. Activity 5): The size, shape and placement of hit zones provided herein could be used for future testing with the Scoring Input System to determine their effectiveness. Conclusions

1. An accessory equal in length to the Doll’s arm adds over 20% greater hit zone surface. 2. On a female proportioned doll, the torso hit zone follows a butterfly pattern, creating a more complicated hit zone shape. 3. The use of a weapon accessory does not extend the “width” of the torso hit zone. It only extends the “height” 4. The face could not be reached by an opposing doll’s hand. The hypotenuse created between the shoulder joint and face is longer than the arm length from shoulder to hand. Sources: Luttgens, K. & Hamilton, N. (1997). Kinesiology: Scientific Basis of Human Motion, 9th Ed., Madison, WI: Brown & Benchmark.

Katie Ingalls : Hasbro Product Design

5.6.2 Fairness Assurance System Objective

The battle doll stand was prototyped using foam core, zip ties, a metal clamp, suction cups and a standard Barbie doll in order to accomplish 3 main goals: • Securely hold the battle doll during gameplay • Anchor the stand to the playing surface • Interface with the battle doll controls and provide fair gameplay Method, Building, Testing

The stand was modeled primarily out of foam core and designed to be large enough to suitably hold up a Barbie doll. Modifications were made in order to allow for the stand to hold the battle system electronic device and to allow for buttons which interface with the doll’s controls. The first goal was to securely hold the doll during gameplay and it is necessary in order to ensure that the doll is kept in an appropriate position for fighting another doll. It ensures that the doll can be hit by another similarly connected opponent and that the doll can also strike this opponent if controlled correctly. This connection was prototyped in two different ways: using a reusable zip tie and by holding one of the Barbie doll’s legs stationary in the foam, see Figure 41. Each of these methods of holding was tested by having three people move the doll using their hands to simulate the battle doll fighting. It was unanimously determined that the zip tie method was superior.

Figure 41: Secure doll holding methods: (a) removable zip tie, (b) stationary leg

The second goal of the stand prototype was to anchor the stand to the playing surface. Two options which were considered were utilizing suction cups and using a plastic clamp.

44 Katie Ingalls : Hasbro Product Design

Initially one standard 1.5 inch diameter suction cup was hot glued onto the foam, but this did not provide enough stability for the stand. In order to remedy this, another 1.5 inch locking suction cup was added to the front of the stand, see Figure 42. Another 1.5 inch normal suction cup is located underneath the base of the stand. The second option (plastic clamp) was simulated using a standard small metal clamp which was readily available. The results from testing done by the same three people determined that the two suction cup design was superior due to the ease of attaching to the playing surface of a table. It was noted that the suction cup design limits play to a clean, hard playing surface such as a table top or a hard floor. On the other hand, the clamp design is much more limited, and the battle doll can only be played with when the edge of a table is readily available. In additon, the thickness of the table also becomes a factor, one table which was readily available was too thick to allow for the clamp to securely attach.

Figure 42: Two suction cup design (1.5in diameter locking and 1.5in diameter normal)

The final goal of the stand prototype was to interface with the battle doll controls, which were determined to have a lever type design. Buttons were designed to be situated on the stand in order to operate these controls. These buttons are colored black in Figure 42. An internal operating mechanism was also designed using Google Sketch Up. This mechanism essentially transfers the force from the button press to hit the lever in the controls using a lever and a fulcrum, see Figure 43. It is necessary for the stand to incorporate the controls for the doll in order to ensure fair gameply. The stand forces the children to play the game as designed and reduces the posssibility for cheating by confining the child to the stand controls instead of letting the child have their hands close to an opponent’s doll.

Katie Ingalls : Hasbro Product Design

Figure 43: Mechanism to transfer button press into hitting lever controls

Conclusions

The final design of the stand was determined to use a reusable zip tie to attach the doll to the stand, utilize a two suction cup design with two 1.5 inch diameter suction cups, one locking and one normal, and have buttons which act to interface with the lever controls for the battle doll. Developing the final stand prototype was an iterative process which was not successful on the first attempt. Testing by multiple people was also very useful in determining which design choices to make since it is difficult to calculate how others will view the design. In addition it was also learned the hard way that interface specifications need to be explicitly spelled out. There was a fair amount of confusion initially with regards to the interface between the stand and the doll controls. This led to a delay in prototyping of both subsystems while it was resolved.

46 Katie Ingalls : Hasbro Product Design

5.6.2 Electronics System Objective

The objective of this component of prototyping was to build the electronic circuit that is responsible for critical related functionalities. The subsystems that involved electronic components that were prototyped were: • •

•

DATA ACQUISITION SYSTEM – Accessory Scanning System DATA TRANSFORMATION SYSTEM – Gameplay Algorithm – Data Transfer Hardware System – Scoring Input System USER INTERFACE SYSTEM – Information Display System – Scoring Control Mechanism System

The major functionalities covered as part of this prototyping are : 1. Hit detection (complete with sensors) 2. LCD Display 3. User interface 4. Communication between battle systems 5. Communication between all above mentioned subsystems Method

In order to prototype the electronic circuit of Battle Doll, the following functionalities were taken into consideration. First, the whole system requires user interface such as buttons for user to input their command and a display monitor. Second, the system requires sensors that can detect and respond to a certain amount of force of impact that came from user. (symbolize a hit made by the opponent’s doll) Third, the system must be able to communicate with another pair of the system. Lastly, the main processor of the system must not exceed a certain size so it can be fit into the battle form system. In reality, the availability of the materials and the development time has also being taken into consideration. With the help of Professor Bruce Land (Cornell ECE), the materials and laboratory are made possible. And the following circuit diagram shows the circuit of the sensor system.

Katie Ingalls : Hasbro Product Design

Figure 44: Wiring diagram for electronics system

Building

In the effort of building the electronic circuit, the following martials has been used, two Mega 644 microcontroller, two LM 358 Low Power Dual Operational Amplifier, four pressure sensitive resistance sponsored by Sensitronics and two STK 500 development board. The program running in the microcontroller was written in C, compiled and downloaded into the microcontroller using ATMEL’s AVR Studio. The prototype eventually covered the following functionalities: Hit detection on two different sensors per system, LCD display that shows the status of the game, three button user input system with mode select, confirm and cancel, respectively and the communication between two battle system.

Figure 45: LCD display system

48 Katie Ingalls : Hasbro Product Design

Figure 46: Sensor System

Figure 47: Mega 644 microcontroller on STK-500 development board

Katie Ingalls : Hasbro Product Design

Testing

In order to test the electronic circuit, the following method was applied: Use multimeter to measure the voltage at each connection point while the system is powered, press the sensor while the system is on gaming mode to see if it actually respond to the force applied and press the user input buttons to see if it actually response as we programed it. The prototyped systems successfully passed all the tests mentioned above. Conclusions

1) Accessory input from user : For the purpose of prototyping the technique used for accessory input was simple number input from user through the user interface buttons. Many techniques were considered for this purpose and ruled out due to cost or size issues. The conclusion reached was that a choice would have to be made between either the current input from user technique, which loses out on the coolness technique and also increases chances of cheating with fake weapon input. The second choice would be an RFID tag system which would win over the other choice in terms of coolness and fairness but increase the cost of manufacturing by about 3-4 dollars. Technology Cost of Name Tag/Transmitter

Cost of Receiver

“Coolness“ Factor (1=uncool, 5= coolest) 5

RFID

$0.5

$10

Magnetic Stripe Bar code scanner IR

$10

~$0

User enter

~$0

Comm ents

Too expensive Too expensive Scanner is Too big Too big to implement into accessories Most feasible but lack of security

Figure 48: Accessory scanning options

2) Communication between Battle Systems: Here again, for the purpose of prototyping, simple serial communication between the two systems was used. This could be implemented in the final design with minimal change or could be replaced by infrared communication with an additional cost increase. 3) Microcontroller used: The microcontroller used for prototyping (Atmel’s Mega644) was one which by far exceeded the needs of the project in its capabilities but was used due to logistic limitations. It can easily be replaced by a range of microcontrollers which range between 75c to a dollar in cost, for example the Atmel Tiny, which is an 8 pin MCU.

50 Katie Ingalls : Hasbro Product Design

4) Power – During prototyping, an adaptor and a plug were used to supply power to the circuit. However it is essential to keep in mind during all decisions between techniques that as a technique of implementation of a functionality becomes more complex it will also require more power from the circuit which directly translates to cost. For example, if infrared technology were to be used for communication between battle systems it would require more power than serial communication. 5) Hidden costs: In the final bill of materials, hidden costs such as those of programming the MCU have not been included as they currently cannot be estimated well. However it would help to keep in mind that these secondary costs would add to the total manufacturing cost as well.

5.7 Gannt Chart In order to lay out the entire schedule for the project a Gantt chart was generated using Microsoft Project 2010 software to document all of the project tasks which were completed, see Figure 49.

Figure 49: Gannt Chart

This chart was generated as a guide for all of the time which was spent on the project and outlines both individual and group design processes. The Gantt chart provides a baseline schedule for all activities and also shows which activities are dependent upon others. The schedule started on 9/13/2010 and is completed on 5/20/2011 with this final report. The chart is especially useful for determining which activities can be completed concurrently, for example after concept generation both use cases and behavioral diagrams were constructed. The Gantt chart is an excellent tool for determining required project tasks, developing a baseline schedule and very useful when coordinating a large project with many tasks and group members.

[END OF REPORT 2] Katie Ingalls : Hasbro Product Design