This is a BA's perspective on how much QAs should participate in requirement analysis

1. Requirements Analysis and
the QA
A BA’s perspective on the QA’s role in requirement
elicitation and analysis

2. Should a QA play the BA’s
partner in crime?
A self-confessed,QA reliant, BA criminal’s rantings

4. Should a QA play the BA’s
partner in crime?
A self-confessed,QA reliant, BA criminal’s rantings

5. Should a QA play the BA’s
partner in analysis?
A BA’s wishes

6. Requirements analysis, also called requirements engineering,
is the process of determining user expectations for a new
or modified product. These features, called requirements,
must be quantifiable, relevant and detailed.

9. BA does:
● Deep domain+product knowledge to make decision about what to build
● Explores and evaluates options that are best fit
● Delivers considered options broken down into requirements and implemented
BA has:
● Analysis modeling
● Elicitation
● Long range business planning
● Help team explore needs - users, actions, data, rules, interfaces, quality, design and
implementation

10. QA does:
● Deep domain+product knowledge to make decision about what to build+how will this break
● Explores and evaluates options that are best fit+say what will and won’t work
● Delivers considered options broken down into requirements and implemented+stamp quality
QA has:
● Knack of exposing tacit requirements
● Uncover unsaid business rules
● Impact- “What won’t work”/“What will break if you do this”

13. Not just

18. We’re in this together..validating requirements
● Correct
● Complete
● Feasible
● Testable
● Ambiguous
● Consistent
● Functional
● Non-functional

19. We’re in this together.. measuring success
● Analyze each requirement end to end
● List down user journeys from test perspective, verify with BA
● Create scenarios based on user journeys
● Clarify queries and functionality along with BA from stakeholders
● Suggest improvements to solutioning based on stakeholder input
● Track and close defects

20. Challenges for a QA
● Scope creep/frequent new requirements
● Ambiguity in requirements
● Ambiguity in role
● Communication of assumptions
● Conflicting customer views