<Product or Project Name>
Product Requirements Document

Document ID	<Document number>
Version	<Version number>
URL	<Path>
Originator	<Originator name>
Approval Date	<Approval date>
Status	<Draft or Final Version>
Approvers	Development: <Approver Name> TPM: <Approver Name> IVV&T <Approver Name> Tech Pubs: <Approver Name> Other: <Approver Name> Other: <Approver Name>

Document all versions and revisions to the document. List with most recent change first.

Modification History:

Version	Date	Author	Description
0.1	16 Oct 2001	Paul Moorhead	First Draft
0.2	3 Nov 2001	Paul Moorhead	Lots of interesting details
0.3	5 Nov 2001	Paul Moorhead	Even more interesting details

Table of Contents

Introduction	3

Definitions, Acronyms and Abbreviations	3

Location of Document	3

Target Audience	3

Signoff	3

Document Scope	3

References and Related Documents	3

Internal References and Related Documents	3

External References and Related Documents	3

Objectives of Release	3

Purpose of this Product Release	3

Criticality of Release	3

Release Criteria	3

General Availability	3

Early Field Trial or FOA	3

Key Assumptions for this Release	3

Target Release Timeframe	3

Product Overview	3

System Overview	3

OPM.ME Overview	3

Product Requirements	3

Features Summary Table	3

<Major Feature or Component Name>	3

Overview (for each major feature or component)	3

Requirements (for each major feature or component)	3

Example(s) of Target Product Usage (for each major feature or component)	3

Dependencies and Linkages	3

Internal Dependencies on Other Products	3

Other Internal Products Dependent on Product	3

Interoperability and Compatibility Requirements	3

Gateway Compatibility	3

Browser Compatibility	3

Handset Compatibility	3

Protocol Compatibility	3

API Compatibility	3

Logging Compatibility	3

Packaging Requirements (bundling with associated products)	3

Internal Linkages to Other Products (distinct from dependencies)	3

Internationalization & Localization	3

Internationalization (I18N)	3

Localization (L10N)	3

Installation/Upgrade and Migration	3

Installation Requirements	3

Upgrade Requirements	3

Migration Requirements	3

Platform Requirements	3

Platforms to be Supported	3

Third Party Requirements	3

Hardware Requirements	3

OAM&P	3

Manageability Requirements	3

Billing/Event Logging Requirements	3

Log Content	3

Reporting	3

Monitoring Requirements	3

Monitoring Events	3

Event Documentation	3

Administration/Configuration	3

Maintenance Requirements	3

Provisioning Requirements	3

License Administration	3

System Wide Requirements	3

Availability	3

Reliability	3

Recoverability	3

Performance	3

Scalability	3

Product Encryption Export Requirements	3

Testing Requirements	3

Product and End-to-End IVV&T	3

Product IVV&T	3

End-to-End IVV&T	3

Web Browsers	3

WAP Browsers	Error! Bookmark not defined.

Handset support	3

WAP Gateway support	Error! Bookmark not defined.

Conformance Testing	3

Performance, Capacity and Scalability Testing	3

Documentation	3

Other Requirements	3

Continuing Engineering	3

De-Support/End Of Life	3

Budgetary Considerations	3

Training	3

Appendixes	3

Introduction

The PRD is the main output from the Requirements Definition phase of the Product Release Lifecycle and is the responsibility of the Development Product Management team. It should detail the implementation of the product features based on the requirements outlined in the associated Marketing Requirements Document (MRD). If no MRD exists for the project, the PRD should detail feature Use Cases which should provide a high-level schematic or sequence flow.

The PRD must contain a detailed/numbered statement of the product requirements.

The PRD must be unambiguous and be sufficiently detailed to enable its translation into a realistic functional specification. The PRD must be agreed and reviewed between the Product Management and the Engineering Group.

Definitions, Acronyms and Abbreviations

Present a table or list defining all acronyms and abbreviations used in this specification. Also define all concepts used that are not common knowledge for the target audience.

