Marketing Requirements Document (MRD by syed sajid (ebook reader computer TXT) 📕

full review of UI and functional designs.
3.4 Operations
Operations must …
Quality of service metrics for this product are…
Test installations and Operations acceptance testing will be done by…
3.5 Sales
Starting in Jan-2007, we will begin looking for beta customers among the existing installed base. This will be led by Sales, specifically Meredith Greenfield (Omaha) and Patty O’Furn (Dublin)…
Presales SEs will get two rounds of product training: initial concepts and selling strategies. Sales Training will be responsible for coordinating these events and turning standard marketing deliverables into Sales formats…
Marketing will launch a contest and campaign during the first three months of availability, with prizes for all Reps who close more than one account…

3.6 Legal
For some products (e.g. this teleportation product), developers will need to worry about liability and failure issues – and include a legal review of the product or claims. Consider the consequences of a network outage on hospital systems, or a security breach of law enforcement databases. For teleportation, are there disclosures and warnings that would minimize lawsuits when an occasional user arrives as a puddle of quivering protoplasm?

4.0 Bill of Materials
This section identifies all of the customer-visible product deliverables to be produced, as well as customer site requirements and dependencies. From this list, a development schedule can be created to complete everything needed "in the box" for successful customer installations and deployments. Once this BOM is matched to a product architecture, all pieces are required – therefore no priority is implied by this section’s numbering scheme.
4.1 Transporter Server
This server software runs on a conventional App Server provided by BEA (WebLogic) or IBM (WebSphere). It controls all transporter functions and continuously checks for errors.
4.2 Transporter Console/GUI
The console manages the Transporter Server and provides its user interface. In addition to physical controls, the Console can be managed via voice commands and unobtrusive ASL (American Sign Language) hand gestures.
4.3 Sound Generator
Every cool device needs its own set of special sounds to indicate proper operation. This subsystem lets engineers choose the sound palates most to their liking, and coordinates the sound generator units (SGUs).
4.4 Demographic Upsell Module (DUM)
The DUM asks each teleportation user to provide some demographic information before being transported. This is useful for contacting next-of-kin after a system failure as well as offering additional products (life insurance, destination-appropriate clothing) and adding to Marketing’s database of user profiles. Legal has asked us to include a disclaimer that demographics are not required, and do not have any effect on Quality of Service.
5.0 Internally Committed Requirements
Within this section, each item is ranked, with 3.1 taking higher priority than 3.2, etc. Product owners and development must know which features are most important. In general, this section contains features or improvements that are invisible to customers, or which will not be announced.

5.1 Elimination of Top 5 High-Priority Bugs
Technical Support and Product Management have compiled a list of our most serious software defects, as follows. All of these must be fixed and tested prior to release. As of this writing, they include:
• Buffer over-write on messages > 28.4 TB
• Memory leak causing required reboot of core service every 88 hours
• Truncated header data on Type II EDI lookups
• Removal of end user option to turn off software updates
• Misreading of ICMP packets as AppleTalk printer queue requests

5.2 Internal Performance Improvements
Two bottlenecks have been identified that are generally not yet visible to customers: retrieval of real-time database records during backup cycles, and simultaneous receipt of multiple items by a single transmitter. Both will start to show up in customer testing (or live production use) as traffic builds beyond 65 GB/hour. Development must tune/redesign the MMG and T6 modules, and QA must verify that we can score more than 88 on the TCP-X benchmark.

In addition, we will require improvement of at least 20% on each of the following metrics…

We will also need more complete analysis charting of the key performance variables that customers keep demanding. This includes the improved performance from additional server memory up to 512GB and support for larger "chunking" hardware to handle extra-long organic molecules such as DNA.
5.3 Backward Compatibility
This version of our product will work with previous versions starting with v2.0 and including our most recent release (4.4B). It must allow a mixed use model, with all versions running simultaneously on separate machines, since forcing an instantaneous upgrade is not yet possible. With the following exceptions, no functions or capabilities will be removed in this version:
• Backup/restore will be limited to formats from versions 4.0 and later. Older backups can be retrieved using a pre-existing copy of the software.
• The "audio only" communications mode will be discontinued.
Customers will be notified 9 months in advance (in writing and from their sales teams) of these changes.

5.4 Next-Generation Architectural Changes
This release will include changes to internal data structures and management mechanisms that will not be complete or visible until a later release…

5.5 Platforms and Protocols
Server-side software will run on Red Hat Enterprise LINUX v7.2 and later, Windows Vista Server 2.5+, and Solaris 10. No special client-side software will be required other than browser support (minimal set of HTML and AJAX supported by both MSIE 6.1+ and Firefox 2.0+). Client-side browser testing will be done on Win2k, WinXP, MacX, LINUX 7.0+ and PalmOS. Communications will be assumed as HTTP(S) or FTP over standard TCP/IP unless otherwise stated.
5.6 End-of-Life for Older Versions
Starting 3 months after launch, we will announce end-of-life (EOL) and end-of-support (EOS) for previous versions running on a variety of obsolete platforms. These include HP-UX, all IBM OS platforms other than LINUX, ULTRIX, DEC OSF/1, SGI IRIX, back versions of Ingres and Informix databases, and networking support for IPX and AppleTalk. Customers will be given from upgrades to any supported platform. Our EOL program outline will be:
• Notify all customers in writing of impending EOL/EOS three months after this launch
• Include offer of free upgrade/ migration to any currently supported platform within 12 months of announcement
• Special "SWAT team" created for professional services opportunities with customer migrations
• No additional patches or fixes to be made 6 months after announcement date
• No ongoing support or technical assistance 12 months after announcement date
5.7 Uptime and Quality of Service
Customers are assumed to accept at least 22 minutes of downtime per month for upgrades, database backup, and hardware preventive maintenance. All configuration and management functions must be performed while applications are running, so cannot require any shut-downs, off-line periods, or restarts. This translates to 99.95% uptime. Operations will monitor and report on all known customer downed systems, collect statistics, and calculate actual field uptime. In addition, monitoring software within the application… Third party test tools will include… Once we have achieved our target uptime, we will begin reporting this monthly to customers as an aggregate result (averaged over all customers and all systems). We will make our measurement tools available to customers who want to track their own uptime…

6.0 Externally Committed Requirements
Within this section, each item is ranked, with 4.1 taking higher priority than 4.2, etc. External announcements and customer communications will follow this list, since they are ranked in importance. If the first 4 items are not completed, we will delay launch until they are finished and fully tested.

6.1 Molecular Transmittal
AKA teleportation, this is the ability to move matter to remote devices without traversing the intermediate space. Customers are eager to get this feature, and the competition is years behind in developing it. Several major customers are waiting for this, including …
This is a major new capability and will set us apart from the competition by allowing customers to…

6.2 Voice-Activated Debug Mode
Since users often have their hands full when problems develop, this new feature allows them to ask "what if" and "what’s wrong" directly – instead of touching a keyboard. Filtering has been included, which deletes inappropriate words before logging and translating them.
Note to QA: extensive testing must be performed on sound-alike words. For instance, customers in the supply chain may often use "ship" or "truck" so should not have these blocked or deleted.
6.3 Broad Performance Improvement
We must show general performance improvement of at least 35%, as measured with our internal ZING2 test suite. This reflects actual customer applications. We will also use standard industry benchmarks (below), which must show at least 30% improvement.
If our work to overcome internal bottlenecks (above, section 3) contributes to this, then we have a double win. If not, we still require that customers running normal application loads or benchmarks see marked improvement. Therefore, a full set of CPU usage and wait time data will be required from our PerfLab – including identification of the top 6 to 10 CPU "hogs" and network latency areas.

6.4 Auto-Upgrade Feature
Customers continue to have difficulty accepting, scheduling or applying software updates (patches, interim releases, and major upgrades). This release will include an "auto-update" feature that is enabled by default, but can be turned off by the customer or by us. In addition, it must allow for selective upgrades by version and customer ID.

If accepted by customers, we expect to discontinue our distribution of physical media in Jan-2008, and begin increasing support charges for versions more than one year old. Customer Support expects this to allow promotion/redeployment of more than 10% of their staff, and is an important part of their plan to reduce case turn-around times by 35% during FY2008.

6.5 Benchmarks
We will run the following performance tests internally, with a plan to release benchmarks beating the competition… Third party test labs that will re-run or verify our results are… Publications that promote these benchmarks include…

6.6 Metering Support for ASP Model
Marketing will require a pricing mechanism for ASPs (application service providers) who will offer teleportation "per trip" rather than on a full license basis. Product must support a method for counting and billing for each use. Ideally, this will include packet counts, so that larger items can be billed at higher rates than smaller ones.


7.0 Highly Desirable Requirements
This section shows items that may be included in this release, but are not committed yet. It is intended to reduce questions about "that thing we asked for, but isn’t included on your list." In general, since lists get shorter during development, few of these items are expected to fit in the current release.
7.1 Status Indicators
While not required, this will dramatically reduce calls to Technical Support. (It may also reduce lawsuits.) System should show status of all transfers in progress, as well as statistics and details on completed and queued transfers. Data must include date/time, destination, origin, size, weight, and delivery options.
Red "alert" signals must identify if any item has failed to be received intact, or if queued items have been flushed from buffers.
8.0 Future Requirements
This section shows items that may be included in later releases, but are not committed in this release. It is intended to reduce questions about "that thing we asked for, but isn’t included on your list."
8.1 Undo/Redo
This has been requested by many customers, but is not included in this release. Some architectural work has been slipped into the main code line for completion in later releases. For now, customers who send something do not have the option to "change their minds" or later destination coordinates.
9.0 Features Not Being Implemented
Some requests are specifically excluded or denied. Showing them here is an excellent way to move conversations from "when?" to "why not?" Most requests that do not come from a