|
Requirements Management
a key process area for level 2: Repeatable
The purpose of Requirements Management is to establish a common understanding
between the customer and the software project of the customer's requirements
that will be addressed by the software project.
Requirements Management involv fd4 es establishing and maintaining an
agreement with the customer on the requirements for the software project.
This agreement is referred to as the "system requirements allocated to
the software." The "customer" may be interpreted as the system engineering
group, the marketing group, another internal organization, or an external
customer. The agreement covers both the technical and nontechnical (e.g.,
delivery dates) requirements. The agreement forms the basis for estimating,
planning, performing, and tracking the software project's activities throughout
the software life cycle.
The allocation of the system requirements to software, hardware, and
other system components (e.g., humans) may be performed by a group external
to the software engineering group (e.g., the system engineering group),
and the software engineering group may have no direct control of this
allocation. Within the constraints of the project, the software engineering
group takes appropriate steps to ensure that the system requirements allocated
to software, which they are responsible for addressing, are documented
and controlled.
To achieve this control, the software engineering group reviews the
initial and revised system requirements allocated to software to resolve
issues before they are incorporated into the software project. Whenever
the system requirements allocated to software are changed, the affected
software plans, work products, and activities are adjusted to remain consistent
with the updated requirements.
Goals
Goal 1
System requirements allocated to software are controlled to establish a
baseline for software engineering and management use.
Goal 2
Software plans, products, and activities are kept consistent with the system
requirements allocated to software.
Commitment to perform
Commitment 1 -- The project follows a written organizational policy
for managing the system requirements allocated to software.
The system requirements allocated to the software are referred to as "allocated
requirements" in these practices.
The allocated requirements are the subset of the system requirements
that are to be implemented in the software components of the system. The
allocated requirements are a primary input to the software development
plan. Software requirements analysis elaborates and refines the allocated
requirements and results in software requirements which are documented.
This policy typically specifies that:
- The allocated requirements are documented.
- The allocated requirements are reviewed by:
- the software managers, and
- other affected groups.
Examples of affected groups include:
- system test,
- software engineering (including all subgroups, such as software
design),
- system engineering,
- software quality assurance,
- software configuration management, and
- documentation support.
- The software plans, work products, and activities are changed to
be consistent with changes to the allocated requirements.
Ability to perform
Ability 1 -- For each project, responsibility is established for analyzing
the system requirements and allocating them to hardware, software, and
other system components.
Analysis and allocation of the system requirements is not the responsibility
of the software engineering group, but is a prerequisite for their work.
This responsibility covers:
- Managing and documenting the system requirements and their allocation
throughout the project's life.
- Effecting changes to the system requirements and their allocation.
Ability 2 -- The allocated requirements are documented.
The allocated requirements include:
- The nontechnical requirements (i.e., the agreements, conditions,
and/or contractual terms) that affect and determine the activities of
th 19c e software project.
Examples of agreements, conditions, and contractual terms include:
- products to be delivered,
- delivery dates, and
- milestones.
- The technical requirements for the software.
Examples of technical requirements include:
- end user, operator, support, or integration functions;
- performance requirements; ff4
- design constraints;
- programming language; and
- interface requirements.
- The acceptance criteria that will be used to validate that the software
products satisfy the allocated requirements.
Ability 3 -- Adequate resources and funding are provided for managing
the allocated requirements.
- Individuals who have experience and expertise in the application
domain and in software engineering are assigned to manage the allocated
requirements.
- Tools to support the activities for managing requirements are made
available.
Examples of support tools include:
- spreadsheet programs,
- tools for configuration management,
- tools for traceability, and
- tools for test management.
Ability 4 -- Members of the software engineering group and other software-related
groups are trained to perform their requirements management activities.
Examples of training include:
- the methods, standards, and procedures used by the project, and
- the application domain.
Activities performed
Activity 1 -- The software engineering group reviews the allocated requirements
before they are incorporated into the software project.
- Incomplete and missing allocated requirements are identified.
- The allocated requirements are reviewed to determine whether they
are:
- feasible and appropriate to implement in software,
- clearly and properly stated,
- consistent with each other, and
- testable.
- Any allocated requirements identified as having potential problems
are reviewed with the group responsible for analyzing and allocating
system requirements, and necessary changes are made.
- Commitments resulting from the allocated requirements are negotiated
with the affected groups.
Examples of affected groups include:
- software engineering (including all subgroups, such as software
design),
- software estimating,
- system engineering,
- system test,
- software quality assurance,
- software configuration management,
- contract management, and
- documentation support.
Refer to Activity 6 of the Software Project Planning key process area
for practices covering negotiating commitments.
Activity 2 -- The software engineering group uses the allocated requirements
as the basis for software plans, work products, and activities.
The allocated requirements:
- Are managed and controlled.
"Managed and controlled" implies that the version of the work product
in use at a given time (past or present) is known (i.e., version control),
and changes are incorporated in a controlled manner (i.e., change control).
If a greater degree of formality than is implied by "managed and
controlled" is desired, the work product can be placed under the full
discipline of configuration management, as is described in the Software
Configuration Management key process area.
- Are the basis for the software development plan.
- Are the basis for developing the software requirements.
Activity 3 -- Changes to the allocated requirements are reviewed and
incorporated into the software project.
- The impact to existing commitments is assessed, and changes are negotiated
as appropriate.
- Changes to commitments made to individuals and groups external
to the organization are reviewed with senior management.
Refer to Activity 4 of the Software Project Planning key process
area and Activity 3 of the Software Project Tracking and Oversight
key process area for practices covering commitments made external
to the organization.
- Changes to commitments within the organization are negotiated
with the affected groups.
Refer to Activities 5, 6, 7, and 8 of the Software Project Tr 19a acking
and Oversight key process area for practices covering negotiating changes
to commitments.
- Changes that need to be made to the software plans, work products,
and activities resulting from changes to the allocated requirements
are:
- identified,
- evaluated,
- assessed for risk,
- documented,
- planned,
- communicated to the affected groups and ffb individuals, and
- tracked to completion.
Measurement and analysis
Measurement 1 -- Measurements are made and used to determine the status
of the activities for managing the allocated requirements.
Examples of measurements include:
- status of each of the allocated requirements;
- change activity for the allocated requirements; and
- cumulative number of changes to the allocated requirements, including
total number of changes proposed, open, approved, and incorporated into
the system baseline.
Verifying implementation
Verification 1 -- The activities for managing the allocated requirements
are reviewed with senior management on a periodic basis.
The primary purpose of periodic reviews by senior management is to provide
awareness of and insight into software process activities at an appropriate
level of abstraction and in a timely manner. The time between reviews should
meet the needs of the organization and may be lengthy, as long as adequate
mechanisms for exception reporting are available.
Refer to Verification 1 of the Software Project Tracking and Oversight key
process area for practices covering the typical content of senior management
oversight reviews.
Verification 2 -- The activities for managing the allocated requirements
are reviewed with the project manager on both a periodic and event-driven
basis.
Refer to Verification 2 of the Software Project Tracking and Oversight key
process area for practices covering the typical content of project management
oversight reviews.
Verification 3 -- The software quality assurance group reviews and/or
audits the activities and work products for managing the allocated requirements
and reports the results.
Refer to the Software Quality Assurance key process area.
At a minimum, these reviews and/or audits verify that:
- The allocated requirements are reviewed, and problems are resolved
before the software engineering group commits to them.
- The software plans, work products, and activities are appropriately
revised when the allocated requirements change.
- Changes to commitments resulting from changes to the allocated requirements
are negotiated with the affected groups.
|
|