Assignment
Voice Mail System RFP Analysis and Requirements
This is a Request for Proposals (RFP) Analyze the RFP and 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.
Decide on what questions to ask, finally decide on the use cases, features, potential changes, and overall design. Assemble all that into a proposal
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.
SUMMARY
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. 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 [email protected].
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
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.
Discuss any planned IPOs, mergers or acquisitions.
Discuss any hardware/software vendor partnerships.
Discuss your testing and support plan.
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.
FORMAT FOR PROPOSALS
Use the following as a guideline to format your proposal:
Length and Font Size:
Use fonts no smaller than 10 point. Maximum proposal length including title page, cover letter, proposal, qualifications and budget should not exceed 20 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?
Describe your technical support.
Describe your security.
Do you have a high-speed, direct connection to the Internet?
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.
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!). 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)
Web-based access for administrators (and users?)
Change default out-going message (administrators only).
Attachment:- java.rar