In the world of project management especially for professionals preparing for PMP certification understanding how to gather, analyze, and track requirements is not just a skill, it is an art. Whether you are building a software system, launching a product, or even planning a vacation with friends, the ability to clearly define and manage requirements determines the success of your project.
Let’s explore this journey step by step, in a way that feels practical, engaging, and deeply insightful.
What is Requirements Collection (Now Called “Elicit and Analyze Requirements”)?
Traditionally, in earlier editions of PMBOK, this process was known as Collect Requirements. However, in the PMBOK 8th Edition, the terminology has evolved to “Elicit and Analyze Requirements”, reflecting a more mature and realistic understanding of how requirements are discovered and refined. At its core, this process is about:
- Eliciting requirements (drawing them out from stakeholders)
- Analyzing them (refining, validating, and structuring them)
Rather than simply asking, “What do you want?”, a skilled project manager or business analyst facilitates a thoughtful exploration.
Requirements are not always obvious they must be uncovered, refined, and validated.
Think of it like fishing in a vast ocean. The requirements are not lying on the surface, you must use the right techniques to catch them.
Understanding Requirements Through a Simple Analogy
Imagine planning a group vacation. Each person has different preferences, someone wants a luxury hotel, another prefers budget-friendly options, someone wants adventure, and someone just wants relaxation. Your job is to balance all these expectations into one workable plan. Similarly, in a project:
- Each stakeholder has unique needs
- Constraints like budget and time exist
- Trade-offs are inevitable (cannot be avoided)
The phrase “Trade-offs are inevitable” means that in any project (or even in real life), you cannot get everything exactly the way you want, you must give up something to gain something else.
A successful outcome doesn’t mean everyone gets everything—it means everyone gets enough to feel satisfied.
Key Techniques for Eliciting and Analyzing Requirements
The shift in terminology from Collect to Elicit and Analyze also highlights that this is not a passive activity… it requires structured techniques and active engagement.
1. Document Analysis (Learning from the Past)
One of the most powerful starting points is reviewing existing documents such as:
- Business plans
- Process diagrams
- User manuals
- Contracts and reports
These documents provide valuable insights into current systems and help you build a strong foundation.
2. Interviews (Deep and Focused Conversations)
Interviews allow you to dive deeper into stakeholder expectations. Unlike surveys, interviews enable you to:
- Ask follow-up questions
- Clarify ambiguities
- Explore hidden needs
For example, asking “Why is this feature important?” often reveals more valuable insights than the feature itself.
3. Surveys and Questionnaires (Reaching the Masses)
When dealing with a large audience, surveys become extremely useful. They help you:
- Collect data quickly
- Identify trends
- Capture diverse opinions
However, the quality of insights depends heavily on asking the right questions.
4. Observation / Job Shadowing (Experiencing Reality)
Sometimes, the best way to understand a problem is to live it. For instance:
- If you are automating a manual process, observe how people currently perform it
- If building a ride sharing app, experience commuting challenges yourself
Observation reveals what stakeholders may not articulate.
5. Workshops vs Focus Groups
These two are often confused but serve different purposes:
- Focus Groups: Gather diverse opinions (no consensus expected)
- Workshops: Aim to reach agreement (consensus-driven)
Workshops are especially powerful in complex projects where alignment is critical.
6. Prototyping (Making Ideas Tangible)
Prototypes bring ideas to life. They can be:
- Wireframes
- Mockups
- Working models
- Even simple sketches
When stakeholders see something visual, their feedback becomes clearer and more actionable.
7. Visual Techniques (Mind Maps & Affinity Diagrams)
Visual representation makes requirements easier to understand. These techniques simplify complexity and improve clarity.
- Mind Maps: Show relationships between features
- Affinity Diagrams: Group similar ideas into categories
Types of Requirements We Must Understand
When working on any project, one of the most critical skills is the ability to differentiate between various types of requirements. Many project failures occur not because teams don’t work hard!!! but because they misunderstand what type of requirement they are dealing with.
Understanding these layers helps you move from “Why are we doing this?” → “What should be built?” → “How will it be delivered?”
Let’s explore each type in depth. A well structured project distinguishes between different types of requirements:
1. Business Requirements
These define why the project exists, such as increasing revenue or improving efficiency. Business requirements define the core purpose of the project. They answer the fundamental question:
“Why are we doing this project at all?”
These are high level and strategic in nature. They focus on business value, not technical details.
Examples
- Increase revenue by 20%
- Reduce operational costs
- Improve customer satisfaction
- Expand into a new market
Real Life Scenario
If a company launches an e-commerce website, the business requirement could be: “Increase online sales and reach a wider customer base.”
Notice: there is no mention of features yet. It’s purely about the business goal.
Stakeholder Requirements
These reflect expectations of users and stakeholders for example, “one-click checkout” in an e-commerce system.
Solution Requirements
Solution requirements explain how the system will fulfill stakeholder needs. Solution requirements are of two types:
- Functional requirements (features)
- Non-functional requirements (performance, security)
A. Functional Requirements (Features & Functions)
These define what the system should do. Think of them as capabilities or features.
Examples
- User can register/login
- Add items to cart
- Make online payment
- Generate invoice
Simple Understanding
If stakeholder says: “I want to transfer money”
Functional requirement becomes: “System should allow user to add beneficiary and transfer funds.”
B. Non-Functional Requirements (Performance & Quality)
These define how well the system performs. They are not about features, but about quality attributes.
Examples
- System should load within 2 seconds
- Website should handle 10,000 users simultaneously
- Data must be encrypted
- System uptime should be 99.9%
Example
A banking app that allows money to transfer is it’s Functional Requirement, however if it crashes frequently it is not fit for use, thus it’s Non-Functional aspect hindered it to work nicely.
Powerful Concept (Very Important for PMP)
Functional = Fit for Purpose (Does it do the job?)
Non-Functional = Fit for Use (Does it do it well?)
Project Requirements (Constraints & Conditions)
Constraints like time, cost, and scope. Project requirements define how the project will be executed, not the product itself. They are related to project management constraints.
Key Insight
They ensure the project stays within boundaries. These requirements guide:
- Planning
- Execution
- Monitoring
Examples
- Project must be completed in 6 months
- Budget is limited to $50,000
- Must comply with company policies
- Must follow Agile methodology
Transition Requirements
Transition requirements are temporary requirements needed to move from the current state to the future state. Once the transition is complete, these are no longer needed.
Real-Life Example
A builder creates a sample flat to show customers. Once the building is complete, that sample flat is removed. That’s a transition requirement.
Examples
- Data migration from old system to new system
- User training sessions
- Parallel system run (old + new system together)
- Temporary reporting setup
How All These Requirements Are Connected
| Requirement Type | Example | |
|---|---|---|
| Business Requirement | Why are we doing this? | “I want a comfortable home for my family” |
| Stakeholder Requirement | “We need 3 bedrooms and a garden” | |
| Solution Requirement | How will we build it? | Functional Requirement: “Build rooms, kitchen, bathrooms” Non-Functional Requirement: “Strong structure, proper ventilation” |
| Project Requirement | Under what constraints? | “Complete within 6 months, budget 50 lakh” |
| Transition Requirement | How do we move from old to new? | “Temporary living arrangement during construction” |
| Quality Requirements | Part of Non-Functional Requirements |
Requirement Traceability Matrix (RTM)
Your Control System
One of the most powerful tools in project management is the Requirement Traceability Matrix (RTM). It ensures that every requirement is:
- Clearly defined
- Properly implemented
- Thoroughly tested
RTM provides complete traceability… from idea to execution.
Why RTM is Essential
Imagine giving multiple requirements to your team and later wondering:
- Which requirements are completed?
- Which are still pending?
- Where is each requirement implemented?
RTM answers all these questions by linking:
- Requirement → Design → Development → Testing → Delivery
It acts as a single source of truth throughout the project lifecycle.
Key Elements of RTM
A typical RTM includes:
- Requirement ID
- Description
- Source (who requested it)
- Priority
- Status (e.g., discussed, implemented, tested)
- Mapping to deliverables and test cases
This ensures end to end visibility and control.
Decision-Making in Requirements
When stakeholders disagree, decision-making becomes critical. Common approaches include:
- Unanimity: Everyone agrees
- Majority: More than 50% agree
- Plurality: Largest group wins (even without majority)
- Autocratic: Project manager decides
In real world projects, a balanced approach is often required.
A Practical Insight: Requirements Evolve
One important reality: requirements are not static. They evolve as:
- Stakeholders gain clarity
- Market conditions change
- New constraints emerge
That is why tools like RTM are continuously updated—not created once and forgotten.
Final Thoughts
The evolution from “Collect Requirements” to “Elicit and Analyze Requirements” is not just a change in wording it reflects a deeper shift in mindset.
Requirements are no longer something you simply gather.
They are something you discover, shape, validate, and continuously refine.
If you truly want to master concepts like requirement elicitation, analysis, RTM, and real world project scenarios, ITHeight is the best PMP institute offering expert mentoring, structured study lectures by Sir Shahid Naseer, and exceptional exam preparation ability helping you succeed with confidence.