Requirements Management

[BruceMcNaughton]

Hi,

Please share your thoughts on how 'Requirements Management' and 'Product Based Planning' may relate together.

Regards,
Bruce

[Drew]

Hello Bruce,

What is Requirements Management by the way? I think I have a basic idea of what Product Based Planning is but I don't know how it relates to the other one.

Cheers,

Drew

[BruceMcNaughton]

Hi,

Many project management processes use the term requirements to identify the items necessary to satisfy the overall objectives (solve a problem) and deliver benefits (as a result of the problem being solved). Satisfying these requirements generally establishes the scope of the project and directly links to customer satisfaction.

Processes such as Atern (DSDM), PMI (scope statements or requirements), even the ISO 9001:2000 quality standards (and TickIT) or the Software Engineering Institute's CMMI identify requirements as a key driver of the solution.

Product Descriptions generally state 'What' is required ... along with associated quality criteria. The products that are identified in the PBS also identify the scope of the project and the items necessary to deliver the benefits identified in the busines case.

So, a PBS may be seen as a visual representation of a PRL (Prioritised Requirements List).

Hope this helps ... if not, anyone welcome to join the discussion.

Regards,
Bruce

[BruceMcNaughton]

Hi,

Taking a step back there are some other differences between the classic Requirements Definition and Management approach and Products in Product Based Planning.

1) Product or Solution Requirements

When creating a product or solution, like a software product or a building, depending upon the current state of the product (new development or new build .. or modification or renovation), the scope of a project may vary considerably.

For either of these cases, Product or Solution Requirements need to cover 100% of the solution requirements to the appropriate level of detail. These requirements are then translated through the development process (down and up the v-model) to become the delivered solution. These requirements ensure that nothing is missed and the full solution can be accepted. The full set of requirements also provides the basis for regression testing to ensure that changes made at a later time do not alter the characteristics of capabilities not changed.

2) Products in a Project (PBS or Product Checklist).

The products in the Product Checklist or PBS tend to relate to those requirements that are changing and establish the scope of the work for the project. For example, the products identified for a new software product or new build construction, would tend to relate to the full set of requirements for a solution. The products for an enhancement to a product or a renovation would only relate to the changes that are necessary. The end result is generally checked against the full set of requirements (including those that have not changed) to ensure that new problems have not been injected into the solution.

3) Prioritised Requirements and Products

When using an agile approach with timeboxes and high user involvement to deliver benefits, prioritisation of a set of products (related to new or changed functions or capabilities) within the timebox is important. The effect of the prioritisation is to alter the scope of a timebox (stage with a fixed time period). The priority assigned to a product determines it's probability of staying in the scope of the timebox.

Any thoughts or feedback... or comments?

Regards, Bruce