Arranging Requirements into a Product Plan
After you analyze your customer requirements sufficiently to understand what the product should do, you must work out a plan to implement the product. Or, for an existing product, you must work out what functionality is missing and work out a plan for making the changes. But the requirements do not automatically tell you the plan.
This topic outlines a method of obtaining a plan, starting from a set of requirements. This is just one method among a variety that will work on Visual Studio, and you should adapt it so that it suits your needs.
In this topic
Requirements and Features
Scenario Decomposition
Assign Leaf Scenarios to Iterations
Features - Requirements Fulfilled in each Iteration
Quality of Service Features
Product Planning
Iteration Planning
Requirements and Features
There are two kinds of requirement in this method: customer requirements and features. Customer requirements are what you get by analyzing what the customer wants from the product. Features are items in the product plan, which correspond to small subsets of the customer requirements. Each feature may include pieces of the customer requirements that come from different parts of the user experience and different functional areas.
Customer Requirements
Customer requirements are determined by discussion with the prospective users and other stakeholders.
To help analyze these requirements, you will typically create storyboards and models, and you decompose the scenarios into smaller steps, forming a tree. You can link modeling elements such as use cases and activities to scenario work items.
There are two kinds of customer requirement:
Scenarios, also known as use cases, represent sequences of interactions between the users and product, in pursuit of specific goals. An example scenario might have the title "User buys a book."
Quality of Service requirements include performance, security, usability, and other criteria.
You can represent these requirements as work items of type requirement, with the Requirement Type field set to Scenario or Quality of Service.
These requirement work items should be linked to system tests so that you can ensure that all the requirements are tested.
Use the Customer Requirement query to list these requirement work items.
Use the Requirements Progress report to monitor which requirements have been satisfied.
For more information, see Developing Requirements, Team Queries (CMMI), Requirements Progress Report (CMMI), and Creating a Test Plan Using Requirements or User Stories.
Features
A feature is an item in a product plan that represents a group of tasks. In product planning, representatives of the development team and stakeholders assign features to iterations. For more information, see Planning the Project (CMMI).
Enter features as requirement work items with the Requirements Type field set to Feature.
The feature's title states, in users' terms, what the users will be able to do with the product, that they could not do in previous iterations. There are no items, or very few items, on the plan that do not deliver new user value.
For example, this sequence of features could form an implementation plan:
"A buyer can pick a book from a list and add it to a wish list."
"The book list displays prices. In the wish list, the total price is displayed."
"Vendors can attach tags to books. Buyers can filter the book list by tag."
Notice that no feature touches just one step in the user experience, and no feature involves just one part of the product architecture. Instead, as the features are implemented, several functions are revisited and augmented with new user value.
A feature is assigned to an iteration during product planning. All the tasks under a feature must be assigned to the same iteration. For more information, see Planning the Project (CMMI).
A feature describes a partial realization of the customer requirements. It is a subset of the customer requirements, and it might implement each customer requirement to a limited extent.
Every feature can be linked to one or more test cases that test the part of the requirements that the feature represents. These test cases are a subset of the system tests that are linked to the customer requirements.
The feature's state must not be marked complete until its tests are fully defined and pass.
Every feature is a group of development and test tasks. It is the root of a tree of tasks in Visual Studio Team Foundation Server. The development tasks implement the partial requirements that the feature describes. The test tasks design and execute the appropriate test cases.
You use the Product Requirements query to list features. To display the product plan, you click Column Options and add Iteration Path to the list of displayed columns. To sort by iteration, you click the Iteration Path column. For more information, see Team Queries (CMMI).
Finding features
Separating requirements into incremental features is a creative task that must involve developers, analysts, and stakeholders. A feature defines a piece of the product's functionality that can sensibly be implemented separately from the surrounding functions. Therefore, a workable set of feature definitions and an ordering into a plan depends partly on the architecture of the system.
For this reason, planning and the initial design of the product must work in parallel, particularly in Iteration 0 where the bulk of the plan is being sketched.
Scenario Decomposition
To help you arrange the requirements into features, it helps to decompose the scenarios into smaller steps.
Storyboards often help with this activity. A storyboard is a sequence of pictures that illustrate the scenario. UML activity diagrams are useful for showing alternative paths, and UML sequence diagrams can help you discuss interactions between several actors. After you use these tools to analyze a scenario, you can enter the decomposed scenarios into Team Explorer. This lets you link test cases to the scenarios and thereby ensure that the requirements have been satisfied. For more information, see UML Activity Diagrams: Guidelines and UML Sequence Diagrams: Guidelines.
In this short walkthrough, you enter a set of customer requirements in the form of a small tree of scenarios. This will provide an example from which to create features.
To open the customer requirements tree in Excel
In Team Explorer, open a MSF for CMMI Process Integration v5.0 project.
Expand Work Items, expand Team Queries, expand Planning and Tracking, and run Customer Requirements.
If the Iteration Path and Requirements Type columns do not appear, click Column Options, and add them to the display list.
You might also want to add the Area Path column.
Set the query to show a tree.
Click Edit Query.
Set Type of Query to Tree of Work Items.
Click Save Query.
If you cannot save the query in Team Queries, save it in My Queries.
Click View Results to close the editing view.
Click Open in Microsoft Office, and then click Open Query in Microsoft Excel.
In Office Excel, if the column headed Title 1 is not followed by columns that are headed Title 2 and Title 3, click the Team tab, and then click Add Tree Level to create the additional columns.
You can now conveniently enter the scenarios as a batch.
In a real situation, you might start by entering one level of scenarios and then decomposing each scenario to smaller steps in separate operations.
To enter the scenarios
In the row immediately after the bottom row of existing work items (if any), enter the title of the top-level scenario in the Title 1 column:
Customer orders a meal.
In discussion with the business stakeholders, you determine the principal steps that make up the top-level scenario.
In the rows that immediately follow the top-level scenario, enter the steps in the Title 2 column:
Customer chooses a restaurant.
Customer chooses items from the restaurant's menu, to create an order.
Customer enters payment details.
Restaurant prepares and delivers order.
Customer's card is charged with the payment.
Further analysis, perhaps using UML activity diagrams or interaction diagrams, yields more detailed steps for some of these scenarios.
Immediately under Customer chooses a restaurant, insert some rows, and enter these steps in the Title 3 column:
Customer enters the delivery postal code.
Web site displays a list of restaurants that deliver to that address.
Customer can browse menus of all displayed restaurants.
Customer selects one restaurant to start an order.
Delete any blank rows.
In the Work Item Type column of all the new rows, set the type to Requirement.
Set the Requirements Type column of all the new rows to Scenario.
To publish the requirements to Team Foundation Server, select any cell in the table of work items, and then click Publish on the Team tab.
You now have a tree of customer requirements, which you can edit further in Office Excel or Team Explorer.
Assign Leaf Scenarios to Iterations
The "leaf" scenarios are those that have no children of their own.
Assign the most basic steps in the scenarios to iterations by setting the iteration path field. You can do this in the Office Excel view.
Then assign each scenario that has children to the earliest iteration in which it can be considered usable.
In the following example, the most essential scenarios are implemented in iterations 1 and 2, and other functions are added in later iterations.
Iteration 2 - Customer chooses a restaurant.
Iteration 5 - Customer enters the postal code.
Iteration 2 - DinnerNow displays a list of restaurants.
Iteration 3 - Customer can browse menu of each restaurant.
Iteration 2 - Customer selects one restaurant to create an order.
Iteration 1 - Customer chooses items from the menu, to create an order.
Iteration 1 - Customer clicks menu item to add to order.
Iteration 2 - Order summary displays total price of order.
Iteration 1 - Customer clicks "Confirm" to complete the order.
Iteration 4 - Customer enters payment details.
Iteration 2 - Restaurant prepares and delivers the order.
Iteration 4 - Customer's card is charged with the payment.
These assignments let you exercise the overall design of the system at an early stage but leave many details until later. Some aspects that are considered low risk can be left to later iterations. In this example, the team has had previous experience of linking to a card payment system. Therefore, it feels confident to leave that part to a later iteration.
In some cases, you will want to decompose the leaf scenarios further, to allow simplified and more complex versions to be separated into different iterations, as the following picture illustrates.
.png "Tree of scenario work items")
Features - Requirements Fulfilled in each Iteration
A feature is a requirement that summarizes what the users can do at the completion of each iteration. You can create more than one feature for each iteration. Enter them as requirement work items, setting the Requirement Type to Feature.
Use your assignments of scenarios to work items to help you define the features. The following example feature plan is derived from the assignments of scenarios to iterations in the previous section:
Iteration 1
- Customer chooses items from a menu, adds them to an order, and adds a delivery address.
Iteration 2
Customers start by displaying a list of restaurants and then choose one.
When the customer completes an order, the order appears on the chosen restaurant's screen.
The prices of items and the total price are displayed on the order.
Iteration 3
Restaurant marks the order as "Done" when the prepared meal has been dispatched. The meal is logged against the restaurant.
Each restaurant can enter and update its menu.
Customer can browse the menu of every restaurant before selecting one.
Iteration 4
Customer enters payment details on completing an order. Customer's card is charged when the restaurant marks the order as Done.
Restaurant is paid for orders that are marked as Done.
Iteration 5
- Restaurants can set their delivery area. Customer enters postal code at start of session. The Web site displays only restaurants that can deliver to the local area.
Partly implemented scenarios
Decomposing the scenarios into small steps helps you to separate some steps that can be implemented earlier from others that can be implemented later.
But sometimes you can separate out other aspects of the scenarios. In this example, the team might implement a basic version of the user experience in early iterations and then improve it later. So you might add the following feature:
- Iteration 6 - Restaurant can choose the color scheme and font of its menu and upload its own logo and pictures of meals.
This type of feature does not emerge directly from the decomposition into steps, but it usually emerges in discussion of storyboards. User experience features are good candidates for later iterations.
Entering and inspecting features
Create work items with work item type of requirement, and set the Requirement Type field to Feature. Set the feature title to the short description.
To enter the features in a batch and to discuss their assignment to iterations, adapt the Product Requirement query, and use an Office Excel view.
To enter and edit features
In Team Explorer, open an MSF for CMMI Process Improvement v5.0 project.
Expand Work Items, expand Team Queries, expand Planning and Tracking, and open Product Requirements.
Click Column Options, and add Original Estimate and Iteration Path to the list of displayed columns.
Click Open in Microsoft Office, and then click Open Query in Microsoft Excel.
In the dialog box that asks whether you want to save the query, click Yes.
(Optional) In Office Excel, enter the list of feature titles, set iteration paths, and order the rows by iteration path.
To save changes to Team Foundation Server, click any cell in the work item table, and then click Publish on the Team tab.
Tracing features to requirements
You can link features to requirements in the following ways:
Link feature work items to the leaf scenario requirements of their iterations. You must link them by using Related Item links because the leaf scenarios already have parents.
Link test case work items to the scenarios and quality of service requirements that they test. Link features to the subset of test cases that should pass when the feature has been developed. In this manner, the test cases act as the link between features and customer requirements.
Quality of Service Features
Quality of service requirements are usually pervasive with regard to the software design. For example, security requirements are generally not related to a particular development task.
Nevertheless, for each quality of service requirement, you should create a feature work item whose children are mainly testing tasks that ensure that a quality of service criterion is met. These work items are called quality of service features.
Some quality of service features can have development tasks. For example, in an early iteration, you might implement a version of the system that can handle only a few users, as a proof of concept. For a later iteration, you might add a feature that specifies the target capacity as stated in the customer requirements.
Product planning
Before the start of every iteration, hold a meeting to review the product plan. The first product planning meeting creates the plan, and subsequent meetings review it based on earlier iterations. For more information, see Planning the Project (CMMI).
In a product plan review, discuss the features with business stakeholders, and be prepared to reprioritize them and arrange them into different iterations. The meeting should include business stakeholders and representatives of the development team.
The meeting discusses the sequence in which features will be developed. This can be done by projecting or screen-sharing the Office Excel view of the Product Requirements query and ordering the features by iteration.
An alternative technique is to place the features in a specific sequence and then consider how much can be done in each iteration. For example, the developers might discuss whether "Customer can display the prices" should be moved from Iteration 2 to Iteration 3, without moving it in the sequence. To place the items in a sequence, add an extra column that is named Rank to the spreadsheet, and insert integers that denote the sequence. Order the spreadsheet by this column. The ranks will not be stored in Team Foundation Server, but you can save the spreadsheet. When you open the spreadsheet again, click any cell in the work item table, and then click Refresh on the Team tab.
Product planning considers the priorities of the features and the development costs. Priorities come from the business stakeholders, with some guidance about risk from the developers. Cost estimates come from the developers. To get an accurate idea of the costs, the development team must have already done some work on the architecture of the product and might need some experience from the early iterations. For this reason, the cost estimates should be refined at every product plan review.
Iteration planning
After the product plan review, plan the iteration. The product plan determines the features that will be delivered by the end of the iteration. The iteration plan determines what work the team will do to implement and test the features.
The following activities are part of iteration planning:
Create tasks for development and testing, and link them as children to the feature requirements.
Create test cases for the aspects of the customer requirements that are to be developed in each feature. The test cases should be linked to the customer requirements so that you can monitor how complete the requirements are.
You can also link test cases to the features so that you can track the correspondence between features and requirements. The feature should not be marked complete until the linked test cases pass.
For more information, see Planning an Iteration (CMMI).