Here are the questions, slightly edited, asked of me by student groups.
What is the time to market for this product?
You need to have requirements and design done by early June. Market time is Autumn 1998.
How long is this product expected to be in the market before being obsolete?
1 to 2 years.
What is the target price range for this product?
$89.95
What is the grouse margins expected from this product?
I expect you mean "gross margin?" 15 to 20%.
What are other potential uses of this product other than answering a call?
Hmmm. Give me some ideas.
What are the reliability requirements for this product?
Very High! No failures.
Where will this product be sold? USA, Asia, Europe, Latin America?
North America
Can we assume that this is a sellable product, given that marketing has done their research?
Yes.
Can we assume that software may control added features to the system?
At this point, there are no standard features. It's your job to define them.
Is there a time frame to develop this product, or is this something that we can establish?
You must have your requirements and design complete by early June. Our coding contractor will take over from then on.
Any specific warranty needs to be given, or also we establish it?
The product has the standard warranty period.
What features do our competitors at this price point offer?
You should conduct a market survey.
How many of these units do we anticipate selling?
300,000 to 500,000.
What's the recurring hardware cost of manufacturing this unit?
We're not sure. It depends on which actual components are included. The hardware costs less than the price point
Why are we designing this phone? Are we breaking into a market, improving on an existing product, or have we identified a specific niche that we feel can be exploited?
We want Phone-A-Sonic to define the market with this product.
If the product is intended to fill an identified niche, are there specialized needs that will drive the defining attributes of the device? If so, what are they? For example, it might be intended for use as a hospital room phone, so there might be a requirement for disability accessibility.
That depends on what you come up with. We're very interested in your ideas.
Is there any external control capability, as in calling in to collect messages?
There is if you program it. Do you think it's a good idea?
How many outgoing messages are required? What is our memory limitation on time?
I don't know. How much would you like.
If the machine is recording a message from an incoming caller, and the phone is "picked up" (hand set goes off hook in some fashion), what should happen? Should the recording stop? Is software informed when the phone goes off hook?
The operating system has a primitive for the hand set hook. It's up to you to decide what to do when that event occurs.
Is there any capability for using "toll saver" features?
The operating system has a primitive for ring detection.
What are the environmental conditions this product must operate in?
Normal ones.
What are the power and power source requirements for this product?
Irrelevant to you.
What Software Development Industry standards must the Software meet? ISO 9000-3, CMM Level 1,2,3,4, or 5, DOD standards?
None that we know of. It just has to work correctly all of the time and be delivered on time and within budget.
Any EFM/CE requirements?
I don't think so.
Who is the targeted user of this product?
Certainly it will be marketed to homes and small businesses. We look to you for more insight.
What will be the physical limitations, if any, of the users of this product?
Do you mean "How small or large will the users be?"
Is the user the same as the client of this product?
No. They are the users. I am the client.
Who is the client?
See above.
What language will the user(s) speak?
Mostly English, I think.
What is the age range of the potential users/clients?
For the users, I don't know. For myself, most people tell me I look younger than I am.
Who is funding the software, the hardware and the overall product development?
Phone-A-Sonic.
What is the amount of money we count on for developing this software?
The contract for development is downstream from your efforts and out of scope.
The initial project listed a set of Hardware Specifications. How much control do we have over the Hardware?
Not much control.
Is it possible to add more Hardware to that list?
Yes, but only for a limited time.
As for the cassette tape to be used, is there any specific length of these tapes required?
This is no longer relevant since changing from tape to memory.
Is there any other hardware documentation in addition to the description you distributed? If so, how can we get a copy of it?
Only the two documents. If there are any changes, they will come from Hardware Central.
What is the purpose of the MEMO/2 WAY button? Can we define its function or is it tied to the hardware?
There is no inherent function tied to any of the buttons. It will all be software controlled.
Does the cassette control hardware (PLAYBACK/PAUSE, REWIND) support skipping messages? Is there hardware in place to detect gaps between messages?
Not specifically. You could program the hardware to "listen" for gaps.
Is the hardware description complete or can we add to to it? For example, is there a speaker in this phone?
There is a speaker, underneath the hand set.
Does software control the LEDs?
Yes. You may assume there are primitives for all hardware devices.
Is the phone analog or digital?
Analog.
Does the power switch turn the just the answering machine portion of the phone off, or the answering machine and the phone?
Just the answering machine. The phone operates off of line voltage.
Does OGM stand for Outgoing Messages?
It does.
Why are the OGM buttons concealed?
That's the way they did it on the previous model.
How are the OGM buttons concealed?
Behind a door.
Can the user control the volume for recording and/or playback?
Yes, but only manually.
Are there any hardware limitations that I should be aware of stemming from the fact that this software is burned into ROM?
No. (Other than no self-modifying code.)
Is the software executed from ROM?
Yes.
Is there any RAM available to the software for data storage?
Yes. The message memory.
In how many rings should the answering device answer?
Is this a trick question?
Will the user require remote massage retrieval?
(I assume you mean "message," not "massage"), which I think the answer to is "yes." The latter would also be a really neat trick.
Will the user require remote message recording to update the greeting (OMG)?
I would think so.
What will be the software update mechanism? does it matter?
Interesting idea. What would you suggest?
How much money is budgeted for product development?
Do not take development budget into consideration. We want a set of requirements independent of development costs, which will be factored in during development.
What is the schedule for development? Are there any external events that drive our schedule, such as a new release of a competing product?
No external events. You need to be done with requirements and design by early June.
Has our company, or any of its affiliates, done similar software before? Is it available for design, code or test reuse? If it is, who is our point of contact for locating and assessing it?
We want to start afresh with this, our next generation signature product.
Is the list of functions complete? Are the only things we are tasked to do contained in the list that you gave us?
We've not defined any functions, yet.
How does the user know how many messages they have?
You're supposed to figure out how to design all user messages. We have high expectations that you will come up with a great design.
Is the message time unlimited for each caller, or is there a maximum time limit?
What is the right answer? We look to you.
How does the user set the clock time?
They program it according to however you decide they should.
Aside from detecting rings and answering the phone, does the software interface with the phone in any other way?
The software can generate tones and raise and lower the line.
More questions? Send me email at brian@coyotevalley.com
Last updated: 14-May-1998
