Project Management Central

Please login or join to subscribe to this thread

Topics: Business Analysis/Requirements Management
Difference between "requirement gathering" and "product analysis"
Network:28



Hello,

I'm still studying to get my PMP and I hope this question is not a duplicate.

Right now the difference between "requirement gathering" and "product analysis" is not clear yet in my mind,

I did find some informations in the book "Head First PMP", where the explanation is something like :
- "requirement gathering" : refers to finding the NEEDS, and is more related to the CONTENT of the product.
- "product analysis" : refers to the DELIVERABLES, and is more related to HOW the work will be done.

I come from an IT background, so the way I understand this is :
-"Requirement gathering" are like functional specifications, where we describe what problem the program will solve and how the program should behave to fix it
-"Product analysis" are like technical specifications, where we describe how the program will be designed so that the application behaves like it is described in the functional specifications

However, this might not be the best way to understand the concept.

If you have other concrete examples to explain this difference, it would be greatly appreciated.

Alexandre
Sort By:
Network:272



Alexandre,
"Product analysis" as used in the PMBoK is about defining scope. It is an architectural level term. Requirements gathering occurs at all levels of product definition from scope, down to detail level components and operations.

Product analysis does require some requirements gathering to define what the product is, and what it does. "The product must be safe" would be a Tier 0 Requirement. What does safe mean relative to the product as a whole, which functions does it apply to, and what are the specific parameters that must be maintained for a sub-routine to ensure safety, are examples of how gathering the necessary requirements span from an overall product level to a detail specification level.
Network:429



Dear Alex,
Product analysis is the tools and technique to define the characteristic of the product or service or deliverable going to be delivered. Collect requirement is a process for gathering requirements/inputs for defining the project scope from stakeholders to meet the project objectives by using various tools and techniques like prototyping, storyboarding and other data gathering techniques as well interpersonal skills.

Regards
Lenin
Network:2323



Alexandre,

requirements gathering/collecting is a process that takes place before product analysis, which is a technique within the process of scope definition.

Product analysis includes an activity 'requirements analysis' and it creates the definition of the product, sometimes in the form of a PBS (product breakdown structure).

Requirements are the needs and wants from all stakeholders, they will contradict each other and be redundant and mostly too many to be considered. The project manager has low influence on the requirements, they are the ask to the project.

The answer during planning would be to develop the scope that can be delivered and fulfills the most important of the requirements, considering time and cost constraints. It is the promise of the project.
...
1 reply by Keith Novak
Apr 08, 2019 11:02 AM
Keith Novak
...
Thomas,
In many engineering frameworks, requirements gathering goes on up to Preliminary Design Review. The fundamental intent of a PDR is to ensure that all requirements are understood, so that there is acceptable of moving from preliminary into the detailed design phase where costs increase sharply.
Keith
Network:21815



I agree with Thomas. The difference is clear in his notes.
Network:28



Hello, thanks for you answers !

Thomas, I think you gave me the best explanation.

Kind regards

Alexandre
Network:272



Apr 08, 2019 7:45 AM
Replying to Thomas Walenta
...
Alexandre,

requirements gathering/collecting is a process that takes place before product analysis, which is a technique within the process of scope definition.

Product analysis includes an activity 'requirements analysis' and it creates the definition of the product, sometimes in the form of a PBS (product breakdown structure).

Requirements are the needs and wants from all stakeholders, they will contradict each other and be redundant and mostly too many to be considered. The project manager has low influence on the requirements, they are the ask to the project.

The answer during planning would be to develop the scope that can be delivered and fulfills the most important of the requirements, considering time and cost constraints. It is the promise of the project.
Thomas,
In many engineering frameworks, requirements gathering goes on up to Preliminary Design Review. The fundamental intent of a PDR is to ensure that all requirements are understood, so that there is acceptable of moving from preliminary into the detailed design phase where costs increase sharply.
Keith
...
1 reply by Thomas Walenta
Apr 09, 2019 5:07 AM
Thomas Walenta
...
Keith,
you are right, agree.

This is perfectly covered by the PMBoK concepts of iterative and incremental planning and progressive elaboration of artifacts, applied to a waterfall lifecycle. Work on the PDR continues until an acceptable level of security is reached to proceed into the phase of detailed design.
If changes (e.g. new requirements) during detailed design evolve, this requires a change request against the PDR.

Logically, some requirements have to be gathered before any design work can start, and it could go in circles. Think it is also important to understand that not every requirement will make it into the design. Those who do not, can be considered 'out of scope' and should be tracked as well.
Network:2323



Apr 08, 2019 11:02 AM
Replying to Keith Novak
...
Thomas,
In many engineering frameworks, requirements gathering goes on up to Preliminary Design Review. The fundamental intent of a PDR is to ensure that all requirements are understood, so that there is acceptable of moving from preliminary into the detailed design phase where costs increase sharply.
Keith
Keith,
you are right, agree.

This is perfectly covered by the PMBoK concepts of iterative and incremental planning and progressive elaboration of artifacts, applied to a waterfall lifecycle. Work on the PDR continues until an acceptable level of security is reached to proceed into the phase of detailed design.
If changes (e.g. new requirements) during detailed design evolve, this requires a change request against the PDR.

Logically, some requirements have to be gathered before any design work can start, and it could go in circles. Think it is also important to understand that not every requirement will make it into the design. Those who do not, can be considered 'out of scope' and should be tracked as well.

Please login or join to reply

Content ID:
ADVERTISEMENTS
ADVERTISEMENT

Sponsors