CESYS501: Getting Started on Product and Service …...To complete the course project, you choose one of two case studies- Internet-based Meal Delivery System or HomeAlone Health Monitoring

Copyright © 2012 eCornell. All rights reserved. All other copyrights, trademarks, trade names, and logos are the sole property of their respective owners. 1

CESYS501: Getting Started on Product and Service Design


This course includes

Multiple discussions; you must participate in two

One tool to download and use on the job

One scored project in multiple parts

One video transcript file

Completing all of the coursework should take about five to seven hours.

What You'll Learn

The benefits of the Getting Design Right process

When and how your organization can use this process

How to use this process and the associated work products to define a design problem in the context of your organization

Course Description

This course is the first in a six-course series devoted to the Cornell Systems Engineering Program's Eight Steps to Getting

Design Right. Here we examine the first step in this process: define the problem. This initial step involves identifying the

product concept; establishing the mission, boundary, and context of the product or service; and identifying functional

requirements for the product or service.

This course should give you the confidence to initiate design projects and to enrich design concepts with important details

critical to the design process. For those of you who are managers or interested in becoming managers, the course makes

clear the kinds of work products you can expect at the earliest stages of design. It also provides the tools and explanation

needed to develop those products.

This course is grounded in systems thinking and requires both detail and abstraction: it teaches you to consider details

carefully and to abstract from those details to create design requirements. It provides widely applicable exercises that you

can use to develop your teams' system-thinking skills. In addition, it is unique in its behavioral emphasis, focusing on end

https://s3.amazonaws.com/ecornell/content/CESYS/CESYS501/CESYS501-video-transcripts.pdf


users and on what the system will do for them. This is a customer-focused design process.

Click Play to Listen

Peter Jackson Professor, School of Operations Research and Industrial Engineering, CornellUniversity

is a Professor in the School of Operations Research and IndustrialPeter Jackson

Engineering. Born in Nipigon, Ontario, Canada, he received a B.A. in Economics with

Mathematics in 1975 (University of Western Ontario), a M.Sc. in Statistics in 1978

(Stanford University), and a Ph.D. in Operations Research in 1980 (Stanford University).

He has served at Cornell since 1980. He is Director of Graduate Studies for, and a former

Director of, the Systems Engineering Program within the College of Engineering.

Start Your Course


Module Introduction: Developing the Concept and Defining the Context

This course about initiating the design process looks at defining the design problem, step one in the eight-step process of

getting design right. According to the process, defining the design problem consists of three substeps: developing the

concept, defining the context, and defining the functional requirements. This module explores two of these substeps. It

also provides both an informative overview of the entire Getting Design Right process and an introduction to the methods,

approaches, and assignments used throughout the series. In this course, take the first critical steps toward developing a

design project of your own using the Getting Design Right process.

This module outlines the Eight Steps to Getting Design Right, the Cornell Systems Engineering Program's systems

approach to customer-oriented design. In addition, the module both introduces the methods and approaches used in this

series and familiarizes you with the assignments in this course, which it presents in the form of a comprehensive course

project. Explore this module to acquire the basic knowledge you'll need to succeed in this course.

After completing this module, you will be able to:

Describe the Getting Design Right process and its benefits

Describe the two design case studies

Explain what a systems approach is

Create a product sketch

List some considerations important to selecting a design project

Identify system stakeholders

Compose a mission statement for a project

Read a context diagram

Complete a context matrix


Watch: The Process of Getting Design Right

An illustrated presentation with audio appears below. This resource provides an overview of the Getting Design Right

process.


Read: Methods and Approaches for This Series

Key Points

A systems approach is a procedural focus on relationships

In the , diving refers to the development of a detailed view of a system, and surfacing refers todive-and-surface technique

abstraction from this detailed view to a more general or systems view

A table is one standard tool for representing relationships, and tables are used throughout this course and this series for

that purpose

Let's take a look at the approaches and methods you will use in this series devoted to the Eight Steps to Getting Design

Right.

A Systems Approach

Why is the eight-step approach called a ? A system is simply a collection of objects in relation to eachsystems approach

other. A systems approach is, therefore, a procedural focus on relationships. Your awareness of and familiarity with

relevant relationships are critical to getting design right, and a systems approach includes formal techniques for the

discovery and consideration of these relationships. This systems approach requires that you look at all aspects of the

product or service-including production and disposal, if relevant-in the context of its use within the larger system that

contains it or forms its environment.

In addition to calling attention to relationships, a systems approach is also beneficial because it employs the language of

systems. The language of systems is applicable in all design contexts. Every discipline has evolved a language to

describe the artifacts and methods within its design domain-and so electrical engineers speak of circuits, mechanical

engineers discuss forces, software engineers describe algorithms, and artists discuss medium and technique. The

language of systems attempts to cut across disciplines and to establish a more generic vocabulary and grammar with

which to discuss design. This course recommends using abstractions such as entities, relationships, goals, functions,

behavior, interfaces, and requirements to describe systems, and helps you become comfortable employing these

abstractions to organize the accustomed concepts of different domains. The language of systems constitutes a universal

language of design.

The Dive-and-Surface Technique

One of the techniques that is central to the approach this course takes is the . Diving refers todive-and-surface technique

the development of a detailed view of a system, and surfacing refers to abstraction from this detailed view to a more

general or systems view. This ability to see both the forest and the trees distinguishes a systems thinker from an individual

who is trapped in discipline-specific details. Nearly every course in this series employs the dive-and-surface technique.

A Tabular Approach

Recall that a system is a set of objects in relation to each other. A table is one standard tool for representing relationships,

and tables are used throughout this course and this series for that purpose. Let's look at how tables communicate

relationships.


Tables consist of rows and columns. Every cell of a table is the intersection of a row and a column. We use the

row-and-column nature of tables to form sentences relating the heading of a row to the heading of a column by means of

the content of the cell at the row-column intersection. For example, the following table presents a simple description of a

solar system, showing the relation of moons to planets and planets to the sun. It indicates that "moons orbit planets" and

"planets orbit the sun." It also captures relative sizes: the "sun is larger than any planet" and "planets are larger than their

moons."

SUN PLANETS MOONS

SUN IS LARGER THAN

PLANETS ORBITARE LARGER

THAN THEIR

MOONS ORBIT

This table provides relationships between elements of the solar system.

For the most part, the design approach described in this course uses simple tools that are widely available. A spreadsheet

program like Microsoft Excel is one of the fundamental tools you need. Excel, or some tool like it, makes it easy to create

and manipulate tables, matrices, and textual lists. Because Microsoft Excel is a tool that most people are familiar with,

Excel tables are featured in a number of examples in this course.

A Diagrammatic Approach

In addition to tables, there are excellent graphical techniques available to describe systems. For example, this diagram

conveys the same information that the previous table did, but this time in graphical form. In the diagram, objects are drawn

as nodes, and relationships are drawn as lines connecting the nodes. Lines are labeled with verbs or verb phrases, and,

