Capability Pattern: Develop Solution (for requirement) (within context)
Design, implement, test and integrate the solution for a requirement within a given context.
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
Purpose
  • For developers: to create a solution for the requirement assigned to/owned by them
  • For project managers: to have a goal-based way of assigning work and tracking project status
Relationships
Context
Description

Project managers use this Capability Pattern as a way to perform a goal-based planning and management. Work is assigned to developers and work progress is tracked based on the goals to be achieved, i.e., the designed, unit-tested and integrated source code.

A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is to be developed in a iteration -- development may be focused on a layer (e.g., user-interface, business logic or database access), on a component and so on.

Whether a context is specified or not, developer's responsibility is to create a design and implementation for that requirement, then to write and run unit tests against the implementation to make sure the implementation works as designed, both as a unit and integrated into the code base.

Properties
Event-Driven
Multiple Occurrences
Ongoing
Optional
Planned
Repeatable
Usage
Usage Notes

This Capability Pattern ocurrs multiple times per iteration. Usually, there will be one instance per requirement planned for that iteration. When instantiated in a project plan, the pattern becomes a development task to be assigned to a developer and is expected to be renamed to contain the actual requirement name in it. Optionally, the word 'Solution' may be suppressed, then this pattern is instantiate as:

 'Develop requirement_name (within context_name context)'

If a context is specified, there will be one instance of this pattern for each requirement for each context.

Example:

  1. Develop scenario 1 (within user interface context)
  2. Develop scenario 1 (within business logic and DB access context)
  3. Develop scenario 2
  4. Develop supplemental requirement 1

Note that there are four instances of this pattern in the example above:

  • the first two are related to the same requirement (scenario 1) but within two different contexts
  • the last two are related to different requirements, no context specified.