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 make 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 shair of the use case, functional requriements, 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.
This RFP was adopted from the one at www.techsoup.org/binaries/Files/samplerfp.pdf, and is used here in accordance with the stated license terms (Educational Fair use). (creativecommons.org/licenses/by-nc-nd/2.5/)
Start of RFP (Jump to end of RFP)
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.
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.
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.
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.
Any user with a valid mailbox and its password may do any of the following:
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).
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 voic email system.
Hosting will be addressed separately and costs for hosting are not included in the budget for this project.
List pricing for:
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.
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.
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:
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:
Please use the following as a guideline to format your proposal:
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
A copy of your use cases and any other requirements documents (e.g., UML use-case diagrams, functional specifications, and hardware assumtions 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.
Please see your syllabus for more information about submitting projects.
See How to design and develop a Java program for some hints and tips.
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:
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.)
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):
Voicemail RFP Part A (PDF) (RFP overview)
Voicemail RFP Part B (Word document) (Initial version of Contract)
Voicemail RFP Part C (PDF) (Exhibits, Tables, etc.)
Voicemail RFP Addendum (PDF) (RFP changes)
Voicemail RFP Q & A (PDF) (Answers to bidder's questions)
Voicemail RFP List of Bidders (PDF) (who actually submitted a proposal)
Voicemail RFP bidders tabulation form (PDF) (internal doc used to tabulate evaluation results of proposals