to eliminate ambiguity, these phrases are positioned nearest the node that forms the subject of the sentence a line and its

nodes articulate. Thus, the verb "orbit" is placed nearest the node "planets" on the line connecting "planets" with "sun" to

suggest the relationship, "planets orbit the sun."

This diagram provides the relationships between elements of the solar system in graphical form. Such a diagram is called

an because it displays both entities (objects) and the relationships between them.entity-relationship diagram


Graphical representations have great visual power. Many individuals prefer them to tables. However, we have chosen to

use the tabular approach in these courses because diagrams and other graphical representations tend to require more

time to create and to make attractive.

Graphical techniques are used extensively in advanced systems design, but there can be a bewildering array of graphical

styles to master (node shapes and meanings, line styles and meanings, and so on). We recommend that you master the

tabular technique first.


Read: About the Course Assignments

This course includes a course project: a series of assignments designed to give you practical experience applying the

tools and skills the course provides. Completion of the project is a requirement for the course. It is also an excellent way to

build a detailed set of notes about how to initiate the design process. Your initial work on the course project involves

sketching your design idea and identifying stakeholders relevant to your design project. In addition, you use a tool

presented in the course to define the system-design context. Later, the course project invites you to analyze use cases

regarding how the product or service will be used and derive requirements from them. As a final step, you summarize the

requirements.

To complete the course project, you choose one of two case studies- or Internet-based Meal Delivery System HomeAlone

-and develop it through each part of the process. Whichever case you choose,Health Monitoring and Trauma Alert System

you have the option of continuing your work on it as you progress through the six courses in this series. Your completed

project should serve as a step-by-step guide to defining the design problem and as a reference for specific approaches

relevant to the initial steps of the Getting Design Right process.

How do you get started? If you follow the recommended learning path, you encounter the course project for the first time

in the project entitled Make Your Own Sketch. There you can download the first section of the project, a set of two

questions. You will work on the course project throughout the course. When you have completed the project, you will

submit all your work for evaluation and feedback.

https://d31owemgwclw9w.cloudfront.net/content/CESYS/CESYS501/CESYS_CaseStudy_NetMealsTonight.pdf

https://d31owemgwclw9w.cloudfront.net/content/CESYS/CESYS501/CESYS_CaseStudy_HomeAlone.pdf

https://d31owemgwclw9w.cloudfront.net/content/CESYS/CESYS501/CESYS_CaseStudy_HomeAlone.pdf


Read: Select the Project and Sketch the Concept

Initiating a design project begins with defining what the design problem itself is. The designer must answer questions like,

how do I define this project? what is the exact context for this project? and, what are the functional requirements for my

design? According to the Getting Design Right process, defining the project takes four steps: selecting the project;

sketching the concept; identifying the owner, the customer, and the user; and writing a mission statement.

As a designer or would-be designer, you can use the Getting Design Right process to get started on a design project. It

looks at selecting the project and sketching the concept-the first steps in initiating your project.


Read: Selecting a Project

Key Points

Two common approaches to beginning a design project are the and the approachtop-down bottom-up

Eight Steps to Getting Design Right is the right process for all design projects

Selecting an appropriate project is the first step in the process of defining a design project. How does project selection

take place?

A design project starts with an idea. The idea may have to do with identifying, conceptualizing, or solving a problem in a

particular way. Sometimes the idea comes from taking a new technology (wireless communications, for example) and

applying it in a novel way. No matter where the idea comes from, our focus is on the design project: how you take that

idea and turn it into a real product or service.

Sometimes a design project begins with a problem.

For example, one sweltering afternoon in Dallas,

Texas, a father found that he was unable to give his

thirsty infant a drink, even though he possessed a

cold bottle of water. That prompted him to come up

with an idea for a water-bottle nipple adapter to

attach a baby-bottle nipple to a commercially

produced bottle of water. It wasn't long before the

father, a Mr. Habeeb, improvised a coupling and

made it work

(Rosenbloom, 2007).

Two common approaches to beginning a design project are the and the approach. The Gettingtop-down bottom-up

Design Right process is valuable in both instances. If you start with a problem, that's called taking a top-down approach to

design. Here, the Getting Design Right process helps the designer generate and explore ideas for a solution. On the other

hand, if you start with a solution, that's called taking a bottom-up approach to design. When a bottom-up approach is

taken, the Getting Design Right process requires the designer to clarify the problem and to consider other solutions.


1.

2.

3.

4.

Eight Steps to Getting Design Right is the right process for all design projects, whether top-down, bottom-up, or something

else. This process facilitates the generation and exploration of ideas needed in a top-down approach by facilitating the

development of a clear and complete understanding of the problem; and it facilitates the consideration of multiple solutions

required in a bottom-up approach. For those projects based on concepts for new products or services, Eight Steps to

Getting Design Right requires the designer to think through what gives the design ideas behind them their appeal.

When the time comes for you to commit yourself to a design project, certain practical considerations can limit your range

of choices. The following are some useful guidelines to adhere to as you decide:

Select a design idea that excites you. You will expend considerable effort in design, so it's important to start with

something that genuinely motivates you.

Select a project that's within your domain of expertise

Select a project that you have the time and resources to bring to fruition

Set a modest goal

Note that, in this course, you stop short of detailed design, and that, for this reason, you are not constrained by the fiscal

and physical pressures of engineering noted in item 3. However important the responsible management of time and

resources is to real-life design projects, in this course, you can afford to be a little imprudent.

The Toy Catapult

While the Eight Step Process is robust enough to handle something as complex as the design of a spacecraft, for the

purposes of introduction, let's take a look at something simpler: the design of a toy catapult, a toy that launches projectiles

short distances and is suitable for use by small children. In addition to being modest, simple, and fun, the toy catapult is

familiar. With the toy catapult as an ongoing example, this course charts design development step-by-step using the Eight

Step Process.

Let's move on to step two in defining the design project.


Read: Sketching a Concept

Key Points

Sketching your concept is the second step in defining the design project

Design engages both hemispheres of the brain: the left brain, with its power for verbalization and logical reasoning, but

also the right brain, with its power for visualization and intuitive reasoning

Once you have selected a project, sketch it. Sketching your concept is the second step in defining the design project.

Whether your artistic ability is good or poor, and even if you do nothing more than select an image or images from an

electronic database and somehow make it your own, it is good design practice to produce some kind of a sketch.

Design engages both hemispheres of the brain: the left brain, with its power for verbalization and logical reasoning, but

also the right brain, with its power for visualization and intuitive reasoning (Edwards, 1999). Though the Getting Design

Right process emphasizes a logical, methodical, left-brained, process-oriented approach, it hinges on the participation of

the right brain, too, to supply new ideas at every stage. Take time and really develop your sketch. When you do, you may

discover a greater excitement about your idea-even if your sketches are crudely drawn.

The Sketch of the Toy Catapult

