Skip to main content

Crash course

Weeks ago I attended a course about requirements at a clients' premises, and spoke briefly as a "special guest" about my experiences in requirements gathering.
The audience was all senior people, from 10 to 30 years experience.

Which were my four cents ?

1. Be careful of the usual three pillars of chaos form the users: wrong facts, omissions and inconsistency,

2. Ask three times Why ? why ? and why ? (the first answer is never the right one),

3. The system needs 100, the users tells you he wants 90, you understand 80, you write 70 and the developer starts working on the 60 he understands,
4. There are things you do know and things you THINK you know but you don't, so
be respectful of the "monkey" user, he always know the business better than you. Be humble.
Labels:

Comments

Post a Comment

Popular posts from this blog

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!
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 »

A good book by Jim Arlow

Currently reading Jim Arlow's " Secrets of Analysis: Generative OOA with NLP, Literate Modeling and M++ ". I found it extremely interesting, first because it has a lot of extremely interesting hints and tips and emphasizes the importance of communication Second, it introduces a simple but useful meta-language, called M++, that allows to recover information from deleted, distorted and generalized communications. It is an extension of the work on language patterns by Bandler and Grinder. M++ could gives you a set of simple, powerful communication strategies that you can apply straight away in your job. M++ (and the original Meta Model) specifies how you can use language to clarify language. It deabstracts to uncover distorted, deleted and generalized information.
Post a Comment
More »