To select a set of use cases or scenarios to be considered during the iteration.
To select a set of non-functional requirements which must be handled during the iteration.
Guidelines: Iteration Plan
The scope of an iteration is driven by four factors:
the top risks to the project
the functionality required of the system
the time allocated to the iteration in the Project Plan
the phase and its specific objectives (See Concept: Phase)
In the initial planning of an iteration, enough work is selected to fill the time already planned for the iteration -
although the Project Manager is permitted some latitude to account for resource constraints and other tactical
considerations at the time the Iteration Plan is being developed. Obviously, work planned for the previous iteration,
but not completed (because the previous iteration's scope was reduced to meet the schedule) will normally have high
The scope of work has also to be driven by a sensible approach to the maximum staffing level that can be applied, in
the duration of the iteration, for its completion. For example, it is not usually possible to double the work completed
in an iteration by doubling the staff applied to it - even if those resources were available. The approximate staff
numbers that can be efficiently applied are determined by overall software size and architecture, and estimation models
such as COCOMO II (see [BOE00]) can provide these.
The execution of an iteration is then managed by timeboxing -
that is, the scope and quality (in terms of discovered defects not rectified) are actively managed to meet the end
There are three main drivers for defining the objectives of an iteration in elaboration:
The main driver to define iteration objectives are risks. You need to mitigate or retire your risks as early as
you can. This is mostly the case in the elaboration phase, where most of your risks should be mitigated, but this can
continue to be a key elements in construction as some risks remain high, or new risks are discovered. But since the
goal of the elaboration phase is to baseline an architecture, some other considerations have to come into play, such as
making sure that the architecture addresses all aspects of the software to be developed (coverage). This is
important since the architecture will be used for further planning: organization of the team, estimation of code to be
Finally, while focusing on risks is important, one should keep in mind what are the primary missions of the system;
solving all the hard issues is good, but this must not be done in detriment of the core functionality: make sure that
the critical functions or services of the system are indeed covered (criticality), even if there is no perceived
risk associated with them.
From the Risk list, for the most damaging risks, identify some scenario in some use case that would force the
development team to "confront" the risk.
if there is an integration risk such as "database D working properly with OS Y", make sure you include one
scenario that involves some database interaction even very modest.
if there is a performance risk such as "time to compute the trajectory of the aircraft", make sure you have one
scenario that includes this computation, at least for the most obvious and frequent case.
For criticality, make sure that the most fundamental function or services provided by the system are included.
Select some scenario out of the use case that represent the most common, the most frequent form of the service or
feature offered by the system. The Software Architecture Document is used to drive this effort,
providing a prioritized set of Use Cases or sub-flows of use cases, selected by the Software Architect to reflect the architecturally significant use cases or scenarios.
for a telephone switch, the plain station-to-station call is the obvious must for an early iteration. This is
far more important to get right than convoluted failure modes in operator configuration of the error handling
For coverage, towards the end of the end of the elaboration phase, include scenarios that touches areas that you
know will require development, although they are neither critical nor risky.
It is often economical to create long, end-to-end scenarios that address multiple issues at once.
The danger is often to get the scenarios to be too "thick", i.e., trying to cover too many different aspects, and
variants, and error cases (See Iteration Plan)
Also, in the elaboration phase, keep in mind that some of the risks may be of a more human or programmatic nature: team
culture, training, selection of tools, new techniques etc. and just going through iteration is mitigating these risks.
Create one subscriber record on a client workstation, to be stored in the database on the server, including
user dialog, but not including all field, and assuming no error is detected.
Combines some critical function, with some integration risks (database and communication software) and
integration issues (dealing with 2 different platforms). Also force designers to become familiar with new GUI
design tool. Finally produces a prototype that can be demonstrated to user for feedback.
Make sure up to 20,000 subscribers can be created, and access to one is not longer than 200
Addresses some key performance issues (volume or data, and response time), that may dramatically affect
the architecture if not met.
Undo a change of subscriber address.
A simple feature that forces designers to think about a design of all "undo" functions. This may in turn
trigger some push-back to the users about what can be undone at reasonable cost.
Complete all the use cases relative to supply-chain management.
The goal of the elaboration phase is also to complete the capture of requirements, maybe also set by set.
As the project moves into the construction phase, risks remain a key driver, especially as new, unsuspected risks are
uncovered. But completeness of use case start to be a driver. The iterations can be planned feature by feature, trying
to complete some of the most critical ones early so that they can be thoroughly tested during more than one iteration.
Towards the end of construction, robustness of full use cases will be the main goal.
Implement all variants of call forwarding, including erroneous ones.
This is a set of related features. One of them may have been implemented during the elaboration phase, and
will serve as a prototype for the rest of the development.
Complete all telephone operator features except night service.
Another set of features.
Achieve 5,000 transactions per hour on a 2 computer set-up.
This may step up the required performance relative to what was actually achieved in the previous iteration
Integrate new version of Geographical Information System.
This may be a modest architectural change, necessitated by some problem discovered earlier.
Fix all level 1 and level 2 defects
Fixes defects discovered during testing in the previous iteration and not fixed immediately but
Finishing this generation of the product is the main goal. Objective for an iteration are set in terms of which bugs
are fixed, which improvements in performance or usability are included. If features had to be dropped (or disabled) in
order to get in time to the end of construction (IOC milestone, or "beta"), they may now be completed, or turned on, if
they do not jeopardize what has been achieved so far.
Fix all severity 1 problems discovered on beta customer sites.
A goal in term of quality, may be related to credibility on the market.
Eliminate all startup crashes due to mismatched data.
Another goal expressed in terms of quality.
Achieve 2,000 transactions per minute.
Performance tuning, involving some optimization: data structure change, caching and smarter algorithm.
Reduce the number of different dialog boxes by 30%.
Improve usability by reducing the visual clutter
Produce German and Japanese versions.
The beta was produced only for English customers by lack of time and to reduce rework.