Let's look at an initial sketch of a toy catapult. This simple sketch of a spring-loaded catapult actually conveys quite a bit of

information regarding the designer's vision of how the toy will look and function.

First, the sketch depicts the catapult in a particular context. An adult and a child are engaged in a mutual activity taking

place on the floor. The activity involves building blocks in addition to the catapult, and the building blocks appear both

strewn about and assembled into a structure. The artist has positioned the catapult in a way that suggests the interaction it

is intended to have with the block structure.

Second, the sketch suggests several different user functions. One function is to construct something, perhaps out of

blocks, whereas another is to use the catapult to knock structures down.

Finally, the sketch indicates that the catapult is freely mobile (it is not pictured on a track, in a bed, or as constrained in

any way). As catapult operators know, the challenge is to position the catapult so that firing it achieves the desired result:

the collapse of the target.

Note that the sketch communicates a potential safety issue: it is possible that a user could end up in the catapult's line of

fire. This sketch has made it possible, then, to envision safety concerns very early in the design process. The designer


can consider this safety issue and others like it more formally as the design process proceeds.

It is also possible to add specific observations to a sketch like this, creating an annotated sketch. Please click the sketch

of the toy catapult below to see the same sketch with annotations.


1.

2.

3.

1.

2.

Activity: Find a Sketch

This activity has two parts. First, perform a two-part Google image search. Then, proceed to the discussion board to share

your findings with other learners.

Use to locate interesting product concept . Find at least one that meets the following criteria:Google Image Search sketches

It must be visually stimulating

It must be annotated

It must be information rich (even if it has little or no text)

Remember your primary interest is communication, not artistic quality.

Save the link to the image.

Use to find interesting product concept . As you will immediately see, they come in manyGoogle Image Search diagrams

varieties. Find at least one that

Does a good job of conveying its product concept

AND

Does a poor job of conveying its product concept

Save the links to the images.

Now, proceed to the discussion board to discuss what you found with your fellow learners.

http://images.google.com/imghp?hl=en&tab=wi

http://images.google.com/imghp?hl=en&tab=wi


Read: The Boeing 777

In order to launch on-time a truly great airplane, we have

the responsibility to work together to design, produce, and

introduce an airplane that exceeds the expectations of

flight crews, cabin crews, and maintenance and support

teams and ultimately our passengers and shippers.

From day one:

Best dispatch reliability in history

Greatest customer appeal in the industry

User-friendly and everything works

Just after Boeing won the launch order from United Airlines to build the Boeing 777, executives Dick Albrecht and Phil

Condit signed the note on the right to express the aspirations of the Boeing team.1

Observe that this mission statement identifies the users that Albrecht and Condit want to delight with this new aircraft:

flight crews, cabin crews, maintenance teams, support teams, passengers, and shippers. It also identifies the particular

areas in which they were determined to excel: dispatch reliability, customer appeal, user-friendliness, and functionality.

What else do Albrecht and Condit explicitly or implicitly state here? How might a mission statement for a toy catapult differ

from this one for the Boeing 777? Explore the next course pages to look in greater depth at stakeholders and mission

statements in the context of defining the design problem.

The Boeing Company1


Read: Identifying Stakeholders

Key Points

By developing a clear idea of the individuals involved and their points of view, you put yourself in a better position to

identify fully the functional requirements for the product or service

You should distinguish three different stakeholder roles at this stage: the owner, the customer, and the user

Early in the design process, identify those individuals you wish to please with your design. By developing a clear idea of

the individuals involved and their points of view, you put yourself in a better position to identify fully the functional

requirements for the product or service you design.

The complete list of stakeholders for your design project may be very long, but your list of primary stakeholders probably

consists of just a few main types. You should distinguish three different stakeholder roles at this stage: the owner, the

customer, and the user. Let's define each one.

The of the system is the individual who sets design goals and authorizes major design decisions. The isowner customer

the individual who approves the purchase of the system and transfers it into use. The is the individual who actuallyuser

uses the system for a purpose the customer intended. The same individual could play all of these roles or multiple

individuals or even groups could each elect to assume a different role. Some roles could involve whole agencies!

The three roles described above represent distinct and distinctly useful perspectives on the product or service being

designed. For example, consider the user. This role is central to design, so it is easy to imagine how usability

requirements would derive from the user's viewpoint. The role of customer is important too, in that the customer appraises

the system from a value standpoint. She may ask questions like, does the aesthetic value of the system justify its cost? or,

what is the functional value of the system? This viewpoint gives rise to economic requirements. Finally, the owner may

have both economic and strategic goals in mind and may impose special constraints on how the product can be built. This

viewpoint can result in design and production constraints.

Stakeholders and the Toy Catapult


Let's consider the primary stakeholders of the toy catapult. The primary user is the child. However, the design sketch

assumed that a child and an adult or an older child would play with the toy together, so the list of users can include these

individuals, too.

Who is the customer of the toy catapult? Recall that the customer is the individual who "approves the purchase of the

system and transfers it into use." Perhaps the individual who approved the purchase of the catapult is a family friend who

bought it as a gift. Here, the friend is the customer. However, the child's parents are most likely to be the individuals who

"transfer [the system] into use." So they are primary customers, too-they decide whether the catapult is a safe and

appropriate entertainment for their child.

As you can see, it's possible to identify two or more individuals as customers in this example, and those individuals are

related to the child in significantly different ways. In addition, the child's parents may be construed as playing at least two

roles: the customer and the user. Although it's possible to identify multiple roles for certain individuals and multiple

individuals for certain roles, let's simplify our approach to this example by specifying that the parents are the customers

and the child is the user.

Finally, who plays the role of the owner? The owner is the individual who defines the project. The catapult designer will

make nearly all of the design decisions, including the imposition of design constraints.


Read: Additional Stakeholders

Owner, customer, and user are the three primary roles you need to consider when defining the design project. However,

other important roles and viewpoints exist as well. For instance, in the context of a construction project, the role of owner

may consist of important subroles like , , and . The is the individual who expresses theclient architect builder client

high-level goals of the system and ultimately evaluates the success of the system. The translates the client'sarchitect

desires into specifications for the builder to execute. The constructs the system according to the architect'sbuilder

specifications. Whereas the goals of the client may be vague and imprecise, the architect's specifications are usually

unambiguous. And although the builder may make low-level design choices, for the most part what the builder can choose

is constrained by the architect's specifications.

Let's continue to look for other important viewpoints. In addition to users, there are , individuals who areunintended users

affected by the system in ways that fall outside of the intended function of the system. For example, if a highway is

constructed near your home and you hear the noise of its traffic, you are an unintended user of the highway: you are

affected by the system whether you drive on it or not. Likewise, when you consider the full life cycle of a product or

service, including its eventual disposal, you can identify many unintended users. Think of residents living near a landfill.

Everything in that landfill was once, or was once part of, a working, active, or useful product that has since been

