Requirements Excellence: The Craft at the Heart of Business Analysis

DAY 5 | Requirements Excellence in Your Career: Mastery, Interviews and the Six Principles to Keep

We have covered a significant amount of ground this week.

• Day 1 established the foundation: the real cost of poor requirements, the difference between documenting and discovering, and the mindset shift from scribe to analyst that changes how you approach requirements work entirely.

• Day 2 went deep on elicitation: the six techniques that find what stakeholders cannot easily articulate, the questions that surface hidden requirements, and the mistakes that consistently produce shallow requirements.

• Day 3 addressed the craft of writing: functional and non-functional requirements in depth, the quality criteria every requirement must meet, and the documentation failures that send projects in the wrong direction.

• Day 4 covered the lifecycle: validation versus verification, the RTM and how to use it properly, requirements change management, and why sign-off is a milestone and not a finish line.

Today we apply all of it to your career, because knowledge that stays in a series and does not change how you work or how you are perceived is not knowledge you have truly acquired.

What Requirements Mastery Looks Like at Every BA Level

Requirements competence does not look the same throughout a BA career. What is expected at each level is different, and understanding those expectations is one of the most direct ways to assess where you are and what your next development priority should be.

At Junior BA level: requirements mastery is about accuracy and discipline. A junior BA demonstrating requirements excellence produces requirements that are clearly written, correctly formatted, and free of the most common quality failures: ambiguity, passive voice, bundled behaviours, and missing acceptance criteria. They follow a defined elicitation process reliably. They ask the right questions in workshops and interviews. They maintain their documentation accurately. They do not yet need to design the elicitation strategy or make independent judgements about requirements quality at programme level. They need to execute the fundamentals with consistency and care.

At Mid-level BA, requirements mastery is about depth and ownership. A mid-level BA who has mastered requirements takes full ownership of the requirements baseline for their project. They design the elicitation approach rather than executing a given one. They make independent judgements about quality and completeness. They identify and resolve requirements conflicts without being prompted. They manage the RTM actively and use it as a decision-making tool rather than a governance artefact. They lead the requirements review process and can defend every requirement in their baseline with clarity and confidence.

At Senior BA level, requirements mastery is about strategy and assurance. A senior BA is responsible for the requirements quality of programmes that span multiple workstreams, methodologies, and stakeholder communities. They design the requirements framework: the standards, templates, and governance processes that all BAs on the programme work within. They provide quality assurance across other BAs' requirements work. They advise programme directors and sponsors on requirements risk. They are the authority on what the programme is building and why, and that authority is grounded in the rigour of the requirements baseline they have maintained.

Six Requirements Interview Questions With Model STAR Answers

Q1: How do you approach requirements elicitation on a new project? (Junior to Mid)

Model answer: My starting point is always to understand the stakeholder landscape before I begin any elicitation. I want to know who the key stakeholders are, what their relationship to the change is, what they already know and what they are likely to be uncertain about, and what political or organisational dynamics might shape what they are willing to say in different settings. From there I design an elicitation approach that uses the right technique for each stakeholder group and objective. One-to-one interviews for sensitive topics or highly specific subject matter knowledge. Workshops where consensus is needed or requirements have cross-functional implications. Observation where the gap between how people describe a process and how they actually perform it is likely to be significant. Document analysis to understand the current state and identify legacy requirements that stakeholders may not consciously surface. During elicitation sessions I treat every answer as the beginning of an investigation rather than a conclusion. I probe for exception cases, failure modes, and unstated assumptions. I validate what I have heard immediately rather than deferring it to a review cycle. And I treat my initial requirements as hypotheses to be confirmed, not facts to be recorded.

Q2: Tell me about a time you had to challenge a requirement from a senior stakeholder. (Mid to Senior)

STAR model answer: On a digital transformation programme I was leading the analysis for, the programme director had included a requirement that the new platform must replicate every function of the legacy system being replaced.

Situation: the legacy system had over four hundred documented functions, many of which had not been used in years and some of which directly contradicted the strategic objectives of the transformation.

Task: I needed to challenge this requirement in a way that was analytically rigorous and politically respectful.

Action: I produced a usage analysis showing that approximately sixty per cent of the legacy functions had not been accessed in the preceding twelve months. I then mapped the remaining active functions against the strategic objectives of the programme and identified thirty per cent that were redundant to those objectives. I presented this analysis to the programme director with a recommendation to scope the new platform around the active, strategically relevant functions and manage the remainder through a separate rationalisation workstream. I framed it not as a challenge to their requirement but as a risk: building and testing four hundred functions would take significantly longer and cost significantly more than the programme plan had accounted for.

Result: the programme director accepted the recommendation. The scope was reduced by approximately forty per cent. The programme delivered on time and within the revised budget.

Q3: How do you ensure non-functional requirements are captured on your projects? (Mid)

