hasbro: consumer product design report
DESCRIPTION
Design report for semester-long project utilizing systems engineering and product design methodologies to develop a consumer product for Hasbro, Inc.TRANSCRIPT
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
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
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.
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.
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.
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
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
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.
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
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
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!
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.
Kat Ingalls 13
Figure 6: Context Diagram – Stakeholders. The entity TOY at the center of
the diagram is detailed further in the next figure.
14 Hasbro Product Design Team
Figure 7: System-level context diagram depicting basic functionality of Battle Doll system.
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
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()3'--)4)5%&&-#)/01 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?
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()3'--)4)5%&&-#)/01%&'()*+,-./,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),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
18 Hasbro Product Design Team
!"
!"#$%&'$()*+,-. /01()3'--)4)5%&&-#)/01#$%&'()%*+(',&&-+(&%*.(/%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()3'--)4)5%&&-#)/01%&'()*+!+,-.)/+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()3'--)4)5%&&-#)/01$%&'()*+,-.)/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
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.
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
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
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+
/'@
A8&+91''6&+7B7'&#+
78166+9&+196&+'"+
.&="0%/;&+1''./94'&7+
":+=6"'8/%0+1==&77".B+
/'@
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+
/'@
A8&+91''6&+7B7'&#+
78166+9&+196&+'"+
.&="0%/;&+1''./94'&7+
":+>&1$"%+1==&77".B+
/'@
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`&+/%'"+#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`BNN 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'@
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
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".:+
/'	=
>"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'	=
>"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*#$
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<
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
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)
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
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
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
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.
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
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$:
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/-
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
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>
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.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"
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.
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
X'U"",H#&@",:"%) Q Q
I I
Y8Z8,:"%)M$C86'(<2'(,J$(,$3%&'(,4&682"
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#&@",:"
%)
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
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
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.
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.
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.
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
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
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
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
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 !
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.
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
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.
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.
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
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
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
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
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
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
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
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.
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.
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
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
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.
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.
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
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
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.
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
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.
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.
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.
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.
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
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.
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
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.
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
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).
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.
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.
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
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.
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.
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.
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
Katie Ingalls : Hasbro Product Design 49
Figure 46: Sensor System
Figure 47: Mega 644 microcontroller on STK-500 development board
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.
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]