abandoned by its customer or user. Neighbors of the landfill have become the unintended users of every object in it.

It is good practice to try to identify as many stakeholders in these additional roles as possible. This will give you the ability

to look at your system more clearly and thoroughly, from a greater number of perspectives. Keep in mind that every new

role you identify gives you a new outlook and may suggest new design requirements. The three primary roles considered

in this course-owner, customer, and user-constitute a minimal set of perspectives.


Watch: A Stakeholder Case Study

An illustrated presentation with audio appears below. Use this resource to enhance your understanding of the role

stakeholders can play in initiating design.


Read: The Role of the Mission Statement

The for a design project is a concise formulation of the purpose or goals of the system, written from themission statement

perspective of the owner or client. In the case of systems design, the mission statement is typically written by the designer

or architect in an attempt to capture the aspirations of the owner or client. The mission statement is considered a critical

document in the design-management process. Let's look at why.

In systems design, larger systems are resolved into smaller systems, and those smaller systems are resolved into still

smaller ones, until what results are subsystems that can be designed and produced effectively. Whether there are as

many designers as there are subsystems, or a single mind behind them all, it is always the responsibility of the system

designer to ensure that the entire design process stays true to the original vision as it was communicated at the outset by

the owner of the system. For this reason, it is important for designers to thoroughly understand what owners want their

completed systems to accomplish, so that they can communicate those goals to everyone else in the design hierarchy. It

is also useful if designers can articulate the individual mission of each subsystem they control so that every secondary and

tertiary designer can be conscious of how his subsystem functions to realize a specific aspect of the owner's original

goals. The mission statement or collection of mission statements is the foundation of the designer's capacity to

communicate the vision and goals of the project to others on the project team.

A Mission Statement for a Toy Catapult

What mission statement might be appropriate for the toy-catapult design project? Here's one:

The mission of this project is to design a toy catapult suitable for use by a child three to ten years of age. Younger children

will delight in using the toy in a shared activity with an older person-a parent, an older sibling, a grandparent, or some

other friend or caregiver. Older children will not require adult supervision to entertain themselves or others with the toy.

The toy must be safe and straightforward to use, meeting the requirements of parents and other caregivers. It must entice

users with its visual appeal. It must also be engaging enough to absorb its users for extended periods of play.

Note that this mission statement commits the design team to the design of a particular type of product, a toy catapult, and

that it identifies stakeholders and users.


Read: Your Stakeholders and Your Mission

Continue your exploration of what it means to initiate a design project, and complete the activities involved in the process

of defining the project. Recall that, according to the Getting Design Right process, defining the project takes four steps:

selecting the project; sketching the concept; identifying the owner, the customer, and the user; and writing a mission

statement.

The following pages will explain how to identify the owner, customer, and user and how to write a mission statement.

These are important substeps in the process of defining the design problem, step one in the Getting Design Right process.


Read: Boundary and Context

To accomplish step one of the Getting Design Right process, the designer must define the design problem by answering

questions like, how do I define this project? what is the exact context for this project? and, what are the functional

requirements for my design?

Continue your exploration of what it means to initiate a design project: examine how to define the design context. Learn to

define the boundary of the system and to document the context of the system using matrices and diagrams.


Watch: The System Boundary

An illustrated presentation with audio appears below. Use this resource to develop your understanding of the meaning and

significance of the system boundary.


Read: Context Diagrams

Key Points

A is a graphical description of the context of a systemcontext diagram

There are two elements: and , where nodes are represented as rectangles, and arcs are drawn as linesnodes arcs

connecting the nodes to each other

Once you have identified the concept system by identifying those entities that are internal and external to it, you must

articulate the relationship the system has with each external entity. This is how you begin to define the project's context.

One tool you can use to do this is a , which is a graphical description of the context of a system. You cancontext diagram

use the context diagram to explain why each external entity is relevant to the system. You can also use it to record any

relationships you feel you should explore in more detail later.

Let's examine the format of a context diagram. There are two elements: and , where nodes are represented asnodes arcs

rectangles, and arcs are drawn as lines connecting the nodes to each other. One node in the diagram represents the

system itself; the others represent the system's external entities. The connecting arcs between nodes represent the

relationships between the system and its external entities. So the context diagram is, in the most basic sense, a network

of rectangular nodes and rectilinear (right-angled) arcs.

When you create a context diagram, you must label the nodes (rectangles) to indicate which entity they represent. In

addition, you must label the arcs between these nodes to indicate the relationship the nodes have to each other. The arcs

are labeled with verb phrases, while the nodes are labeled with nouns. Each node-arc-node combination forms a simple

sentence that expresses the relationship the two nodes have to each other.

A Context Diagram for a Toy Catapult

To see how this works, let's take a look at a context diagram for our ongoing example, the toy catapult. The context

diagram in the figure below contains one node representing the catapult (the system itself) and nodes for each of the

entities external to the system: the child, the parent, the storage unit, and the projectile. The arcs represent the

relationships between these entities. The dashed line indicates the system boundary: the toy is the only internal entity; all

other entities are external.

Note that the rectilinear arcs do not have arrowheads. Instead, the directionality of the arc is given by the placement of the

verb phrase that labels it. Each verb phrase is located closest to the node intended to be the subject of the relationship the


1.

2.

3.

arc expresses. For example, the verb phrase "is stored in," located on the arc between "toy" and "toy storage," is

positioned closer to "toy." Placed in this way, the label forms the sentence, "toy is stored in toy storage." If instead the verb

phrase were located closer to "toy storage," the relationship would read, "toy storage is stored in toy," which of course

wouldn't make any sense.

Also, note that the same arc can be used for two different relationships. This is the case for the arc between "toy" and

"child." It tells us that "toy attracts child" and also that "child retrieves from storage and plays with toy."

Context diagram for the toy catapult

The complete set of relationships communicated by the context diagram can be summarized as follows:

The parent teaches and entertains the child.

The parent stores the toy.

The toy is stored in toy storage.

The toy attracts the child.

The child retrieves the toy from storage and plays with it.

The child loads a projectile into the toy.

The toy throws the projectile.

Some Additional Notes on Context Diagrams

It is possible to form symmetrical statements regarding the relationships between entities, but redundancies

should not be expressed in the context diagram. For example, you could say, "toy storage stores toy," and you

could also say, "toy is stored in toy storage." These are symmetrical statements. Only one of these should be

recorded in the context diagram, because each implies the other.

A context diagram may include arcs between external entities, but it never has to. External entities are, by

definition, outside the design scope, and they are useful only to provide supporting information.

The context diagram is important to activities later in the design process. Eventually, you will specify an interface

for each of the relationships you identify in the context diagram.


Read: Context Matrices

Key Points

A context matrix is a table that succinctly outlines the relationships between the entities in a system

Use the row entities as subjects and the column entities as objects to make statements about the relationships between

the entities

A context matrix is easier to create than a context diagram but may not communicate its relationships as effectively

