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.

Comments

Practical advices by Karl Wiegers

I am reading the beautiful book "More About Software Requirements: Thorny Issues and Practical Advice" by Karl E. Wiegers. I'd like to share with you two of the most important points of his "10 cosmic truth", that to me are #6 and #9. #6 The requirements might be vague, but the product will be specific. I would say this is the usual point of "Natura abhorret a vacuo", that is here... each gap n requirements will be filled by some bad feature. #9 The customer is not always right, but the customer always has a point. Never underrate your key users

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.

Suppliers, suppliers, suppliers

Some managers don't find the time to evaluate new suppliers, not even 10 minutes on the phone. Then they complain for weeks that they are stuck in a project that does not take off in 2 years. Because of the supplier....

REQUIREMENTS !

Search This Blog