hasbro: consumer product design report

89
Katie Ingalls HASBRO PRODUCT DESIGN CORNELL UNIVERSITY PROJECT ADVISOR: DAVID SCHNEIDER 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. Semester 1 Hasbro Product Design Team

Upload: kat-ingalls

Post on 14-Mar-2016

233 views

Category:

Documents


2 download

DESCRIPTION

Design report for semester-long project utilizing systems engineering and product design methodologies to develop a consumer product for Hasbro, Inc.

TRANSCRIPT

Page 1: Hasbro: Consumer Product Design Report

Katie Ingalls

H A S B R O P R O D U C T D E S I G N C O R N E L L U N I V E R S I T Y P R O J E C T A D V I S O R : D A V I D S C H N E I D E R

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.

Semester 1

Hasbro Product Design Team

Page 2: Hasbro: Consumer Product Design Report

2   Hasbro  Product  Design  Team  

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

Page 3: Hasbro: Consumer Product Design Report

Kat  Ingalls   3  

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.

Page 4: Hasbro: Consumer Product Design Report

4   Hasbro  Product  Design  Team  

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 thought-out 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.

Page 5: Hasbro: Consumer Product Design Report

Kat  Ingalls   5  

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.

Page 6: Hasbro: Consumer Product Design Report

6   Hasbro  Product  Design  Team  

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

Page 7: Hasbro: Consumer Product Design Report

Kat  Ingalls   7  

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

Page 8: Hasbro: Consumer Product Design Report

8   Hasbro  Product  Design  Team  

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.

Page 9: Hasbro: Consumer Product Design Report

Kat  Ingalls   9  

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   Level  3  

Business     Price  

  Advertising  

Feelings  

Physical  Visual  Aural  Tactile  

Emotional:  Accomplishment  

Cool  Pride  

Collectable  

   

Styles  of  Play  

  Education  

  Imagnination  

  Inventiveness  

Human  Interaction  Solo  Family  

Friends/Group  

  Play  Environment  

  Grown  up/realistic  

Variability         Longevity  

Construction  Quality  

  Pieces  

  Safety  

  Durability  

  Materials  

  Set  up/Clean  up  

Technology  Low  Tech  High  Tech  

Figure 4: Customer affinity grouping

Page 10: Hasbro: Consumer Product Design Report

10   Hasbro  Product  Design  Team  

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.

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.

7%  

22%  

30%  

9%  

32%  

Customer Values: By Percentage

Business  

Feelings  

Styles  of  Play  

Variability  

ConstrucTon  Quality  

Page 11: Hasbro: Consumer Product Design Report

Kat  Ingalls   11  

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!

Page 12: Hasbro: Consumer Product Design Report

12   Hasbro  Product  Design  Team  

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.

Page 13: Hasbro: Consumer Product Design Report

Kat  Ingalls   13  

Figure 6: Context Diagram – Stakeholders. The entity TOY at the center of

the diagram is detailed further in the next figure.

Page 14: Hasbro: Consumer Product Design Report

14   Hasbro  Product  Design  Team  

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

Page 15: Hasbro: Consumer Product Design Report

Kat  Ingalls   15  

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  2   Game  is  initiated  3   A  hit  is  made  4   Doll  uses  weapon  5   System  is  set  up  6   A  point  is  scored  7   Child  wins  game  8   Child  loses  game  9   Child  puts  clothes  on  doll  10   Child  attaches  weapon  to  doll  11   Child  puts  doll  on  scanner  12   Parent  steps  on  scanner  13   Child  inserts  smart  card  into  scanner  14   Child  loses  smart  card  15   Child  inserts  weapon  into  smart  card  slot  16   Parent  plays  with  doll  17   Child  dresses  weapons  in  clothes  18   Friend  brings  doll,  interacts  with  Child’s  doll  on  arena  19   Friend  and  Child’s  dolls  battle  when  not  standing  on  arena  20   Child  scans  weapon  ID  into  scanner/arena  and  “equips”  doll  21   Parent  puts  toy  away  22   Child  takes  doll  into  bathtub  23   Dog  finds  toy,  chews/buries  it  24   Boy  plays  with  toy  (vs.  “girl”  market)  25   Older  sibling  plays  with  toy  26   Younger  sibling  plays  with  toy  27   Child’s  doll  kicks  friends  doll  28   Friend’s  doll  shoots  Child’s  doll  29   Child  friends’  doll  clothes  on  their  doll  30   Child  disassembles  weapon  31   Child  reassembles  weapon  32   Child  removes  clothes  from  doll  33   Child  bangs  on  scanner  34   Child  uses  weapon  on  arena,  without  doll  35   Water  is  spilled  on  doll  or  toy  36   Small  child  puts  weapon  parts  in  mouth  37   Child  puts  another  toys'  clothes  on  doll  38   Scanner  is  hit  or  stepped  on  

Figure 8: Use Cases

Page 16: Hasbro: Consumer Product Design Report

16   Hasbro  Product  Design  Team  

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.

Figure 9: Use Case - Child equips doll

!"#"$%

!"#$%&'$()*+,-. /01&#2()3'--)4)5%&&-#)/01&#2 6#%"'7)899#11'$0 *-'&+,7:)899#11'$0&'()*+,-./+*0/(10*+2)3.'(45+6220//317+8962:0.;+34.3+*3))"

<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+A06,34+6220//31(0/+/'6))+'6D0+*6?650+)0D0)/+64*+*6?650+.7,0/+6//32(6.0*+A(.'+.'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"+

!"#"$%

!"

<3))+(/+-46..(10*H06,34/+610+43.+)36*0*+(4.3+/7/.0?

<3))+(/+6..(10*+A(.'+A06,34

*+,-.)#;<,"1).'--

<3))+(/+6..(10*+A(.'+2)3.'0/

I4(.(6)+&34*(.(34/

J4*(45+234*(.(34/

K7/.0?+(/+.-140*+34"&)3.'(45+(/+43.+)36*0*+(4.3+/7/.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"

M3.0/

&)3.'(45+(/+)36*0*+(4.3+/7/.0?H06,34+(/+)36*0*+(4.3+/7/.0?

Page 17: Hasbro: Consumer Product Design Report

Kat  Ingalls   17  

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 details of this use case are shown at right, in Figure 10. This behavioral diagram details the functional requirements of the battle system, including structural and data transfer considerations.

After both the accessories and battle system have been set up, gameplay can begin. This behavioral diagram references both of the previous use cases as a subset of beginning gameplay, and is shown on the following page in Figure 11. This diagram details the requirements of the play mode selection to be implemented into the battle system, as well as readings of previous win and loss record.

The next use case analyzed using a behavioral diagram is “A hit is made.” This behavioral diagram analyses the steps needed to make an impact on an opponent doll. It defines the functionality of the control mechanism, as well as scoring mechanism of the doll’s body. This behavioral diagram is shown in Figure 12 on the next page.

The fifth use case analyzed using behavioral diagrams is shown in Figure 13, in which a hit is scored. This behavior translates the physical hit received in the previous use case into a score dependent on equipped accessories as well as the doll’s previous win/loss record. This use case examines requirements related to the gameplay algorithm which will convert these variables into a scoring methodology which is integrated

with the battle system.

!"#"$

!"#$%&'$()*+,-. /01&#2()3'--)4)5%&&-#)/01&#2%&'()*+,-./,0*1233(,*0403,-*56127892786:*;+.-*).(("

<233(,*0403,-*0&2((*1,*03.+,)*='3&*).((>0*1.)4*'?*;.+-*.;*12789278"

%&'()*0,30*1233(,*0403,-*.?*9(24*0@+;27,A*0.*3&23*BC*0,?0.+*'0*)'+,73,)*92+2((,(*3.*;(..+"

<233(,*0403,-*0&2((*1,*21(,*3.*(',*;(23*.?*9(24*0@+;27,"<233(,*0403,-*0&2((*7.?32'?*'?;+2+,)*0,?0.+"

%&'()*9.=,+0*1233(,*0403,-*.?"<233(,*0403,-*0&2((*1,*9.=,+,)"<233(,*0403,-*0&2((*'?)'723,*3.*@0,+*3&23*9.=,+*'0*.?"

%&'()*,D3,?)0*)232*3+2?0;,+*7.+)E9(@F"<233(,*0403,-*0&2((*&2/,*)232*3+2?0;,+*7.+)"G.((*0&2((*&2/,*)232*3+2?0;,+*9(@F"<233(,*0403,-*0&2((*&2/,*)232*3+2?0;,+*9(@F"G232*3+2?0;,+*7.+)*0&2((*1,*23*(,203*#*;,,3*(.?F"

%&'()*'?0,+30*)232*3+2?0;,+*9(@F*;+.-*1233(,*0403,-*'?3.*).((>0*1278"

G232*3+2?0;,+*7.+)*0&2((*7.??,73*).((>0*1.)4*2?)*1233(,*0403,-"

%&'()*)'+,730*BC*0,?0.+*3.=2+)0*H+',?)>0*BC*0,?0.+"

BC*0,?0.+*0&2((*0,?)*2?)*+,7,'/,*)232*3.*2?)*;+.-*.3&,+*1233(,*0403,-0"<233(,*0403,-*0&2((*)'09(24*03230A*'?7(@)'?FI*JKA*9.=,+A*),;,?0,A*2?)*,D9,+',?7,"

%&'()*,L@'90*).(("6

!"#"$M

!"

5%&&-#)101&#2),1)1#&)7"

B?'3'2(*%.?)'3'.?0<233(,*0403,-*'0*3@+?,)*.;;"<233(,*003,-*'0*.?*).((*5/'2*6127892786:"G.((*'0*?.3*7.??,73,)*3.*1233(,*0403,-"

K(,20,*0,,*1,&2/'.+2(*)'2F+2-*,?3'3(,)A*6%&'()*,L@'90*).(("6

N?)'?F*7.?)'3'.?0<233(,*0403,-*'0*3@+?,)*.?"<233(,*003,-*'0*.?*9(24*0@+;27,"G.((*'0*7.??,73,)*3.*1233(,*0403,-"%&'()>0*2?)*H+',?)>0*).((0*,D7&2?F,*)232"

O.3,0

Figure 10: Use Case - Battle system is set up

Page 18: Hasbro: Consumer Product Design Report

18   Hasbro  Product  Design  Team  

!"

!"#$%&'$()*+,-. /01&#2()3'--)4)5%&&-#)/01&#2#$%&'()%*+(',&&-+(&%*.(/%0$(1,203,&(*41$)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"

#,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)+%&>"

!" E%*.(4B042'4'"

6)+,&),1)2%.#

F2%0%)&(#,2'%0%,2+E%*.(3403)104'"

52'%2:(1,2'%0%,2+

!"#"$

!"#$%&'$()*+,-. /01&#2()3'--)4)5%&&-#)/01&#2%&'()*+!+,-.)/+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&'()*/"

!"

!"#"

F80682+7-80636-8/G+/7-*)+:'/+<))8+,'0)"

H-3)/

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

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"

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

!"#"

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

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'025%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?+-"

!"# G&-9'4..),184,()&.)'40(1()&-*4).2.*13"H"

!"#" 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("

N031)6'02)34(1)&.).618&>&1("

E11).160,0*1)/1%0@&4,0')(&0?,03B);$%&'()JA+&6.)O4'';

:%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"

J-(&-?)84-(&*&4-.

N031)&.),10(2)*4)/1?&-"

Q4*1.

Figure 11: Use Case - Game is initiated

Figure 12: Use Case - A hit is made

Figure 13: Use Case - A point is scored

Page 19: Hasbro: Consumer Product Design Report

Kat  Ingalls   19  

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.

Originating Requirements Abstract Function Name OR.1 The battle system shall be able to read codes/sensors on accessory items. Read accessories

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

OR.3 The battle system shall be able to convert experience and accessory attributes to scores.

Convert attributes to scores

OR.4 Doll shall be able to "hold" weapons. Hold weapons

OR.5 Weapons shall not cause child to be cut or otherwise injured. Be safe

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

Assemble weapons

OR.7 The battle system shall be powered. Power on

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

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

Input play mode input

OR.10 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.

Contain play mode options

OR.11 The battle system shall request input from user if score-based mode is chosen.

Input score

OR.12 The battle system shall be able to read and record scored points. Determine scores OR.13 The battle system shall alert user to inform them that game has begun. Alert game begin OR.14 Doll shall be able to register when a "hit" has been successfully made. Receive hit OR.15 The battle system shall display number of points score/HP reduced to

players. 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.

Page 20: Hasbro: Consumer Product Design Report

20   Hasbro  Product  Design  Team  

Figure 15: Originating Requirements (final)

Index Originating Requirement Abstract Name

OR.1 Dolls shall be of uniform size (so that all clothing manufactured for it will fit).

Uniform size

OR.2 The battle system shall be able to recognize accessory items.

Read clothing

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

Read clothing attributes

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

Clothing to Play

OR.5 Doll shall be able to "hold" weapons. Hold weapons

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

Read weapons

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

Read weapon attributes

OR.8 The battle system shall be able to convert damage attributes to gameplay.

Weapons to Play

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

Safety

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

Weapon Assembly

OR.11 Weapons shall be able to be recognized by battle system.

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. Weapons abilities

OR.15 The battle system shall be powered. Power

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

Read Experience

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

Experience to Play

OR.18 The battle system shall request what play mode is desired after doll is equipt.

Play mode request

OR.19 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. 2

Play mode options

OR.20 The battle system shall request input from user if score-based mode is chosen.

Score input

OR.21 The battle system shall be able to read and record scored points.

Keep score

OR.22 The battle system shall alert user to inform them that game has begun.

Game begine alert

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

Sense hit

OR.24 The battle system shall be able to translate experience (record) to amount of HP reduced/points gained when hit.

Experience to Play

OR.25 The battle system shall be able to translate abilities (clothes) to amount of HP reduced/points gained when hit.

Clothing to Play

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

Points Display

Page 21: Hasbro: Consumer Product Design Report

Kat  Ingalls   21  

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

Backpack

OR.28 Battle system shall be able to lie flat on play surface. Play Surface

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

Communication Sensor

OR.30 Battle system shall indicate to user that power is on. Power Indicator

OR.31 Battle system shall have data transfer cord. Communication Cord

OR.32 Doll shall have data transfer plug. Doll plug

OR.33 Battle system shall have data transfer plug. System plug

OR.34 Data transfer cord shall be at least 2 feet long. Communication cord length

OR.35 Doll's body shall be able to communicate with battle system.

Communication Cord connection

OR.36 IR sensor shall send and receive data to and from other battle systems.

Sensor Send and Receive

OR.37 Battle system shall display stats, including: HP, power, defense, and experience.

Display stats

OR.38 Doll's limbs shall be able maneuverable (to make motion to "hit.")

Move limbs

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

Transversal motion

OR.40 Control mechanism shall extend limb in punching/kicking motion.

Extension motion

OR.41 Control mechanism shall re-contract limb after extension is made.

Un-extend motion

OR.42 Control mechanism tip shall be large enough for child to handle easily.

Control handle size

OR.43 Doll shall be fixed in space during battle gameplay for fairness.

Fairness

Page 22: Hasbro: Consumer Product Design Report

22   Hasbro  Product  Design  Team  

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.

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.

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

(%)&*+, 1234 1235 1236 1237 1238 1239 123: 123; 123< 1234= 12344

-./0/%1'/%0+

2&34/.&#&%'

5"667+78166+9&+":+

4%/:".#+7/;&+<7"+'81'+

166+=6"'8/%0+

#1%4:1='4.&)+:".+/'+

>/66+:/'?@

A8&+91''6&+7B7'&#+

78166+9&+196&+'"+.&1)+

=")&7C7&%7".7+"%+

=6"'8/%0+1==&77".B+

/'&#7@

A8&+91''6&+7B7'&#+

78166+9&+196&+'"+

.&="0%/;&+1''./94'&7+

":+=6"'8/%0+1==&77".B+

/'&#7@

A8&+91''6&+7B7'&#+

78166+9&+196&+'"+

="%D&.'+=6"'8/%0+

1''./94'&7+'"+

01#&$61B@+

5"66+78166+9&+196&+'"+

E8"6)E+>&1$"%7@+

A8&+91''6&+7B7'&#+

78166+9&+196&+'"+.&1)+

=")&7C7&%7".7+"%+

>&1$"%+1==&77".B+

/'&#7@

A8&+91''6&+7B7'&#+

78166+9&+196&+'"+

.&="0%/;&+1''./94'&7+

":+>&1$"%+1==&77".B+

/'&#7@

A8&+91''6&+7B7'&#+

78166+9&+196&+'"+

="%D&.'+)1#10&+

1''./94'&7+'"+

01#&$61B@+

F&1$"%7+78166+%"'+

=147&+=8/6)+'"+9&+=4'+

".+"'8&.>/7&+/%G4.&)@

F&1$"%7+78166+81D&+

$1.'7+'81'+=1%+

177&#96&+/%'"+#1%B+

'B$&7+":+>&1$"%.B@

F&1$"%7+78166+9&+

196&+'"+9&+

.&="0%/;&)+9B+91''6&+

7B7'&#@

H97'.1='+I1#& J%/:".#+7/;& 2&1)+=6"'8/%02&1)+=6"'8/%0+

1''./94'&7!"'8/%0+'"+K61B L"6)+>&1$"%7 2&1)+>&1$"%7

2&1)+>&1$"%+

1''./94'&7F&1$"%7+'"+K61B M1:&'B F&1$"%+H77&#96BNN 2&1)196&+>&1$"%7

$).##>*?"##%>?"@A(', 2BC! 2BC!>@DE/ *F"GE0H, I.'@D>"0'">D.0G *&.)(>.&>1235, *$.)(>.&>1236, *F"GE0H, $D.J/>(GH(&K> LM)N(J>"O>/.J'& *$.)(>.&>1235,P(GEM)>*Q.JNE(, I.&(J>[email protected](J Q.J@"G( P"J(>R?& $"@A('>S>&0./ P"J(>!.).H( $).##>/.J'&K>$).##(&'> R"T>'">@"00(@'I.JH(>*+)([email protected]>UEJ#, F"G(>J(.G(J F"G( +GGE'E"0.#>/"E0'& I.'@D>"0'">.J) V+NE#E'E(&V

C0OJ.J(G C2WJ(.G.N#(>@DE/ V+NE#E'E(&VQ#M('""'D UJ(.'(J>!(O(0@( XX>-.0'>'">GE'@D>'DE&>

!"#$"%&%' -(./"0&>G.).H( F#"'DE0H F#"'DE0H $%&'()Y!"## $%&'() $%&'() $%&'() $%&'() $%&'() $%&'() $%&'()Y!"##(%)&*+, 12345 12346 12347 12348 12349 1234: 1234; 1234< 1235= 12354 12355

-./0/%1'/%0+

2&34/.&#&%'

A8&+>&1$"%+

1==&77"./&7+78166+

81D&+)1#10&+6&D&67+

1%)+)1#10&+'B$&7+

177"=/1'&)+>/'8+

'8&#@

A8&+=6"'8/%0+

1==&77"./&7+78166+9&+

196&+'"+9&+

.&="0%/;&)+9B+91''6&+

7B7'&#@

A8&+=6"'8/%0+

1==&77"./&7+78166+

81D&+LK7+1%)+

19/6/'/&7+177"=/1'&)+