Once you have identified the system and the entities that are internal and external to it, it's important to capture the

relationships between those entities in a user-friendly format. One tool you can use to do this is a context diagram. A

second tool you can use to do the same thing is the .context matrix

A context matrix is a table that succinctly outlines the relationships between the entities in a system. The matrix is

constructed by listing the system entities along both the horizontal and vertical axes of the table, in the same order. You

can list them in one of two ways:

List all external entities and all internal entities individually

List all external entities individually but represent all internal entities collectively under a single blanket term, such

as "system"

Note: If you list the internal entities individually, do not intermix them with the external entities. List them together. This will

enable you to construct a system boundary in the matrix.

Complete the matrix by specifying the relationships between each pair of entities at their point of intersection. Use the row

entities as subjects and the column entities as objects to make statements about the relationships between the entities-for

example, "row 9 is related to column 2." Use a heavy border to indicate the system boundary. This boundary plays the

same role that the dotted line in the context diagram did.

Note that, for the context matrix to be a valuable tool, it's important to make the text contained in it fully visible. This may

require special formatting commands depending on the tool you use.

A context matrix is easier to create than a context diagram but may not communicate its relationships as effectively,

especially to those who are visually oriented. On the other hand, it can be more time-consuming to create a context

diagram than it is to create a context matrix, so ease of creation is a valid concern. When deciding on tools, you should

use the one that feels most natural to you. Both the context matrix and the context diagram are useful for determining and

communicating the relationships between systems and external entities.

A Context Matrix for a Toy Catapult


Below is a context matrix for the toy-catapult example. The system is represented by "toy." The external entities are

parent, child, projectile, and toy storage. The system and each of its external entities are represented vertically in column

one and horizontally in row one. These entities appear in the same order in each list. The system boundary is shown

around the cell at the center of the matrix (row 4 column 4).

The matrix is populated with information specifying the relationships between entities. In each case, we can read these

relationships using the rule that the entities listed vertically are the subjects and those listed horizontally are the objects.

For example, the relationship between "parent" in row 2 (R2) and "child" in column 3 (C3) is read as "parent teaches and

entertains child" (R2C3).

Observe that there are no relationships entered along the table diagonal: R2C2, R3C3, R4C4, and so on. These cells

represent the relationships of entities to themselves and in general will not contain meaningful information. In addition, it is

worthwhile to note that, in this specific example, there are no relationships for which the projectile or toy-storage unit are

the subjects (these rows are blank).

Parent Child Toy Projectile Toy Storage

Parentteaches and

entertainsstores

Childretrieves from

storageloads into toy

Toy attracts throws is stored in

Projectile

Toy Storage

Context matrix for the toy catapult

The context matrix for the toy catapult, though quite different in appearance from its context diagram, contains exactly the

same information about the catapult and its external entities.


Module Introduction: Defining the Functional Requirements

Defining the design problem is step one in the eight-step process of Getting Design Right, and it consists of three

substeps: developing the concept, defining the context, and defining the functional requirements. This module explores

the third of these substeps: defining the functional requirements. Here you work with use cases and use-case behaviors,

gradually and systematically developing functional requirements according to your system's desired behavior. As you

learn these skills, you apply them in the context of the course project, using the case study you worked on in Module 1.

After completing this module, you will be able to

Define use case

Prioritize use cases for the purpose of defining functional requirements

Explain how use-case-behavior descriptions are used in the process of defining functional relationships

Use the use-case behaviors template to describe use-case behaviors

Summarize functional requirements from use-case behaviors

Finalize functional requirements


Read: Collect and Prioritize Use Cases

Begin the study of the process of defining functional requirements for your design project in the following pages. There are

five steps to this process. This section examines the first two-collect use cases and prioritize use cases-in the context of

both primary and secondary use cases. From these use cases you develop use-case behaviors and, finally, the functional

requirements themselves. This approach is your first exposure to the strong behavioral focus of the Getting Design Right

process.


Read: Using the Patriot Missile Defense System

On February 25, 1991, a Patriot missile-defense system operating at Dhahran, Saudi Arabia, during

Operation Desert Storm failed to track and intercept an incoming Scud [missile]. This Scud subsequently hit

an Army barracks, killing 28 Americans.

The Patriot is an Army surface-to-air, mobile, air-defense missile system. Since the mid-1960s, the system

has evolved to defend against aircraft and cruise missiles, and more recently against short-range ballistic

missiles. The Patriot system was originally designed to operate in Europe against Soviet medium- to

high-altitude aircraft and cruise missiles traveling at speeds up to about MACH 2 (1500 mph). To avoid

detection it was designed to be mobile and operate for only a few hours at one location.

The Patriot battery at Dhahran failed to track and intercept the Scud missile because of a software problem

in the system's weapons-control computer. This problem led to an inaccurate tracking calculation that

became worse the longer the system operated. At the time of the incident, the battery had been operating

continuously for over 100 hours. By then, the inaccuracy was serious enough to cause the system to look in

the wrong place for the incoming Scud. The Patriot had never before been used to defend against Scud

missiles nor was it expected to operate continuously for long periods of time. Two weeks before the incident,

Army officials received Israeli data indicating some loss in accuracy after the system had been running for 8

consecutive hours. Consequently, Army officials modified the software to improve the system's accuracy.

However, the modified software did not reach Dhahran until February 26, 1991-the day after the Scud

incident. 1

A simple round-off error in the Patriot missile defense system's software contributed significantly to its failure to protect

American soldiers from the Scud missile. However, as this GAO report indicates, a second significant problem was that

the system's designers had never anticipated the situation in which the failure occurred: continuous operation for over 100

hours. The Patriot missile system was designed to be mobile and operate only for a few hours at a time-not for extended

periods. Consequently, there were no functional or performance requirements to cover this situation. Without

requirements, there was no requirements test, and without a test, there was no way to discover the simple software error

that led to the failure.

As you can see from this case study, use cases are a critical aspect of design. In this section, discover how to collect and

prioritize use cases as part of the process of defining functional requirements.

Wolpe, H. United States. General Accounting Office. Information Management and Technology Division. (1992, February1

4). GAO report B-247094: Patriot missile defense--Software problem led to system failure at Dhahran, Saudi Arabia.

Retrieved October 27, 2008.


Watch: An Approach to Defining Functional Requirements

An illustrated presentation with audio appears below. Use this resource to learn the five steps involved in defining

functional requirements.


Read: Primary and Secondary Use Cases

Let's take a look at what is meant by -both primary and secondary.use cases

The first step in defining the functional requirements of a particular product or service design is to collect a set of use

cases. In fact, the whole process hinges on use cases and working effectively with them. So, what is a use case?

A use case is a simple statement of how a particular user may interact with the system. Typically, at least one use case is

immediately obvious (the one for which the object was designed). Ordinarily there is more than one. A consideration of the

system from the perspectives of different users and types of users will most likely yield a broadening assortment of use

