Please login or join to subscribe to this thread
"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.
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.
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.
I agree with Thomas. The difference is clear in his notes.
Hello, thanks for you answers !
Thomas, I think you gave me the best explanation.
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.
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