Hello! Welcome to your next lesson in our module on "Stakeholder Engagement and Requirements Elicitation."
In our previous lessons, we focused on active elicitation—gathering requirements by directly engaging with people through interviews and workshops. You learned how to draw out information, facilitate discussions, and build consensus. However, a significant part of a Business Analyst's work is more like detective work. Not all requirements are stated explicitly; many are hidden in plain sight.
Today's learning outcome is to analyze existing documentation and systems to identify implicit requirements. These are the unspoken assumptions, the "everyone knows that" features, and the constraints baked into current processes. Uncovering them is critical to avoiding project failures and scope creep. Your experience as a project manager, where you've likely had to assess the current state of a project or system, will provide a solid foundation for this more investigative approach.
What are Implicit Requirements?
Stakeholders often assume you know certain things about their business or how systems "should" work. They state the obvious, explicit needs, but forget to mention the requirements that are second nature to them. Missing these implicit requirements is a classic pitfall that can lead to delivering a system that technically works but fails to meet the business's real needs.
Let's start with a simple, practical example of how you can begin uncovering requirements by looking at what already exists.
How to Document Requirements - How to write better requirements [Business Analyst Training]
The video 'How to Document Requirements' by Karaleise offers a great starting point. The presenter uses a simple 'Subway sandwich' analogy to show how researching existing documentation—even a company website—is often the quickest way to find initial requirements.
Watch from 03:46 to 06:14. Notice how by simply looking at Subway's website, you can infer requirements about what a 'sandwich' is (and isn't) in their context, without ever talking to a stakeholder.
This simple act of reviewing a website uncovers a basic set of "rules" or requirements. Now, let's formalize this concept.
Capturing Implicit Requirements - Business Analyst Articles ...
The article 'Capturing Implicit Requirements' from BA Times provides a clear definition of implicit requirements and explains why they are so important. It highlights the difference between what users say (explicit) and what they assume (implicit).
Please read the 'Introduction', 'Understanding Implicit Requirements', and the section with the airline data entry example (up to 'Scope Control'). Pay close attention to: The definition of explicit vs. implicit requirements. The 'Employee data capture screen' example, which shows how assumptions are made. The airline example, which demonstrates the serious business impact of missing an implicit performance requirement.
As the article explains, the key difference is:
- Explicit Requirements: Clearly stated by stakeholders. They are the "what I want" statements.
- Implicit Requirements: Unstated assumptions or expectations. They are often related to business rules, performance, existing workflows, or industry standards.
Missing the implicit requirement for keyboard-only data entry in the airline example could lead to missed KPIs and broken SLAs—a direct impact on the business you can appreciate from your management background.
How to Find Them: The Document Analysis Technique
The formal technique for analyzing existing documentation is, unsurprisingly, called Document Analysis. It is a structured process of reviewing materials to extract relevant information before you even schedule interviews, or to validate what you heard in a workshop.
This next video positions document analysis within the broader set of elicitation techniques and provides a crucial warning.
5 Powerful Requirement Gathering Techniques Every Business Analyst Should Know
In '5 Powerful Requirement Gathering Techniques' by Bridging the Gap, the presenter explains how document review saves valuable stakeholder time but also cautions against making assumptions based on outdated information.
Watch from 05:16 to 06:32. Focus on the core benefit (saving stakeholder time) and the key caveat: always validate your findings with stakeholders.
The video's warning is critical: documentation can be outdated. Think of it as a starting point for your investigation, not the final word.
Now, let's look at the structured process for conducting document analysis and the types of materials you'll be looking for.
Understanding the Document Analysis Technique
The article 'Understanding the Document Analysis Technique' from Business Analyst Learnings provides a fantastic, practical framework.
Please read the sections detailing the three stages of analysis, the pros and cons, and the list of document types. Specifically, focus on: The 3 Stages: Prepare, Review, and Wrap up. This is your process. Pros and Cons: Understand when this technique is most and least effective. List of Documents: Skim this list to get a sense of the wide range of potential sources. You don't need to memorize it, but appreciate the breadth of information available.
To summarize the key points from the article:
The 3-Stage Process
- Prepare: Identify and gather relevant documents. What materials might describe the current process or system?
- Review: Study the documents, taking notes of potential requirements, business rules, and questions for stakeholders.
- Wrap Up: Organize your findings and use them to prepare for interviews or workshops. Validate what you've found with subject matter experts.
What kind of documents should you look for?
The list is extensive, but here are some of the most high-value sources for a BA:
- Business Process Documentation: Standard Operating Procedures (SOPs), process flowcharts, training manuals.
- System & Project Artifacts: Old requirements documents (BRDs, FSDs), user guides, helpdesk tickets, defect reports, project charters.
- Strategic & Contractual Documents: Business plans, annual reports, service level agreements (SLAs).
- User Feedback: Customer satisfaction surveys, feature request logs, product reviews.
In your AdTech domain, this could mean analyzing the technical documentation for a Demand-Side Platform (DSP), reviewing past campaign performance reports to understand existing metrics, or sifting through support tickets from advertisers about reporting issues.
How to Find Them: Analyzing the System Itself
Often, the best documentation for an existing system is the system itself. By using the application, you can reverse-engineer its rules and requirements.
This involves:
- Using the system as intended: Go through the common user journeys. How do you create a campaign? How do you pull a report? Document the steps, fields, and options at each stage.
- Exploring edge cases: What happens if you skip a required field? What error messages appear? These reveal hidden validation rules.
- Observing Non-Functional Requirements (NFRs): How long does it take for a report to load? (Performance). Is the interface intuitive? (Usability). Does it require a specific browser? (Compatibility). These are all implicit NFRs.
The information you gather from document and system analysis is the foundation for understanding the "As-Is" or "Current State." This is a critical input for a Gap Analysis, where you compare the current state to the desired "Future State" to identify what needs to be built.
Test your understanding!
You are a BA at an AdTech company. A product manager has asked you to "build a new, consolidated dashboard for monitoring campaign performance." This is the only explicit requirement you have so far.
Before you interview any stakeholders, you decide to analyze the existing system. You have access to the current platform where users pull multiple, separate reports. What are three potential implicit requirements you might uncover by analyzing the current system and its user guide?
Show answer
Here are a few possible answers. The key is to look for clues beyond the explicit request.
- Data Granularity & Dimensions: By examining the existing reports, you might find that performance data can be broken down by
country,device type, andcreative size. The implicit requirement is that the new consolidated dashboard must also support these dimensions, or users will lose existing functionality. - User Roles and Permissions: The user guide might mention that "Campaign Managers" can see financial data (e.g., cost-per-click), but "Creative Designers" cannot. This uncovers an implicit security requirement: the new dashboard must have role-based permissions that hide or show data accordingly.
- Performance Expectations: You notice that the most complex existing report takes about 45 seconds to load. You might also find helpdesk tickets from users complaining about this. This uncovers an implicit non-functional requirement: the new dashboard must load significantly faster than the current reports to be considered an improvement.
Conclusion
You've now added a crucial investigative technique to your BA toolkit. While interviews and workshops are essential for understanding future needs, analyzing existing documents and systems is the primary way to understand the present reality and uncover the hidden, implicit requirements that are baked into it.
Key Takeaways:
- Implicit requirements are unspoken stakeholder assumptions that are critical to project success.
- Document Analysis is a structured, three-stage process (Prepare, Review, Wrap-up) for extracting requirements from existing artifacts.
- Always be critical of documentation, as it can be outdated. Use it to form hypotheses that you later validate with stakeholders.
- Analyzing a live system is a form of "reverse engineering" that helps you discover business rules, user workflows, and non-functional requirements.
- The findings from this analysis form the "Current State" in a Gap Analysis, which is a core BA activity.
Preview of the Next Lesson:
Gathering requirements is one part of the job; managing stakeholder communication is another. Now that you have a richer understanding of the requirements (both explicit and implicit), how do you keep everyone informed and aligned? In the next lesson, we will focus on how to develop a stakeholder communication plan for a project.