cases.

The Steps Involved in Defining Functional Requirements

Determining the possible varieties of use for a given system is a creative activity. Accordingly, the generation of use cases

is an opportunity for brainstorming. Involve your whole team! Encourage team members to think of as many different use

cases as they can. Remember, even contributions that seem irrelevant or silly can turn out to have value, so try not to

criticize suggestions as they are made. Instead, try to foster the free flow of ideas. Keep notes about any and all

contributions.

Typically, a team of designers can come up with a very long list of possible use cases. Of these, some will be primary and

some will be secondary.

Here is a table listing the basic set of primary use cases for the toy catapult. These use cases were derived from the

information contained in the initial context matrix.


Primary use cases are those that occur to us readily as we think about the intended ways the system would be used. For

example, an automated-teller machine is used to dispense cash and to accept deposits. These are primary use cases.

Secondary use cases, are those we discover by thinking about the system in a more complete way, considering, for

example, how the system might be abused and how it can fail. How a thief may break into an automated-teller machine is

a secondary use case.

It is important for designers to consider secondary use cases in addition to the more obvious primary use cases.

Frequently, some of the most important functional requirements, including those related to safety, security, and reliability,

come from a consideration of secondary use cases. Furthermore, much of the architecture of the final product comes from

the need to satisfy these secondary concerns. For example, Bass et al. emphasize that all software would be written as a

single block of code if it were not for the secondary concerns of reusability and maintainability. These have led to1

modular software architectures and to the modern paradigm of object-oriented programming.

Bass, L., Clements, P., & Kazman, R. (2003). (2nd ed.). Boston: Addison-Wesley.1 Software architecture in practice


Read: Prioritizing Use Cases

Once you have a set of use cases, you must prioritize them. Rank each case as high priority (H), medium priority (M), or

low priority (L). When deciding which rank to assign, consider how likely it is that that use case will give rise to new and

important functional requirements. If it is very likely, rank the use case H. Depending on your judgment, rank use cases

that are less likely to give rise to new and important functional requirements either M or L.

The ranks you assign at this step of the process are used to select use cases to describe use-case behaviors in the next

step in the process.

Use Cases and Priorities for a Toy Catapult

In addition to the primary use cases, we want to consider secondary use cases. To determine secondary use cases, think

about actions the designer may not have anticipated that the child or some other operator could use the toy to perform.

What if the toy were aimed poorly, armed inappropriately, or not cared for properly? Questions like these will help you to

identify secondary use cases.

Let's add secondary use cases to the use cases table.


Now let's assign priorities to these use cases. Which ones should have high priority? Which ones are less important?

This table shows how the designer might prioritize these use cases in the design of the toy catapult. Two primary use

cases are given the highest priority: "child plays with toy" and "parent entertains child with toy." This prioritization indicates

the designer's conviction that the project can benefit most from a detailed exploration of these two use cases. Note also

that the designer has assigned a high priority to most of the secondary use cases. Given the nature of the use cases,

these ranks may reflect the designer's deep concern for safety.

Click the table below to see how the designer might prioritize these use cases.


Read: Describe Use Case Behaviors

This course recommends a to developing designs, where designers "dive" into the details of adive-and-surface approach

particular question and then "surface" to summarize and make more general statements about what they have found or

what they've learned their project needs. is an apt approach to developing an understanding of how toDive and surface

define functional relationships.

The following pages demonstrate how you can create descriptions of use-case behaviors. To collect these behaviors and

compose their descriptions, you dive, in accordance with the dive-and-surface approach.


Watch: Working with Use Case Behaviors

An illustrated presentation with audio appears below. Using this resource, you can learn to use use-case behaviors to

develop functional requirements.


Tool: Use-Case Behavior Template

Download the Tool

Blank Use-Case Behavior Template

The use-case behavior template is a simple spreadsheet tool for describing how users interact with a system. Use it to

create one or more use-case behavior sheets for each of your use-case behaviors. Creating these sheets will help you to

work carefully through the details of your system behaviors and, eventually, to define a complete set of functional

requirements for your design.

The following guide will help you use the template to create a description of a use-case behavior. Just enter data in each

of the template's five sections, according to the instructions provided. This guide uses the toy-catapult primary-use-case

example, "child plays with toy."

The Five Sections of the Template

Enter a suitably descriptive name for one use case. For the use case "child plays with toy," the designerUse-case name:

might choose the use-case name, "child plays with toy."

Use-case name for the use case "child plays with toy."

Enter a description of the condition the system and its environment were in prior to the behaviorInitial conditions:

described in the use case. You may find that several initial conditions are possible. In the use case "child plays with toy,"

the designer could specify the initial condition as either "the system is in the unloaded state" or that "the system is in the

loaded state."

Because different initial conditions may give rise to different behaviors, it is good practice to treat them separately. If you

https://d31owemgwclw9w.cloudfront.net/content/CESYS/CESYS501/cesys501_322_use_case_behav_templ_en-us.xls

Copyright © 2012 eCornell. All rights reserved. All other copyrights, trademarks, trade names, and logos are the sole property of their respective owners. 401.

find you have two or more different initial conditions, create a different use-

case behavior sheet for each one of them. For the use case "child plays with toy," the designer would create one sheet for

the initial condition, "system is in the unloaded state," and another sheet for the initial condition, "system is in the loaded

state."

Use-case behavior sheet for initial condition "System is in the loaded state."

Use this section of the template to enter a description of the behavior as a sequence of events andBehavior thread:

activities. For each event or activity, the description should include the entity it is most closely associated with. Create the

description as a table like the one shown below.

A behavior thread for the use case "child loads toy."

Construct the table so that there is one column to represent the user (the operator), another to represent the system, and

others to represent each relevant external entity. By convention, designers position the user or operator in the left-most

column, the system itself in the second column, and all other external entities involved in the remaining columns.

To use this table, separate each use case into events and activities and assign them, one at a time, to one of the columns.

Typically, a use-case-behavior thread begins with an event in the operator column.

Enter the events and activities sequentially, using separate rows to indicate their order of occurrence. If two activities

occur simultaneously, enter them in the same row.

Keep in mind that the definition of a behavior is always open to some measure of interpretation. A designer creating

use-case behavior sheets may choose to split the use case "child plays with toy" into several smaller threads including, for

example, the use case "child loads toy." This more specific thread might begin with "the child pushes the receptacle into

position" and end with "the system shall secure the receptacle in position." This alternative use-case behavior is shown in

the table above.

Notes


1.

2.

3.

If an activity is in the system column, it is a required activity of the system. Therefore, describe it as a system

requirement using "shall" statements, beginning, "the system shall…" Activities in other columns don't need to be

phrased this way, because they don't reflect system requirements.

An activity in the system column should state what the system must do, but it doesn't need to specify how the

system must go about doing it.

Describe events and activities in complete sentences instead of in phrases and abbreviations. These statements