Model answer: Non-functional requirements are the category most consistently underwritten in BA practice, usually because stakeholders do not spontaneously volunteer them and less experienced BAs do not systematically elicit them. My approach is to treat non-functional requirements as a structured elicitation objective in their own right rather than waiting for them to emerge from functional requirements conversations. I use the FURPS framework as a prompt: for every major functional area, I ask specifically about performance expectations, usability and accessibility standards, reliability and availability requirements, security and data protection obligations, and maintainability considerations. I also review regulatory and contractual obligations for the project, because many non-functional requirements exist in those documents rather than in stakeholders' heads. For performance and availability specifically, I work with the technical architect to ensure that the requirements we set are achievable within the proposed design, because a non-functional requirement that cannot be met by the architecture is not actually a requirement but a problem.

Q4: How do you manage requirements when they change mid-project? (Mid to Senior)

STAR model answer: On a core banking system replacement programme, we experienced a significant volume of requirements changes in the third month of development when the business completed a parallel regulatory review.

Situation: the regulatory review surfaced twelve requirements changes, three of which affected areas that were already in development.

Task: I needed to process all twelve changes through a rigorous change management process without losing the development team's momentum or the stakeholder community's confidence.

Action: I had established a formal change management process at the start of the programme, including a change request template, an impact assessment framework, and a change control board with fortnightly meetings. Each of the twelve changes was submitted as a formal change request. I produced impact assessments for each one, covering the effect on scope, schedule, budget, the RTM, and any dependent requirements. The three changes affecting work in progress were expedited to an emergency change control board session. I presented the full impact picture for each change including the cost of implementation and the cost of not implementing, and the board made informed decisions on all three within forty-eight hours.

Result: all twelve changes were formally processed and baselined within two weeks. The development team had clear, updated requirements to work to. The regulatory requirement was met. The programme did not experience any uncontrolled scope drift.

Q5: How do you know when your requirements are good enough to proceed to development? (Mid to Senior)

Model answer: I use a defined quality checklist applied to every requirement before I consider the baseline ready for development. Each requirement must be necessary: traceable to a business objective; unambiguous: with no words that could be interpreted in more than one reasonable way; complete: specifying all conditions, actors, and constraints without requiring development assumptions; consistent: not conflicting with any other requirement in the baseline; and verifiable: with a corresponding acceptance criterion or test case that confirms whether it has been met. Beyond the individual requirement level, I look at the requirements set as a whole. Are all functional areas covered? Has every stakeholder group's needs been represented? Have non-functional requirements been addressed for each major functional area? Is the RTM complete enough that every requirement can be traced to a design element? I also run a structured requirements review session with the development team before finalising the baseline. Developers identify ambiguities and gaps that BAs and business stakeholders miss, because they are reading requirements through a build lens. That review session frequently surfaces the last ten per cent of quality issues that the BA review process did not catch.

Q6: What do you consider your biggest development area in requirements practice? (All levels)

Model answer: My deepest experience is in requirements for system replacement and process improvement programmes, where the current state is relatively well-documented and the elicitation challenge is primarily about understanding what the future state needs to do differently. My development area is in requirements for innovation and new product development, where the current state does not exist and requirements must be built from a much less certain foundation through user research, market analysis, and iterative prototyping rather than process elicitation. I am addressing this by seeking out the opportunity to work on product development initiatives within my current organisation and by studying how BAs operating in product environments approach requirements discovery. I believe that being able to work effectively across both replacement and innovation contexts makes a BA significantly more versatile and I am developing that range deliberately.

The Six Principles to Carry Forward

1. You are an analyst, not a scribe. Your job is not to record what stakeholders say. It is to find out what they mean, what they need, and what the system must do to serve those needs. That distinction is the foundation of everything else in requirements practice.

2. A requirement is only as good as its testability. If you cannot describe a test that would confirm whether a requirement has been met, you do not have a requirement. You have an intention. Go back and make it specific enough to test.

3. Non-functional requirements are not optional extras. They are half of the picture. The performance, security, usability, and reliability requirements you write or fail to write will determine whether the system that is built is the system the business can actually use.

4. Elicitation never ends at the workshop. The most important requirements information often emerges later; when stakeholders see working software, when the business context changes, when someone asks the right question at the right moment. Stay curious and stay engaged throughout the project lifecycle.

5. Sign-off is a milestone, not a finish line. The requirements baseline you establish is the foundation of everything that follows. Maintaining it - keeping it current, keeping it visible, managing change through rigorous process, is as important as building it.

6. Requirements excellence is a career asset that compounds. Every project where your requirements hold up, where the delivered system matches what was agreed, where stakeholders recognise what they asked for, builds a professional reputation that opens doors. Requirements excellence is not just good practice. It is career infrastructure.

   
   

Thank you for following this series all week. Requirements Excellence is the craft at the heart of what we do as Business Analysts, and I hope every edition has given you something specific and practical to take into your next project. If this series has been useful, share it with a BA colleague who is working on building their requirements practice. And if someone sent it to you, subscribe at www.flotogbainsights.com to go over this week's discussion and receive next week's series directly.

Go out and be successful.

Oluwatosin Ogunkoya | Flotog BA Insights | www.flotogbainsights.com

Next week: Agile Business Analysis - The BA's Role in Scrum, Sprints and Product Delivery. Five days going deep on what a Business Analyst actually does inside an Agile team: writing user stories that hold up, running backlog refinement, working with Product Owners, and managing requirements without a BRD. Day 1 launches Monday, 26th May.