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 »

Vague requirements

An old school tip on vague requirements. A lot of words and sentences that we write in our requirements documents are often too vague . And these kind of unclear requirements have a big chance to cause problems at the end of your work. Blurred Something like: the system must be scalable , the system must be user friendly , the system must be quick . A good way to at least improve these three requirements could be something like this: 1. The system must be scalable up to 1.000 concurrent users without upgrading our servers, 2. The system must be usable by an average 50 years old accountant that only knows Word and some Excel, 3. The system must have any functinality ready on the screen  in 1" when all concurrent users are using the system. So, by just exploring a bit more with the stakeholders, you can reduce ambiguity a lot. It's not too difficult and you can have a huge improvement in the end product or service.
Post a Comment
More »