will be read out of context in the next step of this process, making it difficult to interpret informal phrases and

abbreviations.

Enter a description of the state of the system you desire as a result of the behavior. The endingEnding conditions:

condition is important for several reasons. For one, you need to specify the ending condition to know how the next

behavior thread begins. For another, at the testing stage, you will need to know the ending condition to know if the

behavior has been successful. If the specified ending conditions are not met, you will have to consider the behavior a

failure.

Let's consider the toy-catapult use-case behavior, "child loads toy." The ending condition is "the toy is in the armed state."

If the designer finds during testing that the toy is not armed at the end of the behavior, he must consider the behavior as

failed.

Use-case behavior sheet for ending condition "The toy is in the armed state."

Since this is a process of discovery, project-related ideas that you will want to save may occur to you while you areNotes:

writing your behavioral descriptions. Use the notes section to record these observations and concerns as they emerge.

You might think, what if the operator chooses to load a small pet in the receptacle? or, what if the operator gets frustrated

and uses the toy itself as a projectile? You can record concerns like these in the notes section.

Click the links below to download two examples of completed use-case behavior templates for the toy catapult.

Child plays with toy

Parent Entertains Child

https://d31owemgwclw9w.cloudfront.net/content/CESYS/CESYS501/cesys501_322_childplays_en-us.pdf

https://d31owemgwclw9w.cloudfront.net/content/CESYS/CESYS501/cesys501_322_prntntrtns_en-us.pdf


Read: Adding Details to the Context Matrix

As you develop use-case behaviors and define functional requirements, it's good practice to expand your description of

the context and details of the system where you can. To see how you might accomplish this, let's revisit the context matrix

for the toy catapult.

"is related to" Child Parent Toy

Child retrieves and plays with

Parent teaches and entertains stores

Toy attracts

Original context matrix for the toy catapult.

Note that this matrix contains a three-by-three space describing just four interactions. You can expand it to include more

entities and more interactions. Are you able to identify any additional entities using the use-case-behavior descriptions for

"child plays with toy"? Several behaviors for this use case are described in the sheet below.


Behavioral description of use case "child plays with toy."

After considering the content of this sheet, you may have some ideas about how to add to the context matrix. You could

add internal entities like receptacle, spring, release, or lock. In addition, you could add the external entity projectile,

referenced in several of the threads.

What if you discover in time that some of these additional entities were not actually essential to the design? If you do,

that's fine; it will still have been a good idea to have added them. Having done so at the time enabled you to describe the

system more fully. In any event, you can always adjust these descriptions of the system as you need to later on.

Here's what an expanded context matrix might look like. The new entries in the matrix are highlighted. The bold border

indicates the system boundary: toy, receptacle, lock, spring, and release are all internal to the system. Child, parent and

projectile are external to the system.


"is related

to"Child Parent Toy Receptacle Lock Spring Release Projectile

Child

retrieves

and

plays

with

pushes

into

position

triggersplaces in

receptacle

Parent

teaches

and

entertains

stores

Toy attractsconsists

of

consists

of

consists

of

consists

of

Receptacleis part

of

holds and

launches

Lockis part

of

secures

in

position

withstands

force ofarms

Springis part

of

powers

launch of

Releaseis part

ofreleases

Projectile amuses

Expanded context matrix using details from use case "child plays with toy."

The expanded context matrix communicates several new things about the system. It indicates that the toy includes a

receptacle, a lock, a spring, and a release; that the child pushes the receptacle into position; and that the spring powers

the launch of the receptacle. As you can see, an expanded context matrix is an even better reference with which to

proceed through the design process. Later in this series we will discover that a spring-loaded catapult may not be the best

design. At this stage, showing the spring as an internal entity does not commit us to this design idea. It is just useful to

capture that concept.


Read: Summarize and Finalize Requirements

At this point in the process, the designer must summarize the detailed requirements to create a set of well-thought-out

final functional requirements. The consequences of not carefully finalizing requirements could be catastrophic for a

project. The classic example of failure due to casual or incomplete requirements is the man who spends months building a

boat in his basement, only to discover, when the work is done, that the boat is too big to be carried upstairs and outdoors.

This deeply frustrating conclusion of the shipwright's story could have been avoided if his requirements had included one

that read, "The boat shall be small enough to be carried upstairs and outdoors."

In following pages you will study the process of summarizing and finalizing functional requirements. Then complete your

course project and proceed to the author's concluding comments.


Watch: Summarizing Functional Requirements


1.

2.

3.

1.

2.

Read: How to Write Functional Requirements

Key Points

Requirements are reserved for expressing what a system must do, and are therefore constructed using the word shall

When writing functional requirements, take care not to preempt the development of potentially user-pleasing design

elements by making your requirements too restrictive

At this point in the process, you should be ready to document and finalize your functional requirements. The following are

a few guidelines for constructing and polishing them:

Write your functional requirements at an abstract or general level.

Functional requirements state what the system must do, but they should not specify how it must do it.

Write each functional requirement as a complete sentence, including the verb "shall."

Let's look in more detail at the third guideline. Why is it good practice to write functional requirements using the word shall

? For example, why say, "the system shall present the user with a menu of choices," instead of saying it do so? Toshould

say that the system do something is to articulate an objective rather than a requirement. The designers andshould

builders are under no obligation to satisfy "should" statements. Requirements are reserved for expressing what a system

must do, and are therefore constructed using the word .shall

Concerning the second guideline, note that whereas the question of what to do is a high-level design decision, the

question of how to do it is a lower-level decision. Though you may be tempted to develop now your thoughts regarding

how requirements will be met, you should set this task aside until later in the process.

A final note: When writing functional requirements, take care not to preempt the development of potentially user-pleasing

design elements by making your requirements too restrictive at the outset. On the other hand, don't keep things so loose

that you thereby compromise a requirement that is essential to the mission of the project.

Functional Requirements for the Toy Catapult

This table is a collection of all the high-level functional requirements-the originating requirements-that the owner or

designer has identified for the toy catapult. Do these requirements adhere to the conditions listed above? Each

requirement in the table is expressed formally, using the verb "shall." Each one provides information about what the

system must do, stopping short of indicating how the system must do it. Finally, these requirements are written at a

general level.

In this table, each requirement bears two identifying codes:

A number. When deriving detailed requirements from originating requirements, designers will use these

reference numbers to trace detailed requirements back to the originating requirements they were derived from.

An abstract function name. Function names can be used as shorthand for functional requirements.

Originating Requirements Abstract Function Name


OR. 1 The system shall detect its receptacle in proper position. Detect

OR. 2 The system shall secure its receptacle in position. Arm

OR. 3 The system shall hold the projectile in its receptacle. Load

OR. 4

The system shall detect the command to release from a

passing toy (lateral direction) and also from a child or falling

projectile (vertical direction).

Trigger

OR. 5 The system shall eject the content of its receptacle. Eject

OR. 6The system shall notify the parents of the dangers and

