Alice: Oh, no, no. I was just wondering if you could help me
find my way.
Cheshire Cat: Well that depends on where you want to get to.
Alice: Oh, it really doesn't matter, as long as...
Cheshire Cat: Then it really doesn't matter which way you go.
Cheshire Cat: Well that depends on where you want to get to.
Alice: Oh, it really doesn't matter, as long as...
Cheshire Cat: Then it really doesn't matter which way you go.
The requirements are the start of it all. If there
weren’t any we would all be in the unemployment line. Without solid
requirements, the solution will never meet expectations. It’s as simple as
that. Most of the information here is common sense and industry’s best practice;
however it still gets ignored most of the time. You would be surprised at how
many systems start being designed without requirements. There are a few things
that I would like to add on top of the regular “requirements gathering”
curriculum.
There are plenty of resources on requirements
gathering and I will not attempt to explain the entire process, however here
are some common pitfalls that I have seen:
●
Requirements gathering and validation is a
very politically and fiscally challenging process. Few people realize that
there is a very direct relationship between requirements and money. Simply
said, the more you ask for, the more you will need to pay. If this is not
acknowledged, the project team needs to help the customer manage expectations.
●
Another common mistake is for incorrect
requirements, your requirement can’t be to buy product XYZ. The requirement
needs to be for a system that provides functionality A, B and C. Based on this
the project team should conduct market research and select the best product or
a combination of products to meet the requirements.
●
The requirements shouldn’t be blindly
accepted by the project team. If the information you need is not there, you
need to take a step back and get the right information. This is sometimes
difficult.
●
Nothing kills morale more than working for
weeks in one direction only to find that the requirements weren’t accurately
documented and having to shift gears.
●
Requirements are complete when all
requirements have been documented and mapped to validation criteria which in
turn map to validation scenarios. Documentation of requirements is essential
because it communicates the requirements to all parties involved. Language in
the document needs to be plain, clear and specific.
No comments:
Post a Comment