This short videos explains the difference between the 3 main types of user interviews (structured, semi-structured and unstructured), and at what stages of a UX design process it makes the most sense to use each.

This presentation discusses the various different requirement elicitation methods. These techniques include brainstorming, interview, survey, and many more! This video illustrates the challenges of requirement elicitation and should allow you to choose the right elicitation techniques for your software project.

The Acceptance Testing syllabus is joint effort between IQBBA (International Qualification Board for Business Analysis) and the ISTQB (International Software Testing Qualifications Board). This syllabus will facilitate the efficiency of acceptance testing through the joint training of business analysts / product owners and testers.

Why is it so hard to reconcile Agile approaches and long-term product planning? What causes the friction between product teams and stakeholders that prevents delivering desired outcomes as fast as possible? This presentation shares some research on the issue and gives a sneak-peak into ongoing experiments to solve this painful requirements problem.

This session talks about how to understand your customers – how they’re behaving, how capable they are of learning and changing, how they make decisions, what they care enough about to pay money or attention to fix. It’s not easy.

Sharing low fidelity user-interface prototypes with project stakeholders is a great way to transfer knowledge and get buy-in early from them. A low-fidelity prototype is a prototype that is sketchy and incomplete, that has some characteristics of the target product but is otherwise simple, usually in order to quickly produce the prototype and test broad concepts.

Modern software development approaches like Agile support a strong collaboration between all member of the software development team, software testers and business analysts included. Even if you don’t use a method like Behavior-Driven Development or Specification by Example, checking the fact that you will be able to actually test your requirements is a good thing. In his article, Richard Ellison share some best practices to reviewing requirements for testability from the point of view of a software tester.