Workflow Detail: Manage
the Scope of the System
|
The purpose of this workflow detail is to make the scope of the system being developed as explicit as possible, and focus on a manageable body of requirements work for the iteration. |
|
|
|
Description
This workflow detail addresses:
- Prioritizing and refining the input to the selection of features and requirements that are to be included in the current iteration.
- Defining the set of behavioral scenarios, for one or more use cases, that represent some significant central functionality.
- Defining how traceability will be maintained, including which requirement attributes and traceability relationships to maintain.
The scope of a project is defined by the set of requirements allocated to it. Managing project scope to fit the available resources (time, people, and money) is key to managing successful projects. Managing scope is a continuous activity that requires iterative or incremental development, which breaks project scope into smaller more manageable pieces.
Use requirement attributes, such as priority, effort, and risk, as the basis for negotiating the inclusion of a requirement is a particularly useful technique for managing scope. Focusing on the attributes rather than the requirements themselves helps desensitize negotiations that are otherwise contentious.
It is also helpful for team leaders to be trained in negotiation skills and for the project to have a champion in the organization, as well as on the customer side. Product/project champions should have the organizational power to refuse scope changes beyond the available resources or to expand resources to accommodate additional scope.
Project scope should be managed continuously throughout the project. A
better understanding of system functionality can be formulated at the point
that most actors and use cases (e.g. 80%) have been identified and outlined.
Non-functional requirements, which either do not fit in the use-case model or
are general across multiple use cases, should be documented in the supplementary
specifications. The System Analyst
role is responsible for determining values of priority, effort, cost, risk values
etc., from the appropriate stakeholders,
which are collected in the repository of requirements attributes.
These will be used by staff in the Project
Manager role when planning each iteration
and
will enable staff in the Software Architect
role to identify the architecturally significant scenario's or complete use
cases, which will help define the use-case view of the architecture.
(See also: stakeholders, non-functional
requirements,
architecture, use-case
view,
requirements attributes,
use cases, actors,
supplementary specifications and architecturally
significant use cases).
Related Information
This section provides links to additional information related to this workflow detail.
Timing
This work is normally addressed from part-way into until the end of each iteration.
Optionality
Should be performed in each iteration where the requirements will be further refined.
How to Staff
The people involved in this workflow detail should all be members of the architecture team.
Work Guidelines
The architecture team will facilitate a session for various team members to discuss how to best prioritize the requirements.
See the Related Information section for additional guidance that will help you in performing this work.
