Component Product Descriptions

What is the purpose of Component Product descriptions

Component Product descriptions govern the development of products/services as well as their subsequent review and approval; as a result they should be mandatory. The level of detail must provide an accurate description and appropriate measure of control sufficient to fulfil the client’s quality expectations.

The purpose of the Component Product Description is to help in planning, requirements development, technical development, quality and approval processes. The detail of the component products is documented in the related User Scenarios and Acceptance Tests.
You can see the collection of Component Product Descriptions as a high level Product Backlog that in combination with the Product Breakdown Structure (PBS) and Product Flow Diagram (Road Map) gives a definitive view of what should be the output of the different management stages and ultimatly the project.

The Component Product Descriptions should be updated by the Senior User / Product Owner to reflect changes in the needs of the client, new ideas or insights, changes in the market, technical issues that appear, etc. Once a Component Product Description has been baselined it is ok to make changes but they should be communicated through the change request process and the new description baselined with an incremental version number

Tip: Some people find it useful to create the component product descriptions iteratively while creating US&ATs, when they first start.

Developing component product descriptions itirativly

What does a well-formed Component Product Description do?

  • Represents a natural grouping for specific functionality or behaviour that is required as part of the project product to be complete.
  • Gives a more detailed description of the component product/behaviour within the scope set by the project product description.
  • Explicitly states the quality requirements required for the component product to be accepted.
  • Sets the scope limits for what should be included in the component product.
  • Define and understand what the term “Done” means for the component product
  • States what is important in the least amount of space necessary so that we make clear what is necessary for there to be a good understanding of the component product.

  • What can we use a well-formed Component Product Description for?

  • Eliminating unpleasant surprises and broken promises.
  • Enable the project team to develop a high level understanding as to what they are asking for.
  • As an input for the technical experts to refine non-functional requirements for infrastructure and architecture.
  • Gain agreement on the component product outer scope limits and requirements
  • Developing a more detailed business case for the project
  • Communication to stakeholders across organisation and culture boundaries what is required for the project product to be built.
  • As a reference when developing US&ATs, and only developing the US&ATs for component products that will be developed within the planning horizon (ex 1-4 months) of US&ATs.
  • Scope management
  • Cost management
  • Quality management
  • In conjunction with the Product Breakdown Structur (PBS) and the product flow diagram, sequencing the most appropriate order in which to develop the component products.

  • Comments are closed.