Skip to main content

Questiologie for complex requirements - Frédéric Falisse

I just watched this TedX video of Frédéric Falisse explaining his Questiolgie and found it very interesting. The video is in french but it has English captions. I think it could be greatly useful while gathering elaborate or difficult requirements.

As far as I understand it, he proposes four tips for asking good questions

1. Change of mental posture 
If the interviewed is already an actor, remove him from the action and ask for a feeling. Do not ask "why do you get stuck" but "what do you feel when you feel stuck ?
If instead he starts with an emotion, ask about an action.

2. Double the verb
Like in the phrase "What are you afraid of when you are afraid of losing control?"

3. Reconcile
Use right and left hands  "When you fail a test ... Makes you lose control over future choices"

4. Project in the future
i.e. What will happen if you fail the test?

Here's his main site https://www.questiologie.fr/

Have a great day!

Comments

Popular posts from this blog

Crash course - 2

Why ? The more I think about it, the more "why" is the word when it comes to requirements gathering. The question "Why ?" has two different meanings: THE PAST : you ask questions to understand the cause, what has happened in the past. THE FUTURE : we ask questions to understand what the user will need in the future, what he wants to do.

"Volere" Requirements process

I found in my library the "Mastering the Requirements Process" book , that some might know as the " Volere " book. After many years I still find it very useful. I don't think the good Robertsons invented anything really new, but I do believe that this book covers 90% of the "how to" solve requirements problems in software development.  And 90% is a lot ! The parts I appreciated more, this last time are: Chapter 12. Prototyping the Requirements  Working together to the prototype, can really take out the users' implicit knowledge, correct lapses and help in many other ways. Chapter 11. The Quality Gateway You could try put an analyst that doesn't work on the same project, to read the project's requirements and have him refuse: all incomplete or inconsistent entries, frills, etc. I think it can be a very powerful practice.