Mastering Requirements: From Elicitation to Documentation

The Business Analyst's Core Process

At its core, solving a requirements-focused problem involves a systematic process. The diagram below shows a typical lifecycle for identifying and gathering requirements, which we will follow in our case study today.

1. Understanding the Business Problem

Every project starts with a problem or an opportunity. A great Business Analyst doesn't just accept a proposed solution; they first seek to deeply understand the underlying business need.

We'll use a case study to guide our work. To begin, watch the following video, which introduces the core challenge of requirements elicitation and then presents the business scenario we will be tackling.

So, here is our problem statement, drawn from the video:

You are a Business Analyst at American Airlines. Due to a massive, pandemic-related drop in revenue, the company must lay off up to 25,000 employees. The HR Director has asked you to find a way to perform a mass update in the payroll system for these employees. The current process is manual, and the payroll team cannot handle this volume. She needs an answer by the end of the week.

2. Elicitation: Asking the Right Questions

Your first reaction might be to jump into solution mode. However, as the video points out, the first step is to "not panic" and to gather more information. You need to move from the high-level problem to a detailed understanding of the need. This is requirements elicitation.

The Initial Response and High-Level Analysis

As the video suggests (from 09:44 onwards), a good BA would first manage the stakeholder's expectations and then use a simple framework like the 5 Ws and H (Who, What, When, Where, Why, How) to structure their initial thoughts.

• Who? ~25,000 unionized employees (pilots, flight attendants, etc.).
• What? A mass layoff process.
• When? "This fall."
• Where? United States.
• Why? To reduce costs due to an 80% revenue decline.
• How? This is the unknown we need to solve.

This initial analysis gives you a foundation. The next step is to schedule a meeting with the right people—not necessarily the Director who gave you the task, but the Subject Matter Experts (SMEs) who understand the operational details. In this case, that might be a Payroll Manager or a senior HR Operations specialist.

Preparing for and Conducting the Elicitation Session

To make that meeting productive, you must come prepared. The most common techniques for elicitation are stakeholder interviews and workshops.

Let's explore how to structure a requirements workshop.

Based on both videos, your preparation would involve brainstorming detailed questions. For our American Airlines case, these could include:

• Process Questions:
  • What are the different types of employees impacted (full-time, part-time, union status)?
  • What is the exact effective date of separation?
  • Are there different reasons for separation (e.g., voluntary layoff, early retirement, involuntary layoff)? Will the system need to handle each differently?
• Data Questions:
  • What specific employee data is needed to process a termination (Employee ID, Name, Job Title, Manager, Department)?
  • Do you have a list of all impacted employees? What format is it in?
• System/Output Questions:
  • What notifications need to be sent, and to whom (e.g., manager, IT for de-provisioning)?
  • What reports are needed for auditing purposes after the process is complete?

During the execution of this "workshop" (which could just be a meeting with the SME), you would use a template, like the one shown in Stefano's video, to document the conversation. You would capture not just requirements, but also action items, and topics for later discussion (the "parking lot").

3. Analysis: Structuring the Elicited Information

After the meeting, you'll have a collection of notes, answers, and new questions. Now, you need to analyze and structure this information. A key part of this is categorizing what you've learned into different types of requirements.

Let's get a formal definition of the main requirement categories.

Now, let's apply these categories to our American Airlines case. The elicitation video does a great job of this.

Synthesizing from the video and our own analysis, we get:

• Business Requirement: Reduce operational costs to remain financially viable amidst an 80% revenue drop. (The "Why")
• Stakeholder Requirement: The HR/Payroll department needs a way to process up to 25,000 terminations efficiently without hiring more staff. (The "Need")
• Solution Requirements (Functional): These describe what the system must do.
  • The system shall allow a user to upload a file (e.g., Excel) containing a list of employees to be terminated.
  • The system shall process each record from the file and update the employee's status to 'terminated' with the specified effective date and reason code.
  • The system shall generate a confirmation report of all processed records.
  • The system shall generate an error report for any records that failed to process.
• Solution Requirements (Non-Functional): These describe how well the system must do it.
  • Performance: The system must be able to process 25,000 records in under 4 hours.
  • Security: Only users with 'Payroll Administrator' privileges shall be able to access the mass termination feature.
  • Usability: The process of uploading a file and initiating the process should take no more than 5 clicks.

4. Documentation: Creating the Formal Output

The final step is to formalize these requirements into a document that the development and testing teams can use. Your goal in an interview is not to produce a 50-page document, but to show that you know how to structure one.

There are several types of requirements documents. Your experience as a project manager likely exposed you to high-level project charters; a Business Requirements Document (BRD) is similar but focuses on the business needs. A Software Requirements Specification (SRS) gets more technical.

The table below provides a quick visual reference for the key differences between these documents.

For many modern teams, especially those using Agile methodologies, requirements are often captured as User Stories. This format is simple, user-centric, and focuses on delivering value.

A user story follows the template: As a [user type], I want to [perform an action] so that I can [achieve a goal].

Let's document one of our functional requirements as a user story.

User Story:

As a Payroll Administrator, I want to upload a spreadsheet of employees to be terminated so that I can process multiple terminations at once without manual data entry for each person.

A user story isn't complete without Acceptance Criteria (AC). These are the testable conditions that must be met for the story to be considered "done."

Acceptance Criteria for the story above:

• (Given) I am logged in as a Payroll Administrator,
• (When) I navigate to the "Mass Actions" page,
• (Then) I should see an option to "Upload Termination File".
• The system accepts files in .xlsx and .csv format.
• The file must contain columns for 'EmployeeID', 'TerminationDate', and 'TerminationReason'.
• If the file is missing required columns, an error message is displayed.
• After a successful upload, a confirmation screen shows the number of records to be processed.

Conclusion

Congratulations on working through your first capstone case study! You have successfully navigated the entire requirements process from initial problem to final documentation.

Key Takeaways:

• A Structured Process is Essential: Don't jump to solutions. Follow a systematic process: understand the business problem, elicit details from stakeholders, analyze and categorize the information, and then document it clearly.
• Elicitation is an Active Skill: Great BAs are great investigators. They prepare thoroughly, ask clarifying questions, and listen actively to uncover the real needs behind a request.
• Categorize to Clarify: Separating requirements into Business, Stakeholder, Functional, and Non-functional types brings structure and ensures all aspects of the need are considered.
• Documentation is Communication: Whether it's a formal SRS or a set of user stories, the goal of documentation is to create a shared understanding between business stakeholders and the technology team.

Preview of the Next Lesson:

In this lesson, we focused on what the system needs to do. In our next lesson, we will tackle a process-focused case study. You will learn how to model the 'as-is' (current) and 'to-be' (future) business processes, a crucial skill for identifying inefficiencies and designing streamlined workflows.