>/'8+'8&#@

A8&+91''6&+7B7'&#+

78166+9&+$">&.&)@

A8&+91''6&+7B7'&#+

78166+9&+196&+'"+.&1)+

>/%C6"77+.&=".)+

<E&*$&./&%=&E?+1:'&.+

)"66+/7+1''1=8&)+'"+

1.&%1@

A8&+91''6&+7B7'&#+

78166+9&+196&+'"+

'.1%761'&+&*$&./&%=&+

/%'"+01#&$61B+

1)D1%'10&7@

A8&+91''6&+7B7'&#+

78166+.&34&7'+>81'+

$61B+#")&+/7+)&7/.&)+

1:'&.+)"66+/7+&34/$'@

A8&+91''6&+7B7'&#+78166+

81D&+)/::&.&%'+$61B+

#")&7O+917&)+"%+%4#9&.+

":+$61B&.7+<"%&+".+'>"?+

1%)+&/'8&.+7=".&P917&)+

$61BO+&6/#/%1'/"%+".+

4%6/#/'&)+$61B@+ Q

A8&+91''6&+7B7'&#+

78166+.&34&7'+/%$4'+

:."#+47&.+/:+7=".&P

917&)+#")&+/7+

=8"7&%@

A8&+91''6&+7B7'&#+

78166+9&+196&+'"+.&1)+

1%)+.&=".)+7=".&)+

$"/%'7@

A8&+91''6&+7B7'&#+

78166+16&.'+47&.+'"+

/%:".#+'8&#+'81'+

01#&+817+9&04%@

H97'.1='+I1#& F&1$"%7+)1#10& 2&1)196&+=6"'8/%0 !6"'8/%0+19/6/'/&7 K">&. 2&1)+R*$&./&%=& R*$&./&%=&+'"+K61B K61B+#")&+.&34&7' K61B+#")&+"$'/"%7 M=".&+/%$4' S&&$+7=".& T1#&+9&0/%+16&.'

*$.)(>.&>123;, *$.)(>.&>1235, *$.)(>.&>1237, ?#MHWE0 F"JG UJ(.'(J>G(O(0@( !(GE@.'(G>NM''"0 $E0H#(>?#.%(J> LM)N(J>/.G *.#H"JE'D), Q((/Q.''(JE(& FDE/ UJ(.'(J>"OO(0@( $@J"##>.0G>&(#(@' $E0H#(>?#.%(J>$@"J(W $@J"##>.0G>&(#(@' VQ.''#(V>0"E&(>*RE%.Z,$"#.J $).J'>@.JG V2(T.JG&V>O"J>TE0> [T">?#.%(J>\0#E)E'(G> +00"M0@(J>]"E@(RM).0W/"T(J(GZ F"G( [T">?#.%(J>$@"J(W IEHD'

C0'(J0('>@0^0 [E)(WN.&(GYJ.@(

!"#$"%&%' !"## $%&'() $%&'() $%&'() $%&'()Y!"## $%&'() $%&'() $%&'()Y!"## $%&'() $%&'()Y!"## !"##>/#MH(%)&*+, 12356 12357 12358 12359 1235: 1235; 1235< 1236= 12364 12365 12366

-./0/%1'/%0+

2&34/.&#&%'

5"66+78166+9&+196&+'"+

.&0/7'&.+>8&%+1+E8/'E+

817+9&&%+74==&77:466B+

#1)&@

A8&+91''6&+7B7'&#+78166+

9&+196&+'"+'.1%761'&+

&*$&./&%=&+<.&=".)?+'"+

1#"4%'+":+LK+

.&)4=&)C$"/%'7+01/%&)+

>8&%+8/'@

A8&+91''6&+7B7'&#+78166+

9&+196&+'"+'.1%761'&+

19/6/'/&7+<=6"'8&7?+'"+

1#"4%'+":+LK+

.&)4=&)C$"/%'7+01/%&)+

>8&%+8/'@

A8&+91''6&+7B7'&#+

78166+)/7$61B+%4#9&.+

":+$"/%'7+7=".&CLK+

.&)4=&)+'"+$61B&.7@

U1''6&+7B7'&#+78166+

9&+7'".&)+>/'8+)"66V7+

9")B@

U1''6&+7B7'&#+78166+

9&+196&+'"+6/&+:61'+"%+

$61B+74.:1=&@

U1''6&+7B7'&#+78166+

="%'1/%+/%:.1.&)+

7&%7".@

U1''6&+7B7'&#+78166+

9&+$">&.&)@

U1''6&+7B7'&#+78166+

/%)/=1'&+'"+47&.+'81'+

$">&.+/7+"%@

U1''6&+7B7'&#+78166+

81D&+)1'1+'.1%7:&.+

=".)@

5"66+78166+81D&+)1'1+

'.1%7:&.+$640@

H97'.1='+I1#& M&%7&+8/' R*$&./&%=&+'"+K61B !6"'8/%0+'"+K61B K"/%'7+5/7$61B M'".10& K61B+M4.:1=&!"##4%/=1'/"%+

M&%7".K">&.+M"4.=& K">&.+(%)/=1'". !"##4%/=1'/"%+!".) 5"66+$640