inherent risks of the system.Warn

OR. 7The system shall suggest to the parent the appropriate age of

the child to use the system.Suggest Age

OR. 8

The moving parts of the system shall be prevented from

striking the face of a child with sufficient force to cause a

bruise.

Protect face

OR. 9

The system shall not launch projectiles from the child's

domain with sufficient force to cause damage to the child or

the projectile.

Constrain launch force

OR. 10The system shall enable the escape of a pet rodent from the

receptacle.Enable pet escape

OR. 11The system shall successfully complete each cycle of use for

many cycles.Repeat

OR. 12The system shall survive a collision with a hard surface in

working order.Survive collision

OR. 13Verification of all requirements shall be conducted in such a

way as to preserve the health of human and animal subjects.Test safely

Draft of originating requirements.

These originating requirements are the initial characteristics the owner has identified as critical to the definition of the

system. Sometimes, someone other than the owner will conduct the functional-requirements analysis. But even in those

cases, analysts need owners to approve their originating requirements and to suggest modification of them where

warranted.


Read: Finalizing Requirements

Key Points

Check to make sure originating requirements are not ambiguous, overly restrictive, or contradictory

A great deal of design effort can be wasted if originating requirements are flawed

Before accepting a collection of originating requirements as final, check to make sure they are not ambiguous, overly

restrictive, or contradictory. Although it is possible later in the design cycle to come back to clarify originating requirements

or to challenge their validity, the later these challenges occur, the more difficult they are to resolve. A great deal of design

effort can be wasted if originating requirements are flawed.

Take a moment now to review the originating requirements for the toy catapult, to see if you can spot any potential

problems. Check for underlying assumptions which may not be valid, potential conflicts with other requirements, unclear

wording, overly restrictive wording, and possible safety concerns.

Finalizing the Requirements for the Toy Catapult

Review the below table of originating requirements for the toy catapult. Do you consider them to be in final form? In our

own final review of these requirements, we identified issues related to OR. 1 and OR. 5. Here are the issues and their

resolutions.

Originating Requirement 1

The system shall detect its receptacle in proper position.

- this assumes a particular spring-based design, but one could also imagine instead a remote-controlledIssue

battery-operated toy. Is there a more general way to state the requirement that won't needlessly restrict the design

choices?

- revise the requirement to read less restrictively: the system shall detect the command to arm.Resolution

Originating Requirement 5


The system shall eject the content of its receptacle.

- what contents shall it expel? OR. 9 raises a pertinent safety issue: do not cause damage to child or projectile.Issue

- revise the requirement to be more specific: the system shall be capable of ejecting lightweight balls andResolution

dolls from its receptacle.


OR. 1 The system shall detect its receptacle in proper position. Detect

OR. 2 The system shall secure its receptacle in position. Arm


OR. 4




Trigger

OR. 5 The system shall eject the content of its receptacle. Eject





OR. 8



bruise.

Protect face

OR. 9



the projectile.





many cycles.Repeat





The originating requirements for the toy catapult.


The resolutions are implemented through rewritten requirements in the final table, below.


OR. 1 The system shall detect the command to arm. Detect

OR. 2

The system shall secure its receptacle in the armed position.

The force required to arm the system may be supplied by the

system (eg. battery-power) or by the child.

Arm


OR. 4




Trigger

OR. 5The system shall be capable of ejecting lightweight balls and

dolls from its receptacle.Eject





OR. 8



bruise.

Protect face

OR. 9



the projectile.





many cycles.Repeat





The finalized originating requirements for the toy catapult.

Since the owner is responsible for originating requirements, the designer must get approval for these changes from him or

her before proceeding with the design.


Listen: Thank You and Farewell

Click Play to Listen

Peter Jackson Director, Systems Engineering Program

Cornell University College of Engineering

In this course, we began with a product concept, a simple idea of a product. We sketched it, and used a context diagram

and context matrix to identify internal and external entities. This helped us to limit the scope of our design. Then we

identified three different points of view from which to study our product: the owner, the customer, and the user, and

realized that the product can look quite different depending on your point of view. We expressed our goals for the design

by means of a mission statement. We made an effort to study the context in which the product would be used, and

identified important relationships between our product and the external entities.

We then moved on to defining the functional requirements. This involved identifying primary and secondary use cases for

the product and prioritizing them. We developed detailed use-case behavioral descriptions. Each behavior consisted of a

thread of activities from a stimulus to a response or set of responses. We wrote activities that the product performed in the

formal fashion of a functional requirement.

We collected all the detailed functional requirements from these behavioral descriptions and summarized them as more

abstract originating requirements. We also expanded the context matrix based on new entities we discovered during the

behavioral-analysis process. We considered issues with the functional requirements and resolved them by writing clearer

finalized originating requirements.

By the end of the course, we had created a product-concept diagram, a context matrix, a mission statement, and a list of

finalized originating functional requirements. We're off to a good start. I hope you'll continue your work in the next course.


Stay Connected


Supplemental Reading List

To learn more about the concepts presented in this course, you may want to consult, on your own, the following

supplemental resources:

(1968) - Bertalanffy, L., von. "General systems theory: Foundations, development, applications."

New York: George Braziller Inc.

(1997) - Beyer, H., & Holtzblatt, K. "Contextual design: A customer-centered approach to systems designs."

San Francisco: Morgan Kaufmann Publishers.

(1999) - Edwards, B., & Tarcher, J. P. "The new drawing on the right side of the brain."

New York: Putnam

(1992) - Fossberg, K., & Mooz, H. "The relationship of systems engineering to the project cycle."

Engineering Management Journal, 4(3), 36-43.

(2000) - Hatley, D., Hruschka, P., & Pirbhai, I. "Process for system architecture and requirements engineering."

New York: Dorset House Publishing.

(1987) - Karas, L., & Rhodes, D. "Systems engineering technique."

NATO Advisory Group for Aerospace Research & Development Conference Proceedings, 417.

(2000) - Meier, M., & Rechtin, E. "The art of systems architecting(2nd ed.)."

New York: CRC Press.

Norris, G. "Boeing's seventh wonder." (1995) -

IEEE Spectrum, 32(10), 20-23.

(1997) - Oliver, D., Kelliher T., & Keegan Jr., J. "Engineering complex systems with models and objects."

New York: McGraw Hill.

(2007) - Rosenbloom, S. "My dad, American inventor."

The New York Times. Retrieved July 20, 2008, from

http://www.nytimes.com/2007/08/16/fashion/16dads.html?n=Top/Reference/Times%20Topics/People/R/Rosenbloom,%20Stephanie

http://www.nytimes.com/2007/08/16/fashion/16dads.html?n=Top/Reference/Times%20Topics/People/R/Rosenbloom,%20Stephanie


Documents

CESYS501: Getting Started on Product and Service …...To complete the course project, you choose one of two case studies- Internet-based Meal Delivery System or HomeAlone Health Monitoring