(Content example)

APN	Access Point Name
AI	Administration Interface
CSP	Communication Service Providers
DNS	Domain Name Server
IVV&T	Integration Verification
FOA	First Office Application
IOT	Interoperability Test
GA	General Availability
CR	Controlled Release
PAC	Performance and Capacity (Testing)
CE	Continuing Engineering (aka Maintenance)

Location of Document

The latest version of this document must be stored in XXX and the location specified in this section.

Target Audience

(Describe who should be reading this document.The intended audience should be clearly identified and listed in this section).

Signoff

Indicate who must sign off on this document. A standard list is provided below. Provide specific names where possible.

R	Required
I	If applicable (if they're part of the team)
X	Review, Signoff not required

R	Product Manager (PM)
R	Technical Product Manager (TPM)
R	Engineering Project Manager (EPM)
R	Engineering (Eng)
R	Quality Assurance (QA)
I	Systems Integration Testing (SIT)
I	Performance and Capacity (PaC)
R	Technical Publications (Doc)
I	Field Engineering (FE)
I	Localization (L10N)
I	Interoperability (IOT)
I	Platform Integration Testing (PIE)
X	Marketing Program Manager (MPM)
X	Services Product Manager (SPM)
X	Training
X	Customer Support (TAC)
X	Professional Services/Consulting (PS)
X	Partner Programs

Document Scope

The scope of the document is restricted to documenting release specific requirements. Specifically:

(Format example)

Product Overview (If required, this should be in the form of a high-level architecture diagram)

Features

Required deliverables

Administration/Configuration

Maintenance

Provisioning

Manageability (SNMP, logging, etc.)

Billing/Event Logging

Capacity

Performance and Reliability

Packaging (bundling with associated products)

Installation/Upgrade/Migration

Availability (e.g., 99.999%)

Backward Compatibility

Localization & Internationalization

FOA

IOT

SIT

Product Dependencies

Product Linkages (distinct from dependencies)

License Administration

Scalability (i.e. scaled on different platforms)

Geographical Distribution

Conformance / Standards

All requirements listed in the PRD should be as detailed as possible and should have each of the following attributes:

S: Specific

M: Measurable

A: Attainable

R: Realistic

T: Timed

References and Related Documents

Include Internal Documents, External Documents, Other Requirements Documents, etc.

<Text>

Internal References and Related Documents

List references and other documents associated with this product and which support this functional specification or are interdependent with it (include relevant FSs and other documents)

Product And Release Number:	Example: Fred 5.3
Code branch(es), if known:	Example: 50-201-260-101-1
Product Release Plan:	Example: DAS #2354
Marketing Requirements Document	Example: DAS #2354
Other reference
Other reference

External References and Related Documents

List references and other documents associated with other products or external components and which support this functional specification or are interdependent with it (include relevant PRDs and other FSs)

Product And Release Number:	Example: Fred 5.3
Code branch(es), if known:	Example: 50-201-260-101-1
Product Release Plan:	Example: DAS #2354
Product Requirements Document:	Example: DAS #2354
Other reference
Other reference

Objectives of Release

Purpose of this Product Release

The main purpose of the product and its key new features should be outlined in this section. Extra detail must be given of critical new features to the product without which the product cannot ship.

Include key objectives for the release.

<Text>

Criticality of Release

This section contains the motivation for the intended release. Summary of the business case here.

<Text>

Release Criteria

General Availability

The criteria a release should satisfy before it can be launched should be determined beforehand and noted in this section along with who has responsibility for approval. Also, the decision of a Defect Identification freeze date should be explained along with the defect count permissible for the product. Criteria for different levels of defect should be explained here. Further sections on different levels of testing can be added as appropriate.

<Text>

Early Field Trial or FOA

Decide if there are going to be any Early Field Trial or FOA for the release. If so, how many and when will they be conducted ? Discussion with the E2E IVV&T Manager will be necessary when setting any targets for FOA releases.

Also, just like the GA criteria, list the criteria and approval responsibility for releasing the EFT or FOA version of the software.

Define the goals or the focus for the EFT or FOA. If you need attention on a certain area of the product, then call it out here.

EFT criteria can be a subset of, and have more allowances than the GA criteria. EFT or FOA and GA criteria should be well understood by the product team and other related groups that will participate in the release.

Add a section for each instance planned EFT or FOA.

<Text>

Key Assumptions for this Release

List all known assumptions being made here. For example, which OS'es are being supported, if any functionality is not provided, list it here, and so on.

<Text>

Target Release Timeframe

Release is targeted for <date> based on the following assumptions:

<Text>

Product Overview

System Overview

A short description on what the system does should be included in this chapter. It is also good practice to include the high-level goals and the primary functions of the system in this description. (The following is a format example.)

The Magical Manager (MM) oversees, integrates and automates the sorcery process for network operators (carriers). The high-level goal of the MM is to centralize subscriber transformation both on the network and over the air (OTA) to the Goblin.

As Figure 1 shows, MM acts as a single point of contact between the carrier legacy Provisioning Application Server and the entities to be transformed. The following figure illustrates the MM system and its various interfaces.

(The following section is an example.)

MM Overview

The MM is currently meant to perform following primary functions:

Communicate with network elements, carrier's provisioning server, customer care reps, and administrators by triggering transformation, transmogrifcation and transmutations, and administering the system.

Provision the Elf with subscriber information necessary to facilitate data communications with a Goblin.

Communicate with a Goblin to carry out over-the-air transformation of the goblin.

Provide logs and reports of all transmutation activity sufficient to debug failures and chronicle system events.

Product Requirements

Features Summary Table

All features contained in the product, tracked from the MRD, should be listed in this section in a summary table, as shown below. Each feature should have a rank of importance to the overall product, based on the following values:

C - Critical

H - High Priority

M - Medium. Need to have a plan for developing these features in the next two major releases.

L - Low. Can be omitted if resources are not available to develop.

MRD Req #	Feature	Benefits	For	Driver	Rank
1	Billing solution enhancemens	Provides a unified billing solution	All	Customer Requirement	C
3	…	…	…	…	…
4	…	…	…	…	…
16	Admin GUI enhancemens	Better Userexperience by grouping config parameters in a more logical fashion	All	Customer Requirement	H

If no MRD is avaiable for the project then Product Feature Usecases should be provided in this section along with the business justification behind each product feature.

<Major Feature or Component Name>

Each major Feature or Component is given a separate section. Standard subsections under each major Feature or Component are Feature Overview and Detailed Feature Requirements.

Details should be provided on all system features and interfaces that are being built or modified. A system block diagram describing expected architecture should be supplied if appropriate. Each important feature requirement must be provided in enough detail to provide delivery teams with an unambiguous description of what is desired and allow engineering to produce functional specifications. This should include tuneable parameters, user interface descriptions, extensible feature sets and any other characteristics that Product Management feels are important to the success of the project.

Each requirement provided must be prioritised and identified with a unique requirement number in the section heading that introduces the feature description. These numbers will be used in the project functional specifications and test plans to refer back to original requirements.

Overview (for each major feature or component)

Format example. If table format does not apply, supply whatever format appropriate

Feature (Name and/or ID number)	Feature Description	Supported Interfaces
12345	This feature will knock your socks off. It will cook your lunch, make dinner reservations, arrange your junk drawer, walk your dog, and rearrange your furniture.
12345	This feature will be the coolest thing you ever saw.

Requirements (for each major feature or component)

(Format example. Create one of these tables for each requirement )

<unique Req#>	<feature name>
<unique requirement>
Dev Lead:	John Doe	Priority:	High	Status:	Still thinking about it
Dev LOE:	Rec’d 1/1/02	QA LOE:	Not Rec’d	Doc LOE:	Rec’d 1/1/02

Example(s) of Target Product Usage (for each major feature or component)

Describe how the product will be used by our customers and by the end user. Provide an example for each usage scenario anticipated.

<Text>

Dependencies and Linkages

Internal Dependencies on Other Products

Describe products and/or components that this product depends on. Identify expected deliverables and owners if applicable. It is recommended that this information be presented in a table format as shown below:

Level of Dependancy	Dept	Owner	Milestone
PM	PM responsible	PRD Signoff
Dev	DEV responsible	Design and Implementation, Unit Test, Handover to QA
QA	QA responsible	QA certification of all new Functionality, Execute Load and Stability Tests
SIT	SIT responsible	SIT to verify that new product works with other related Feature Creep Products
FE	FE responsible	FE carries out FOA testing at customer network
PAC	PAC responsible	PAC to certify new product’s performance and capacity
RE	RE responsible	RE complete packaging. Make release available on ftp and CDs

Each dependancy should have an associated level, based on the following values:

C - Critical

H - High Priority

M - Medium

L - Low

Other Internal Products Dependent on Product

Describe products and/or components that depend on this product. Identify deliverables and dates that are expected from this product. The information should be presented in the same table format under the previous heading.

Interoperability and Compatibility Requirements

The product's external dependencies need to be listed here for the knowledge of the product team. E.g., indicate the need for the product to interoperate with other Feature Creep products, and whether it may be installed on the same server as other products. Also the versions of each of these components/products you expect to ship your GA version with should be noted.

<Text>

Gateway Compatibility

If the product interoperates with gateway or proxies, enumerate gateway products and releases that this product is expected to work with. Identify, required optional components, if any

<Text>

Browser Compatibility

If the product interoperates with browsers, enumerate browser products and releases that this product is expected to work with. Identify, required optional components/features, if any

<Text>

Handset Compatibility

If the product interoperates with handsets, enumerate all handsets that this product is expected to work with. Identify, required optional components/features, if any

<Text>

Protocol Compatibility

Enumerate external interface protocols respective revisions the product is required to support

<Text>

API Compatibility

If the product provides Application Programming Interface (API), enumerate earlier versions of the API that the product (and its newer API) is required to maintain (backward) compatibility with

<Text>

Logging Compatibility

If the product provides event logs for billing or network management, enumerate earlier versions of the log formats that the product (and its newer log format) is required to maintain (backward) compatibility with

<Text>

Packaging Requirements (bundling with associated products)

Describe the list of Feature Creep and non-Feature Creep products and components the product is expected to ship with. Enumerate different product packaging options, if any

<Text>

Internal Linkages to Other Products (distinct from dependencies)

Linkages are a strategic consideration - please indicate what benefit is gained by this product's linkage to another product

<Text>

Internationalization & Localization

List all Internationalization and localization requirements here:

Considerations:

What languages to support, prioritized list of languages.

When you want the localized versions to ship.

Specific unique I18N requirements must be listed . (See example below)

Specific unique L10N requirements must be listed . (See example below)

<Text>

Internationalization (I18N)

The following is an example.

The product must be 'I18N-aware'. This means that special care must be taken when processing "user data".

"User data" is any data that may be entered by or displayed to an end user. This includes, but is not limited to, message contents and any user-visible <Text> stored in the directory.

Any "user data" the product accepts from an external source must be treated as potentially containing multi-byte characters. A 'character' may be 8-bit encoded, and/or a single 'character' may occupy more than one octet of storage.

Characters and <Text> containing "user data" should be operated upon programmatically and displayed only by using appropriate 'I18N-aware' classes and routines, including collation (sorting and searching) and other types of operations on <Text>.

HTML and other fixed user-visible <Text> must be placed in template and/or resource files, not embedded in code. Variable <Text> must be prepared and displayed using 'I18N-aware' classes and routines.

INTL005	Web page layout directives must be 188N-aware. For example, the product must be able to display text either left- or right justified.
INTL006	The product must pass the 188N Review, which includes linguistic content, functionality, architecture and packaging.

Localization (L10N)

The following is an example.

If/when the product is to be localized and supported by Feature Creep then an automated test suite for each language supported must be created and kept current. A localization done and supported by a local partner need not meet this requirement.

Installation/Upgrade and Migration

Provide a complete list of supported upgrade and migration paths and detailed expectations for scope, complexity and performance of the processes. Describe whether the upgrade/migrations require are to be done by Feature Creep PS, partners, or site administrators. If there are order dependencies to the upgrade or migration process, these must be clearly defined.

Only describe the upgrade requirements as they impact this component release.

If this is a release that is expected to be upgraded to, then list here the requirements for upgrade and/or migration from previous releases of the product. List the supported upgrades on the various platforms. You may need to consider upgrades from previous versions of individual components to current versions. This requires discussion with each component's product group.

<Text>

Installation Requirements

Describe installation requirements, target audience (does this install require PS or can it be done by site admin, etc). If there are administrative requirements such as maintenance windows, disruption of live service, etc. these must be listed in detail.

List delivery media types required for the installation package.

<Text>

Upgrade Requirements

List upgrade paths that will be supported by the planned release of the product from earlier versions. Explicitly state the upgrade paths that are not supported. Specify, if any, intermediate upgrades that are required in order to upgrade to the planned release.

Release	Supported Upgrades	Platforms
MM 1.0	MN 5.1, 5.1.1, 5.1.2	Sun, HP

Migration Requirements

List migration paths that will be supported by the planned release of the product from other discontinued products and from competing products

Release	Supported Migration Platforms	Platforms
MM 1.0	GX 5.0	Sun, HP

The following list shows the order in which components need to be migrated. Modify this list as needed or delete it if the information is not applicable or available.

Order of Component Cutover from 4.1.3 to 5.1

XXX

YYY

ZZZ

Platform Requirements

PRDs for more new and emerging products should generally be a lot more detailed than those being written for more mature products which have had these requirements specified in previous PRDs.

Platforms to be Supported

Provide a complete list of platforms supported, along with OS version numbers and patch levels. Indicate the version(s) of Solaris, Oracle, and other supporting systems the product is intended to work with. If there are any specific hardware requirements relating to platform configuration the these should be listed in detail.

<Text>

Third Party Requirements

List any third party products to be included in the product, and any requirement for integration with external products and services. Include third party software requirements, with specific version numbers for all third party software required for this product.

<Text>

Hardware Requirements

Describe reference hardware configurations that the product shall be tested and certified on. Specify recommended for deployment configurations, if any

<Text>

OAM&P

Manageability Requirements

Specify requirements related to manageability and monitoring of the product. Specify any new SNMP requirements, error logging requirements, any other manageability requirements, for better manageability of the planned release. Include specifics of logging requirements under Billing/Event Logging below.

<Text>

Billing/Event Logging Requirements

Log Content

Specify types of events and supporting data for each event that is required to be logged by the product. Logged events must add significant value in enhancing, billing, monitoring, trouble shooting or managing the product.

<Text>

(Format example)

Minimum Required Events Logged

Event	Associated Data	Description

Reporting

Specify reports that the product is required to support such as, administration, usage, billing, etc. Specify customization requirements, content of the report and method of generation (manual, prescheduled, etc.)

<Text>

Monitoring Requirements

Specify monitoring tools, protocols (e.g. SNMP), interfaces that shall be supported by the product

Monitoring Events

Specify types of events that product is expected to generate in order to monitor the health and performance of the product and method of delivering the event to the monitoring tools

<Text>

Event Documentation

Specify information that needs be documented for monitoring and logging events. Such documentation is targeted to better assist our customers to trouble shoot and/or better manage the product

<Text>

Administration/Configuration

Specify requirements for administration capabilities, administration interfaces and configurable parameters

<Text>

Maintenance Requirements

Specify installability, upgradability and configuration requirements for the planned release. Specify upgrade paths that must be supported and tested, configuration parameters that must be configurable, any backout procedure requirements, any other maintenance requirements.

<Text>

Provisioning Requirements

Specify method of provisioning the subscribers/users in the product. Highlight, any additional subscriber attributes that needs to be provisioned for the planned release

<Text>

License Administration

Describe the licensing to be used with the product, and any requirements for the product to actively support the licensing policy.

<Text>

System Wide Requirements

Impacts and functional details of System Wide Requirements are described in the Functional Specification. Indicate all high level requirements here.

<Text>

Availability

Availability is the characteristic of the system to remain in service with little or no disruption even in the event of a cataclysmic failure of hardware and/or software components. Specify availability requirements for the product.

<Text>

Reliability

Reliability is the characteristic of the system to maintain stated service levels, without errors, through a variety of service environments and load conditions. It also allows for monitoring and problem detection. Indicate required reliability for product.

<Text>

Recoverability

Recoverability allows the system to resume functioning, with minimal disruption, in the event of failure of one or more components. Recoverability is a measure of how robust the system is. Indicate required reliability for product.

<Text>

Performance

Indicate overall performance requirements in terms that are appropriate to PRD presentation, if any. A starting point might be an assessment of the number of seconds of lag time permissible between user input and resultant output from the system.

<Text>

Scalability

Scalability is the capacity of the system to handle higher and higher load levels in a seamless and easy to manage way. Indicate the level of scalability required of this product.

<Text>

Product Encryption Export Requirements

Have product encryption export requirements been assessed? (Y/N)

Has an analysis of the product’s encryption and security features been implemented? (Y/N)

If so, has this analysis been filed with legal counsel for processing? (Y/N)

Add more details below:

<Text>

Testing Requirements

Product and End-to-End IVV&T

Product IVV&T

The Product IVV&T tests for the project must thoroughly exercise each new feature/requirement described in this document. In the Product IVV&T Software Development Plan there must be a description of how the Product IVV&T tests prove each of the requirements have been met..

<Text>

End-to-End IVV&T

All requirements for End to End IVV&T, including FOA should be specified here. Describe end-to-end hardware and software test configurations and test scenarios that must be verified during E2E testing of the planned release. E2E testing strategies will be described in the FOA Statement of Work.

Web Browsers

List the browser versions that need to be tested.

Windows 2000	Windows NT 4.0	Windows ME	Windows XP
IE 4.0	Detailed	Detailed	Acceptance	Acceptance
IE 5.0	Detailed	Detailed	Acceptance	Acceptance
Netscape 4.7	Detailed	Detailed	Acceptance	Acceptance
Netscape 6.0	Detailed	Detailed	Acceptance	Acceptance

Handset support

List the handsets that need to be tested and level of testing

<Text>

Handset	Browser Version	Network
Motorola P7389	4.1.16	GSM
Nokia 7110	2.0	GSM
Samsung SCH8500	3.1	CDMA

Conformance Testing

Specify conformance testing and certification requirements

<Text>

Performance, Capacity and Scalability Testing

The PAC tests should be described in terms of the target customer sites and how the product will be used on the site. The usage profile and performance parameters must be adapted for each project. Common methods of characterizing performance on a messaging site are:

User population size

Busy hour percentage

Messages per day

Message size

Customer access line speed(s)

Bandwidth constraints

Database constraints

Results of PAC testing must result in test reports usable by sales and PS during customer engagements.

The following <Text> is boilerplate and usable in many instances:

PAC testing for this project must be completed before product release. PAC must provide a written test plan detailing how the testing will be accomplished, and a written test result. The test results will be reviewed by product management and will then be made available to the sales team by placing it on the PAC website.

The user population and usage profile for the PAC testing are:

Target user population	25 Million
Percentage online during busy hour	20
messages per day received:	7
messages per day sent:	3
average message size (KB)	25
logins per day	3
Notifications per day	2
client-server connection	modem

Description of usage scenario:

Blah blah

PAC must publish a performance report that documents the performance and scalability of this release of the product. The tests run, results observed and methods for applying the results to planning and scalability of customer sites must be included. Any special considerations for system tuning such as references to special HA or disk configuration must be included. If the testing is in conformance with any industry standards such as SPEC, results must be reported using standard measures and documentation techniques.

Intended audience. This report will be posted on the PAC website and made available to customers under NDA.

A hardware sizing spreadsheet must be supplied that enables correct estimation of hardware requirements for installations of various sizes. (supply details of requirements as appropriate)

Documentation

Product documentation will cover the areas listed below. Details can be found in the documentation plan at insert link here.

The following is an example:

Overview of the architecture

Installation instructions

Advice about distributing or co-locating various pieces

Estimates as to the load each component is expected to bear

The actual installation procedure (step by step)

Configuration options

Basic guidelines for hooking into provisioning and billing

Template customization overview for creating target device experiences

Basic operations

Basic message flow

Activating accounts

Allowing access and denying access (if security controls exist)

Monitoring servers and troubleshooting

Reference material

Details on all configuration keys, admin commands, COS values, log events, and error messages

Customization

Guidelines on using the messaging formatting language and localizing resource files

Other Requirements

Continuing Engineering

Include transition criteria, including timeframe.

For products that have never been transitioned into CE, a CE Transition plan must be drafted and approved by TPM and CE.

For products that have already been transitioned into CE, the usual timeframe for transitioning the new version into CE occurs after this product has been put into a "live" production environment in at least one or more customers' sites and the first patch against this release has been generated and released.

<Text>

De-Support/End Of Life

With the release of this new software package, the "de-support" date of the previous release is determined. The de-support date of the predecessor is determined based on the version number of this new software release.

"Major Releases" means a release of the Licensed Software that is made generally available by Feature Creep, if any, and is designated by a change in the number to the left of the decimal point of the version number of the Licensed Software (e.g. from 1.0 to 2.0). Feature Creep will support Major Releases for a period of one (1) year after the date that Feature Creep makes the next Major Release generally available;

"Minor Release" means a release of the Licensed Software that is made generally available by Feature Creep, if any, and is designated by a change in the number to the right of the first decimal point of the version number of the Licensed Software (e.g. from 1.2 to 1.3). Feature Creep will support Minor Releases for the shorter of: (i) six (6) months after the date that Feature Creep makes the next Minor Release generally available; or (ii) twelve (12) months after Feature Creep makes the next Major Release generally available;

"Patch Release" means an Error Correction that Feature Creep makes generally available to its customers that is designated by Feature Creep by a change: (a) to the right of the second decimal point of the version number of the Licensed Software (e.g. from 1.2.3 to 1.2.4); or (b) to the right of the third decimal point of the version number of the Licensed Software (e.g. from 1.2.3.4 to 1.2.3.5). Feature Creep will support Patch Releases for the shorter of: (i) three (3) months after the date that Feature Creep makes the next Patch Release generally available; or (ii) six (6) months after Feature Creep makes the next Minor Release generally available; or (iii) twelve (12) months after Feature Creep makes the next Major Release generally available.

End of Life. Feature Creep may discontinue Support Services for a Licensed Software product upon at least twelve (12) months prior written notice to Licensee. Such notice may be satisfied by Feature Creep sending an email link to a website posting.

When this software package is released, a de-support notice on its predecessor should made to the field by Product Management.

<Text>

Budgetary Considerations

Include any special budgetary considerations that may be required with this release. These may include: third party development needs, outsourced localization, outsourced handset testing, required purchase of third party software to be used or included in this package.

<Text>

Training

Include any training requirements or issues in this section.

<Text>

Appendixes

Place critical supporting documentation and figures here.