QM''"0 *$.)(>.&>1234:, *$.)(>.&>WW, 10>!"## Q.@AN.@A>O"J)>O.@'"J LY+ *C2>&(0&"J, !M/#E@.'(Z>!(#('(3> IEHD' +#&">TEJ(#(&&>"/'E"0_> \$Q?J(&&MJ(W&(0&E'E](> 10>&%&'()>&@J((0 ?MJ&( Q.@A#E'>&@J((0 PE0EW+?J(&&MJ(>&(0&"J `(JN.#> +&>G"##a&>/(' V10V>0"E&( PE0EWQF"0GM@'E]E'%> [MJ0>!E&/#.%>"0 1'D(JY@M&'")

*D.](>@"0&'.0'#%>"0b,

!"#$"%&%' $%&%() $%&'()Y!"## $%&'()>S>!"## $%&'() $%&'() !"## !"## !"## !"## !"## $'.0G(%)&*+, 12367 12368 12369 1236: 1236; 1236< 1237= 12374 12375 12376 12377

-./0/%1'/%0+

2&34/.&#&%'

U1''6&+7B7'&#+78166+

81D&+)1'1+'.1%7:&.+

$640@

51'1+'.1%7:&.+=".)+

78166+9&+1'+6&17'+Q+

:&&'+6"%0@

51'1+'.1%7:&.+=".)+

78166+="%%&='+)"66V7+

9")B+1%)+91''6&+

7B7'&#@

(2+7&%7".+78166+7&%)+

1%)+.&=&/D&+)1'1+'"+

1%)+:."#+"'8&.+

91''6&+7B7'&#7@

U1''6&+7B7'&#+78166+

)/7$61B+7'1'7O+

/%=64)/%0W+LKO+$">&.O+

)&:&%7&O+1%)+

&*$&./&%=&@

R1=8+":+)"66V7+6/#97+

<Q+1.#7O+Q+6&07?+78166+

9&+#1%&4D&.196&+9B+

="%'."6+#&=81%/7#@

!"%'."6+#&=81%/7#+

78166+#"D&+6/#9+4$+

1%)+)">%+1%)+7/)&+

'"+7/)&@

!"%'."6+#&=81%/7#+

78166+&*'&%)+6/#9+/%+

$4%=8/%0CX/=X/%0+

#"'/"%@

!"%'."6+#&=81%/7#+

78166+.&P="%'.1='+6/#9+

1:'&.+&*'&%7/"%+/7+

#1)&@

!"%'."6+#&=81%/7#+

'/$+78166+9&+61.0&+

&%"408+:".+=8/6)+'"+

81%)6&+&17/6B@

T1#&$61B+78166+9&+

E:1/.@E

H97'.1='+I1#& MB7'&#+$640!"##4%/=1'/"%+=".)+

6&%0'8

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

="%%&='/"%

M&%7".+M&%)+1%)+

2&=&/D&5/7$61B+7'1'7 Y"D&+6/#97 A.1%7D&.716+#"'/"% R*'&%7/"%+#"'/"% J%P&*'&%)+#"'/"% !"%'."6+81%)6&+7/;& EZ1/.%&77E

?#MH>@"JJ(&/"0GE0H> LY+ ?D%&E@.#>@"JG $('>"0>HJ"M0G>E0> Q.&E@>IF!>GE&/#.% $E0H#(>c"%&'E@A $#EG(J>)(@D.0E&)>O"J> ?M&D $/JE0H Q.##Y&/D(J(>&D./( $'.0G>'">D"#G>G"##-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 e"%&'E@A>O"J>(.@D>#E)N ?M## 2MNN(J>N.0G $'E@A Q.&(>'">.''.@D>'">G"##

?"GEM)>"J>&'.0G F"#"J>@"G(G>GE&/#.%> $'JE0H&YJ(E0& $E0H#(>c"%&'E@A>O"J>.##> [TE&' ?M##>"0>)(@D.0E&) !EJ(@'E"0.#>/.G 10#%>M&(>.J)&_>.''.@D>QM''"0 QM''"0& 10#%>M&(>#(H&_>.''.@D>e"%&'E@A>S>NM''"0 +''.@D>"0(>#(H_>AE@A>

$'.0GK>R"#G>M0G(J>$'.0GK>R"#G>.'>T.E&'

!"%=&$'+Z.10#&%'7

!"%=&$'+Z.10#&%'7

!"%=&$'+Z.10#&%'7

!"%=&$'+Z.10#&%'7

Page 23: Hasbro: Consumer Product Design Report

Kat  Ingalls   23  

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.

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.

!"#$"%&%' !"#$%& '%()*+#,-(&(.% /0*$12+. !"#$%&,3,4*00 4*00 !$(+- !"#$%& 4*00(%)&*+, 5678 56798 5679: 567;< 567;= 567>> 5678= 5678;

-./0/%1'/%0+2&34/.&#&%'56&+71''8&+9:9'&#+96188+7&+178&+'"+.&;"0%/<&+1;;&99".:+

/'&#9=

>"88?9+7"):+96188+7&+178&+'"+;"##4%/;1'&+@/'6+71''8&+

9:9'&#=

>"88?9+8/#79+96188+7&+178&+#1%&4A&.178&+B'"+#1C&+

#"'/"%+'"+D6/'=DE

>"88+96188+7&+F/*&)+/%+9$1;&+)4./%0+71''8&+01#&$81:+F".+

F1/.%&99=

G1''8&+9:9'&#+96188+7&+178&+'"+;"##4%/;1'&+@/'6+"'6&.+

71''8&+9:9'&#9=

>"88+96188+7&+178&+'"+.&0/9'&.+@6&%+1+D6/'D+619+7&&%+94;;&99F488:+#1)&=

H79'.1;'+I1#& 2&1)+1;;&99"./&9 J&1$"%9+)1#10& !8"'6/%0+17/8/'/&9 !"##4%/;1'/"%+!".)+;"%%&;'/"% K"A&+8/#79 DL1/.%&99D !"##4%/;1'/"%+M&%9". M&%9&+6/'

