Feature Requirements Template



Feature Requirements Document

Feature Name

[Document purpose: The feature requirements document provides a detailed description of a specific feature within a release based on customer needs. A separate feature requirements document should be written for every feature listed in the release requirements document. The feature requirements document should draw heavily on information contained in the release requirements document. The feature requirements document should include

1)

2)

Enter your name here

[The author is typically the Product Manager]

0.1

[The revisions start at 0.1 with 1.0 being the first approved version]

Enter date here

Table of contents

1 Introduction 3

2 Feature requirements 4

2.1 “Must have” requirements 4

2.2 “Should have” requirements 4

2.3 “Could have” requirements 4

3 User scenarios 5

3.1 User 1 5

3.2 User 2 5

4 Prototype example or storyboard picture 6

5 Other feature-specific requirements 7

5.1 Platform requirements 7

5.2 Usability requirements 7

6 Schedule 8

7 Dependencies 8

8 Risks and issues 8

Introduction

[Use the Introduction to give the reader an overview of the document.

•

•

•

•

[Classify your feature requirements into “must have”, “should have” and “could have” requirements. This will make it much easier to decide on functionality if the feature set needs to be reduced due to shortage of resources or time.

1

[Describe requirements that you “must have” for this feature in this release. You are signaling that the release cannot ship without them and that the feature will be delayed to allow time for completion of these features. Use general descriptions for each requirement; the functional specification will allow for detail.]

2

[Describe requirements that you “should have” for this feature in this release. By classifying these requirements as “should have”, you are signaling that the feature would be hurt without them, but you would probably not hold up shipment for these requirements. Use general descriptions for each requirement; the functional specification will allow for detail.]

3

[Describe requirements that you “could have” for this feature in this release. By classifying these requirements as “could have”, you are signaling that the success of the feature would not be significantly hurt without them. The release will not be delayed to allow time for the completion of these requirements. Use general descriptions for each requirement; the functional specification will allow for detail.]

[This section provides the product team with an idea of how the feature will be used by customers.]

1

[Use the scenarios to illustrate to the reader how the feature functionality will be used. Use the personas to make your examples more real. Describe as many situations as possible. In addition to describing what happens when everything works perfectly, describe what happens when common problems occur. Be general in your descriptions. Step-by-step detail will be outlined in the detail specification.]

2

Prototype example or storyboard picture

[Add a picture(s) from the prototype or a storyboard(s) to show which user interface(s) will be required to enable the user scenarios above. Describe how the UI will work.

▪

▪

▪

▪

[Include any other requirements that are specific to this feature. If the requirement has been stated in the release requirements document, do not duplicate it here. Other requirements could include:

•

•

•

•

•

•

•

•

•

1

[Describe any platform requirements specific to this feature.]

2

[Describe any usability requirements specific to this feature. This section may not apply to this feature.]

[Provide a schedule that contains major feature activities, including dates when the activities will finish. This schedule will be preliminary. The schedule contained in the MRD can be used as a starting point. Refer the reader to the Release Schedule for more detail.]

[Describe how this feature depends on other features contained in the release.]

[List any risks or issues surrounding the feature requirements, including:

•

•

•

General style guidelines

Audience and purpose

A feature requirements document is written for the product team, specifically for the engineers that are going to develop the feature described in the document. A feature requirements document does the following:

• Provides a general description of each capability of a specific feature to be developed for a release.

• Gives examples of how the feature will be used by customers.

The feature requirements document will become a primary reference for creation of the functional specification. Approval of this document signals the beginning of the Functional Specification.

Tone, approach, and writing style

Be as straightforward as possible, clarifying points and highlighting uncertainties where necessary. This document is for use by your product team, so no need to use marketing language or a persuasive tone.

Length

Length can vary, depending on the

• Complexity of the feature

• Number of possible scenarios using the feature

Much of the feature detail will be described in the functional specification. Use the feature requirements document to give the reader a broad understanding of each feature requirement and user scenario. Short paragraphs are preferred.

Maintenance

As feature requirements are modified, be sure to update this document so that it can be a reference for future engineering specifications.

Feature Requirements Document checklists

Introduction

❑ Provide an overview of the feature described in this feature requirements document.

❑ Give a brief reminder of the target customer.

❑ Describe any limitations of the feature.

❑ Briefly outline the purpose of the document.

Feature requirements

❑ Describe each feature requirement at a summary level.

❑ Classify each requirement into “must have”, “should have” and “could have” buckets.

User scenarios

❑ Using your personas, illustrate how the functionality described in this document will be used.

❑ Describe as many different scenarios as possible.

❑ Be general in your descriptions.

Other feature-specific requirements

❑ Include other requirements that are specific to this feature.

❑ Do not repeat a requirement listed in the release requirements document.

Schedule

❑ Include a table that contains major feature activities and estimated completion dates.

Dependencies

❑ Alert the reader to any dependence between this feature and the other features in the release.

Risks and issues

❑ Specify any issues surrounding this feature.

-----------------------

Revision history

|Revision |Author |Reason for Revision |Date |

|0.1 | |Initial document | |

Approvals

|Approvers |Comments |Date |

|TBD | | |

|TBD | | |

|TBD | | |

| | | |

| | | |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download