Skip to main content

Pain in the ass people (?)


We all know that many software projects don't end up well because in the beginning phase it is not clear what will really be useful, yet there are always more job postings for Technical Analyst or Architect than for "Requirements Seekers".
Perhaps many believe that intelligent and experienced people in their field can also explain well all they need from a software application.

I don't think so, and I believe this is a very specific job.
I think we need more Socrates-like people, that is,  meticulous and sometimes "pain in the ass" persons that can really "extract"  everything they can out of those users who express their (often complicated) business needs.
Labels:

Comments

Post a Comment

Popular posts from this blog

3. Simple, Complicated, Complex... Chaos !

A few words about the different kind of systems, just so you know in which kind of trouble you are when you start gathering requirements :-) SIMPLE What it is: you can see clearly all the connections between cause and effect . How to handle it: it is usually easy. COMPLICATED What it is: there are cause - effect connections, but it's not easy to see them. There is never a unique solution. How to handle it: ask questions to the experts (if there is any). COMPLEX What it is: it is made of many pieces, and they are highly interconnected. The output is usually part of the system itself and influences it, so it's difficult even to ask yourself the right questions. How to handle it: test some small parts and see what it happens (someone calls it "dance with the system.") CHAOS What it is:  high uncertainty, no apparent cause and effect and ... when some rule seem to apply, it will probably change very rapidly. How to handle it: run away !
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 »

1. What is a Requirement ?

The word Requirement comes from the latin word Requisitum , that comes from requirĕre  «to demand, to require, to call for» and quaerĕre  «to ask, to strive for, to require». Never forget that asking a lot of questions is one of the key in understaning the real needs of your customers.
Post a Comment
More »