6?@4 @+AB%(#%,4(&(.% @+AB%(#%,4(&(.% @6 !2+.0%,C*"#$2AD E#%,(,#$(+- @6 FG$$*+H,/0*$1%#

I(#%B,!A(++%B @+AB%(#%,4%J%+#% @+AB%(#%,4%J%+#% '2,?2 K*"#$2AD,J*B,%(A1,02&L E#%,(,#$B() '2,?2 FG$$*+H,F*-",($,A*+$(A$,)*2+$#

M+$%B,(,A*-% NL202$2%#,OP(.2AQ,!G)%BQ,!$%(0R NL202$2%#,OP(.2AQ,!G)%BQ,!$%(0R F0G%$**$1 !$B2+.#SB%2+# E#%,*+0",(B&#Q,($$(A1,0%.# F0G%$**$1 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$$*+ N$$(A1,*+%,0%.Q,D2AD,W2$1,*$1%B,O)2V*$,)*2+$R

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

@+$%.B($%-S@+,-*00 X(+-,/*+$B*0,OP(+G(0R U0G. /*+-GA$2V2$",L%$W%%+,-*00#

6(A1%$,P%A1(+2#&

!W2$A1,P%A1(+2#&

I%.,U2V*$

42B%A$2*+(0,U(-

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

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

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

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

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

I"'&9NFG$$*+,2+,A0*$1%#,B%&*V%-,LSA,2+$B*-GA%#,G++%AA(B",B%)%($%-,A*#$

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

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

H;;&99"./&9+B@&1$"%9+1%)+;8"'6/%0E+96188+61A&+/#$1;'+"%+01#&$81:=

!"%;&$'+L.10#&%'9

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

Page 24: Hasbro: Consumer Product Design Report

24   Hasbro  Product  Design  Team  

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.

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.

Attribute

Cost of materials (reverse scored) 3 2 6 1 3 3 9 2 6

Ease of Use 2 3 6 1 2 3 6 2 4

Technologically complicated (reverse scored)

1 1 1 3 3 2 2 1 1

Safety 3 3 9 2 6 3 9 3 9

Durability 2 2 4 1 2 3 6 1 2

11 26 8 16 14 32 9 22TOTAL

Ra

ting

We

igh

ted

Ra

ting

Ra

ting

We

igh

ted

Ra

ting

Att

ribu

te W

eig

ht

Single JoystickJoystick for Each

LimbButtons Joystick + Button

Ra

ting

We

igh

ted

Ra

ting

Ra

ting

We

igh

ted

Ra

ting

!"#$% &'()("*+("),-$./('$0$"+ 123+'*4+,5*0$ !""#$ -$367/+(6"

!"#$ %&'()*++,'(-.-+'/(-&*,,()'(*),'(+0(1'*2(302'-4-'5-01-(05(3,0+&657(*33'--01.(6+'/-# "'*2(3,0+&657 !"#$%&'%(')"*&+,-'*.)"*&/'01"2+(+"&'33'

."*4"')%%5'(%)'+,,%4*#+%,689$,2*++7$,3:3+$0,39*77,2$,*27$,+6,

'$46)"(;$,*44$336':,(+$03<

!"#8$ %&'(9'*:05(*33'--016'-(-&*,,(&*;'(2*/*7'(,';',-(*52(2*/*7'(+.:'-(*--036*+'2(96+&(+&'/# <'*:05-(2*/*7' 7*5"1.*/'+51*2#'+0'*.)"*&/'01"2+(+"&'3'

."*4"')%%5'(%)'+,,%4*#+%,6144$336'($3,=$*>6"3,39*77,9*?$,(0>*4+,6",)*0$>7*:<

!"#8= %&'(3,0+&657(*33'--016'-(-&*,,(&*;'(>?-(*52(*)6,6+6'-(*--036*+'2(96+&(+&'/# <'*:05-(*)6,6+6'- 7*5"1.*/'+51*2#'+0'*.)"*&/'01"2+(+"&'3'

."*4"')%%5'(%)'+,,%4*#+%,6144$336'($3,476+9("),39*77,9*?$,(0>*4+,6",)*0$>7*:<

!"#$@ A*++,'(-.-+'/(-&*,,(305+*65(65B1*1'2(-'5-01# C0//D563*+605(E'5-01 !"#$%&'%('2%558,+2*#+%,'+0'*.)"*&/'01"2+(+"&6

@*++7$,3:3+$0,39*77,2$,*27$,+6,4600/"(4*+$,=(+9,6+9$',2*++7$,3:3+$03<

!"#FG H*+*(+1*5-B'1(3012(-&*,,(3055'3+(20,,I-()02.(*52()*++,'(-.-+'/# C0//D563*+605(C012(3055'3+6059:%)&9'0%.8#+%,'0$%8.&',%#'/"#';"'01"2+(+"&6

A677B3,26#:,39*77,2$,*27$,+6,4600/"(4*+$,=(+9,2*++7$,3:3+$0<

!"#F@ J*3&(0B(20,,I-(,6/)-(K$(*1/-L($(,'7-M(-&*,,()'(/*5'D;'1*),'().(305+10,(/'3&*56-/# N0;'(,6/)- <%#'*..'='.+5;0',"2"00*)+./'>+..';"'

5%4+,-?'%)',""&'#%'5%4"'@0""'AB6==CA677B3,7(023,39*77,2$,*27$,0*"$/?$'*27$,C+6,

0*D$,06+(6",+6,E9(+<EF

!"#==

O*/':,*.(-&*,,()'(PB*61#P

Q*615'--

D*+),"00'+0',%#'01"2+(+"&6'E%>'2*,'-*5"1.*/';"'5*&"'9(*+)F9'G$"'+008"'>*0'>+#$'5%4+,-'#$"'&%..'*>*/'>$",'

*'$+#'>*0'*;%8#'#%';"'5*&"?'0%'(*+),"00';*0"&'%,'.%2*#+%,6

A677,39*77,2$,G(%$#,(",3>*4$,#/'("),2*++7$,)*0$>7*:,G6',G*('"$33<

Page 25: Hasbro: Consumer Product Design Report

Kat  Ingalls   25  

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

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.

Accessory Recognition System

Accessory Gameply System

Scoring Communication System

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

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

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

Point Acquisition System

(Scoring System)

!"#$ #%&'()*(+$),)-( #! ;,(($)"&(($%#$&%(#$',$-#/1)'#-$6"#0$&$>"1'>$"&)$%##0$)=..#))?=((*$+&8#3

@&''(#$)*)'#+$)"&(($81)7(&*$)'&')A$10.(=810/B$CDA$7,6#-A$8#?#0)#A$

&08$#E7#-1#0.#3.)*('+/&)%%(' #%&'()*(+$(0(%*( 12+"2 34556%7+8965:(* 3)*2&+.8$+;2*<9)=>%5('+)+&6;( ?@29252(*+AB)-2&C+/4<('C+/5()9D 394(5665: /(%*(+:25 E6&)92F)526%#%0')'(; G'()5('+$(0(%&( 86'; 34556%7+2%+02*5*H0((5 ?;I)%&(;+.8$+;2*<9)=394(5665: J94- J'(**4'(K*(%*252I(+,)5('2)9 L%+$699

#%5(-')5(;H#%+;699 J'(**4'(+*(%*6' L%+*=*5(,+*&'((%@&''(#$)*)'#+$)"&(($%#$&%(#$',$.,++=01.&'#$61'"$,'"#-$%&''(#$)*)'#+)3

86%;4&52I25=+@(5M((%+;699*

E('@)9+)%%64%&(,(%5#! !"#$).,-10/$)*)'#+$)"&(($%#$&%(#$

',$-#&8$610F(,))$-#.,-8$5>#E7#-1#0.#>9$6"#0$&''&."#8$',$

8,((312+"2 86';394(5665: 8:2<86;(K56K86%%(&5+A:6MND /,)'5+&)';86'; 86;(J94- #%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

Scoring System

Page 26: Hasbro: Consumer Product Design Report

26   Hasbro  Product  Design  Team  

Figure 21: Summary of final subsystem organization

Doll's Form SystemBattle Device Form SystemAccessories Form System

POWER SYSTEM POWER SYSTEM Power System

FAIRNESS SYSTEM Fairness Assurance System

Accessory Scanning SystemSkill Level Acquisition SystemGameplay AlgorithmData Transfer Hardware SystemScoring Input SystemInformation Display SystemScoring Control Mechanism SystemPlay Modes

FORM FACTOR SYSTEM PHYSCIAL FORM

SCORING SYSTEM

DATA ACQUISITION SYSTEM

DATA TRANSFORMATION SYSTEM

USER INTERFACE SYSTEM

Figure 22: Subsystem development (final)

Page 27: Hasbro: Consumer Product Design Report

Kat  Ingalls   27  

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

Page 28: Hasbro: Consumer Product Design Report

28   Hasbro  Product  Design  Team  

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

Page 29: Hasbro: Consumer Product Design Report

Kat  Ingalls   29  

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

Page 30: Hasbro: Consumer Product Design Report

30   Hasbro  Product  Design  Team  

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 mechanism.

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 battle system and the battle doll could be created to determine the best distance of wire to be used, or other 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.

Figure 29: Highback form allowing for constant data

connection

Figure 28: The end of the cable could easily be attached to a joystick to control all limbs.

Page 31: Hasbro: Consumer Product Design Report

Kat  Ingalls   31  

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.

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.

Material # Component ! "#$%&%'()%'&('% *+,, -'#.%/# 0..1233444+%'#.%/#+5/637%/(85.93:;'5.%/#<5=>/61/#'#.9+0.6! ?*+,,)@ A&..'%<'9 *+@B C6&D/# 0..1233444+&6&D/#+5/631&5E=FCG:HH=CI!B=J8../#=J&..'%K3(13A**!LMNO>P3%'$Q9%R!R!S9Q015T<'QUVLWTX<(Q!B*,Y!!ZW@T9%Q!=!! ?*+@B)B A8../#9)4<.0)5/#.&5.9)[0<.)D/#'9;\ *+!* :9.<6&.' [&..&50).<#)$<;6)./)J&5E)/$)D/#'9\ Z ?*+Z*)Z A8../#9)4<.0)5/#.&5.9)[J&..;')9K9\ *+!* :9.<6&.' [&..&50).<#)$<;6)./)96&;;)%8JJ'%\ Z ?*+Z*), 7890)J8../#)6'50&#<96 *+Z* :19<;/# 0..1233'19<;/#<#(89.%<'9+5/631%<5<#]35/9.=/$=.//;<#]3@ ?*+W*)Y M/;;)$/%6 *+W* :19<;/# 0..1233'19<;/#<#(89.%<'9+5/631%<5<#]35/9.=/$=.//;<#]3! ?*+W*)^ H>M)95%''# !+** C;<J&J& 0..1233444+&;<J&J&+5/631%/(85.=]93ZZWB_*^,!3!RWR<#50R.$.R;5(R95%''#+0.6;! ?!+**)W 7;&9.<5)(/;;)9.&#( *+W* :19<;/# 0..1233'19<;/#<#(89.%<'9+5/631%<5<#]35/9.=/$=.//;<#]3! ?*+W*)_ ><%58<.)J/&%( @+** :9.<6&.' [8#&J;')./)('.'%6<#'\ ! ?@+**)

!"!#$ %&'()

Bill of Materials Cost Per Unit

Supplier Reference Quantity per Toy

Sub Totals

Page 32: Hasbro: Consumer Product Design Report

32   Hasbro  Product  Design  Team  

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.

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.

Figure 32: Snapshot of GQM

The complete GQM table is included in Figure 33 on the next page, as well as in the Appendix included on the accompanying CD. The GQM is an important tool to measure how customer preferences will be met.

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

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

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

(>A5<34@>A7,B53CD>7,-;>4<;E7,/6=<;F5 '<;G5H4,*9G5H4CF5 (35<7,I825<7,-;>45J4,K@4<CJ &>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$68.->-2.687E+??-+;6874

.01 5-2678 .-:/80;076:+;$68.->-2. :/6;5D31->

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

*+,-$./-$.01$2+9-$.0$32-4 .01 5-2678 2+9-.1 :/6;5D31->

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

!"#$% &'(%)*"+% *,(#$-.()/*0 #11/"2*.#)(-.()/*0 ,#)#-0"$$(0)*"+-.()3",*4-567-894:-79:;-<94-9-=9>>?@-A98@-=@-

B?9:@CD

,@>@E8F4@C-GE68-C@;FA4-H-?66I-JBK H/@G@E->6-C@;FA4L-?F;>-M9?J@

367-894:-79:;-<94->5@->6:-=@-<J;>68FN@C-

9G>@E-BJE<59;@D-O0?6>5@;L-9<<@;;6EF@;L-<6?6E-

,@>@E8F4@-GFE;>-E94A@-6G-9<<@;;6EF@;-6GG@E@4C-

G6E-C6??L-<6J4>K

+J8=@E->5@-CFGG@E@4>-79:;-F4-75F<5-9-C6??-<94-

=@-<J;>68FN@CK+J8=@E@C-?F;>

,6@;->5@-<5F?C-J;@->5@->6:-9;-9-E@AJ?9E-C6??-F4-

9CCF>F64->6-J;F4A-=9>>?@-A98@D

"=@EMF4A-<5F?C 19E@4>9?-PJ@;>F649FE@19E@4>9?-%JEM@:

,6@;->5@->6:-89I@-AFE?;-G@@?-B66E?:-9=6J>->5@FE-

=6C:D

%JEM@:F4A-94CQ6E-6=;@EMF4A-<5F?CE@4 #;IF4A-B9E@4>;19E@4>9?-%JEM@:

,6->5@-B9E@4>;-46>F<@-94:-CFGG@E@4<@;-F4->5@-

AFE?R;-<64GFC@4<@-?@M@?D

19E@4>9?-94;7@E-S-:@;Q46 H*4>@EMF@7-6E-%JEM@:

,6@;->5@-<5F?C-;@@->5@-C6??-9;-9-E6?@-86C@?-G6E-

B@E;649?-;>E@4A>5D

%JEM@:F4A-<5F?CE@4 #;IF4A-<5F?C-B;:<56?6AF;>1E6G@;;F649?-E@G@E@4<@

367-?64A-C6@;->5@-<5F?C-;B@4C-=EJ;5F4A->5@-

C6??R;-59FED

"=;@EM@-<5F?CS-367-894:-8F4J>@;-9E@-;B@4>-

=EJ;5F4A-C6??T;-59FE-F4-9-UVH8F4J>@-B?9:-;@;;F64L-

64-9M@E9A@D

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

/@;@9E<5

,6@;->5@-<5F?C-G@@?->5@-4@@C->6-W>9I@-<9E@X-6G-

>5@-C6??D

"=;@EM@-<5F?CS-,6@;->5@-<5F?C-@4A9A@-*4-

4JE>JEF4A-9<>FMF>F@;L-F4<?JCF4A-=EJ;5F4A-59FEL-

G@@CF4AL-;6<F9?FNF4AL-@><KD

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

/@;@9E<5

*;->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@

#;IF4A-B9E@4>;-FG->5@:-59M@-46>F<@C-9->E@4C-F4-

<5F?CT;-6J>A6F4A4@;;K 19E@4>9?-%JEM@:

,6@;->5@-<5F?C-G@@?-@8B67@E@C-9G>@E-J;F4A->5@-

>6:D

"=;@EM@-<5F?C-6M@E-B@EF6C-6G->F8@Y-C6@;->5@-

<5F?C-89I@-86E@-F4C@B@4C@4>-<56F<@;-9G>@E-

J;F4A->5@->6:D

ZEF>@-9-?F;>-6G-79:;-F4-75F<5->5@-C6??-BE@;@4>;-

94-[@8B67@EF4A[-E6?@-86C@?K $F;>-6G-G@9>JE@;

*;->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

#;I-B9E@4>;K19E@4>9?-%JEM@:

,6@;->5@->6:-8@@>-;9G@>:-E@PJFE@8@4>;-

;B@<FGF@C-=:-39;=E6-;>94C9EC;-94CQ6E-<64;J8@E-

BE6CJ<>-E@AJ?9>F64;D

)56E6JA5-949?:;F;-6G-9??-<68B64@4>;-6G->6:-F4-

E@G@E@4<@->6-E@AJ?9>F64;K

!@4@E9?-949?:;F;-6G-<68B64@4>;-F4-E@G@E@4<@->6-

E@AJ?9>F64;K #49?:;F;-<5@<I?F;>

367-8J<5-EF;I-F;-9;;6<F9>@C-7F>5-9-<5F?C-J4C@E-

>5@-;JAA@;>@C-9A@-B?9:F4A-7F>5->5@-C6??D

^6E89?-EF;I-949?:;F;-@M9?J9>F64 \9;F<-EF;I-949?:;F;-@M9?J9>F64/F;I-949?:;F;

!"#$%&'$%&()%'"*$%+",)%-.//$0$,&%1")2%(/%34").,5%6"-"3&"7.4.&)8*"0."7.4.&)9:

!"#$%&'$%&()%.,2&.44%"%3(2.&.*$;%2&0(,5;%.,-$3$,-$,&%2$4/<.+"5$%

.,%5.042:

!"#$%&'$%&()%"33$"4.,5%&(%5.042=%,"&>0"4%,>&>0.,5%30$/$0$,?$2:

!"#$%&'$%&()%.,23.0$%"%2$,2$%(/%2&0$,5&':

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

Page 33: Hasbro: Consumer Product Design Report

Kat  Ingalls   33  

Figure 33: Complete GQM matrix

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

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

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

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

$:><-4B-<:6=>

,4=>-<E=-FE:K?-7>@-B4A-E=KO-BA46-78-7?;K<P "Q>=AM:8D-FE:K?->=<-;O-<49I #>@-O7A=8<>I 17A=8<7K-%;AM=9N-R=>S+4,4=>-<E=-O=A>48->=<<:8D-;O-<E=-<49-K44@-7<-<E=-?:A=F<:48>P-345-K48DP "Q>=AM:8D-FE:K?->=<-;O-<49I "Q>=AM:8D-7?;K<->=<-;O-<49I $:><-4B-<:6=>*8-E45-6789-579>-F78-7-Q7<<K=-D76=-Q=-OK79=?P ,=<=A6:8=?-BA46-?=>:D8-T-K44@-;OI T

/=B=A-<4-?=>:D8N-K:><-M7K;=

345-6789-579>-F78-<E=-<49-Q=-F;><46:U=?-7B<=A-O;AFE7>=P-G0K4<E=>N-7FF=>>4A:=>N-F4K4A-M7A:7<:48N-7A<:><:F-BK4;A:>E=>L

,=<=A6:8=-B:A><-A78D=-4B-7FF=>>4A:=>-4BB=A=8?-B4A-?4KKN-F4;8<I

+;6Q=A-<E=-?:BB=A=8<-579>-:8-5E:FE-7-?4KK-F78-Q=-F;><46:U=?I

+;6Q=A=?-K:><

,4=>-<E=-FE:K?-;>=-<E=-<49-7>-7-A=D;K7A-?4KK-:8-7??:<:48-<4-;>:8D-Q7<<K=-D76=P "Q=AM:8D-FE:K? 17A=8<7K-C;=><:487:A= 17A=8<7K-%;AM=9,:?-<E=-O7A=8<-Q;9-4A-FE:K?-A=C;=><-<E=-?4KK-Q=F7;>=-4B-:<>-<=FE84K4D:F7K-7<<A:Q;<=>P-:I=I-*8<=A7F<:M=-OE9>:F7K-V-M:A<;7K-D76=-78?-*/-F466;8:F7<:48

%;AM=9-7>@:8D-5E9-FE:K?A=8-578<=?S-O7A=8<>-Q4;DE<-<49

#>@-F454A@=A>-5E9-<E=9-54;K?-578<-<4-Q;9-<E=-<49I 0454A@=A-%;AM=9

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

%;AM=9-7>@:8D-5E9-FE:K?A=8-578<=?S-O7A=8<>-Q4;DE<-<49

#>@-F454A@=A>-5E9-<E=9-54;K?-578<-<4-Q;9-<E=-<49I

0454A@=A-%;AM=9

,4=>-<E=-<49-6==<->7B=<9-A=C;:A=6=8<>->O=F:B:=?-Q9-37>QA4-><78?7A?>-78?S4A-F48>;6=A-OA4?;F<-A=D;K7<:48>P

)E4A4;DE-787K9>:>-4B-7KK-F46O48=8<>-4B-<49-:8-A=B=A=8F=-<4-A=D;K7<:48>I

!=8=A7K-787K9>:>-4B-F46O48=8<>-:8-A=B=A=8F=-<4-A=D;K7<:48>I

#87K9>:>-FE=F@K:><

345-6;FE-A:>@-:>-7>>4F:7<=?-5:<E-7-FE:K?-;8?=A-<E=->;DD=><=?-7D=-OK79:8D-5:<E-<E=-?4KKP

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

,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 #>@:8D-O7A=8<> 17A=8<7K-%;AM=9

,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 T *8<=AM:=5-4A-%;AM=9

,4=>-<E=-FE:K?->==-<E=-?4KK-7>-7-A4K=-64?=K-B4A-O=A>487K-><A=8D<EP %;AM=9:8D-FE:K?A=8 #>@:8D-FE:K?-O>9FE4K4D:>< 1A4B=>>:487K-A=B=A=8F=345-6;FE-<:6=-?4=>-<E=-;>=A-OK79-5:<E-<E=-?4KK-:8-7-D:M=8-OK79->=>>:48P "Q=AM=A:8D-FE:K?-T-<:6=-Q=<5==8-O:F@:8D-;O-

<49-78?-64M:8D-<4-784<E=A-<4904KK=F<:8D-?7<7-48->:6:K7A-<49>

/=>=7AFE

345-4B<=8-:>-<E=-<49-OK79=?-5:<E-O=A-?79SO=A-5==@P "Q>=AM=-8;6Q=A-4B-<:6=>-FE:K?-O:F@>;O-?4KK #>@:8D-O7A=8<>-E45-4B<=8-<49-:>-OK79=?-5:<E-M=A>;>-4<E=A-<49>-48->F7K=-4B-]-<4-^

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

345-K48D-:>-<E=-<49-OK79=?-48-<E=-K48D-<=A6-Q=B4A=-:8<=A=><-:>-K4><-78?-:>-A=OK7F=?-5:<E-784<E=A-<49P

"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

04KK=F<:8D-?7<7-48->:6:K7A-<49>/=>=7AFE

WE7<-A78D=-4B-7D=>-:>-:8<=A=><=?-:8-<E=-<49P %;AM=A9-4B-FE:K?A=8-7B<=A-Q=:8D->E458-67A@=<:8D-7?M=A<:>=6=8<>-4A-Q=:8D-D:M=8-7-?4KK-<4-OK79-5:<E

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

,4=>-<E=-?4KK-DA45-78?-7?`;><-5:<E-<E=-;>=AP "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

04KK=F<:8D-?7<7-48->:6:K7A-<49>/=>=7AFE

*>-<E=-;>=A-64A=-4;<D4:8DSQA7M=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=

#>@:8D-O7A=8<>-:B-<E=9-E7M=-84<:F=?-7-<A=8?-:8-FE:K?a>-4;<D4:8D8=>>I 17A=8<7K-%;AM=9

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

WA:<=-7-K:><-4B-579>-:8-5E:FE-<E=-?4KK-OA=>=8<>-78-_=6O45=A:8D_-A4K=-64?=KI $:><-4B-B=7<;A=>

*>-<E=-FE:K?-64A=-=8=AD=<: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

#>@-O7A=8<>I17A=8<7K-%;AM=9

*>-<E=-<49-;>=?-64A=-B4A-Q7<<K=-OK79-5:<E-O7A<8=A>N-4A->4K:<7A:K9P "Q>=AM=-FE:K?-<4->==-E45-6789-<:6=>-<E=-?4KK-:>-O:F@=?-;O-78?-OK79=?-5:<E-48-48=a>-458-M=A>;>-:8-DA4;OI

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

/=>=7AFE

*>-<E=-<49-;>=?-B4A-<A7?:<:487K-?4KK-OK79-5:<E-4<E=A>P "Q>=AM=-FE:K?-OK79:8D-5:<E-?4KKb-4A-?4=>-<E=-FE:K?-7K>4-;>=-<E=-?4KK-7>-7-<A7?:<:487K-?4KK-5:<E-4<E=A>P-R=>S84

04KK=F<-?7<7-48->:6:K7A-<49>I/=>=7AFE

*>-<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-:8-D76=OK79N-4A-?4=>-<E=-FE:K?-7K>4-;>=-<E=-?4KK-7>-7-<A7?:<:487K-?4KKP-R=>S84

04KK=F<-?7<7-48->:6:K7A-<49>I

/=>=7AFE

,4=>-<E=-;>=A-:67D:8=-=8M:A486=8<>-:8-5E:FE-<E=-?4KK-:>-Q7<<K:8DP "Q>=AM=-FE:K?-OK79:8D-5:<E-?4KK-T-?4=>-<E=-FE:K?-><7<=-<E7<-<E=-?4KK-:>-:8-<E=-`;8DK=N-:8-4;<=A->O7F=N-4A-4<E=A-:67D:87<:M=-OK79->=<<:8D>P

#>@-O7A=8<>I

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

,4=>-<E=-FE:K?-:67D:8=->F=87A:4>-B4A-5E:FE-<E=-?4KK-:>-Q7<<K:8DP "Q>=AM=-FE:K?-OK79:8D-5:<E-?4KK-T-?4=>-<E=-FE:K?-><7<=-<E7<-<E=-?4KK-:>-B:DE<:8D-<4->7M=-<E=-OK78=<N-B4A-OA4<=F<:8D->46=48=-4A->46=<E:8DN-4A-<4-67@=->46=<E:8D-E7OO=8P

#>@-O7A=8<>I

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

WE7<-:>-<E=->67KK=><-><78?7K48=-O7A<-4B-<E=-<49P-G>67KK-c-=7>9-<4-K4>=L .=7>;A=-?:6=8>:48>-4B->67KK=><-O7A<-4B-<49I T.=7>;A=6=8<

,4=>-<E=-<49-:8FK;?=-><4A7D=->9><=6>-:8-:<>-?=>:D8P /=M:=5-OA4?;F<->O=F:B:F7<:48>-T-K:><-579>-:8-5E:FE-><4A7D=->4K;<:48>-E7M=-Q==8-:8FK;?=?I

T1A4?;F<-B=7<;A=>-K:><:8D

345-6789-O7A<>-?4=>-<E=-?4KK-E7M=P /=M:=5-OA4?;F<->O=F:B:F7<:48>-<4-?=<=A6:8=-8;6Q=A-4B-_BA==-><78?:8D_-O7A<>-:8-<49I

Td7K;=-BA46-OA4?;F<->O=F:B:F7<:48>

345-K48D--?4=>-:<-<7@=-<4-F4KK=F<-O:=F=>-7B<=A->F7<<=A=?P "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

"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

0454A@=A-/=>=7AFE

WE7<-:>-<E=-F4><-4B-F46O7A7QK=-OA4?;F<>P-,4=>-4;A-<49-F4><-64A=-4A-K=>>P /=>=7AFE-67A@=<-OA:F=>-4B-F46O=<:<4A>S>:6:K7A-<49>I-WE7<-:>-<E=-O=AF=8<-?:BB=A=8F=-Q=<5==8-4;A-OA:F=>P

T

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

,4-Q;9=A>-B==K-<E=-OA:F=-:>-B7:A-e-<E7<-<E=9-7A=-?=A:M:8D-M7K;=P %;AM=A9-O7A=8<>-:8-A=>O=F<-<4-<E=:A-O=AF=:M=?-M7K;=-T-<44-=HO=8>:M=-B4A-5E7<-<E=9-A=F=:M=?N-B7:AN-4A-_DA=7<-?=7K_

/=>=7AFE-?7<7-B4A->:6:K7A-OA4?;F<>-78?->;AM=9>-?48=-B4A-<E=:A-OA:F:8DI /=>=7AFE

,4-@:?>-578<-<E=:A-458-<49P "Q>=AM=-FE:K?-7B<=A->E45:8D-<E=6-=:<E=A-7-<49-:8-7-><4A=->=<<:8DN-7-<49-Q=:8D-OK79=?-5:<E-Q9-784<E=A-FE:K?N-4A-7-67A@=<:8D-F466=AF:7KI-,4-<E=9->79N-_*-578<-<E7<f_

#>@-O7A=8<>-:B-FE:K?A=8-54;K?-578<-<49I

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

,4=>-<E=-FE:K?->E45-<E=-<49-4BB-<4-<E=:A-BA:=8?>P "Q>=AM=-FE:K?A=8-:8-FK7>>A446N-K;8FEA446N-4A-E46=->=<<:8DI-,4=>-<E=-FE:K?-67@=-7-O4:8<-4B->E45:8D-4A-<=KK:8D-BA:=8?>-7Q4;<-<49P-R=>S84I

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

,4=>-<E=-FE:K?->E45-<E=-<49-4BB-<4-<E=:A-O7A=8<>P #>@-O7A=8<>-:B-FE:K?-K:@=>->E45:8D-4A-<=KK:8D-O7A=8<-7Q4;<-<E=:A-<49I

T17A=8<7K-%;AM=9

345-6789->4;8?>-?4=>-<E=-<49-67@=P /=M:=5-OA4?;F<->O=F:B:F7<:48>-T-E45-6789-;8:C;=-84:>=>-7A=-?=>:D8=?-:8<4-<E=-<49P-

T

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

,4-<E=-<49[>->4;8?>-=8E78F=-<E=-Q=K:=M7Q:K:<9-4B-D76=OK79P #>@-FE:K?A=8-:B-<E=->4;8?>-67@=-?;A:8D-D76=OK79-67@=>-<E=-D76=-64A=-A=7K:><:F-G:8-<E=:A-4O:8:48LI

#>@-7?;K<>-:B->4;8?>-67@=-?;A:8D-<E=-D76=OK79-67@=>-<E=-D76=-64A=-A=7K:><:F 0454A@=A->;AM=9

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

"Q>=AM=-FE:K?\-.7@=-FE=F@K:><-4B-E45-6789-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

P

"Q>=AM7<:48

,4=>-<E=-FE:K?-QA;>E-<E=-?4KK[>-E7:AP "Q>=AM=-FE:K?\-,4=>-FE:K?-QA;>E-?4KKa>-E7:AP #>@-O7A=8<>-:B-FE:K?-QA;>E=>-?4KKa>-E7:A 17A=8<7K-%;AM=9345-K48D-?4=>-<E=-FE:K?->O=8?-=H76:8:8D-<E=-?4KK[>-B=7<;A=>P "Q>=AM=-FE:K?\-W:<E:8-<E=-B:A><-]h-6:8;<=>-4B-

D76=OK79N-E45-K48D-?4=>-<E=-FE:K?->O=8?-`;><-K44@:8D-7<-G84<-64M:8DL-<E=-?4KKI

#>@-FE:K?N-O7A=8<>-4A-F454A@=A>\-*>-<E=-?4KK-M:>;7KK9-:8<=A=><:8DP-R=>S+4 %;AM=9

,4=>-<E=-?4KK-E7M=-A=7K:><:F-OA4O4A<:48>P /=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

T

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

,4=>-<E=-?4KK-E7M=-A=7K:><:F-E7:AP #>@-FE:K?-:B-E7:A-K44@>SB==K>-A=7K:><:FI #>@-F454A@=A>-:B-E7:A-K44@>SB==K>-A=7K:><:FI 0454A@=A->;AM=9345-K48D-F78-<E=-<49-Q=-OK79=?-5:<E-Q=B4A=-7-F46O48=8<-QA=7@>-GQ;<-><:KK-B;8F<:48>LP

09FK=-<49-<EA4;DE-FE:K?A=8-;8<:K-848T=>>=8<:7K-F46O48=8<-QA=7@>-T-?=<=A6:8=-7M=A7D=-E4;A>-4B-OK79I

37M=-O7A=8<>-A=O4A<-E45-K48D-7B<=A-Q;9:8D-?4KKN-848T=>>=8<:7K-F46O48=8<-QA=7@>I 17A=8<7K-%;AM=9

345-K48D-F78-<E=-<49-Q=-OK79=?-5:<E-Q=B4A=-:<-8==?>-<4-Q=-A=OK7F=?P 09FK=-<49-<EA4;DE-FE:K?A=8-;8<:K-<49-QA=7@>-T-?=<=A6:8=-7M=A7D=-E4;A>-4B-OK79I

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

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

345-K48D-F78-<E=-<49-Q=-OK79=?-5:<E-Q=B4A=-:<->E45>->:D8>-4B-5=7AP "Q>=AM=-FE:K?A=8\-345-6789-E4;A>-4B-OK79-;8<:K-B:A><->FA7FES?=8<SFE:O-7OO=7A>P

04KK=F<:8D-?7<7-48->:6:K7A-<49>/=>=7AFE

*>-<E=-?4KK-57<=AOA44B-78?S4A-;87BB=F<=?-Q9-E;6:?-F48?:<:48>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

+48=

1A4?;F<-%O=F:B:F7<:48-,7<7

*>-<E=-?4KK-7QK=-<4-Q=-;>=?-4;<-4B-?44A>-5:<E4;<-?767D=P "Q>=AM=-E45-<49-A=7F<>-<4-Q=:8D-OK79=?-5:<E-48-A4;DE-F48FA=<=N-:8-=H<A=6=-E=7<-4A-F4K?N-48-?=59-DA7>>-T-=8M:A486=8<7K-B7F<4A>I

/=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=-<49a>-F46O48=8<>P-046O7A=-5:<E-M7A:4;>-4;<?44A-F48?:<:48>I

/=>=7AFE-*8-A=K7<:48-<4-OA4?;F<->O=F:B:F7<:48>

345-K48D-?4=>-<E=-FE:K?->O=8?-QA;>E:8D-<E=-?4KK[>-E7:AP "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

04KK=F<:8D-?7<7-48->:6:K7A-<49>/=>=7AFE

,4=>-<E=-FE:K?-B==K-<E=-8==?-<4-X<7@=-F7A=Y-4B-<E=-?4KKP "Q>=AM=-FE:K?\-,4=>-<E=-FE:K?-=8D7D=-*8-8;A<;A:8D-7F<:M:<:=>N-:8FK;?:8D-QA;>E:8D-E7:AN-B==?:8DN->4F:7K:U:8DN-=<FIP

04KK=F<:8D-?7<7-48->:6:K7A-<49>/=>=7AFE

345-4B<=8-:>-<E=-<49-OK79=?-5:<EP "Q>=AM=-FE:K?-4M=A->=M=A7K-E4;A>-:8-_E46=TK:@=_->=<<:8Db-E45-6789-<:6=>-:>-?4KK-O:F@=?-;O-78?-OK79=?-5:<E-B4A-7<-K=7><-^-6:8;<=>P-345-K48D-:>-<E=-?4KK-OK79=?-5:<E-48-7M=A7D=-Q=B4A=-Q=:8D->=<-?458P

#>@-O7A=8<>-<4-=><:67<=I

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

,4=>-<E=-FE:K?-FE44>=-<E:>-<49-5E=8-D:M=8-<E=-4O<:48-4B-FE44>:8D-4<E=A>P "Q>=AM=-FE:K?\-345-6789-<:6=>-:>-<E:>-<49-<E=-B:A><-FE4>=8-B4A-=7FE-OK79->=>>:48P

#>@-O7A=8<>-5E7<-O=AF=8<7D=-4B-FE:K?a>-<:6=->O=8<-OK79:8D-:>-5:<E-<E:>-<49I

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

,4=>-<E=-FE:K?->6:K=-5E:K=-OK79:8D-5:<E-<E=-<49P "Q>=AM=-FE:K?\-*>->E=->6:K:8D-7>->E=-OK79>-5:<E-<E=-<49P-R=>S84

#>@-O7A=8<>-:B-FE:K?->6:K=>-5E:K=-<49-:>-Q=:8D-OK79=?-5:<EI

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

,4=>-<E=-FE:K?-7>@-<4-QA:8D-<E=-<49-48->E4A<-<A:O>P "Q>=AM=-FE:K?\-,4=>-FE:K?-7>@-<4-QA:8D-?4KK-5:<E-<E=6-5E=8-7>@=?-<4-D4->46=OK7F=-G>FE44KN-DA4F=A9-><4A=N-BA:=8?>a-E4;>=N-DA78?67a>-E4;>=L

#>@-O7A=8<>-:B-FE:K?-4B<=8-7>@>-<4-QA:8D-<49-5:<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==@

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

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

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

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

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

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

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

!"#$%&'$%&()%.,/&.44%"%/$,/$%(*%01.6$%.,%&'$%+/$1%<3((4%*"3&(1=-

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

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

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

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

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

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

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

!"#$%&'$%&()%'"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/-

Page 34: Hasbro: Consumer Product Design Report

34   Hasbro  Product  Design  Team  

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:

Figure 34: Customer affinity weighting

Attribute Shortname

GQM Attributes

Customer weight (%)

NurturingMake the toy appealing to girls' natural nuturing preferences. 3.5

Sense of StrengthMake the toy instill a positive, strong, independent self-image in girls. 5

PrideMake the toy instill a sense of pride in the user (cool factor). 9

ImaginationMake the toy develop the user's imagination. 10.5

CollaborationMake the toy encourage play with others. 8

LongevityMake the toy playable for a long time. 3.5

Tech InterestMake the toy technologically interesting/appealing. 2

VariabilityMake the toy have many different ways of playing (variability). 9

SoundMake the toy aurally stimulating.

5

TouchMake the toy tactile-ly stimulating.

1

LookMake the toy visually stimulating.

9

UsabilityMake the toy easy to use.

8

CostMake the toy affordable.

6

Clean upMake the toy easy to clean up/not messy. 3.5

DurabilityMake the toy durable, resistant to damage. 5

SafetyMake the toy safe to use.

12

Page 35: Hasbro: Consumer Product Design Report

Kat  Ingalls   35  

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>

Page 36: Hasbro: Consumer Product Design Report

36   Hasbro  Product  Design  Team  

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.

Figure 36: Customer perception analysis

Figure 37: Graphical representation of customer perception

!"#$"#%&' !"#$%&$'(()'*%+,$-"$,%.*&/$+'-0.'*$+0-0.%+,$(.)1).)+2)&3 3.5 4 5 6 7 6 8 8 6

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

/#%0) !"#$%+&-%**&$'$&)+&)$"1$(.%;)$%+$->)$0&).$?2""*$1'2-".@3 9 5 4 5 7 6 6 6 5

123'%&3$%,& !"#$;)9)*"(&$->)$0&)./&$%=',%+'-%"+3 10.5 4 6 7 8 5 4 5 4

4,5536,#3$%,& A'B)$->)$-"#$)+2"0.',)$(*'#$C%->$"->).&3 8 5 4 7 5 7 4 8 7

7,&')8%$9 !"#$%&$(*'#'D*)$1".$'$*"+,$-%=)33.5 5 6 4 8 4 5 4 7

:);.+1&$)#)*$ !"#$%&$-)2>+"*",%2'**#$%+-).)&-%+,E'(()'*%+,3 2 6 7 5 8 5 7 4 6

<3#%36%5%$9 !"#$>'&$='+#$;%11).)+-$C'#&$"1$(*'#%+,$?9'.%'D%*%-#@3 9 5 6 7 8 7 4 7 8

(,"&0 !"#$%&$'0.'**#$&-%=0*'-%+,35 5 8 7 7 8 8 5 6

:,";. !"#$%&$-'2-%*)<*#$&-%=0*'-%+,31 5 4 8 6 5 5 7 6

7,,= !"#$%&$9%&0'**#$&-%=0*'-%+,39 5 6 8 8 4 6 4 5

>*36%5%$9 !"#$%&$)'&#$-"$0&)38 7 5 4 6 5 5 4 4

4,*$ !"#$%&$'11".;'D*)36 8 6 5 6 4 5 7 7

45)3&+"? !"#$%&$)'&#$-"$2*)'+$0(E+"-$=)&&#3 3.5 4 7 6 6 8 4 5 6

@"#36%5%$9 !"#$%&$;0.'D*):$.)&%&-'+-$-"$;'=',)3 5 4 5 8 6 4 5 4 7

(3-)$9 !"#$%&$&'1)$-"$0&)312 5 6 6 8 4 7 4 5

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

1#,&+A3&

+3;$%,&+-%'

"#)

B,C

))+D5%8)+/)

$*

+++CUSTOMER ATTRIBUTES

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

BATT

LE D

OLL+HOD(

MGEN

M3#6%)

:323',$;.%

G,;=+F2+(,;=+F2

+G,6

,$*

P"Q"+/)$*

M3="

',&

!"

#"

$"

%"

&"

'"

()*+)*,-."

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

5*,60"

789.,-9:2-"

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

>2-.0?,+@"

A0B4"7-+0*01+"

C9*,9=,<,+@"

/2)-6"

A2)B4"

>22D"

E19=,<,+@"

;21+"

;<09-")F"

G)*9=,<,+@"

/930+@"

HIAA>J"GK>>"LMI/HNKO"

H9*=,0"

A989.2+B4,"

N2BD"J8"/2BD"J8"N2=2+1"

P)Q)"50+1"

H9D).2-"

7*2-"R9-"9B:2-"S.)*0"

T2U00"I<,?0"50+1"

Page 37: Hasbro: Consumer Product Design Report

Kat  Ingalls   37  

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.

Page 38: Hasbro: Consumer Product Design Report

38   Hasbro  Product  Design  Team  

Figure 38: Completed House of Quality

[END OF REPORT 1]

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

,,,CUSTOMER ATTRIBUTES

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

782%82&(64&5!+*!366-37+'(!$&!(+%7*8!'3$0%37!'0$0%+'(!6%-9-%-':-*; 3.5 < = > ? > @ @ >

9"()",'4,9%2"(6%*

4&5!+'*$+77*!3!6&*+$+,-A!*$%&'(A!+'/-6-'/-'$!*-79"+13(-!+'!(+%7*; 5 = @ < ? = = = <

:2&;"4&5!+'*$+77*!3!*-'*-!&9!6%+/-!+'!$B-!0*-%!C:&&7!93:$&%D; 9 = < = ? > > > =

<=$6&($%&'(4&5!/-,-7&6*!$B-!0*-%8*!+13(+'3$+&'; 10.5 < > ? @ = < = <

5'##$>'2$%&'(

.3E-!$B-!$&5!-':&0%3(-!6735!F+$B!&$B-%*; 8 = < ? = ? < @ ?

?'(6"@&%.4&5!+*!67353G7-!9&%!3!7&'(!$+1-;

3.5 = > < @ < = < ?A"3*,

<(%"2")%4&5!+*!$-:B'&7&(+:3775!+'$-%-*$+'(H366-37+'(; 2 > ? = @ = ? < >

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

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

5 = @ ? ? @ @ = >

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

1 = < @ > = = ? >

?''C4&5!+*!,+*03775!*$+1073$+'(;

9 = > @ @ < > < =

D)$>&#&%.4&5!+*!-3*5!$&!0*-;

8 ? = < > = = < <

5')%4&5!+*!399&%/3G7-;

6 @ > = > < = ? ?

5#"$(,8+4&5!+*!-3*5!$&!:7-3'!06H'&$!1-**5;

3.5 < ? > > @ < = >

182$>&#&%.4&5!+*!/0%3G7-A!%-*+*$3'$!$&!/313(-;

5 < = @ > < = < ?

9$4"%.4&5!+*!*39-!$&!0*-;

12 < > > @ < ? < =

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

// //

///

/

.+'+1

01!%3

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

.+'+1

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

//

K3$+&

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

K3$+&

!&9!F

3+*$"$&"B+6!%3$+&

201

G-%!&

9!90775!3%$+:073$-/

!L&+'$*

.3M+1

01!,-7&:+$5

!&9!B

+$

201

G-%!&

9!6+-:-*H:&16&

'-'$*!+':70/-

/!+'!63:E3(+'(

.3M+1

01!'01

G-%!&

9!:&'

'-:$+&'*!$&

!&$B-%!6735-%*

N3$3!:&'

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

--/

201

G-%!&

9!C*6-:+9+-/

D1&/

-*!&9!6

735

O&*$!&9!-

7-:$%&'+:!:&16&

'-'$*

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

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

G7-

E7F<7EE!<7F,5G

H!H5

AE!<9A<59

201

G-%!&

9!13$-%+37*!0*-/

I I I I I I

00 // //

0 0 /

/ / 0 0

/ / //

// //

// // / //

0

/

// // /

0 00

00

00

00

0

00 // /

J+$ K

BATTLE DOLL,LGH9M!NO

K K >.%")P) K Q QUNITS OF MEASURE K K K =P)

M$2>&" P;>I Q

A$=$6'%3*& Q Q Q Q

Q Q Q

< > < = @

=&(R

< @

==

@ P

Q

Q

P

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

OBJE

CTIV

E M

EASU

RES

? ??

= @= >

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

= < ? > = =

@ => = <

A$26"%)

= > ? ? @

00

000

00

/

0 0

HOUSE OF QUALITY

CU + HASBRO

BATTLE DOLL

I I I

0

//

/

/ / / ////

// // //

I I I

Q @ P

Q

Q

Q

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

//

Q Q

QQ

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

I I

Y8Z8,:"%)M$C86'(<2'(,J$(,$3%&'(,4&682"

QQ

BATT

LE D

OLL ,LGH9

M!NO

M$2>&"

A$=$6'%3*&

!'3C,E=,9'3C,E=

,!'>

'%)

Y8Z8,:"%)

M$C8

6'(

<2'(,J$(

,$3%&'(,4&6

82"

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

X'U

"",H#&@",:"

%)

Page 39: Hasbro: Consumer Product Design Report

Katie Ingalls

H A S B R O P R O D U C T D E S I G N C O R N E L L U N I V E R S I T Y P R O J E C T A D V I S O R : D A V I D S C H N E I D E R

Hasbro Product Design Team Semester 2

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.

WITH SIGNIFICANT CONTRIBUTIONS FROM: Nnamdi Alwabudine | Swapnil Bansal | Kenneth Bayus Aaron Johansen | Eric Ross | Paul Yen

Page 40: Hasbro: Consumer Product Design Report

2   Katie  Ingalls  :  Hasbro  Product  Design  

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

Page 41: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   3  

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.

Page 42: Hasbro: Consumer Product Design Report

4   Katie  Ingalls  :  Hasbro  Product  Design  

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.

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.

Page 43: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   5  

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.

Page 44: Hasbro: Consumer Product Design Report

6   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.

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.

Add? Delete/Replace? Change

type?

Behavior Num

Req Description Req Description

DR 4 DR.34 The system shall have a power on/off switch for user DR.7 Battle system shall have a power switch.DR 11 DR.61 Doll's form shall hold weapon firmly DR.30 Weapon shall be able to be held by doll securely.DR 12 DR.73 Weapon accessories shall be removable by significant impact Same as DR. 30DR 13 OR.31 Battle system shall be stored with doll's body in form of backpack. DR.X Traceable to OR.1DR 13 OR.30 Doll's form shall be able to hold battle system for storage. OR.2 Doll's form shall be able to hold battle system for storage.DR 13 OR.34 Battle system shall indicate to user that power is on. DR.8 Battle system shall indicate to user that power is on.DR 13 OR.32 Battle system must be able to display conncection status to user. DR.4 Battle system shall be able to display conncection status to user.A 13 OR Battle system shall have tamagotchi ("digital pet") mode.

DR 13 DR.48Battle system shall indicate to user that it is not connected (Tamagotchi Mode) DR Battle system shall indicate to user that it is in Tamgotchi mode.

Replace withChanged Items

Page 45: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   7  

Figure 5: Originating Requirements

Index Originating Requirement Abstract Function NameOR.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 Data shall transfer from doll to system. Doll-system communication

OR.6The system shall be able to determine whether the smart card inserted has data that was previously created by the system. Check previous data

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 systemRead experience

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 The doll shall be able to differentiate between being hit by another doll or by a child's hand. Hit type

OR.34 The battle system shall alert users that a cheating behavior has occured. Alert user of cheating

OR.35The battle system shall not translate experience to amount of HP reduced/points gained when hit is not made by doll. No points when hit is not by doll

OR.36The battle system shall be able not to translate abilities (clothes) to amount of HP reduced/points gained when hit is not made by doll. No abilities when hit is not 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 The weapon shall be able to be removed by average user in under X seconds. Weapon time

OR.41The doll's gameplay algorithm shall be altered accordingly when an accessory is removed or replaced. Accessory Status

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

Originating Requirements

Page 46: Hasbro: Consumer Product Design Report

8   Katie  Ingalls  :  Hasbro  Product  Design  

Figure 6: Derived Requirements

Index Derived Functional Requirement Function Name Source ORDR.1 Battle system shall be removable. Removability OR 1

DR.2 Data transfer system shall be powered. Data Power OR.4

DR.3Battle 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 OR.4

DR.9 Battle system shall indicate to user that power is on. Power on OR.42

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

Data transfer OR 5

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.13Data 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

DR.15Data system shall communicate to info system that connection is established.

Connection established system

OR 5

DR.16Battle system shall indicate to user that a connection has been established.

Connection established user

OR 42

DR.17 Data transfer mechanism shall send data to other battle systems. Data sending OR 3

DR.18Data 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.20The 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.22The 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.24The battle system shall be able to read codes/sensors on clothing accessory items.

Read clothing OR 10

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

Read clothing attriibutes OR 11

DR.26 Weapons shall be able to be held by doll.Weapon holding capability

OR 12

DR.27The 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.32The 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 OR.4

Derived Requirements

Page 47: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   9  

Figure 7: Derived Requirements (cont'd)

Index Derived Functional Requirement Function Name Source ORDR.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.46Both 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

DR.49The doll shall be able to differentiate between being hit by another doll or by a child's hand.

Source of hit OR.33

DR.50Data shall be transferred between the scoring and gameplay algorithms.

Scoring-Gameplay communication

OR.16

DR.51The gameplay algorithm shall determine change in HP based on the hit.

HP algorithm OR.27

DR.52The gameplay algorithm shall determine experience gained based on the hit.

Experience algorithm OR.28

DR.53The battle system shall display experience gained to the player who initiated the successful hit.

Experience display OR.32

DR.54The data transfer hardware system shall transfer cheating flag from fairness system to data acquisition system.

Fairness alerts data acquisition of cheating

OR 34

DR.55The game play algorithm shall drop/cancel game when cheating behavior has occered X times in a single round.

Cancel game due to cheating

OR 34

DR.56 The clothing removal system shall not contain pinch points. Pinch Points OR 20

DR.57The scanning system shall recognize that clothing has been removed.

Clothing removed OR 10

DR.58 The data transfer system shall be continually updating. Update OR 3

DR.59The 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 OR.9

DR.67Clothing 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

DR.70Doll's form shall be resistant to water for up to 1 minute before retrieval

Water Resistant OR 44

DR.71Battle system shall indicate to user that it is not connected (Tamagotchi Mode)

Tamagotchi mode OR.39

DR.72 Battle system shall switch from tamagotchi game mode Switch tamagotchi OR.39

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

Algorithm update OR 41

Derived Requirements

Page 48: Hasbro: Consumer Product Design Report

10   Katie  Ingalls  :  Hasbro  Product  Design  

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

OR.1

OR.2

OR.3

OR.4

OR.5

OR.6

OR.7

OR.8

OR.9

OR.10

OR.11

OR.12

OR.13

OR.14

OR.15

OR.16

OR.17

OR.18

OR.19

OR.20

OR.21

OR.22

OR.23

OR.24

OR.25

OR.26

OR.27

OR.28

OR.29

OR.30

OR.31

OR.32

OR.33

OR.34

OR.35

OR.36

OR.37

OR.38

OR.39

OR.40

OR.41

OR.42

OR.43

OR.44

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 8 !DR.23 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 !

Page 49: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   11  

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 State

1 Battle system on/off 2 System connected / not connected 3 Doll Connected /not connected 4 Battle System/Doll Communication on/off 5 Battle system /Battle System Communication on/off 6 Card Inserted/not inserted 7 Scanner on/off 8 Fairness on/off 9 Data Loaded/Unloaded

10 Corrupted Data Yes/No 11 New Data Yes/No 12 Clothing On/Off 13 Clothing Data loaded/unloaded 14 Weapons On/Off 15 Weapons loaded/unloaded 16 Play Mode Selected / Not Selected 17 Arm Not Extended/ Extended 18 Leg Extended/Not Extended 19 Hit Registered/Unregistered 20 Score Calculated/Uncalculated 21 Cheating flag on/off 22 Battle Stand set up/not set up 23 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.

Page 50: Hasbro: Consumer Product Design Report

12   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.

Figure 11: Portion of State Transition Matrix

Initial Set Up Battle System ON Doll Connected Battle System - Doll Communication ON

Initial Set Up "Turn on"

Battle System ON "Connect Doll"

Doll Connected "Establish Communication"

Battle System - Doll Communication ON

Page 51: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   13  

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.

Page 52: Hasbro: Consumer Product Design Report

14   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.

Page 53: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   15  

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   Originating  Requirements   Derived  Requirements  

TP.1   OR.1   DR.10,  DR.11,  DR.12,  DR.14,  DR.15,  DR.16  TP.2   OR.3   DR.3,  DR.5,  DR.17,  DR.18,  DR.19  TP.3   OR.4   DR.2,  DR.7,  DR.40  TP.4   OR.10   DR.25,  DR.29,  DR.34,  DR.35  TP.5   OR.12   DR.27  TP.6   OR.16,    OR.27,  OR.28,  OR.32   DR.58,  DR.59,  DR.60,  DR.61  TP.7   OR.39   DR.87  TP.8   OR.39   DR.72,  DR.73,  DR.88  TP.9       DR.72,  DR.73    TP.10       DR.79,  DR.74  TP.11   OR.38,  OR.37      TP.12       DR.75,DR.76,  DR.77  TP.13       DR.80  TP.14       DR.81,  DR.82,  DR.83,  DR.84,  DR.85,  DR.86  TP.15   OR.15      TP.16   OR.7      TP.17   OR.43      TP.18   OR.21   DR.44,DR.45  TP.19   OR.15   DR.37  TP.20   OR.16,  OR.17,  OR.18,  OR  19   DR.38  -­‐  DR.42  TP.21   OR.20,  OR.21,  OR.22,  OR.23,  OR.24   DR.49,  DR.50  

Figure 14: Test precedence matrix

Page 54: Hasbro: Consumer Product Design Report

16   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   Non-­‐Behavioral  Requirement   Abstract  Name   Test  

Procedure  

OR.4 Data transfer system shall be

powered at 1 watts/second 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

OR.17 The system shall accept

play mode input from user for 60 seconds

Accept Play mode TP 20

OR.4 The system provides power to all toy circuitry at 6

watts/second Provide power TP 20

OR.22 Control mechanism shall

extend leg in kicking motion in <2 sec

Extend leg TP. 18

OR.42 Information system shall

display the hit being recorded in <1ms

Show hit recorded TP 21

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

Page 55: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   17  

3.5 Verification Cross-Reference Matrix

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.

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-requirement-only purpose. Originating requirements with no associated test procedures created null columns, which were omitted here.

OR

.1

OR

.3

OR

.4

OR

.7

OR

.10

OR

.12

OR

.15

OR

.16

OR

.17

OR

.16

OR

.18

OR

.19

OR

.20

OR

.21

OR

.22

OR

.23

OR

.24

OR

.27

OR

.28

OR

.32

OR

.37

OR

.38

OR

.39

OR

.43

Satis

fies

a D

R?

TP.1 xTP.2 xTP.3 xTP.4 xTP.5 xTP.6 x x x x x x xTP.7 x xTP.8 x xTP.9 Y

TP.10 YTP.11 x xTP.12 YTP.13 YTP.14 YTP.15 xTP.16 xTP.17 xTP.18 xTP.19 xTP.20 x x x x xTP.21 x x x x x

Page 56: Hasbro: Consumer Product Design Report

18   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.

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.

Severity Description Explanation

1 None Variation within performance limits2 Very minor Variation correctible during production3 Minor Reparable within 10 min4 Very low Reparable within 30 min5 Low Reparable within 1 hour6 Moderate Reparable within 4 hours7 High Not worth repair; degraded functionality or capability 8 Very High Not worth repair; mission failure

9Hazardous - With Warning

Affects safety of operator and others but with advance warning

10Hazardous - Without Warning

Affects safety of operator and others with no advance warning

Page 57: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   19  

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:

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 system allotted approximately 30% of the available range to 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.

Criticality  Ratings       Min   Max  High   70   100  Medium   30   69  Low   1   29  

Figure 19: Criticality ratings

Page 58: Hasbro: Consumer Product Design Report

20   Katie  Ingalls  :  Hasbro  Product  Design  

Definitions                      High   The  game  cannot  be  played.  The  value  of  the  toy  may  be  lost.  Safety  has  been  compromised.  

Medium   The  game  can  be  played.  The  user  experience  may  be  diminished.  Safety  may  be  reduced.  

Low   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.

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

Failure Assessment Criticality

Failure to remain attached to surface during gameplay 80 High

Failure to keep doll attached to stand during gameplay 80 High

Failure of the stand during gameplay (material) 70 HighFailure to provide a physical connection to another battle doll stand 50 Medium

Failure to establish connection between 2 battle systems. 49 Medium

Failure to provide sufficient electricity to battle system 49 MediumFailure to establish connection between battle system and doll's body. 42 Medium

Failure to receive input from user (button failure) 36 Medium

Arm does not respond when actuator activated 36 Medium

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

Failure to communicate connection status. 35 Medium

Failure to record a proper hit 32 MediumFailure to communicate correctly with sensor system (the hit sensor subsystem) 30 Low

Failure to transfer data properly. 30 Low

Failure to move in prescribed method 30 Low

Leg does not respond when actuator activated 30 Low

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

28 Low

Arm cannot move at all 28 Low

Failure to display data to user (viewing angle) 24 Low

Failure to generate correct game statistics. (Software failure) 21 Low

Failure to generate correct game statistics 21 LowFailure to hit zone performance due to accessory interference (accessory blocks a hit zone) 21 Low

Failure to provide stable current to battle system 21 Low

Failure to move in prescribed method 20 Low

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

14 Low

Page 59: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   21  

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.

Figure 22: Portion of FMEA

Failure Effects Corrective

ActionOccurrence Likelihood

Risk Priority Number

Criticality

(a. Local b. System c. Mission)

(a. design, b. manufacturing

process, c. operation)

(under current design)

(=severity * occurrence)

(Corrective Action Priority)

(1) Using an improper play surface

(1-c) Use a proper, clean surface

(2) Suction cup becomes detached

(2-a) More suction design

(1) Doll's leg becomes loose due to excessive rotation

(1) More robust design

(2) Doll's leg becomes loose due to excessive force applied

(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

70 HighF.12 Battle Doll Stand

Failure of the stand during gameplay (material)

c. Unable to continue playing

10 7

80 High

F.11 Battle Doll Stand

Failure to keep doll attached to stand during gameplay

c. Unable to continue playing

10 8 80 High

F.10 Battle Doll Stand

Failure to remain attached to surface during gameplay

c. Unable to continue playing

10 8

Failure Mode#

Identification of Item

Failure ModePossible Cause

Failure Effects Severity

Page 60: Hasbro: Consumer Product Design Report

22   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.

Page 61: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   23  

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.

Page 62: Hasbro: Consumer Product Design Report

24   Katie  Ingalls  :  Hasbro  Product  Design  

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

A.01 Develop subsystem requirements (ODT construction) 25 hrs 30 5 0 100%

A.02 Develop Prototyping Design Plans 29 hrs 22! !2 7! !76%

Determine electronic equipment required 5 hrs 5 0 0! 100%

Determine user preferences 2 hrs 2 0 !0 100%

Method for connecting systems 4 hrs 4 0 !0 100%

Attributes in use during gameplay 1 hr 1 0 !0 100%!

Accessories and weapons database 5 hrs 2 0 3 40%

How accessories are read 2 hrs 1 0 1 50%

Power required by system 2 hrs 1 0 1 50%

Final Doll Dimensions 2 hrs 0 0 2 0%

Gameplay Algorithm 3 hrs 3 0 0 100%

Specs of hit input data 1 hr 1 1 0 100%

Determine range of motion without accessories 1 hr 1 1 0 100%

Determine range of motion with accessories 1 hr 1 0 0 100%

A.03 Build Prototypes 79 hrs 40 5 39 51%

Code the algorithms 6 hrs 6 2 0 100% Develop connections between doll and battle system 4 hrs 4 0 0 100%

Integrate gameplay algorithm with data transfer 4 hrs 4 1 0 100%

Establish connection between two battle systems 4 hrs 4 1 0 100%

Wiring of power system 4 hrs 3 0 0 100%

Wire the hit sensors 4 hrs 2 0 0 100%

Connect arm joints 2 hrs 0 0 2 0%

Connect leg joints 2 hrs 0 0 2 0%

Build arm actuators 4 hrs 0 0 4 0%

Build leg actuators 4 hrs 0 0 4 0%

Connect actuators to doll 6 hrs 0 0 6 0%

Display user interface 3 hrs 1 0 2 33%

Model form (shape / size) 3 hrs 0 0 3 0%

Model buttons 1 hr 0 0 1 0%

Build doll-battle system connection 8 hrs 0 0 8 0% Build physical connection between two battle systems 2 hrs 0 0 2 0%

Build doll-stand connection 6 hrs 5 0 1 83%

Build surface-stand connection 6 hrs 5 0 1 83%

Paint hitzones 2 hrs 2 0 0 100%

Refine range of motion 4 hrs 4 1 0 100%

A.04 Test Prototyped Systems 45 hrs 16 0 29 36%

TP.18 Test arm control mechanism 4 hrs 0 0 4 0%

TP.18 Test leg control mechanism 4 hrs 0 0 4 0%

TP.18 Test joint movements 4 hrs 0 0 4 0%

TP.21 Test hitzone geometry 8 hrs 4 0 4 50%

TP. 17 Test the stand 3 hrs 3 1 2 100%

TP.6 Test battle system interface 1 hr 0 0 1 0%

TP.12 Test battle system form 3 hrs 0 0 3 0%

TP.2 Test data transfer between two systems 5 hrs 5 0 0 100%

TP.3 Test power systems 4 hrs 4 0 0 100%

Ac

tivity

#

Prototyping Activity Table

Dur

atio

n

Wo

rk

Co

mp

lete

d

Ad

diti

ona

l W

ork

Perc

ent

C

om

ple

te

Wo

rk

Rem

ain

ing

Page 63: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   25  

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.

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.

(row) task supplies to (column) task

Develop subsystem requirements (ODT construction)

Develop Prototyping Design Plans

Build Prototypes

Test prototyped systems

Test joint movements

Test hitzone geometry Test the stand

Test battle system interface

Test battle system form

Test data transfer between two systems

Test power systems

A.01 A.02 A.03 A.04 TP.18 TP.21 TP. 17 TP.6 TP.12 TP.2 TP.3

Develop subsystem requirements (ODT construction)

A.01 xSubsystem Requirements and Interface Specifications

Subsystem Requirements and Interface Specifications

Subsystem Requirements and Interface Specifications

Develop Prototyping Design Plans A.02 x

Design Specifications and Drawings

Build Prototypes A.03 x Completed prototypes

Test prototyped systems A.04 x

Test joint movements TP.18 x Hits using actual doll

Test hitzone geometry TP.21 x

Test the stand TP. 17 x

Test battle system interface TP.6 x Working user

interface

Test battle system form TP.12 x

Test data transfer between two systems TP.2 x

Test power systems TP.3 Power available x

Page 64: Hasbro: Consumer Product Design Report

26   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.

Page 65: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   27  

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.

Page 66: Hasbro: Consumer Product Design Report

28   Katie  Ingalls  :  Hasbro  Product  Design  

5.4 Subsystem Decision Matrix

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.

Figure 27: Power subsystem weighting analysis

!"#$%&

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

'(/$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

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

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 A B C D C E F D

Page 67: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   29  

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.

Figure 28: Power subsystem decision matrix

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

*+%%,-".&//

01*"23$'4(-4

Min S

core

Min S

core

Weight

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

*+%%,-"2&//

01*"23$'4(-4

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

-./&01.#234"2/ ( ' * * ( 5 ', *6 5

-.7$8.4/$01793:"2/ ( + * * ( + *, ) +

;&79/<3"834"0= ' ' ' ' ' ' > > >

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

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

' ' ' ' ' ) *+ *+ *+

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

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

' ' ' ' ' ' > > >

HI- >) 65 5J

Normalized Score

User

DependenciesFinal Score

Page 68: Hasbro: Consumer Product Design Report

30   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.

Page 69: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   31  

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.

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.

Doll's Form SystemBattle Device Form SystemAccessories Form System

POWER SYSTEM POWER SYSTEM Power System

FAIRNESS SYSTEM Fairness Assurance System

Accessory Scanning SystemSkill Level Acquisition SystemGameplay AlgorithmData Transfer Hardware SystemScoring Input SystemInformation Display SystemScoring Control Mechanism SystemPlay Modes

FORM FACTOR SYSTEM PHYSCIAL FORM

SCORING SYSTEM

DATA ACQUISITION SYSTEM

DATA TRANSFORMATION SYSTEM

USER INTERFACE SYSTEM

Page 70: Hasbro: Consumer Product Design Report

32   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.

Page 71: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   33  

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.

Page 72: Hasbro: Consumer Product Design Report

34   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.

Page 73: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   35  

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.

Page 74: Hasbro: Consumer Product Design Report

36   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

Page 75: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   37  

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.

Page 76: Hasbro: Consumer Product Design Report

38   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

Page 77: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   39  

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.

Page 78: Hasbro: Consumer Product Design Report

40   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 pre-determined 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

Page 79: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   41  

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).

Page 80: Hasbro: Consumer Product Design Report

42   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 Movement Artist Doll (In Degrees)

Elbow Flexion 140 Hyperextension 0

Forearm Pronation 80 Supination 80

Wrist Extension (Dorsiflexion) 60 Flexion (Palmar flexion) 60 Radial Deviation 20 Ulnar Deviation 30

Shoulder Flexion 180 Hyperextension 50 Abduction 180 Adduction 50

Shoulder Internal Rotation 90 Hip Flexion 100

Hyperextension 30 Abduction 40

Extended Hip Internal Rotation 40 External Rotation 50

Knee Flexion 150 Ankle Plantar flexion 20

Dorsiflexion 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.

Page 81: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   43  

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.

Page 82: Hasbro: Consumer Product Design Report

44   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.

B A

Page 83: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   45  

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.

Page 84: Hasbro: Consumer Product Design Report

46   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.

Page 85: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   47  

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.

Page 86: Hasbro: Consumer Product Design Report

48   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

Page 87: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   49  

Figure 46: Sensor System

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

Page 88: Hasbro: Consumer Product Design Report

50   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 Name

Cost of Tag/Transmitter

Cost of Receiver

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

Comments

RFID $0.5 $10 5 Too expensive

Magnetic Stripe

$1 $10 1 Too expensive

Bar code scanner

~$0 $5 1 Scanner is Too big

IR $8 $8 3 Too big to implement into accessories

User enter ~$0 ~$0 0 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.

Page 89: Hasbro: Consumer Product Design Report

Katie  Ingalls  :  Hasbro  Product  Design   51  

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]