COP 2805C (Java II) Project
Voice Mail System RFP
Analysis and Requirements
Due: by the start of class
on the date shown on the
syllabus
Description:
This is a Request for Proposals (RFP).
Your job is to seek more information as needed from your contact
person
(in this case, your instructor), and to work in small groups
to analyze the RFP and to determine the complete
requirements and specifications.
The result will be a collection of use cases and/or
functional requirements.
You may also describe the over-all design for clarification
purposes (but do not submit any detailed design; i.e. no class
diagrams).
These may be submitted as text, graphics, or a mixture.
Note that some features are not needed for the initial system but will
likely be needed in the future.
For this assignment only consider the basic requirements and leave the
rest for version 2.
However your design should make such potential changes
to the requirements simple to implement (that is, without a major
requiring a re-design of the whole system).
You are to provide the initial high-level specifications (as noted above,
the detailed requirements and optionally, an overview (“high-level”)
of the design) for a voice mail system.
The system has a collection of mailboxes,
each of which may be accessed by a four digit extension number
(7213 for example).
A user of the system may put a message into any existing mailbox
by dialing the extension, waiting for the tone, then recording
a message.
First form your groups and decide on when and how to meet.
Then read the RFP and note any question you may have.
After discussion with your group, decide on what questions to ask
and send email to the RFP contact person.
Finally, as a group, decide on the use cases, features, potential
changes, and overall design.
when everyone in your group agrees, you then have the various group
members write up their share of the use case, functional requirements,
and design documents or UML (or other) graphics.
Then as a group assemble all that into a proposal and submit.
Note that any communications you have with your RFP contact (me)
should be via email.
This is because any clarifications or changes must be documented
in writing in the real world.
Any such clarifications or changes should be included with your
design proposal.
(Try your best to act professional in all these communications.)
The real-world voice mail proposal that this assignment is based on,
took teams of expert, experienced developers many months to come up
with the detailed requirements.
And many more months for the detailed design, and still more months
to actually build anything.
You've only been given a couple of weeks, and you are not expected
to be experts in telephony or software design.
Try not to go overboard!
The purpose of this assignment is to give you a bit of experience
in software analysis, nothing more.
Example Corp. is accepting proposals to design, develop,
deploy, and support the company's voice mail system.
This will be a concept to completion production.
The purpose of this RFP is to provide a fair evaluation for
all candidates and to provide the candidates with the
evaluation criteria against which they will be judged.
PROPOSAL GUIDELINES AND REQUIREMENTS
This is an open and competitive process.
Proposals received after 7:00pm EST March 1 2011
will not be considered and will be returned unopened.
The proposal must contain the signature of a duly authorized
officer or agent of the company submitting the proposal.
If you wish to submit alternate solutions, please do so.
The price you quote should be inclusive.
If your price excludes certain fees or charges,
you must provide a detailed list of excluded fees with a complete
explanation of the nature of those fees.
If the execution of work to be performed by your company requires the
hiring of subcontractors you must clearly state this in your proposal.
Sub-contractors must be identified and the work they will
perform must be defined.
In your proposal please provide the name, address,
and EIN of the
sub-contractor.
The Example Corp. of Tampa Florida will not refuse a proposal based upon
the use of sub-contractors;
however we retain the right to refuse the sub-contractors you have
selected.
Provisions of this RFP and the contents of the successful responses are
considered available for inclusion in final contractual obligations.
CONTRACT TERMS
Example Corp. of Tampa Florida will negotiate contract terms upon
selection.
All contracts are subject to review by Example Corp. legal counsel,
and a project will be awarded upon signing of an agreement or contract
which outlines terms, scope, budget and other necessary items.
PURPOSE
Example Corp. has recently expanded and has no current voice mail
system.
In the past individuals were provided telephone message recording
machines individually, as needed.
We want a friendly, easy to use voice mail system that all can use.
We currently have several hundred employees.
DESCRIPTION AND OBJECTIVES
Any user with a valid mailbox and its password may do any of the
following:
play back messages
delete messages
change the greeting
change the password
An administrator needs to be able to activate and deactivate
mailboxes.
In addition administrators must be able to play and copy selected
messages.
Only administrators should be able to do these tasks.
The system must remember the messages even if the power should fail and
the system needs to be restarted.
The saved voice mail needs to be able to be backed up (and restored).
TIMELINE
This RFP is dated February 15
(all dates are for the current year).
Proposers may also request a copy be sent via email by contacting
Betty Boop at bboop@example.com.
Proposals are due no later than 7:00pm EST, March 15.
Proposals will be evaluated immediately thereafter.
During this time we may require interviews at our office with our
evaluation team on or about March 21.
You will be notified if this is requested.
The name of the candidate firm who has been selected will be
decided on or about April 1.
Negotiations will begin immediately with the successful candidate
and should conclude no later than April 30.
All other candidates will be notified on or about
May 1.
Phase I of the project must be completed and delivered by
February 1 of next year.
Engagement work complete and voice mail system live
– deliverable date to be determined during Phase I.
BUDGET
Please provide several cost proposals to accomplish the scope as
outlined.
The budget must encompass all design, production, and software
acquisitions necessary for development and maintenance of the
voice email system.
Hosting will be addressed separately and costs for hosting are not
included in the budget for this project.
List pricing for:
Phase I: Discovery, Requirements Planning & Site Definition
Phase II: Site Development, Testing and Deployment
Hosting: We have not yet made a decision to host on or off-site.
Discussions during the discovery phase and your input and advice will
help us make a decision in this regard.
Example Corp. of Tampa Florida has allocated $25,000 for this project
(Phase I and II).
However, we will entertain responses for greater than $25,000 if they
show an incremental project plan.
Hosting costs will be addressed separately.
AVAILABLE TECHNOLOGY RESOURCES / INTEGRATION ISSUES
We have not yet purchased any new phones or servers to support this
project.
During deployment, basic phone service must not be interrupted during
normal business hours.
QUALIFICATIONS
List three systems your firm has produced that best reflect
your work and relevancy to this project.
Briefly list the role your firm played in each project.
Provide current reference information for three former or current
clients.
Briefly describe your firm's organizational capacity to produce our
voice mail system (e.g. staff, equipment, software, physical space,
office location, etc.).
How many full-time staff does your firm employ?
Please include a copy of your firm's organizational chart.
Provide a company profile, length of time in business
and core competencies.
Briefly describe the percentage of your development staff that would
end up working on this project relative to your entire staff
(using full time equivalents).
For example, if you would use five staff on the project and
you have ten developers, the percentage would be 50%.
What type of team will be assigned to this project?
What will each person's role be?
Please include a brief background summary for each key staff member
assigned to this project.
Briefly describe your firm's project management process.
Percent of total revenue derived from voicemail/PBX developments
and other business ventures.
Explain your business model.
Please discuss any planned IPOs,
mergers or acquisitions.
Please discuss any hardware/software vendor partnerships.
Please discuss your testing and support plan.
Please explain your service level agreement
(SLA) structure.
List the time frame for completion.
The time frame for completion of the project will be evaluated
will be part of the contractual agreement;
therefore, a realistic time frame for completion is requested.
List any terms and conditions.
EVALUATION CRITERIA
The following criteria will form the basis upon which the
Example Corp. of Tampa will evaluate proposals.
The mandatory criteria must be met and include:
Ten (10) copies of your proposal must be received no later than
7:00pm EST, March 15 of this year.
Your proposal must include a cost proposal as described above.
All costs associated with the delivery of the project should be presented
in a flat rate, fee for service format.
Deliver proposals to the attention of:
Betty Boop
Example Corp. of Tampa Florida
123 Main Street
Anytown, USA 12345
Proposals that meet the mandatory requirements as stated above
will be evaluated with the following criteria:
Suitability of the Proposal – the proposed solution meets the needs and
criteria set forth in the RFP.
Expertise in recommending and communicating appropriate technical and
aesthetic solutions as evidenced by the proposal and references.
Candidate Experience – Candidate has successfully completed similar
projects and has the qualifications necessary to undertake this project.
Value/Pricing Structure and Price Levels – The price is commensurate with
the value offered by the proposer.
Depth and Breadth of Staff – The candidate firm has appropriate
staff to develop the site in the time frame needed.
Proposal Presentation – The information is presented in a clear,
logical manner and is well organized.
Demonstrated commitment to high service level agreements
(SLA).
FORMAT FOR PROPOSALS
Please use the following as a guideline to format your proposal:
Length and Font Size:
Please use fonts no smaller than 10 point.
Maximum proposal length including title page, cover letter, proposal,
qualifications and budget should not exceed 35 pages
(not including Hosting Attachment information).
Title Page:
Example Corp. of Tampa Florida, voice mail Development Proposal,
your company name, address, Web site address, telephone number,
fax number, e-mail address and primary contact person.
Cover Letter:
Signed by the person or persons authorized to sign on behalf of
the company (1-2 pages).
Proposal:
Discuss your proposed solution, including the features, benefits and
uniqueness of your solution.
You should also touch on your ability to deliver the project in the
time frame noted in Section 5 (3-10 pages).
Qualifications:
Provide the information requested in Section 12 (10-20 pages).
Budget and Fees:
List budgets as requested above. Identify staff you anticipate working
on the project and their hourly rates for work that may be needed for
Phase I and Phase II.
Attachments:
Hosting options/information:
Do you provide hosting?
If so, please provide answers to the following questions:
How often do you backup?
How often do you have down time?
How often do you upgrade software/hardware?
Please describe your technical support.
Please describe your security.
Do you have a high-speed, direct connection to the Internet?
Please describe your methodology and service level agreements.
Pricing, terms and conditions.
If you do not provide hosting, please suggest a vendor/partner
to provide this service and provide answers to the above questions.
End of RFP
To be turned in:
A copy of your use cases and any other requirements documents (e.g.,
UML use-case diagrams, functional specifications,
and hardware assumptions if any).
If you created any high-level design documents you may submit those as well,
although this isn't required.
A copy of any emails (and the responses) sent to the RFP
contact should be included as well.
You can send as email to
(preferred).
If email is a problem for some reason, you may turn in a hard-copy.
In this case
the pages should be readable, dated, and stapled together.
Your name should appear on the first page.
Submit these documents to the correct Canvas dropbox for this assignment.
Only a single submission is needed per group.
All such designs start out with brain storming, then recording a set
of use cases (or scenarios) that show all required
interactions with your system.
Finally you work out a high-level design, or system
architecture, that you hope will facilitate implementation of
all the required features.
This high-level design need not (and should not) have all
the details; you only need sufficient detail so that you know you
could complete the detailed design.
(If not sure, it is safer to include extra detail than leave it
out.)
I only want the requirements for this RFP, expressed
as a set of project requirements, and not any design documents
you may have come up with during brain storming.
(Don't think about the design until you have sufficient details
about the requirements.)
These requirements can be expressed as a collection of
user interaction scenarios, or use cases, something like:
Use Case #1: Caller Leaves A Message
Person dials extension
After N rings (mailbox-user settable) the voice mail system responds
Plays message previously recorded by the mailbox-user (or a default)
Checks for mailbox full/active
Plays “sorry” message if box not accepting messages, and hangs up
Plays “beep” tone to indicate start of recording
Records message until user hangs up, hits the '#' key', or the
maximum message length (settable by administrator) is reached
Message is stored in database (possibly as “.wav” data),
along with time of call and ANI (Caller-ID)
data, if available
Call terminates
Your system should have a number of such use cases.
No design details are needed at this stage, although other requirements
documentation may be needed in addition to the use cases.
The various use cases can be organized as a list or decision tree.
Here is a graphic I found showing some of the use cases needed for a voice mail
system, shown as a decision tree:
Note the picture doesn't have the use case details, only the names and relationships
between use cases.
You still need to document your use cases.
Sometimes thinking about design, and
building a prototype can help you understand some
requirement, some interaction, or if some design aspect
will be feasible.
You do not have to do design or implement a prototype for this project
(you won't be given enough time for one!).
However you may prototype some parts of a preliminary design,
if you wish (but don't turn that in).
Since we don't have the hardware to actually record voice mail messages
as “.wav” files available, for a quick voice-mail prototype,
simply have users type text messages in at the keyboard,
after first typing in the extension.)
Potential Changes (Features to consider in your design):
Quotas (maximum number of messages, or maximum number of seconds of recorded
messages) for mailboxes
Have very old messages automatically deleted
Multiple mailboxes per user
Support Spanish and English
Remote access to mailboxes
A directory callers can use when they know a name but not
the extension
Call forwarding
Message forwarding
Hi-tech phone support (LCD screens and extra
buttons)
Restore system-default out-going message (if a mailbox owner
doesn't like their recorded message)
I found the following actual RFC using this Google Search:
Sample RFP voicemail -VOIP, at the site
www.metrokc.gov/procurement/
(which apparently has since been moved elsewhere on their site).
You can look these over to see what a real-world RFP
looks like.
Here are some copies of these documents (in case they vanish from
the web):
![[decision tree showing several use cases and their relationships]](VoiceMail/VoiceMailUseCases.gif)