Hello! Welcome to your next lesson in the Business Analysis course.
In our last session, we explored the crucial skills of managing stakeholder expectations and negotiating conflicting requirements. We established that navigating these challenges is a core part of a BA's role. Now, we'll zoom out to see how these interactions fit into the larger picture of your day-to-day work.
This lesson focuses on a topic you specifically mentioned as an area of interest: BA work management. The learning outcome is to organize daily BA tasks and manage the requirements preparation workflow.
Your background in project management has given you a solid foundation in planning and execution. We'll build on that by looking at these activities through the specific lens of a Business Analyst. We'll break down how BAs structure their days and, most importantly, how they manage a requirement's journey from a raw idea to a fully formed specification ready for the development team. This is a very practical skill that is essential for on-the-job success and is frequently discussed in BA interviews.
A Day in the Life of a Business Analyst
Before diving into formal processes, let's get a feel for what a BA's daily routine can look like. It's a blend of planned activities and responsive communication. No two days are identical, but they are generally structured around a core set of responsibilities.
A LinkedIn post by a BA offers a great snapshot of a typical day's structure.
How to Solve 5 Real-World BA Case Studies
This post, 'A Day in the Life of a Business Analyst,' provides a quick, high-level overview of the types of activities that fill a BA's schedule. It helps frame the different 'modes' a BA works in throughout the day.
Read the short post titled 'Day 5 – A Day in the Life of a Business Analyst'. Notice the mix of activities: meetings, independent analysis, documentation, and collaboration.
This structure of meetings, analysis, and documentation can be organized into a daily schedule.
To see how these activities come together in a real-world context, let's follow a consultant BA through her day as she works on a project to optimize a client's pricing and quoting system.
What Does a Business Analyst Do Day to Day
The video 'What Does a Business Analyst Do Day to Day' offers a fantastic narrative of a BA's thought process and daily tasks. It illustrates how a BA moves between different types of work to move a project forward.
Watch the video from the beginning, paying close attention to the following sequence of activities: Starting the Day (02:16 - 03:00): How the analyst uses a shared action list to organize priorities. Driving Work with Data (03:43 - 05:46): How she pulls data and uses the 80/20 rule to decide where to focus her effort. Validating with Stakeholders (05:56 - 07:22): Why she talks to people to confirm what the data is telling her. Preparing the Solution (07:22 - 11:06): The process of sketching out a new workflow and getting iterative feedback. Summarizing the Role (11:06 - 12:41): The final recap of the core BA functions performed during the day.
The video demonstrates a key principle of BA work management: it’s an iterative cycle of planning, analyzing, communicating, and solutioning. The shared action list, the data analysis, the stakeholder check-ins, and the process sketching are all part of a structured workflow, even if it looks like a series of distinct tasks.
Managing the Requirements Preparation Workflow
The daily activities we just saw are all in service of a larger process: taking requirements from their initial, often vague, state to a point where they are clear, agreed-upon, and ready for action. This is called the requirements lifecycle or requirements management process.
A well-managed workflow ensures that time isn't wasted on ill-defined ideas and that the development team has everything they need to build the right solution.
The article "Requirements Management 101" from Smartsheet gives a clear, high-level overview of the core activities in this workflow.
Requirements Management 101: Processes, Plans ...
Let's read about the five core activities that form the backbone of the requirements management process. This will give us a simple framework to organize our thinking.
Read the section titled 'What Does Requirements Management Involve?'. Focus on understanding the purpose of each of the five activities: Collection, Analysis, Definition, Prioritization, and Validation.
These five activities—Collection, Analysis, Definition, Prioritization, and Validation—are the building blocks. Now, let's see how they map to the states or statuses a requirement moves through on its journey.
Business Analyst Training For Beginners: Requirements Lifecycle (EASY Model for 2021)
The video 'Business Analyst Training For Beginners: Requirements Lifecycle' breaks down the journey of a requirement into distinct stages. This is the formal process that structures a BA's daily work.
This video details several requirement statuses. Please focus on these key stages: From Drafted to Verified (00:37 - 05:31): Pay very close attention to the criteria a requirement must meet to be considered 'verified' (e.g., atomic, testable, unambiguous). These quality criteria are fundamental to your work. From Verified to Validated to Approved (05:40 - 07:20): Understand the crucial difference between verification (Is the requirement well-written?) and validation (Does this requirement solve a real business need?). The Maintenance Cycle (10:00 - 11:03): This part explains that managing requirements is an ongoing process of handling changes, prioritization, and governance, not a one-time activity.
This lifecycle provides the structure for your work. When a stakeholder gives you a new idea, it enters your workflow as Drafted. Your job is to perform the necessary analysis and refinement to move it through the subsequent stages: Verified, Validated, and Approved. This systematic approach prevents "scope creep" and ensures that only valuable, well-understood requirements make it into the final product.
Test your understanding!
A marketing manager at an AdTech company tells you, "We need a better dashboard to see campaign performance and it should be mobile-friendly."
According to the criteria discussed in the "Requirements Lifecycle" video, why is this Drafted requirement not yet Verified? Identify at least three criteria it fails to meet.
Show answer
This requirement is not yet Verified because it fails to meet several key criteria:
- Not Atomic: It's two requirements in one: 1) a better dashboard for campaign performance, and 2) making it mobile-friendly. These should be separated as they might have different priorities and complexities.
- Not Specific/Unambiguous: What does "better" mean? What specific metrics define "campaign performance" (e.g., click-through rate, cost per acquisition, return on ad spend)? What defines "mobile-friendly" (responsive design, a dedicated app)? Different people will interpret "better" in different ways.
- Not Testable: Because "better" is not defined, you cannot create a test case to confirm if the final product meets the requirement. A testable version might be: "The dashboard must load in under 2 seconds and display the cost per acquisition (CPA) for all active campaigns."
Formalizing the Process: The Requirements Management Plan
For larger projects, the rules for managing this workflow are formally documented in a Requirements Management Plan (RMP). As a project manager, you are familiar with creating project plans; the RMP is a subsidiary plan that focuses entirely on the "how" of the requirements process.
It answers questions like:
- How will we prioritize requirements? (e.g., MoSCoW, Value vs. Effort)
- What is the process for approving requirements?
- How will we handle change requests?
- How will we track the status of each requirement?
Creating this plan upfront ensures that all stakeholders agree on the process, which saves significant time and conflict later.
Requirements Management 101: Processes, Plans ...
Let's briefly look at the components of a Requirements Management Plan. You don't need to memorize this, but you should understand its purpose as the governing document for your workflow.
Read the section 'What Is in a Requirements Management Plan?'. Skim through the list of areas (General Information, Process, Prioritization, etc.) to get a sense of how comprehensive this plan can be.
Conclusion
Organizing your daily tasks and managing the requirements workflow are the twin engines of an effective Business Analyst. It's about combining a structured daily routine with a formal process to ensure requirements are handled efficiently and effectively. This disciplined approach is what allows a BA to translate ambiguous business needs into clear, valuable, and achievable solutions.
Key Takeaways:
- A BA's day is a dynamic mix of planned analysis, documentation, and responsive stakeholder communication.
- The Requirements Lifecycle provides a formal workflow for moving requirements through states like
Drafted,Verified,Validated, andApproved. - Each state transition requires specific BA activities, primarily analysis and communication, to ensure the requirement meets quality standards (e.g., is atomic, testable, and unambiguous).
- A Requirements Management Plan (RMP) is a formal document that sets the rules for how requirements will be elicited, analyzed, prioritized, and approved throughout a project.
Preview of the Next Lesson:
The entire workflow we've discussed is designed to produce high-quality, approved requirements. But where do these requirements live? The next step is to formally document them. The final output of this workflow is often a document that can be shared, reviewed, and signed off.
To set the stage, look at the image below. It compares three of the most common requirements documents.
In our next lesson, we will start Module 3 by learning how to Structure a formal Business Requirements Document (BRD), which answers the "what the business needs" question.