Skip to main content

Why this blog ?

Why this ?

This blog was born from an experience of 27 years of product requirements gathering.
I am neither the leading expert nor the best, I have worked with much better analysts than me.
But I made and I saw so many errors and omissions that... I am sure that many of the problems of collecting requirements are quite easily solvable.
I will try to say here how.



Comments

Post a Comment

Popular posts from this blog

Requirements takeaway

If someone should ever force me to summarize this blog in a single line, it would be: Listen carefully, be attentive and... be humble !
1 comment
More »

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.
Post a Comment
More »

"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.
Post a Comment
More »