6th Edition PMBOK® Guide–Process 5.2 Collect Requirements: Tools & Techniques (1)

When I sat down to do this post, I realized that a) this process is so crucial to the success of a project and b) there are so many tools & techniques in this process , that I can’t do it justice in one post.   I am going to start with an introduction to the different types of requirements.

Types of requirements

  1. Business requirements–these high-level requirements a) help the project align with the strategic objectives of the company, as well as b) assuring that the business need, i.e., the reason why the project has been undertaken, will be filled by the product, service or result that the project will create.   The source of these requirements can be found in the project charter and/or business case document.
  2. Stakeholder requirements–These are requirements from a particular stakeholder or group of stakeholders.   These requirements are found by engaging with the stakeholders.
  3. Solution requirements–What are the particular features, functions, and characteristics of the product, service or result that will meet the business and stakeholder requirements listed above.   Now we are getting into the details of what the product will turn out to be, and for that reason the source of these requirements will be subject matter experts.   There are two sub-types of solution requirements:
    • Functional requirements–what are the data, actions, or processes that the product should execute?
    • Non-functional requirements–these supplement functional requirements and describes the environmental conditions or qualities required for the product to be effective.   How reliable is the product?   How easy is it to use?   What technical or other support will it require for continued use?
  4. Transition and readiness requirements–these are the temporary capabilities, such as a training requirements, that will need to be in place to transition to using the product.
  5. Project requirements–these deal not with the scope of the product, as the categories above do, but with the scope of the project itself.    For example, what are the constraints on the budget and schedule?   (The quality requirements are a constraint that are dealt with in the category below.)
  6. Quality requirements–scope is a constraint that deals with the completeness of the work, quality is a constraint that deals with the correctness of the work.    What are the conditions or criteria needed to validate the end result of the project?   Are there tests that need to be performed?   What is the inspection procedure going to consist of?   Is it important to get this spelled out at the beginning of the project so that the process of validation of the end result is a) objective and b) understood by the customer or the sponsor of the project.

So, these requirements range from the high-level (category 1) to the specific (category 3 and 4); stakeholder requirements (category 2) can be either high-level or specific.    The requirements can be related to either the scope of the product (categories 1-4) or the scope of the project (5-6).

Now that we have categorized what requirements may be considered, the next post will start to go through the tools & techniques that will collect, organize, prioritize, and finally select the requirements that will form the shape of the scope of the product and the project itself.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: